[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AAA for Handovers
Hi,
On Thu, Aug 11, 2005 at 09:53:52AM -0500, Narayanan Vidya-CVN065 wrote:
>
> > 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.
> >
>
> I am not very familiar with how accounting works. Is the
> Accounting-Start message not authenticated? If it is authenticated
> using an SA shared between the NAS and the AAA server, I am wondering
> why that isn't enough to trust the NAS.
Accounting messages are signed using the Request Authenticator and
possibly Message-Authenticator (required in case of EAP), by the RADIUS
client (ie. NAS or proxy).
There is generally no SA between NAS and AAA (the endpoints), only
between individual RADIUS link partners.
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.
Indeed, many roaming agreements even require NASes to do so. Support
also seems very widely implemented, perhaps because it's a trivial
thing, and I would advocate to require the NAS to support it for new
applications, just like Message-Authenticator support was required in
RFC 2869 if EAP is used.
If the home AAA chooses a new value of Class per session, A rogue proxy
operator can change the value of all attributes in the accounting
request, but 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. 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 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)
The rogue proxy or NAS can replay Class values in forged accounting
messages, but the home AAA can always be programmed to allow only one
start and one stop record for each session.
> > 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.
>
> Is it that the AAA server relies on the successive timing of the
> authentication via the target NAS and the Accounting-Start message?
> 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? If it is the former, isn't there a problem with
> pre-authentication itself? The MN may have pre-authenticated via a
> target NAS well before handoff, but an Accounting-Start may be sent
> much later. On the other hand, if it is the latter, doesn't this cause
> concern for the state build-up in the AAA server?
As illustrated above, the home AAA /can/ check that the MN was
authenticated by it before accepting an accounting start. There's
currently nothing in RADIUS itself that requires tying accounting to
authentication. Some home AAA policies will cause some connection
between accounting and subsequent authentications to exist, eg. by
subtracting time from a user's voucher or locking a session, but such a
connection is always rather indirect and application specific.
With respect to timing, a home AAA can only be certain that it has sent
an accept before it can ever receive a valid accounting start. The rest
is variable.
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.
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/>