Re: Scope of applicability for CUI

[Barney Wolff <barney@databus.com>]

On Tue, Dec 21, 2004 at 05:02:10PM -0500, Nelson, David wrote:
> Barney Wolff writes...
> 
> > Whether the CUI is opaque or an NAI does not change the fact that
> > it should be meaningful only to the home server.  The only test
> > that the NAS/proxy should be able to make on CUI is for equality
> > to some previously seen CUI.  Otherwise the privacy of the user has
> > been compromised for no legitimate reason.  A business agreement
> > on how long a one-to-one relation between CUI and the "true" user
> > identity must persist does not depend in any way on the form of the
> > CUI.  Given that, I would have said the opposite, that CUI should
> > always be an opaque octet string.
> 
> I wonder if we are using the word "transparent" in a similar fashion?
> My argument is that the format and syntax of the CUI be standardized.
> That is what I means by transparent.  I mean that it is possible for the
> NAS or Proxy to parse the CUI attribute and do something with the
> content, such as export it to a local backup accounting system.
> Reconciliation of accounting/billing information between intermediaries
> and home AAA operators has been listed as one of the use cases for CUI.
> In that event, the intermediaries need to be able to know what form it
> takes.

I don't understand the need to parse the CUI.  The NAS/proxy would be
foolish to take the "who to bill" from the CUI, which is under the
complete control of the home server, when the realm is known from
User-Name and the IP address from which the Accept was received is also
known.

If it's not parsed, the only issue is whether to require that it be a
printable string rather than an arbitrary octet string.  Again, the NAS/
proxy would be foolish to count on there being no control characters in
the CUI even if the RFC said that there must be none.  So in effect there
is no saving of software effort in requiring a printable string.

> It does not, of course, mean that having the CUI "parsed" will remove
> any of the privacy.  The fact that I can look at a CUI of the form
> temp-user-id-4732875092384082309480923@example.com does not assist me in
> mapping that CUI to the human user behind it.  Ostensibly, only the Home
> AAA Server can do that.
> 
> Beyond that, any notion of "security by obscurity" in allowing undefined
> syntax and formats for the CUI seems pointless.

I don't for a minute believe that making it an opaque string provides any
better security, but it does reinforce to NAS/proxy developers that the
only operations that should be attempted on CUI are memcmp() and memcpy(),
never strxxx().

> I don't advocate the loss of privacy, just the standardization of packet
> payload formats.  

There's only one standard way to print an octet string - in hex. :)

Regards,
Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

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