Re: Isssue on CUI-03

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

Hi,

On Tue, Mar 08, 2005 at 11:38:56AM -0800, Adrangi, Farid wrote:

> 	In discussions on the WG mailing list or in other e-mail threads
> on this draft, I believe we had reached agreement that the content of
> the CUI attribute would be described as an "opaque token", or as an
> authenticated surrogate identity, but that only the Home AAA server was
> in a position to make any other semantic interpretation of the CUI
> content and that all other entities, e.g. proxy servers or NASes, should
> treat the CUI as a "cookie", performing a binary-equality-test operation
> on two CUI instances, but making no other interpretation of the CUI
> content.  That restriction didn't make in into the -03 draft.
> 	 
> 
> 	I would recommend that "The format and the interpretation of the
> string value, and the binding lifetime of the reference to the user is
> determined based on business agreements." (above) be changed to "The
> format and content of the string value is determined by the Home RADIUS
> server.  The binding lifetime of the reference to the user is determined
> based on business agreements.  RADIUS entities other than the Home
> RADIUS server MUST treat the CUI content as an opaque token, and SHOULD
> NOT perform operations on its content other than a binary equality
> comparison test, between two instances of CUI."    

I could not agree more. CUI should be as opaque as Class. 

Let's not define things we don't need to define for the application that
needs CUI. That just needs binary comparison of opaque tokens, so that
should be defined, nothing more. The IETF is about the minimum that
needs to be put on the wire in order to achieve interoperability; future
applications should not be needlessly obstructed. We should not invite
people to make stupid assumptions with respect to attribute content
because of an attribute's semantics in the example application it was
devised for.

As an example if RADIUS had specified that Class may only hold a human
readable service description that should be the same for all users of a
certain service? It would never have acquired its excellent application
as a validator for accounting from untrusted upstream parties.

Kind regards,


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