Subject: [eap] comments on draft-ohba-aaakey-binding-01

From: Jari Arkko <[email-masked]>
Date: Sat, 16 Jul 2005 20:55:13 +0300

Thanks for writing this draft, Yoshihiro. I like your scheme
very much. Its simple and effective.

A couple of questions and comments for further discussion,
however.

1. As far as I can determine, it looks like the security level of
   this scheme is equivalent to what draft-arkko-eap-service-identity-auth
   or draft-tschofenig-eap-ikev2 can provide. Is this also your 
understanding?
   Or what can you say about the differences?

   (I'm primarily thinking of the case where EAP server and
   authenticator are in separate administrative domains. And I'm
   excluding the difference that is discussed in the next bullet.)

2. The security considerations say

  "The solution described in this document improves the security
   characteristics of the EAP key management framework in that a secure
   association is never established if there is a difference in EAP
   lower-layer parameters recognized by the EAP peer and the EAP
   authenticator.  This is in contrast to existing parameter binding
   methods described in [I-D.arkko-eap-service-identity-auth]
   [I-D.tschofenig-eap-ikev2] in which an EAP peer can still establish a
   secure association even when a mismatch in EAP lower-layer parameters
   is detected by the EAP peer, as the EAP peer can ignore the mismatch
   and continue the EAP conversation to succeed."

   This is true, but I guess its to some extent dependent on what
   the specifications will say. If they say "MUST check and MUST fail
   the authentication if the check fails", then the result is similar.
   Nevertheless, in your scheme even a bad (or malicious) peer
   implementation could not continue, because it doesn't have the
   right key.

3. The draft says...

  "Each EAP lower-layer must define a blob that is an octet-string used
   for carrying lower-layer parameters that need to be bound to the AAA-
   Key. Such a blob is referred to as a "key-binding-blob".  A key-
   binding-blob contains parameters that persist long-term such as the
   identification of the EAP authenticator.  It is the responsibility of
   each EAP lower-layer to define how the EAP lower-layer parameters are
   encoded in the blob."

  Why is this necessary? Of course, the blob needs to be agreed upon
  on both sides, but presumably one could (a) send it or (b) define
  how it is derived from already exchanged lower layer parameters.
  But I may be missing something... I'd like to know how hard it would
  be to define this for something that is already widely deployed
  like 802.11.

4. Deployment implications. Am I correct in saying that the
    implications for existing systems are different in the aaakey
    and eap channel binding approaches? For the aaakey
    case we need either modification (a) from above, or at
    least some new code to calculate the blob according to
    the procedure (b). In either case, new access points are
    needed. Presumably some code changes in peers and
    servers are needed too, to make it possible to use the
    new types of keys and to verify them. No changes to
    EAP methods or credentials are needed.

    For the channel binding case, a change is needed in the
    peers and servers to adopt a channel-binding EAP method;
    presumably the same credentials can still be used, however.
    Depending on how ambitious channel bindings are desired,
    the access points may or may not need to be changed. Basically,
    if existing AAA attributes are sufficient, then no changes are
    needed. However, if new attributes are needed then new
    access points are needed. The lower layer protocol is never
    changed, however.

    Is this analysis correct?

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Jul 2005 13:17:48 -0400

> very much. Its simple and effective.

Thank you Jari for your encouraging comment.

>   or draft-tschofenig-eap-ikev2 can provide. Is this also your 

Yes, that is my understanding.

>   the authentication if the check fails", then the result is similar.

Yes, I think so.

>   implementation could not continue, because it doesn't have the

This is true, and I think this applies to server implementation also.

>  be to define this for something that is already widely deployed

For example, in the case of 802.11, I think at least SSID needs to be
carried in key-binding-blob.  Then, some document (defined in IEEE
802.11 or IETF) would be needed to specify it.  If there is no rule as
to which lower-layer parameters are included in key-binding-blob and
the format used when they are included in the blob, it will end up
with generating diffferent AAA-Keys between the EAP peer and EAP
authenticator.

>    needed. 

Yes.

> Presumably some code changes in peers and
>    new types of keys and to verify them. 

Yes.

> No changes to

Yes.

>    access points are needed. The lower layer protocol is never

Yes, I think so.

>    Is this analysis correct?

Yes, I have the exactly same view as yours.

Best regards,

Yoshihiro Ohba