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

[Jari Arkko (jari.arkko]

Yes. This is alternative 1 from my previous e-mail.
The other alternative is that we also specify how
AMSKs are cryptographically calculated based on
f(EMSK, AMSKid), but leave the definition of how
this could be used for purpose X to keying-extns.

--Jari

Salowey, Joe wrote:

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