Subject: [eap] Eap keying review: use of MSK/ EMSK for AMSK creation

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 1 Nov 2005 12:50:07 -0500

Hi Bernard,

I did some more reading in the 08 doc, and I am trying to put all the
pieces of the puzzle together. 

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

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

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. Problems: 
1) The EAP RFC does not distinguish between authenticator and
authentication server (the EAP server).
2) The EAP RFC does not specify an MSK transport process. It says that
AAA key and MSK are a lot of times the same, but it also says:

   "This specification does not provide detailed guidance on how EAP
   methods derive the MSK and EMSK, how the AAA-Key is derived from the
   MSK and/or EMSK, or how the TSKs are derived from the AAA-Key."

It only talks about an optional process of AAA transport

"[d] A AAA-Key derived from the MSK and/or EMSK negotiated between the
       peer and authentication server MAY be transmitted to the
       authenticator.  Therefore, a mechanism needs to be provided to
       transmit the AAA-Key from the authentication server to the
       authenticator that needs it.  The specification of the AAA-key
       derivation, transport, and wrapping mechanisms is outside the
       scope of this document.  Further details on AAA-Key Derivation
       are provided within [KEYFRAME]."

So EAP RFC does not really talk about MSK transport. We are now saying
MSK and AAA key are the same and then lets pass (MSK instead of AAA-key)
to the authenticator (which btw is not recognized in 3748) and then dump
MSK both at the EAP server and AAA server. The EMSK does not go down to
AAA layer either. So I am really trying to figure out how we can have a
practical way of creating AMSKs for applications that 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.

Regards,

Madjid

<Snips for Bernard's email: >

 The definitions are copied from [RFC3748] without modification.  Note
that [RFC3748] does include the term "export".  See Section 1.2: 

   Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.

   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is reserved for
      future uses that are not defined yet.

Given the above definition, the lower layer does not "create" the
AAA-Key; it is passed down to it from the EAP Method.  There has been
some discussion as to whether the lower layer "creates" AMSKs after
receiving the EMSK from the EAP layer, or whether the EAP layer keeps
the EMSK secret from the lower layer and calculates AMSKs from the EMSK
based on a request from the lower layer
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 01 Nov 2005 10:20:13 -0800

>Section 2.2. of EAP keying 08 prohibits sending EMSK down to the lower

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

>does not include AAA as a lower layer, even though 3579 is dated before

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

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

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.

>Not only we are including a role of

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

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

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

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

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

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

>EAP layer should really not care about (AAA should deal with that)?

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.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 01 Nov 2005 10:55:57 -0800

I would like to point out one other consequence of preventing lower layers 
(including AAA) from accessing the EMSK.  It appears to me that this 
severely restricts implementation of a key cache on the AAA server.

1. We've talked about deletion of transported keys from the AAA server.  So 
if an MSK (or AMSK) is calculated within the AAA layer and subsequently 
transported, that key is destroyed and cannot be cached.

2. We've talked about how the EMSK cannot be passed down to the lower layer 
(including AAA).  Therefore the EMSK also cannot be cached by the AAA layer.

3. Given 1) and 2) what keys *can* be cached in the AAA layer?  Limited 
answers appear to be available.  Caching of MSKs does not make much sense, 
even if they are not transported in a particular application, because some 
applications *do* transport MSKs.

It would be possible for the AAA layer to request more than one AMSK, then 
cache the AMSKs that are not transported.

However, this approach does not appear to enable implementation of schemes 
such as "Key Request" and "Pre-emptive Key Distribution", both of which 
appear to require the AAA layer to calculate AMSKs *on demand*.

To be able to do this, it would seem like the AAA server would need to have 
access to the EMSK -- since the EAP layer doesn't cache EMSKs, how else 
could AMSKs be calculated once EAP authentication completes?  In the case of 
roaming systems it is not feasible to ask the EAP layer to calculate every 
conceivable AMSK that could be useful -- there could be thousands of them.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Nov 2005 22:40:54 +0200

Bernard Aboba wrote:

> I would like to point out one other consequence of preventing lower 
> layers (including AAA) from accessing the EMSK.  It appears to me that 
> this severely restricts implementation of a key cache on the AAA server.
>
> 1. We've talked about deletion of transported keys from the AAA 
> server.  So if an MSK (or AMSK) is calculated within the AAA layer and 
> subsequently transported, that key is destroyed and cannot be cached.

 From what I can recall, our earlier discussions about this focused on
the MSK. I'm not sure the same should apply on AMSKs, particularly
when we haven't defined what they are used for.

> 2. We've talked about how the EMSK cannot be passed down to the lower 
> layer (including AAA).  Therefore the EMSK also cannot be cached by 
> the AAA layer.

This I still think should apply.

>
> 3. Given 1) and 2) what keys *can* be cached in the AAA layer?  
> Limited answers appear to be available.  Caching of MSKs does not make 
> much sense, even if they are not transported in a particular 
> application, because some applications *do* transport MSKs.
>
> It would be possible for the AAA layer to request more than one AMSK, 
> then cache the AMSKs that are not transported.
>
> However, this approach does not appear to enable implementation of 
> schemes such as "Key Request" and "Pre-emptive Key Distribution", both 
> of which appear to require the AAA layer to calculate AMSKs *on demand*.
>
> To be able to do this, it would seem like the AAA server would need to 
> have access to the EMSK -- since the EAP layer doesn't cache EMSKs, 
> how else could AMSKs be calculated once EAP authentication completes?  
> In the case of roaming systems it is not feasible to ask the EAP layer 
> to calculate every conceivable AMSK that could be useful -- there 
> could be thousands of them.

I think the answer lies in where the hierarchy is split. I still believe
EAP server should hold to EMSK and calculate AMSKs on demand.
But it seems possible to hand keys to lower layers (e.g. AAA server
side logic) that are themselves branching of to number of subkeys.
E.g. "the master handoff key for session xyz". The entity holding
such an AMSK can then branch it to, e.g., "the i:th handoff key
for NAS abc". There's a lot of room to do various designs, including
proxy, AAA-server etc. based caching.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 01 Nov 2005 13:43:06 -0800

>when we haven't defined what they are used for.

The principle is a general one -- if a key that is transported is to be  
used for derivation of TSKs that are only to be known to the EAP peer and 
authenticator who need to be able to mutually authorize each other, then 
that same key cannot also continue to be held by the  AAA server.   If the 
AAA server continues to hold the key, then the TSKs will also be known by 
the AAA server;  also, the peer cannot know whether the entity proving 
possession of keying material is the EAP authenticator, or an imposter such 
as the AAA server.

As an example, the Secure Association Protocol relies on mutual proof of
possession of keying material to enable the EAP peer and authenticator to
determine that they are mutually authorized.  If the keying material used
for proof could also possessed by other parties then mutual
authorization is not demonstrated -- the EAP peer could be talking
to the AAA server or a proxy instead of the EAP authenticator.

As a result, without key deletion, the EAP peer and authenticator no longer 
demonstrate authorization; neither the transported keys nor the derived TSKs 
are uniquely held;  the scope of
transported keys and TSKs is undefined; even Channel Bindings become open to 
forgery.  About the only thing that can still be asserted about the exchange 
is that the TSKs are fresh -- although it's questionable how valuable this 
is if the other properties are absent.

>proxy, AAA-server etc. based caching.

Right.  I think this solves the problem.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Nov 2005 09:40:11 +0200

Bernard Aboba wrote:

> The principle is a general one (snip)
>
> As a result, without key deletion, the EAP peer and authenticator no 
> longer demonstrate authorization; neither the transported keys nor the 
> derived TSKs are uniquely held;  the scope of
> transported keys and TSKs is undefined; even Channel Bindings become 
> open to forgery.

I could be missing something obvious, but I'm not sure the above
is true if we look at the details. Not all keys are created equal...
Secure Association Protocol runs on MSKs, so a compromise of
an AMSK form the same session could not compromise Secure
Association Protocol or the MSK, given that we already require
that these keys are cryptographically separate.

Similarly, if the usage of AMSK_1 in application 1 is compromised,
this does not lead to a compromise of AMSK_2 in application 2.

However, what we DO want to ensure is that if AMSKs are used
for a fast handoff design, then in that particular design
the Secure Association Protocol can still demonstrate
mutual proof of possession. This may not be trivial, but
I would note that we do not have a proposal on the table
for this, so the issue seems Someone Else's Problem from
the point of view of the EAP keying framework document.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 2 Nov 2005 18:10:18 -0800

Bernard,

> are uniquely held;  the scope of

I am missing one thing here. Even if we specify that the keys SHOULD be deleted
after it is transported, how do you prevent a mis-behaving AAA server that does
not follow this. In other words, if there are mis-behaving/erroneous AAA servers
out there, there is no way the peer can find out. Does this mean the peer can
never be sure who he is talking to ? 

-mohan

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 02 Nov 2005 21:48:59 -0800

>never be sure who he is talking to ?

Actually, the peer does have a mechanism for determining whether keys have 
been spread beyond their intended scope.  This is handled by the explicit 
identification of the parties involved in the key exchange, and by mutual 
authentication, and by the explicit binding of keys to their context (such 
as via Channel Bindings).

For example, if the AAA server does not delete transported keys, and resends 
them to another NAS, if the NAS is properly identified in the SAP exchange, 
then the peer can determine that it has access to keys that it is not 
authorized to possess.  If the keys are bound to their context, then the 
peer can detect a binding mismatch.

For example, on Yoshi's proposed "Channel Bindings" proposal, it is not 
possible for the AAA server to send the same key to multiple NASes and have 
the EAP peer successfully negotiate use of that key, because the key is 
bound only to the NAS that the EAP peer believes it should be communicating 
with.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 3 Nov 2005 10:15:34 -0800 (PST)

--- Bernard Aboba <[email-masked]> wrote:

> >I am missing one thing here. Even if we specify
> that the keys SHOULD be 
> >deleted
> >after it is transported, how do you prevent a
> mis-behaving AAA server that 
> >does
> >not follow this. In other words, if there are
> mis-behaving/erroneous AAA 
> >servers
> >out there, there is no way the peer can find out.
> Does this mean the peer 
> >can
Sure, but we are talking about the AAA server and the 
authenticator involved in the exchange. We can
find whether the key has been spread to other
authenticators. But can the peer tell the difference
between the authenticator and the AAA server ? 
Does it matter ? In your other response you said:

> Also by deleting the transported 
>keys, the EAP authenticator and peer can derive other
>keys (the TSKs) 
>known 
>only to those parties and not to the AAA server

AAA server cannot derive TSKs even if it did not
delete the transported key because the secure
association protocol exchange involves other
parameters e.g. nonce, in the exchange that is known
just to the authenticator and the peer.

So, what useful attack can the AAA server (which the
peer has a trust relationship with) do by holding
on to the transported key ? Even if it holds on to it
(erroneous or deliberate), but can never derive any
keys that will be used in the commuication between the
authenticator and the peer, would it not be okay ?
I understand that from security point of view, it
makes
no sense for three parties hold on to the same key.
But here the AAA server cannot do much with it
i guess. At least, it cannot send it to other NASes
as the peer can find it out as you have explained
below. Are there any other attacks we are concerned
about ? 

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Nov 2005 16:18:28 +0200

>So this prohibits the AAA server to take EMSK and create new keys
We may have discussed this already, but this is I believe
correct. The EMSK should not be handed to the lower

>the EAP keying process. Should not be the AAA server to make
I think we can easily arrange things so that the AAA layer
asks for AMSKs 1, 2, and 3, which fulfils security requirements
(EMSK is not exposed) and does not require application
knowledge from EAP layer. Does this work for you?

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap