Subject: [eap] Re: EAP key management support for handover??

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Apr 2005 22:26:03 -0700 (PDT)

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

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.

> *   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?

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

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

RFC 3576 is being implemented and will presumably be
deployed, so that RADIUS server initiated exchanges are feasible.
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.

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.

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.

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

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

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Sat, 30 Apr 2005 07:55:37 -0500

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:[email-masked]] 
Sent: Thursday, April 28, 2005 12:26 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: EAP key management support for handover??

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?

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

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

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.

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.

Madjid>> I will look into that.

Madjid>>I think we are converging now.

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

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.

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.