RE: Clearinghouse/Aggregator Support for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Alan, Blair, 

Before we start spiralling out of control let me summarize:

If you want opaque value use Class.

No.  Class can't be used as a handle because it will probably change on each
invocation unless of course we standerdized its contents which is not even a
starter.  I hope we never talk about Class in this context again.


Regarding non-opaque handles to users.  Some business models may require an
IMSI or NAI for the subscriber, which does reveal the identity of the user
and may or may not be a privacy issue.  Remember the parties trust each
other so this is probably okay.

However in some cases eventhough the parties trust each other, the true
identity of the subscriber is not to be delivered outside the subscriber's
home realm.  In this case we allow for an opaque handle to the user.  

1) Whether that handle is a UTF-8 string (or text) is really not important. 

2) How it is generated is really not important to the clients that use that
handle.  Clients need to know two things about that string: 
a) that it uniquely represents a subscriber in the home network; 
b) how long is that assertion valid for.
Item b) is made known during business agreement.

3) The generating function is only important to the home entity since it is
making the assertion.  It could simply be a hash( real identity + a
timevalue). In 3GPP they can probably use TIMSI which is created for exactly
this reason.  Note that the Home Entity must make sure that there are no
possible collisions. 

So given 2 I don't think there is an interoperability issue. 

And Item 3) is strictly a producer issue and I don't think that we need to
tell people how to generate that identity.  There are so many ways to do it.
But if you feel that we must perhaps the following will work:

       CUI = '04:' || Hex((HMAC-SHA1(secret,{real identity || realm ||
timestamp})) || @ realm
       
      This would generate a UTF-8 string that looks like:

           04:00112233445566778899aabbccddeeff@example.com

    Furthermore, this value MUST be unique (most likely it is ) for the home
network.  Once computed the home network would make sure that it does not
collide with an existing number and would store this value against the
realuser, and keep issuing it until it expired. 

The client would treat the CUI (as received) as a handle to the subscriber.

> -----Original Message-----
> From: Alan DeKok [mailto:aland@ox.org] 
> Sent: Tuesday, October 26, 2004 10:18 AM
> To: radiusext@ops.ietf.org
> Subject: Re: Clearinghouse/Aggregator Support for CUI
> 
> 
> "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/>
> 

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