eap Mailing List: RE: Key derivation and the principle of equivalence

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Thursday, May 12, 2005 11:13 PM
> To: Salowey, Joe
> Cc: Jari Arkko; eap [at] frascone.com
> Subject: RE: [eap] Key derivation and the principle of equivalence
> 
> > [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.
> 
> 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.
> 

[Joe] Agreed, these are the authenticated 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.
> 

[Joe] So I don't know that the authenticator identity is ever dealt with
by EAP at all.  It seems to be the server that is authenticated within
EAP.  This should exported out of a method so a lower layer could use it
for authorization.  A lower layer could also associate capabilites with
a server identity as well.