[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] ISE seeks comments on: draft-cakulev-ibake-02.txt
From:       "Jim Schaad" <ietf () augustcellars ! com>
Date:       2010-10-22 23:15:49
Message-ID: 003001cb723f$14367350$3ca359f0$ () augustcellars ! com
[Download RAW message or body]

This document, if published, would be strictly as an informational draft.
It is not on standards track in any way.

Jim

> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
> David Wagner
> Sent: Tuesday, October 19, 2010 12:40 PM
> To: cfrg@irtf.org
> Subject: Re: [Cfrg] ISE seeks comments on: draft-cakulev-ibake-02.txt
> 
> [I tried sending this two weeks ago, but it never seems to have hit the
list.  I
> apologize for any duplicates anyone may receive.
> This is regarding draft-cakulev-ibake-02.txt.]
> 
> draft-cakulev-ibake-02.txt's abstract says:
> >   "Cryptographic protocols based on public key methods are based on
> >    certificates and large scale public key infrastructure (PKI) to
> >    support certificate management.  The emerging field of Identity Based
> >    Encryption protocols allows to simplify the infrastructure
> >    requirements via a Key Generation Function (KGF) while providing the
> >    same flexibility.  However one significant limitation of Identity
> >    Based Encryption methods is that the KGF can end up being a de-facto
> >    key escrow server with undesirable consequences.  Another observed
> >    deficiency is a lack of mutual authentication of communicating
> >    parties.  Here, Identity Based Authenticated Key Exchange (IBAKE)
> >    Protocol is specified which does not suffer from the key escrow
> >    problem and in addition provides mutual authentication and a perfect
> >    forward and backwards secrecy."
> 
> Here are my notes, after a quick informal review:
> 
> I don't immediately see any practical advantage over standard PKI.
> IBAKE doesn't seem to address the hard problems or limitations of PKI.
> The practical limitations of PKI mainly arise from the way it is used in a
larger
> system, not from the crypto-mathematics themselves.  (See, e.g., writings
from
> Peter Gutmann, Carl Ellison, or Bruce Schneier.) I don't see how IBAKE
changes
> the game in any significant way.
> 
> For instance, IBAKE "assumes that the Initiator and the Responder trust a
third
> party" (the key generator).  If it's acceptable to trust a third party,
then one
> could equally well trust a Certificate Authority.  I do not see how IBAKE
> simplifies the management, revocation, authorization, or other issues
> associated with standard PKI.  I see no advantage here.
> 
> The Internet-Draft claims that by making the keys date-dependent, IBAKE
can
> address key revocation.  But as far as I can see, PKI can support a
similar
> functionality by issuing certificates with appropriately chosen expiration
dates.
> In either case, the requirement for tighter time synchronization may have
some
> practical consequences.
> 
> Some technical comments (many are nitpicky or at least addressable):
> 
> * I have questions about the security of this protocol.  It does not
>   come with a proof of security, which is the accepted standard for new
>   proposals of this sort.  The scheme has apparently not been previously
>   published in an appropriate peer-reviewed scientific conference.
> 
>   I will illustrate some examples of specific potential concerns, which a
>   proof of security would put to rest.  The IBAKE protocol uses encryption
>   to authenticate the parties, and relies upon the encryption to bind
>   various plaintext entities securely to each other, which requires
careful
>   analysis (for instance, if the encryption method is malleable, then
>   various active attacks may be possible, so any proof of security would
>   need to account for this, implicitly or explicitly).  As another
example,
>   Message_1 and Message_3 have the same format, raising the possibility of
>   cut-and-paste attacks that copy an intercepted Message_1 and introduce
>   it as Message_3, or vice versa (any proof of security would need to
>   demonstrate, either implicitly or explicitly, that this cannot cause
>   any problems).  As a third example, the protocol specification does
>   not explicitly specify that, after decrypting, each party should check
>   that the identities in the decrypted plaintext match what is expected.
>   It's not obvious whether this might have any security consequences;
>   a proof of security would address that concern.  These examples are not
>   intended to be exhaustive, and the main value of a proof of security is
>   that it addresses even concerns we may not have anticipated (as opposed
>   to solely those concerns that we were able to identify in advance).
> 
> * The protocol specification does not require the parties to check
>   that the elliptic curve points they receive are indeed elements of
>   the curve and members of the group.  I wonder if this has any
>   consequences.  Can a malicious Initiator achieve anything interesting
>   by sending a value of xP that is not actually on the curve?
> 
> * The security analysis doesn't make explicit the consequences
>   of active man-in-the-middle attacks, where the attacker colludes with
>   the KGF (or compromises the KGF).  The security analysis says it is
>   assumed this will not happen.
> 
> * The protocol specification could provide stronger guidance on the
>   choice of x and y.  It says that they should be random and seems to
>   assume they will be chosen anew for each session, but it might help to
>   specify explicitly for implementors that they must be chosen anew for
>   each session.  If the Responder re-uses y for multiple sessions with the
>   same Initiator, then it becomes possible for an active attacker to
replay
>   past sessions, fooling the Initiator into thinking that he is talking
>   with the Responder when he is actually not.  If the Responder's message
>   is a non-idempotent command to the Responder, these replay attacks could
>   be problematic.  The Internet-Draft could clearly state that no value
>   of x,y may ever be reused across sessions, not even in a new session
>   with the same (Initiator,Responder)-pair.
> 
> * The protocol does not describe how messages are associated with
>   or bound to a particular session.  There is no session ID.  The
>   Internet-Draft does not discuss issues such as concurrent session
>   establishment.
> 
> 
> Overall, it seemed to me that the IBAKE Internet-Draft did not make a
> compelling argument for IBAKE, and I felt that its comparison of PKI vs
IBAKE
> was unconvincing.  Even if the technical issues listed above were
addressed, I
> feel that the failure to articulate a clear advantage over standard PKI
would be
> sufficient to prevent advancement of this Internet-Draft.
> 
> Therefore, if I have understood the situation accurately, I do not
recommend
> that this Internet-Draft be advanced for standardization.
> 
> Caveat: This is based upon a quick look at the I-D.  There may well be
> significant errors or oversight in my analysis, for all I know.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]