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

[Salowey, Joe (jsalowey]

I think in the current document it might be wise to document as little
about AMSK/EMSK as possible unless we want to take on the full task.
Making use of the EMSK will probably require some changes/extensions to
what we have already defined.  

In the document we should not show the propagation of the EMSK and have
a statement like the following (I'm not sure where it goes yet):

"The EMSK is reserved for future usage.  The EMSK itself should have
limited exposure outside the EAP method.  Instead of using the EMSK
directly keys should be derived for application specific usage.  This
usage and specification is beyond the scope of the current document."

Jari Arkko wrote:
> 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