RE: AAA for Handovers

[Bernard Aboba <aboba@internaut.com>]

> Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs
> from the current NAS through which the STA is authenticating? I agree
> that it is unrealistic to expect the AAA server to have complete
> knowledge of the topology. By allowing this information to be carried in
> RADIUS to the server, the topology information can still come from the
> STA - of course, this will require some support from EAP as well to get
> this from the STA to the current NAS, but it still seems like it can be
> done. So, in this model, the AAA server will only derive keys for the
> requested target NAS devices - so, the station will know where the keys
> are sent. Am I missing something?

While technologies such as 802.11 allow a NAS to discover the L2 address
of its neighbors (e.g. IEEE 802.11k Neighbor Report), there is currently
no mechanism to allow discovery of L3 addresses or names.  So today an AP
has no way to learn the L3 address of a neighbor, let alone the neighbor
NAS-Identifier.  So before the AAA client could provide this information
to the server it would need a mechanism to obtain it.  In the case of
802.11, this would probably imply the addition of an L3 address or
NAS-Identifier IE to the Beacon/Probe Response.  I think that IEEE 802.11r
does include support for the latter, but not the former.

> Yes, true. I have wondered why RFC3576 wasn't made a bit more generic,
> with "disconnect" being one type of message. But, why is this style bad?

The issue is that RFC 3576 has not been widely implemented.  There are a
few devices that support it (e.g. Airespace WLAN switches) and a few
servers.  This makes it possible to deploy RFC 3576 in an intra-domain
scenario, but in inter-domain scenarios you'd need to upgrade all the
intervening proxies and there are some substantial security issues to deal.
For example, you'd need to make sure one ISP couldn't disconnect or change
authorization for another ISP's users.  The end result of this is
that building a proxy that supports RFC 3576 in a secure way
is non-trivial.

> > 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.
>
> Maybe I'm not remembering draft-housley properly - what threat does this introduce?
> If the AAA server shares an SA with the target NAS, and the MN can be
> properly authenticated, why is it important that the MN be authenticated
> through that NAS?

Pre-emptive keying seeds the key cache at potential points of attachment,
but the EAP peer only authenticates with the target NAS, the AAA server
never confirms that the EAP peer used the key.  The only indication the
AAA server receives is an Accounting-Start from the target NAS, indicating
that the EAP peer has connected.

Because the AAA server can never confirm that the EAP peer was even
considering the target NAS, it has no way to know whether the
Accounting-Start it received is authentic.  This enables a rogue operator
to generate fraudulent accounting records that cannot be easily checked by
the AAA server.

> > 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.
> >
>
> Obviously, this is straightforward - but, are there security reasons why this is better?

The requirement that the EAP peer demonstrate interest in the target NAS
and prove its identity means that there is an authentication attempt to go
along with the Accounting-Start.


> > b. A conventional AAA Request/Response conversation is
> > sufficient; server initiated messages are not required.
>
> I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs.

From what I can tell, the security of the "Key Request" scheme is equal to
or better than pre-emptive keying, without requiring server-initiated
messages or changes to the lower layer neighbor reporting mechanisms.

> > 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.
>
> As I mentioned above, perhaps this model can still be preserved?

The nice thing about "Key Request" is that the peer figures out who the
neighbors are, so the AAA server or NAS doesn't have to.

Note also that in inter-media handoffs, the peer's idea of a "neighbor"
may not correspond to the AP's idea.

> I was not aware that a proactive approach was considered by 802.11r -
> any particular reason why it was rejected? Is it simply to avoid making
> changes to AAA or due to other reasons?

Since both "Key Request" and "pre-emptive keying" approaches require AAA
changes, I don't think that this was the deciding factor.  My
understanding is that "Key Request" is more in tune with the
station-initiated nature of 802.11 roaming than "pre-emptive keying", and
that this coupled with the RFC 3576 deployment issues and potential
security concerns lead to "Key Request" being preferred.

> Yes, and therein lies the problem. At least for requirements we have on handoff
> times for some of the applications we are seeing, it seems rather
> unacceptable to have any need for conversation with the AAA server at
> the time of handoff. This is leading to designs that include intermediate key
> hierarchy branches off the MSK as Madjid pointed out.

One thing to keep in mind is that the total transaction time is not the
only factor determining whether a handoff can be completed in time.
A more important factor is the key cache hit rate and the lead time.  If
knowledge of key state is synchronized and the neighboring NASes can be
determined well ahead of time, then the introduction of one or more
roundtrips to the AAA server may not matter that much because EAP
authentication or "Key Request" may be a rare event.

As an example, in a building where there are two WLAN switches, an EAP
peer with an awareness of the key cache boundaries would
only need to authenticate with each switch once a key cache entry had
expired.  So if the key lifetime is 24 hours, the peer might
authenticate with each switch at the beginning of the day, and then not do
any other EAP authentications until the next day.

In such a situation the extra round-trips to the AAA server of an EAP
pre-authentication or "Key Request" do not affect performance or AAA
server loading that adversely.

> This is true. However, is it because AAA lacks support for this or is
> it the "key request" approach is technically a better one?

AAA servers don't support either pre-emptive keying or key request, so
that's probably not a factor.

> I do realize that the pre-emptive handoff work as written in the IRTF
> draft does not satisfy all requirements. Is it worth looking at whether
> it will be more applicable with some changes, such as a method to send
> multiple NAS-IDs to the AAA server?

I think it would probably be worth bringing the issue up in IEEE 802.11r,
so as to clarify exactly what (if anything) they want from the IETF.
From my perspective, a very valuable contribution would be to
develop a requirements document that states clearly what the problem is
and what a good solution would look like.  For example, to date there are
a lot of different notions of what "fast" means, or what scenarios need to
be supported and why.  Without consensus on what the problem is or how
we know when it is solved, it is difficult to make much progress.



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