Re: Clearinghouse/Aggregator Support for CUI

["Alan DeKok" <aland@ox.org>]

"Blair T. Bullock" <bbullock@ipass.com> wrote:
> If you desire opaque data, then use CLASS.  That is what it is for.

  As Avi noted, Class has issues that the CUI is designed to avoid.

>  CUI must be visible to all parties and if you want it to be
> private,

  I think you misunderstood.  The CUI attribute is, of course,
publicly visible.  My concerns about privacy were that the
*interpretation* of the CUI attribute is often best left to the home
system.  Intermediate systems can treat it as an opaque token, with no
loss of functionality.

> If the Home network or any trusted AAA authority wishes to send an
> alias or hash/encode the string prior to transmission so that it is
> private or opaque, fine and dandy,

  That's exactly what I've said.

> but the CUI must be a STRING and cleartext possible.

  "cleartext" has a specific interpretation in the security world: the
information is publicly available to all, and not hashed or encoded.

  So I'm not sure what you mean here.  If the CUI is in a RADIUS
attribute, then all RADIUS servers should be able to understand and
proxy it without any problems.

  Are you saying that the CUI must be an ASCII/UTF-8 string?  If so,
why?

> i.e., every time I login, my Accounting would appear as:
> 
> User-Name=IPASS/anonymous@corp.ipass.com
> Chargeable-User-Identity=x4188  (or bbullock)

  Exactly.  The numerical ascii string has no meaning to
intermediaries, but the home system knows how to interpret it.  This
is a good idea, and I'm all for it.

  My only extension to this idea is that IMHO the document should
describe a way for the home server to generate opaque tokens from
usernames.  Doing so permits the method to be peer reviewed, secure,
correct, and common across many implementations.

> Since the CUI only transports between the NAS and the Home
> authentication server over a privately peered proxy network and is
> never broadcast over the air, there is no exposure to 3rd parties
> unless your RADIUS stream has been compromised....

  Are all proxy networks privately peered?  I don't think so.  I would
like to see recommendations in the document for how to use CUI in
other widely deployed systems.

> Besides, this is an Accounting stream which contains no
> authentication credential...they are already clear!

  Yes, but as I said before, the real username is hidden inside of the
TLS tunnel.  Exposing the username in accounting packets pretty much
defeats the purpose putting the name in the tunnel.

  While the intent of putting the name in the tunnel is to protect it
from wireless sniffers and not people on a wired net, I don't think
that it's a good idea to expose that information in accounting
packets.  Doing so unnecessarily makes accounting the weak link in the
chain.  Since in some situatuions, there's no requirement for
intermediaries to parse the CUI, it's entirely reasonable to use an
opaque set of octets for the CUI.

  Alan DeKok.

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