eap Mailing List: RE: Eap keying review: use of MSK/ EMSK for AMSK creation

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Tuesday, November 01, 2005 12:20 PM
To: Nakhjiri Madjid-MNAKHJI1; aboba [at] internaut.com
Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
Subject: RE: [eap] Eap keying review: use of MSK/ EMSK for AMSK creation

>Section 2.2. of EAP keying 08 prohibits sending EMSK down to the lower 
>layer (section 2.2).

Right.  This restriction was added in response to a comment which
pointed out that sending the EMSK to the lower layer violated the
principle of Mode Independence, since this would mean that the
authenticator lower layer could obtain the EMSK in "stand alone" mode,
but not in "pass-through" mode (since the EMSK cannot be transported).

Madjid>>If I understand the mode independence, it means that the EAP
method layer function is independent of existence of pass-through. For
authentication, this makes sense. However, for key management I think it
is a stretch. We are saying MSK and EMSK are generated through a
method-dependent logic. Why would the EAP method layer care whether the
keys are being sent down or not? The mode-independent notion of
"authenticator" is the EAP server, not the pass-through, so whether you
physically 3 parties or two parties, the EMSK could be pushed to the EAP
server in either case. Aren't we mixing export and transport? Export is
vertical in the layers, while transport is between boxes (at least in a
pass-through model). I was really talking about export and that is why I
was asking for a spelled out definition of export.

>I assume "lower layer" includes AAA layer (even though 3748 section
2.2.
>does not include AAA as a lower layer, even though 3579 is dated before

>3748).

RFC 3748, Figure 2 includes a diagram in which AAA operates as an EAP
lower layer.

Madjid>>I understand, I was just noting the lack of consistency in the
specs. We are really down to hair splitting in the application of these
drafts in other SDOs.

>So this prohibits the AAA server to take EMSK and create new keys
>(AMSKs) for new applications or services.  This means the EAP layer 
>must itself authorize each service application and calculate any AMSK 
>that are needed for that application.

The implication is that the EAP layer is creating AMSKs in response to
requests from lower layers (including AAA).  Also note that the EAP
layer is transforming the Method-ID into a Session-ID.  So the document
is outlining a role for the EAP layer as something of a "security
policeman", something which is not described in RFC 3748.

Madjid>> This means EAP layer needs to get into creating keys for any
other application. People have already suggested AMSKs for Mobile IPv6,
do we want EAP to handle all that? It really should be AAA.

However, I don't think this necessarily extends to adding authorization
to the EAP layer.  My understanding was the the EAP layer does not
examine the AMSK request, it just honors it.

Madjid>> so it means EAP layer acts as a very generous AAA server. Also
it means EAP needs to keep EMSK and generates AMSKs from whatever
application that asks for it. 

>Not only we are including a role of
>authorization into an EAP server, but also we are saying the EAP layer 
>must anticipate all applications that need to derive their keys based 
>on the EAP keying process. Should not be the AAA server to make 
>authorization decisions and generate keys for the services accordingly 
>(say a master key for an access technology or a master key to provide 
>handover support)?

Well, that is what the document had said prior to the change being
applied in response to the comment.  In some ways leaving AMSK
generation to the lower layer is cleaner, because it does not add
functionality to the EAP layer, which is typically just thought of as a
"switch" in RFC 3748 and RFC 4317.  However, there is the issue that
this violates "Mode Independence".

>Furthermore in section 2.3 under AAA, a "AAA layer" is mentioned and it

>says, the AAA layer must delete an MSK that has been transported to the

>authenticator.

The requirement is actually that *any* transported key be deleted.  This
would apply to more than just the MSK -- if an AMSK were transported, it
also would need to be deleted.  This is required in order to fulfill the
basic security goal, which is that the TSKs are known only to the EAP
peer and authenticator.  If transported keys are left on the AAA server,
then the AAA server also has knowledge of the TSKs.

Madjid>> Well, lets pause and see how practical that is. If TSKs are
generated based a nonce-exchange between the peer and the authenticator,
the AAA server would really have to have a sensor to listen in on the
link. Even if it did, what is the trust issue with AAA server knowing
the keys. What is the threat?
So I don't understand that requirement on the AAA server, why would a
key transported from AAA server must be deleted?

Problems:
>1) The EAP RFC does not distinguish between authenticator and 
>authentication server (the EAP server).

The way to read this is that the document is specifying the behavior of
the AAA layer with respect to key  handling.  This is not inherently a
violation 
of the principle of "Mode Independence".   For example, it is not 
incompatible to say that existing AAA servers don't cache keys while
reviewing key caching behavior of IEEE 802.11i.

Madjid>>Still not convinced that some implementation of AAA server for
802.11i should be the base for such a strong requirement.

>So EAP RFC does not really talk about MSK transport. We are now saying 
>MSK and AAA key are >the same

In RFC 4072 (an IETF Proposed Standard) the keying attribute is called
"EAP-Master-Session-Key" rather than "AAA-Key" This choice (which I
think was quite wise) was made in order to make sure it is very clear
what key is being referred to.  Going forward, there may be more than
one key involved (MSK, AMSKs, etc.), so that talking about a "AAA-Key"
is very problematic.  
If it is necessary to transport AMSKs, it is probably best if a specific
attribute is created for this purpose (e.g. 
EAP-Application-Master-Session-Key), so as to be able to distinguish
different kinds of keys and keep confusion to a minimum.

Madjid>>Yes, unfortunately, RADIUS does not have that, I was hoping that
Glen's key wrapping draft would fill that gap, not sure what is
happening with that.
And yes on the "AAA-key" being problematic. I think adding the AAA-key
notion into the EAP keying draft is only confusing. I think this draft
should only focus on MSK/ EMSK and provide more guidance on the whichs
and hows of the transport of these keys. I understand if EMSK is not
supposed to be transported, but I am debating for allowing to export it
to EAP lower layer to allow that layer to decide on authorization,
calculation and transportation of AMSK.

>to the authenticator (which btw is not recognized in 3748)

The term "authenticator" is both defined and used in RFC 3748.

Madjid>> what I meant was authenticator as pass-through, not as server
is not recognized in 3748

>EAP layer should really not care about (AAA should deal with that)?
>It seems that even when we are talking about method independence, 
>algorithm independence and lower layer independence, we are building an

>application dependence in the EAP layer.

It would indeed be unfortunate to create an "application dependence" in
the EAP layer.  However, I'm not sure that AMSK proposal does that,
necessarily.  If all the EAP layer does it take parameters from the
lower layer to create AMSKs, and then unconditionally carry out the
lower layer's instructions, then I think the mechanism could be quite
general.

Madjid>> Yes, I agree, but prohibiting EMSK export will make application
dependence very hard.