Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria

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

Hi,

On Thu, Jul 28, 2005 at 01:50:32PM +0300, Pasi.Eronen@nokia.com wrote:

> Emile van Bergen wrote:
> > 
> > Let's take the example of Class for simplicity, supposing for a
> > moment that it isn't already defined. The generic opaque
> > attribute that SHOULD be echoed by the NAS would be defined by
> > a RADIUS extension RFC, and be available for use in any
> > application that requires an attribute with those external
> > semantics. The upgrade from SHOULD to MUST would require an
> > upgrade to the core RADIUS RFC.
> > 
> > The RADIUS extension RFC defining Class could suggest its use
> > as a billing item reference or similar uses. However, it should
> > not enumerate or limit future applications, or put constraints
> > on its value, when not required for its basic definition ('an
> > attribute whose contents are copied from access accept to
> > subsequent accounting request').
> 
> I disagree about this, to some degree at least. If we have two
> different "applications" that use an attribute for two quite
> distinct purposes, IMHO they should define two separate
> attributes.
> 
> The current approach of reusing the same attribute number for
> different purposes is there basically only because getting a new
> attribute number has been difficult (and using a "vendor-specific" 
> number has a stigma attached to it, although many attributes with 
> "vendor-specific" numbers are not really specific to any vendor 
> but instead widely used...)

True. So you see in practice that RADIUS can very well be extended
on a level just above the core protocol. If VSAs have a stigma, then
perhaps my earlier suggestion of creating a VSA space with IETF as the
vendor may be a solution. EAP also has this in its EAP-Type space.

> Class is actually a good example here: It is defined as an
> attribute that MUST NOT be interpreted by the client (implying
> that the server can put anything it wants there). But people are
> anyway using it to carry things that the client _does_ somehow
> interprete (e.g., some semi-permanent identifier for the
> subscriber in roaming cases). Thus, the server can't anymore
> follow the original "put whatever I want there"; the contents 
> has to be in line with what the client's expectations. 
> 
> (And in this case, there is progress towards defining a separate
> attribute, Chargeable-User-Identity...)

Agreed, and in this case CUI is the proper solution, and the whole issue
of clients misusing the Class should not affect the definition of Class
from a standards perspective. Server vendors or service providers should
not feel limited in their choice of what to set Class to.

Of course, if two parties (eg. a service provider and a roaming broker)
contractually agree that the service provider sets class to a particular
value in particular cases so that the roaming broker can perform some
form of special accounting based on it, then that's a contractual issue
between two parties that already need to have a contractual relationship
(because they need a shared secret, and the service provider needs to
pay the roaming broker, and so on). 

But I'd say that that is entirely within the freedom granted by the
standard that defines Class.

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