eap Mailing List: RE: About use of EMSK

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

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:jari.arkko [at] piuha.net] 
Sent: Monday, March 06, 2006 3:36 AM
To: Bernard Aboba
Cc: eap [at] frascone.com
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

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

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