Subject: RE: [eap] Key derivation and the principle of equivalence

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 12 May 2005 22:09:07 -0700

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, May 12, 2005 12:09 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Key derivation and the principle of equivalence
> 
> I think this looks like a useful simplification of the 
> document. There may be some smaller things to think about, 
> however. For instance,
> 
> >   Within EAP, the primary function of the AAA protocol is 
> to maintain
> >   the principle of Mode Independence, so that as far as the 
> EAP peer is
> >   concerned, its conversation with the EAP authenticator, and all
> >   consequences of that conversation, are identical, 
> regardless of the
> >   authenticator mode of operation.
> >
> This seems true. Interestingly, it even seems true if one 
> imagines a fast handoff scenario where you start off from a 
> combined NAS-AAA device and handoff to another NAS.
> 
> But its also interesting to note what the text above does not 
> say. I believe peers already can learn the identities of both 
> the authenticator and the server, separately, and if channel 
> bindings are provided peers can also learn of potential 
> discrepancies among the properties claimed by the different 
> parties. Of course, such discrepancies can be learned even if 
> all of this is in the same box.
> 

[Joe] Yes, It seems that the peer (or the entity hosting the peer) can
know the identity of the of the party it is communicating with and
possibly determine that it is an EAP-Server vs. an Authenticator.
However the basic method operation and communication should be the same.
It seems a method shouldn't change its behavior if it is running on a
EAP server vs. an authenticator.  I think it is possible that context
data exported from the method may be interpreted differently by
processes external to EAP.  

> Secondly, the text does not say anything about fast handoffs 
> (and this may well be right). But in fast handoffs peer would 
> again be aware of changing identities of the authenticator 
> (even though in this case you'd not really be running EAP 
> again). And keys for this would be created slightly 
> differently. But again, the peer has no real knowledge of 
> whether he handed off to a new box or just a different part 
> of the same box.
> 

[Joe] I think it would really be good to avoid fast handoff discussion
in this part of the document. 

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 May 2005 23:12:54 -0700 (PDT)

> processes external to EAP.

I think we need to be clear about which layer learns this information.
The EAP method layer is aware of the identities provided in the
EAP-Response/Identity but according to RFC 3748 should be using its own
method-specific identities instead; these are exported as the Peer-ID and
Server-ID.  From the perspective of EAP, I think those are the only
relevant identities.

It is the EAP lower layer that is aware of the authenticator identity
because this identity is only communicated at the lower layer.  The
diagram doesn't describe the Authenticator-Identity as being passed to the
EAP method, and existing methods wouldn't make use of it, so I'm assuming
that the EAP method doesn't obtain this or care about it.

The authenticator identity is important to the lower layer because it uses
that information to organize its key cache and figure out whether it
already has keying material relating to a particular authenticator or not.

> in this part of the document.

Right.  I think the focus is to clearly articulate how things work and
what the constraints are.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 May 2005 10:32:46 +0300

>that the EAP method doesn't obtain this or care about it.
Yes, you are right. The EAP method may in some cases
transport information about these, but if it does, it should
do it so as opaque data.

--Jari