RE: [RADIUS FIXES] Authorize Only

["Nelson, David" <dnelson@enterasys.com>]

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.

RADIUS was originally conceived as a "service description language" and
a "service provisioning service".  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.
 
> 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.  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).
 
> 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.  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.  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.



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