eap Mailing List: RE: EAP key management support for handover??

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Hi Bernard,

Well, the actual key derivation formula is a bit of deviation of my main 
objective with that email. But this is also important to sort out as well. 
 
Please see my inline responses

Regards,

Madjid 

-----Original Message-----
From: Bernard Aboba [mailto:aboba [at] internaut.com] 
Sent: Thursday, April 28, 2005 12:26 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: eap [at] frascone.com
Subject: Re: EAP key management support for handover??

> To prevent the domino effect, prior EAP key management specifications 
> [EAPKEY5] suggested
>a procedure by which the AAA-key can be bound to each of the
> authenticators:

The formula described here is quite different from what was in the -05
draft.  The formula in the -05 draft did not depend on the MSK, only on
AMSK derived from the EMSK, which is not transported from the AAA server.

Madjid>> I must admit that I first included the formula in my email, but then 
simplified for the sake of discussion. If you think I made serious errors in my 
simplification. Let us discuss that as well. This is what it was in EAP keying 
05 (I changed the names a bit to relate to base stations:

AAA-Key = MSK(0,63)

      AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
                  length)

      AAABS-Key-A = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key, BS-A-Id,
                  Peer-Id,length)

Madjid>>
Here are my issues:
1) After reading the draft a few times, I am still not clear how EMSK is 
derived? And what the distinction between MSK and EMSK is?
2) on generation of AAABS-Key-A, I am wondering why there is first AMSK(0,63) 
and then AAA-key? Aren't they the same (according to the first expression). Is 
this just the notation, or the AMSK is actually used twice?
3) Ok, so if the AAABS-key is derived based on the AMSK only and the AMSK is 
never transported from the AAA server, and only AAA-key is transported to the 
authenticator, that partly addresses my concern. But what does transferring the 
AAA-key to the authenticator achieve anyway?
For every new authenticator the AAABS-key must still be derived by the AAA 
server?


Deriving keys from the AMSK formula not only enables cryptographic
separation, but it addresses the domino effect as well since the EMSK
never leaves the peer or server on which it is derived.

Madjid>>agreed, however, I still now how EMSK is derived?

> *   Since only the EAP/AAA server is aware of MSK and EMSK,

The MSK and EMSK are derived on both the EAP peer and server.  In
conventional EAP authentication the MSK is sent to the authenticator in
the AAA-Key.  So wouldn't the MSK be known by the peer, server and
authenticator; and the EMSK by the peer and server?

Madjid>> same question again, how is EMSK derived and its differentiation from 
MSK?

>the AAABS-Key-X (the key to authenticator X) must be calculated by the
>AAA server and needs either be pushed to a number of authenticators
>(possibly a neighbor set) proactively or as part of a request/ response
>procedure in conjunction with each handover.

These two alternatives correspond to existing proposals - proactive keying
and key request.  As I understand it, both of these proposals can use the
existing AMSK derivation.  Why is an alternative formula required?

Madjid>> Again, I am not stressing on defining a new formula. I apologize if I 
caused any confusion. The point is that both alternatives seems to require 
involvement of a AAA server.

>The former is not practical with RADIUS implementations
>and possibly requires the AAA server to be aware of mobility patterns or
>network edge topology, while the latter inserts the AAABS-Key-X
>installation on the timing critical path for handover and requires
>a busy AAA server to be involved in every handover.

I'd suggest that more careful evaluation is required to justify these
conclusions.  The reality is that mobility patterns can vary considerably
depending on the scenario, and there are probably scenarios in which each
of the above techiques will work fine.  For example, it matters a lot if
the mobile station is revisiting the same group of authenticators (e.g.
personnel in a building) versus constantly encountering new authenticators
(wireless-enabled part on an assembly line, or car on a highway).
The implication is that evaluation of these techniques probably requires
detailed usage scenarios and simulations.

Madjid>> Not sure if this is the right place to discuss mobility patterns, but 
just as you mentioned in your final scenario, well you are talking about big 
cell sizes (not 802.11) , faster mobility on a highway, things are very 
different. I personally don't need a simulation to have a justification for not 
having AAA server involved in every handover. Proactive methods will only work 
for a neighbor set, once you do inter-set handovers, you are back to the same 
issue.

RFC 3576 is being implemented and will presumably be
deployed, so that RADIUS server initiated exchanges are feasible.

Madjid>> I will look into that.

AAA server knowledge of mobility patterns is also probably feasible for
local authentication.  Where this approach becomes more suspect is when
roaming is involved.  It may not be reasonable for a RADIUS server to
have a-priori knowledge of the topology of the access networks of all
potential roaming partners.

Madjid>>I think we are converging now.

I am not clear that AAA server involvement is really a showstopper for the
"Key Request" approach.  Today's AAA servers can handle enormous loads
at modest cost.  Think about how many authentications/second a box
with four 64-bit processors can handle.

Madjid>> I was planning on writing a draft on EAP key management and handover 
and include this as a simplest (but less desirable) alternative.

The "Key Request" approach does seem feasible for use in
roaming situations, but in terms of scaling it has some of the same
potential drawbacks as pre-authentication: load will scale with the number
of potential roaming candidates and the key lifetime.

If the mobility patterns cause a station to revisit the same
authenticators, and the key lifetime is suitably long, a "Key Request"
will not be required for each attachment.  Whereas if a station is
constantly encountering new authenticators or key lifetime is short, it is
possible that more than one "Key Request" could be needed for each
successful handoff.

> *    In many deployments, access points or base stations are light weight and 
> AAA-incapable

I think the point is not that light weight APs are incapable of handling
AAA (they generally are quite capable in that regard) but that there are
advantages to multi-port authenticators.  One of these advantages is
sharing of the key cache.  This enables the peer to change the point of
attachment without changing the authenticator.  Existing WLAN switches
take advantage of this (this is known as "optimistic PMK caching" within
WPA2).  The existing EAP key hierarchy already handles this, and Channel
Bindings (see RFC 3748, Section 7.15) can take care of ensuring that the
NAS-Identifier is synch'd between peer, server and authenticator,
providing that the authenticator advertises it and securely confirms it
with the peer in the Secure Association Protocol.

Madjid>> As I understand this currently, the WLAN AP and WLAN switch are 
separate boxes, no? how does EAP traverses over these two hops?
That is why I was suggesting the local key distribution function because I was 
trying to get away from the two hop-problem.

>Another main flaw is that the peer must first initiate contact the base
>station, to become aware of the authenticator identity and the AAA server
>is only aware of the authenticator identity rather than BS identity.

In 802.11, the NAS-ID can be advertised in the Beacon as well as sent
in a Probe-Response.  Does 802.16 not support Beaconing?

Madjid>> I don't think 802.16 actually separates between BS and NAS in a clear 
way, so even if the BS ID goes in a "beacon", I don't think a NAS-ID does.

>The AAA server does not have any control over how the AAA key X is
>generated from the AAA key, or how AAABS-key-X is cached or used.

I don't think this is necessarily the case.  For example, the key
management framework talks about "key usage restrictions" that can be sent
along with the AAA-Key.