: Re: AAA for Handovers

> > Specifically, with pre-emptive keying, getting an Accounting message with
> > an echo'd class attribute doesn't actually demonstrate that the user
> > authenticated to the NAS, since no evidence is provided to the AAA server.
>
> No, but it does demonstrate that the second NAS obtained it from the
> first one, possibly with other context and credentials, as part part of
> an IAPP.

The IRTF pre-emptive keying proposal does not involve IAPP.  See:
http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt

> 0. user connects to NAS X
> 1. AAA receives authentication request from NAS X
> 2. AAA sends key + Class + other authorization parameters to nas X
> 3. AAA sends key to nas Y, Z, etc.
>
> and nas Y and Z will only be able to use the key and send accounting if
> they are trusted by nas X, because nas X decided to give them Class.

In pre-emptive keying, there is no transport of attributes between NASes,
because the NAS obtains the attributes directly from the AAA server.

> Or am I shifting the problem too easily to the NASes? Is the underlying
> assumption for this work that there's no IAPP operating at all?

I think you're confusing the IRTF pre-emptive keying proposal with another
proposal.

> > If the AAA server sends pre-emptive notifications to several NAS devices,
> > each one of them can pretend that the user connected to it, and can generate
> > Accounting records with the correct Class attribute.  Without user
> > authentication there is no way for the AAA server to know whether the
> > Accounting-Start messages are valid.
>
> Not if those notifications don't include Class. Class would then only be
> transported between NASes through an IAPP, at the actual handoff time.

The IRTF pre-emptive keying proposal doesn't involve IAPP, so this not
possible.

> I think if there is one Class per session, instead of one Class per
> session per NAS, this problem does not occur.

It can occur either way because any NAS that obtains a pre-emptive key can
issue an Accounting-Start with the same Class attribute.

> Exactly. The model where a user session is a set of lightweight RADIUS
> sessions, one session per NAS contact, is probably easier to design and
> implement.

That was the feedback provided by 802.11r participants.

> I think we should only choose one of the extremes: either use a full
> RADIUS authentication/start/interim/stop per NAS contact, implying we
> must solve caching and reauthentication speed issues at the EAP layer,
> or use one RADIUS authentication/start/interim/stop per full user
> session, and let handoff be done wholly outside RADIUS, through an IAPP.

As I understand it, IEEE 802.11r supports both of these modes as well as
as "Key Request" mode.  At the last meeting, the group was looking at
features to cut, so if you have an opinion, bring your occam's razor with
you :)

BTW, if a specification supports multiple modes, it's worth considering
whether *all* of them need to satisfy the Housley Criteria.  As long as
there is one mode that does satisfy the criteria, then operators who value
security can deploy it.  There is a distinction between making
security "mandatory to implement" and "mandatory to use".  As long as one
mode is secure and its implementation is mandatory, then I think the
"mandatory to implement" requirement is satisfied.