[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RADIUS FIXES] Authorize Only
Hi,
On Tue, Jul 26, 2005 at 10:51:35AM -0400, Avi Lior wrote:
> Thanx for the support. I don't agree that the use of Authorize-Only
> should be discouraged though. It has tremendous use for allowing the
> NAS and Server to manage an already established session without the need
> for re-authentication.
>
> This is important since AAA (Diameter and RADIUS) are being used to
> manage sessions that are much more complex today.
This is of course true, but why is it required for the RADIUS client to
use the Service-Type attribute to flag that the
authentication/authorization request is actually an extension of an
earlier one?
The way I have come to think about RADIUS is that an Access-Request /
Access-Response transaction is just a way for a client to ask a
questions to server that it trusts.
The question may actually be 'verify identity and return profile X', the
question may be 'return profile X', the question may be 'proceed with
another step in a lengthy EAP discussion'; but in all cases the meaning
of such a question may only be obvious to a particularly configured
instance of a RADIUS server, playing a role in a particular application.
To put it differently: I think that it helps to distinguish two layers
in RADIUS, with RFC2865 at the bottom, and an *user defined* application
at the top.
So if in a particular scheme a NAS has a question to ask that happens to
pertain to an existing session, that is between the NAS and the EAP type
or other backend logic to figure out, and should not have an influence
on the RADIUS protocol.
Even the separation of authentication and authorization is problematic
because the client needs to supply a ticket to refer to an earlier,
succesful authentication, and the server needs to keep state about that.
The combination of attributes that would define a ticket, and how its
lifetime would be governed, is definitely a question for the future
application, and not for RADIUS.
I am afraid that if we try to separate authentication from authorization
in RADIUS, we're making RADIUS into something that it fundamentally
isn't (a protocol that requires the server to keep state after an
authentication *as part of the basic protocol*).
So in short, I would suggest to have the application define the
attribute(s) to be used as the session ticket and the attributes to
distinguish updates in whatever direction from new sessions in such
cases, but to keep all that jazz on a layer well above the simple,
fundamentally stateless Access-Request / Access-Accept transaction.
Authorize-Only should not affect a RADIUS server core in any way. User
defined logic, yes. SQL, yes. Internal state, no. The RADIUS server
itself should not care whether you're starting a new session, continuing
an existing session, reauthorize because someone's worried about
something.
A RADIUS server should answer the access request using whatever rules
the administrator gives, possibly updating whatever state in a database,
but should then be allowed to forget about it all. It should not be
required to hold some abstract 'session' for which subsequent
Authorize-Only requests may be received -- at least not outside the
external, high level database.
Such a database or the logic (lifetimes, timeouts, session state
transitions) should not be required for scenarios that don't
need them, ie. authorizations that don't care about reauthentications.
If a NAS or application can avoid the un-RADIUS-like separation of
authentication and authorization, it should.
If reauthentication is a problem, supply a different set of credentials
that have a different meaning to the upper layers, and use them to
refer to an existing session. Cf. EAP.
Sorry for the long rant, but I see an explosion of complexity here in
the last months, without the clear layering that would keep RADIUS the
simple, elegant protocol it's always been.
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/>