Re: AAA for Handovers

[Bernard Aboba <aboba@internaut.com>]

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

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

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

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

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

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