RE: Scope of applicability for CUI

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

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.

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 advocate the loss of privacy, just the standardization of packet
payload formats.  



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