Re: [RADIUS FIXES] Authorize Only / RADIUS layering

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

Hi,

On Wed, Jul 27, 2005 at 10:21:26AM -0400, Nelson, David wrote:

> 
> Emile van Bergen writes...
> 
> > 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.
> 
> I think that your suggestion for layering RADIUS and related
> applications sounds appealing, but has some serious drawbacks.  Diameter
> was designed to have a base protocol and a suite of Diameter
> applications.  RADIUS has no such provisions.  There seems to be some
> confusion in the Diameter community as to the guidelines for extending
> Diameter applications, so even in that case the problem may not be fully
> specified.

Exactly. It lacks much of the clarity and simplicity of RADIUS.

> RADIUS was originally conceived as a "service description language" and
> a "service provisioning service".  

Perhaps, I wasn't there when it happened, but if you consider the fact
that the base RFC only specifies the PDU and the basic request/response
transactions, certainly not the way you define services, only the way in
which you convey certain sorts of data with certain required semantics
and suggested usage to a certain device, I personally feel it was more
conceived as a simple way to remove a database from a network device for
authentication and service definition purposes.

It doesn't really deal with provisioning in my view; there's no request
you can send to a RADIUS server to tell it to create user X.

> RADIUS Servers were "smart" and
> RADIUS Clients were "dumb".  Over time, some folks have come to think of
> RADIUS as a convenient transport for all sorts of applications.  I think
> this leads to problems.  If we're looking for a generic application
> transport, perhaps BEEP might be a more appropriate choice.

Perhaps, unless RADIUS fits the bill as it is. Don't forget how /simple/
the original RADIUS protocol is. The only cruft over a simple TLA
transport is the bad home grown MAC scheme, but that's been fixed since
Message-Authenticator.

(Not that that solves all its security problems, but then I think it was
never intended to provide RADIUS as a general service to the world.  It
makes no sense to allow the world to query your user databases. It's
always either your own devices or proxies of parties you have a
(contractual) relationship with. The very least you need is a shared
secret).

> > 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.
> 
> The problem I see with the use of RADIUS as a transport mechanism for
> other applications is that it leads to poor multi-vendor
> interoperability.  

Why? That depends entirely on how well those other applications are
standardized.

The fact that TCP doesn't talk about web browsing isn't the cause of
browser vendor incompatibilities.

> I understand that individual vendors or consortia
> might not be so concerned with interoperability for a specialized
> application, but the IETF is concerned.  If we continue to add opaque
> "blobs" of data in RADIUS attributes, and rely on non-RADIUS
> documentation to define the semantics of that data, I think we run the
> risk of fragmenting RADIUS into several distinct dialects.  IMHO, this
> would be a Bad Thing (tm).

I agree with your last sentence. But opaque blobs are not a problem, if
the semantics of when they are sent and when they are required are well
defined.

See for example Class; conceived to have a 1:1 relationship with a
certain billing article, but what was standardised was the attribute's
semantics on the NAS' side: the fact that the NAS SHOULD echo it in its
accounting (too bad 2866 didn't make it a MUST, but that's another
matter).  This property allows the logic behind a RADIUS server to tie
accounting to authentication in whatever way required by the service
provider.

And this freedom has no adverse effect whatsoever on interoperability;
as far as the contents of the attribute go, the service provider is
talking to himself, not to anyone else. The proxies forward, the NASes
echo, and that's it.

> > 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.
> 
> I happen to personally agree that there is a lot of complexity in some
> of the current and recent proposals to extend RADIUS.  I also believe
> that some of the complexity is desired but not needed.  By that, I mean
> that the problem could be solved in a simpler way without much loss of
> generality.  

I have personally never seen a form of complexity that's desired but not
needed, unless we're talking about wine instead of software.

I would agree that a slightly more complex base layer may sometimes
produce a more elegant and less complex overall system than a forced
simple base layer would do, but that's a different issue.

If RADIUS needs certain attributes with certain generic semantics that
we don't already have (Cf. CUI, slightly different from Class in that
you talk to the intermediates, not to yourself), then those attributes
and their semantics should be defined, without requiring any particular
application.

> OTOH, I think that simply hiding that complexity "under the rug" of
> another, non-RADIUS, protocol does substantial damage to RADIUS as a
> highly interoperable protocol.  

Generally, yes, but this is also a bit of a blanket statement. We should
not hide complexity, because it will bite you twice as hard elsewhere.
Complexity should be divided and conquered.

> So, yes, by all means, let's attempt to keep the extensions as simple
> as they reasonably can be, but let's not decide to "punt" on the hard
> issue of global interoperability by simply declaring the details as
> out of scope for RADIUS.

Not outside the scope RADIUS-based AAA, but perhaps still out of scope
for RADIUS, unless RADIUS needs to deliver extra basic infrastructure.
'Needs' as in 'whenever it makes the application more elegant and is
demonstrably useful to more than one application'.

I think that the current complexity would definitely benefit from
a better effort at layering.

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