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

[Jari Arkko (jari.arkko]

Salowey, Joe wrote:

> [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.
>  
Perhaps we could move forward on the AMSK/EMSK issue
by looking at the constraints we are under:

o  RFC 3748 model, which I don't think we want to change
o  Desire to reserve EMSK for future uses, including uses
   that involve multiple devices (NASes)
o  Desire to keep different uses cryptographically separate
   from each other
o  Desire to avoid API and method changes

We can also think about our goals with eap-keying vs.
keying-extns. Are we specifying the way to get AMSKs
or just the branching of the tree as a "reservation" for
future use of AMSKs? If the latter, then we don't need to
design the specifics of how AMSKs are accessed.

So, one suggestion would be to say that (1) EMSK is
exported from EAP methods, (2) EMSK shall not leave
the device where it is derived, (3) AMSKs can be derived
from EMSK and they can leave the device, (4) AMSK
calculation rules ensuring cryptographic separation,
and (5) the actual requests to create AMSKs and the
applications are out of scope for eap-keying.

--Jari