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

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 7 Oct 2005 09:01:20 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, October 06, 2005 10:36 PM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: RE: [eap] Re: Rewrite of Section 2 of the EAP Key 
> Management Framework
> 
> > - I am not sure that a lower layer MUST NOT export keys 
> passed down by 
> > EAP methods to other lower layers.  It should at least be 
> possible for 
> > a lower layer to export keys derived from keys passed down by EAP 
> > methods to other lower layers.
> 
> The problem with sharing keys between media is that it 
> creates cascading vulnerabilities.  If one media has a weak 
> ciphersuite that results in key compromise, then if keys are 
> shared between media, this could result in compromise of a 
> key used on another media with a strong ciphersuite. 
> 
> At IETF 62, Sam Hartman brought up this point. 
> 
> The one exception to this is AAA, which shares keying 
> material received by the AAA client with the EAP authenticator. 
> 

[Joe] I agree that the same key should not be used for two different
purposes, however it should be possible for an implementation of a
"lower layer" to use a key to derive keying material to be used within
it's domain of applicability.  These derived keys may actually be used
by different entities.  Here is a possible revision to clarify this:

" In order to preserve separation of keying material and security
considerations fort lower layers separate,
   lower layers MUST NOT export keys passed down by EAP methods outside
their domain of control.  This implies that EAP keying material or
parameters passed down to a lower layer are for the exclusive use of
that lower and MUST NOT be used within another lower layer for a
different purpose."

> > - The EMSK MUST NOT be exported to a lower layer.  AMSKs 
> derived form 
> > the EMSK may be exported.
> 
> The EAP method calculates the EMSK and exports it.  Methods 
> do not calculate AMSKs.  The EAP layer cannot know whether 
> the lower layer will calculate AMSKs or not.  So the EAP 
> layer really has no choice but to pass the EMSK down to the 
> lower layer. 
> 

[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.  I also don't think it is appropriate to call AAA a lower layer
as it is a bit confusing and a special case.  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.  When there is AAA involved this
distribution layer uses the AAA protocol between the AAA server and AAA
client.  When there is no AAA involved then the distribution layer is
local between the EAP implementation in the lower layer.  The
distribution layer may help clarify the above exception to lower layers
and exported key material. 

> On the other hand, I think it makes sense to say that AAA 
> MUST NOT transport the EMSK, or that the EAP peer or 
> authenticator MUST NOT use the EMSK directly.  It also makes 
> sense to say that existing lower layers (including AAA) do 
> not cache the EMSK. 

[Joe] I agree with this. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 07 Oct 2005 13:01:00 -0700

Here is a possible revision to clarify this:

>" In order to preserve separation of keying material and security,

This looks good.

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

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.

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

>I think between the
>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.

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.

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

---

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

Salowey, Joe wrote

>that lower and MUST NOT be used within another lower layer for a
I'm not sure this is precise enough. What does "domain of
control mean"? That I can pass the key from WEP to something
else, as long as I own all devices? Hopefully not... And "lower
layer" is not precise either. Unfortunately, I'm not sure I
have better text to propose!

--Jari