Subject: RE: [eap] About use of EMSK

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 1 Mar 2006 18:08:26 -0500

>From previous discussion, I personally made the conclusion that the EAP
server/ AAA server/ backend server are collocated. And as a consumer of
EAP keying, I came to think that AAA layer at the backend is implemented
by AAA servers, while EAP method/EAP auth layers are implemented by EAP
server. I don't really have a reason to worry about what AAA layer is,
except trying to understand EAP keying documentations and figure out
where I get my keys (AMSK at this point) from and so far I have not
understood it. So if we say EMSK-AMSK generation at AAA layer would
require changes to AAA servers, I can accept that, but 

Are we now saying that AAA layer does not correspond to functionality at
AAA servers and AAA clients??? I am lost! Who implements AAA layer?

Madjid 

> >
> Clarified this point. In your answer you specify "only" lower layer. 
> Did you forget to include AAA layer ? Or do you think AAA layer might 
> receive EMSK?.
> 

[Joe] this would depend on where you draw your AAA and EAP server
boundaries.  They are two separate entities and do not even need to be
collocated, but it is fairly common for the EAP server and AAA server to
be collocated or for the EAP server to be part of the AAA server.  How
the EAP server and AAA server divide up their responsibilities depends
upon local implementation so I would say that the AAA server may know
the EMSK as far as it may contain the EAP server. Now I am not sure what
the AAA layer is, but it may not be the same as a AAA server so I can't
really answer your question.  It would seem that the AAA layer would
include the AAA client and AAA server communication.  The EMSK does not
pass through this communication so under this definition it would not go
to the AAA layer.  

> "what layer (EAP method layer, EAP peer/authenticator layer, EAP 
> layer, lower layer/AAA layer) is intended to get EMSK to create new 
> possible keys (AMSK)?"
> 
> (From your previous answer, it is clear we can discard lower layer as 
> a possible answer)
> 
[Joe] I'm not convinced that I understand the layers or that the layer
model is the right thing to apply here,  but given the choices my answer
is the EAP method layer. 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 03 Mar 2006 16:43:56 -0500

Hi Joe...

I would like to do some comments to your e-mail. Please see inline...

>include the AAA client and AAA server communication.
>
My understanding is that figure 3 is referring to AAA server. 

But in any case, i re-formulate the question: if EAP server and AAA 
server are co-located ... could EMSK be exported to AAA server? (From your
answer

"the AAA server may know
the EMSK as far as it may contain the EAP server"

I would say yes .

<snip>

>model is the right thing to apply here,  
>
Ok, I see.   In EAP key mng fwk is described this layering .  
Additionally , let me give some notes about EAP state machine (though it 
is informational).

For example (RFC 4137):

6.1.2.  Variables (Backend Authenticator to AAA Interface)

.....

aaaEapKeyData (EAP key)

      Set in authenticator state machine when keying material becomes
      available.  Set during the METHOD_RESPONSE state.  Note that this
      document does not define the structure of the type "EAP key".  We
      expect that it will be defined in [Keying].

If we check the EAP state machine that method (aaaEapKeyData (EAP key) ) is provided by EAP backend authenticator state machine (Figure 5 in rfc 4137). That state machine recovers the "EAP key"
from the EAP method through m.getKey()

m.getKey()

      Method procedure to obtain key material for use by EAP or lower
      layers.  Returns an EAP key.

Thus, the layer model remains....

Having said this, and after your comment

My question is : is it expected another interface (different than "aaaEapKeyData (EAP key)") to provide keys to AAA server? or could AAA server use for example something like m.getKey()
to obtain a particular key from EAP method?.

>but given the choices my answer
>is the EAP method layer. 
>  
>
In that case, why would EAP method need to export EMSK?.

Thanks.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 10:11:54 -0800

<snip>
> 
> My question is : is it expected another interface (different 
> than "aaaEapKeyData (EAP key)") to provide keys to AAA 
> server? or could AAA server use for example something like m.getKey()
[Joe] I don't think the EAP state machine took into acount EMSK usage.
I would expect there would need to be an interface for retrieving AMSKs.

> In that case, why would EAP method need to export EMSK?.
[Joe] It wouldn't.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 19:07:54 -0500

Hi Jari,
 
I think keeping EMSK at the server (EAP or AAA server), and calculating
AMSK there (your alternative 1) provides for better control of the
overall AAA and security of both handover and applications. So I favor
1. 
This way not only you are not worried about misuse of EMSK in generating
unauthorized AMSKs by the authenticator, but also are covered against a
few things:

1) authenticator handover does not require regeneration of EMSK (read
new EAPs).
2) application keying does not require authenticator-application agent
SA s that may otherwise not exist. We ran into this problem with Proxy
MIP. Authenticator gets a PMIP key (say generated from a PMIP-AMSK), the
authenticator can have an SA with the proxy MN, since they are expected
to be within the foreign network, but the authenticator is not expected
to have an SA with the HA, meaning, the HA cannot get the PMIP key, it
has to go to the AAA server to get it and guess what, the AAA server
cannot even send the PMIP-AMSK to the authenticator, because according
to EAP requirements, it has to have deleted it after transport to
authenticator.

3) As you mentioned, the AAA server may even have a policy about the
KDFs to be used for each application keying, say MIP or whatever, so you
may not have negotiate the KDF.

Madjid
-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, March 06, 2006 3:36 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [eap] About use of EMSK

Here's some analysis of the server vs. lower-layer based EMSK processing
approaches.

(1) In the server based approach we keep the EMSK in the server (perhaps
just for a moment) and generate the AMSKs, which are given to the the
different applications, such as fast handoff mechanisms.
The use of these applications goes via AAA, e.g., some kind of key
requests or fast re-auth requests can be sent from NASes to the server.
The AMSKs are derived using a KDF which is decided either (a) by a
default plus optional negotiation in methods or (b) by lower layer
negotiation and having AAA tell the server which KDF to use.

(2) In the lower-layer based EMSK processing approach, the EMSK is
delivered to the authenticator along with the MSK.
KDF is selected either (a) by a default in EAP plus optional negotiation
in methods, choice is communicated to the lower layer via AAA or (b) by
lower layer negotiation alone.
The lower layer is responsible for all use of the AMSKs in a local
context. That is, no AAA key requests are needed or possible.

Discussion about the chosen approach for EMSK use has so far appeared to
assume 1a vs. 2b. Based on the above, it seems that the KDF negotiation
may be a separate issue from who maintains the EMSK and calculates
AMSKs.
In the following I'll try to analyze these issues.

The KDF negotiation is indeed problematic almost no matter what we do.
Requiring new funtionality in methods is in practice often a
non-starter; while we can develop new methods and update old ones, it is
expected that most of current usage will continue to use the existing
methods. Having a default does not help much either, if the default
becomes broken in the near future.
But requiring new functionality in link layers it not always easy
either. It would be easy when we are developing a new link layer and
including some EMSK usage as a part of that. But if we were to use EMSK
for some new function over 802.11, for instance, would there be enough
incentive to extend 802.11 just to make this possible?

The choices and their implications are:

  (a) Specified default, optional negotiation in EAP methods.

       This implies an interface either from methods to the AAA/EAP
server
       code (for solution 1) or AAA protocol extensions for solution 2.

       Changes in peers, servers, methods, possibly AAA protocols.

  (b) Lower layer negotiation.

       If used together with solution 1, implies AAA protocol extensions
       to communicate the KDF. If used with solution 2, implies AAA
       protocol extensions to carry the EMSK.
      
       Changes in lower layers, AAA protocol. No changes in EAP or
methods.

Based on this my current preference is (b). I'd be willing to accept
(a), too.

The choice between server or lower-layer based EMSK processing depends
on security implications and ease of use for different purposes.
The choices are:

  (1) Derive AMSKs at the EAP/AAA server.

       Implies a AAA protocol extension to retrieve AMSKs.

       Changes at the EAP/AAA server, authenticator. New, stateful
       nature of the EAP/AAA server.

  (2) Derive AMSKs at the lower layer.

       Implies a AAA protocol extension to carry EMSK to the
       authenticator.

       Small changes at the EAP/AAA server, main functionality in
       the authenticator.

       Hard to see how other nodes than the authenticator would
       actually use the AMSKs. Traditionally, NAS -> NAS communication
       has not been easy compared to NAS -> AAA communication.

Based on this my current preference is (1). But its a close call.

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Mar 2006 21:34:31 -0800

> 
> Narayanan, Vidya wrote:
> 
> > I don't think the keying framework document would still 
> discuss this.
> > I think there is consensus that the text about EMSK will be in a 
> > separate document. The issue was discussed in the context 
> of the EAP 
> > keying framework, since there are parts of that document that 
> > specifically say that the EMSK MUST NOT be transported and MUST be 
> > deleted - question is whether we can change that wording 
> and leave any 
> > other explanation on EMSK usage or AMSK derivation to a future spec.
> 
> What we intend to do, I think, is to set the high-level 
> requirements for EMSK in the keying framework (e.g., MUST NOT 
> be transported).
> 

I think if we said MUST NOT be transported out of the authentication
server to any other entity, without saying if it is the EAP layer or AAA
layer, that might work. In light of all the discussion on this topic
lately, I don't know that we can say anything more specific yet. 

Vidya

> But the derivation of AMSKs from the EMSK, and the specific 
> proposals for specific uses of the AMSKs in applications need 
> to be in other documents.
> 
> In any case, I'm hoping that what we say in the keying 
> framework document holds and does not have to be changed in 
> these other documents.
> 
> --Jari
> 
>