eap Mailing List: RE: Re: Rewrite of Section 2 of the EAP Key Management Framework

[Salowey, Joe (jsalowey]

> >[Joe] Perhaps methods should deal with derivation of AMSKs.  I don't 
> >think it is appropriate for the EMSK to be passed down to any lower 
> >layer.
> 
> RFC 3748 describes the export of the EMSK by EAP methods.  
> Since the EAP layer does not cache keys and needs to maintain 
> lower layer independence, when it obtains the EMSK from the 
> method, it can't know that a given lower requires an AMSK 
> unless the lower layer specifically indicates that it needs 
> an AMSK and provides all the parameters to calculate it.  Are 
> you suggesting that there is an interface between the lower 
> layer and EAP layer, indicating what keys are to be passed 
> down to the lower layer?

[Joe] Yes, I think there needs to be an interface between the lower
layer and some EAP layer to indicate which AMSKs are needed.  

> 
> One question is how such an interface would work within the 
> EAP layering 
> model described in RFC 3748, Figure 2.   One hypothesis is 
> that the lower 
> layer on the EAP authenticator can indicate to the EAP layer 
> what types of keys it needs.
> 

[Joe] Yes, this is along the lines of what I was thinking.  The lower
layer determines what keys it needs. 


> >I also don't think it is appropriate to call AAA a lower 
> layer as it is 
> >a bit confusing and a special case.
> 
> RFC 3748 Figure 2 shows a picture of EAP with AAA/IP 
> functioning as an EAP lower layer.  For the purposes of EAP 
> key management,  a AAA lower layer interacts with the EAP 
> layer the same as any other lower layer, no?
> 
> For example, doesn't AAA receive the same keys from the EAP 
> layer as any other lower layer?  It might be able to do 
> things that other lower layers can't (like replicating keys 
> between entities) but that is a separate issue.
> 

[Joe] A lower layer should not have access to the EMSK.  Perhaps in
general AAA shouldn't either if it is treated just as a lower layer.
The AAA is also typically not using the key material but is rather
transporting it.  AAA may be separate from some other part of the system
that handles the EMSK and related derivations. 

> >I think between the
> >EAP-Server and EAP-Authenticator is a key distribution (or perhaps 
> >parameter distribution) "layer" which controls the distribution (and 
> >perhaps derivation) of keys.
> 
> AAA can handle the derivation of keys, just like any other 
> lower layer.   
> Key transport is a special property of AAA, though.
> 

[Joe] I don't think that lower layers should be deriving keys from the
EMSK.  

> If you look at figure 2 of RFC 3748, it shows the EAP 
> authenticator, with one interface having a conventional EAP 
> lower layer, and the other interface having a AAA lower 
> layer, with EAP packets being routed between interfaces.
> 
> Presumably the AAA packet that carries EAP packets also 
> carries the keys, and one question that arises is whether the 
> keys travel the same path that the EAP packet does or not.  
> If so, then the AAA-transported keying material gets passed 
> down into the lower layer the same way as locally generated 
> keys do.  Since the EMSK is not replicated, this would imply 
> that an AMSK needs to be passed down to the lower layer, not the EMSK.
> 

[Joe] Yes, I think here we are in agreement that the AMSK should be
passed down and not the EMSK.  

> >When there is no AAA involved then the distribution layer is local 
> >between the EAP implementation in the lower layer.
> 
> The EAP layer sits on top of the lower layer, so I'm not sure 
> where a "distribution" layer would fit in.
> 

[Joe] In this case the distribution is through a locally defined
mechanism it may be in the same process or use some IPC mechanism.