Subject: RE: [eap] Re: Rewrite of Section 2 of the EAP Key Management Framework

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 19 Oct 2005 14:27:14 -0700

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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Oct 2005 00:31:25 +0300

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 19 Oct 2005 15:13:39 -0700

>about AMSK/EMSK as possible unless we want to take on the full task.

I agree. 

>what we have already defined.

RFC 3748 already defines the EMSK and specifies that it needs to be exported
by the EAP method. 

>a statement like the following (I'm not sure where it goes yet):

While I agree that we should not be adding material relating to the EMSK, we
do have to be consistent with RFC 3748, which states that the EMSK is
exported by EAP methods.  This means that the EAP peer/authenticator layer
(and presumably the EAP layer) will receive the EMSK.  

My current proposal is to state that the EMSK is passed down to the EAP
peer/authenticator layer and EAP layer, but is never passed down to the
lower layer, although keys calculated from the EMSK can be passed down to
the lower layer if requested by the lower layer, as long as the EMSK itself
is not exposed. 

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

I think that some language specifying that the lower layer never receives
the EMSK, or quantities from which the EMSK can be derived should do the
job.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap