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

From: "Salowey, Joe" <[email-masked]>
Date: Sun, 9 Oct 2005 20:48:23 -0700

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

[Joe] Yes, I think there needs to be an interface between the lower
layer and some EAP layer to indicate which AMSKs are needed.  

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

[Joe] Yes, this is along the lines of what I was thinking.  The lower
layer determines what 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.
> 

[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.
The AAA is also typically not using the key material but is rather
transporting it.  AAA may be separate from some other part of the system
that handles the EMSK and related derivations. 

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

[Joe] I don't think that lower layers should be deriving keys from the
EMSK.  

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

[Joe] Yes, I think here we are in agreement that the AMSK should be
passed down and 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.
> 

[Joe] In this case the distribution is through a locally defined
mechanism it may be in the same process or use some IPC mechanism. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Oct 2005 18:29:03 +0300

>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

---

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

>by looking at the constraints we are under:

I presume that you're talking about a future document, not the current key
framework document, right? 

As I see it, we really only need to do a few things in the key framework
document:

a. Define the interactions between the EAP method layer, EAP
authenticator/peer layer, EAP layer, and lower layer (including AAA).

b. Define the EAP security model (e.g. the cryptographic assumptions). 

c. Derive the security requirements for the lower layer based on a) and b).

d. Describe how current implementations behave (including lower layers). 

If we've do these things, then we can always build on that in future
documents.   However, it has turned out to be difficult enough to accomplish
just these goals that taking on even more probably will make it even more
difficult to finish. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

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

My e-mail was a response to the discussion you and Joe
had about Joe's comments to 2.6. I agree that we want
to keep eap-keying as small as possible. But I think
the practical alternatives are saying that the key
hieararchy ends at EMSK (and leave rest of keying-extns)
or that the hieararchy ends at AMSK (and leave all applications
of AMSKs to keying-extns). I'd prefer the latter, but
I could be persuaded to go for the former, too.

--Jari