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

[Bernard Aboba (bernard_aboba]

Here is a possible revision to clarify this:

> " In order to preserve separation of keying material and security,
> lower layers MUST NOT export keys passed down by EAP methods outside
> their domain of control.  This implies that EAP keying material or
> parameters passed down to a lower layer are for the exclusive use of
> that lower and MUST NOT be used within another lower layer for a
> different purpose."

This looks good.

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

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.

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

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

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.

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