Re: AAA for Handovers

[Bernard Aboba <aboba@internaut.com>]

> A while ago, some work was done in the IRTF on RADIUS for handovers in the
> aaaarch-handoff draft, but it seems to have rather died now.

The extension specified in the draft was implemented, and experimental
measurements were made that showed that the technique was effective in
intra-domain use.

However, in other scenarios there are potential efficiency
issues since in 802.11 handoff is station-initiated and yet
pre-emptive keying does not allow the station to know where keys
have been sent.  As a result, the key state between the
peer, authenticator and server is not kept in sync and the station may not
be able to make effective roaming decisions.  For example, in roaming
scenarios the server would be unlikely to have a complete knowledge of
the topology and thus would be unable to determine where to send keying material.

This causes pre-emptive keying to be ineffective in
inter-domain use.  There are also concerns about intra-domain
deployments because pre-emptive keying requires RFC 3576-style
server-initiated messages.

Finally, questions were also raised about whether the mechanism satisfied
the criteria in draft-housley since the pre-emptive keying scheme does not
authenticate the user through the NAS that it will connect to.

As a result, the focus of work on fast handoff has shifted away from
pre-emptive keying schemes initiated by the server, toward "key request"
schemes initiated by the peer.  Advantages of "Key Request" include:

a. The station can send an authenticated "Key Request" via the target
NAS, sychronizing the key state between the peer, NAS and
server and enabling integration between roaming and key management on the
peer.

b. A conventional AAA Request/Response conversation is sufficient; server
initiated messages are not required.

c. "Key Request" relies on local information available to the station
rather than a global map of the topology kept on the AAA server, so that
it scales better in roaming scenarios.

> Thinking about this a little further, it seems like such a design is becoming popular due to the lack
>of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively
>distribute keys to the NAS-es.

As I understand it, IEEE 802.11r supports both conventional
pre-authentication as well as a "Key Request" mode.  However, it does not
support pre-emptive keying.

Note that the terms "pre-authentication" and "proactive" are mutually
exclusive. Pre-authentication schemes (such as Key Request) are station
initiated; "proactive" schemes are server-initiated.  Typically a given
approach will do one or the other, but not both.  My understanding is that
IEEE 802.11r has rejected the "proactive" approach.

Note that "Key Request" schemes do not eliminate the need for a
conversation between the NAS and AAA server, they merely shorten it.  For
example, a "fast resume" typically requires 2.5 roundtrips, while a Key
Request might be completed in a single round-trip.

>It seems to me that if the IETF worked on this and matured it enough,
>people would be willing to use it to provide more secure faster handoffs.

Dorothy Stanley the IEEE 802.11 liaison has mentioned that IEEE 802.11r
may make a liaison request for work on fast handoff.  However, based on
the discussion that has occurred so far, it seems unlikely that such a
request will relate to pre-emptive keying.  "Key Request" approaches
have a lot more support at this point.

>Especially since some work was done in this space earlier on, it seems
>like it might be worth looking into. The IRTF draft was ahead of its time
>when it was written - but, it seems like the timing for such a task would
>be perfect now.

As mentioned earlier, the IRTF work on pre-emptive handoff is not moving
forward because it does not satisfy the problem requirements as they are
currently understood.  Current work is focused on "Key Request"
approaches. However, some fundamental questions remain about how
"Key Request" would work:

a. How are the keys to be named?  Can the key naming scheme used in the
EAP key management framework be used?

b. Can different media simultaneously use the key request scheme?  If so,
does the AAA server need to maintain a different cache for each media or
can a single cache be supported?

c. How is the key request authenticated?

d. How does the peer direct the key request to the correct AAA server?
How does this work if the EAP method in question does not provide a
Server-ID so that the peer is unaware of where its keys are being cached?

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>