Re: [Cfrg] ISE seeks comments on: draft-cakulev-ibake-02.txt

[David Wagner <[e-mail]>]

[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.