Re: AAA for Handovers

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote:

> > However, AAA servers can authenticate accounting messages by including a
> > Class attribute in its access accept message. According to RFC2865, the
> > NAS SHOULD echo the given A/V pair, regardless of value, in all its
> > accounting messages that pertain to the session, including
> > Accounting-Start.
> 
> Yes, but Class was created to link the accounting message to a previous
> authentication on the same NAS.  In pre-emptive keying the problem
> is linking an accounting message on one NAS to an authentication that
> occurred previously on another NAS.
> 
> 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.

> This means that any NAS that received a Class attribute along with the
> pushed key can subsequently send an Accounting-Start regardless of
> whether the user actually connected to the NAS and actually used the key.

I would say the sequence would be

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. 

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?

> > cannot fabricate sessions that never took place, because
> > the home AAA can test whether the unique value of Class corresponds to a
> > session autenticated by it earlier.
> 
> 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.

> > And by tying the accounting record
> > to a specific authentication instance, the home AAA can verify if the
> > session duration given by Acct-Session-Time in Accounting-Stop messages
> > doesn't exceed the time granted in its earlier Access-Accept.
> 
> The problem is that pre-emptive keying does not require a client to
> demonstrate possession of the key to the AAA server.  The AAA server
> just pushes the key out and assumes that it is either used or expires
> on the NAS.  As a result, there may be no corresponding authentication
> instance for each accounting record sent by a NAS.  That means that
> the AAA server cannot verify the Acct-Session-Time or even whether the
> session started at all.

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

> > The secure tying of accounting to an earlier authentication can be done
> > securely by the home AAA if the home AAA generates Class as
> >
> >   nonce + locally-unique-session-id + HMAC(Class + local-secret)
> 
> Unfortunately in pre-emptive keying there may be no "local-secret" between
> the NAS and the home AAA server.

No, local as in only known on the AAA server. It's talking to itself
via the NAS, which only echos Class after all.

> > Or, is the AAA server keeping track of the fact that the MN
> > authenticated through the target NAS and checks that when receiving
> > the Accounting-Start?
> 
> The AAA server doesn't need to check this in real-time but if a question
> arises it is helpful to have logs to be able to figure out what happened.
> 
> > On the other hand, if it is the latter, doesn't this cause
> > concern for the state build-up in the AAA server?
> 
> For forensic purposes, it isn't necessary for the AAA server to keep
> state on authentications and corresponding accounting records; logging is
> sufficient.  However, both pre-emptive keying and key-request require
> the AAA server to cache key state, which does represent a fundamental
> change.

As long as such caching it can be done on a layer above the core
protocol as given in RFC2865, -6, -9, it needn't be any worse than other
schemes that use accounting information for subsequent authentications.

> > As illustrated above, the home AAA /can/ check that the MN was
> > authenticated by it before accepting an accounting start.
> 
> In pre-emptive keying, there is no corresponding authentication on the NAS
> that produces the accounting-start.
> 
> > Other than that, I would like to second a preference towards a key
> > request (as a form of lightweight authentication; of course the home AAA
> > must see /some/ form of credentials or session cookie before it should
> > hand out keying material) rather than the AAA pushing material outwards.
> 
> Key-Request does not bring up these concerns because there can be an
> authentication corresponding to each accounting-start.  This means that a
> log can verify that the client authenticated to the AAA server via a
> particular NAS and this can be correlated with a subsequent
> accounting-start.

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.

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.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

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