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

[Bernard Aboba (aboba]

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