RE: Clearinghouse/Aggregator Support for CUI

["Blair T. Bullock" <bbullock@ipass.com>]

If you desire opaque data, then use CLASS.  That is what it is for.  CUI
must be visible to all parties and if you want it to be private, then
don't pass-back a real User-Name in the Access-Accept...or if you can
correlate it directly from the NAI, don't pass a User-Name at all.   I
would say use the CUI in the Access-Accept in order to signal desire to
use the attribute, but we should pay attention to legacy AAA endpoints
for things like TTLS/PAP or CHAP functionality with downwards
compatibility.

Mediating networks who oversee the aggregation of footprint for
reselling network services will need to have visibility into this CUI
string.   The CUI should be transparent to all parties.  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, but the CUI must be a STRING and cleartext
possible.

An Anonymous TTLS/PEAP using a logical alias CUI, in effect provides the
necessary privacy while still maintaining service oversight on a
per-user/per-session basis.

i.e., every time I login, my Accounting would appear as:

User-Name=IPASS/anonymous@corp.ipass.com
Chargeable-User-Identity=x4188  (or bbullock)

The need is truly for a correlate to the authorized profile, but not
transmitted over the EAP ID which is interceptable.  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....and if so, you have bigger problems than maintaining CUI
privacy.  Besides, this is an Accounting stream which contains no
authentication credential...they are already clear!  This actually
allows us all to use anonymous tunneled EAP logins without losing the
actual user identity and without transmitting that user's ID over the
air.

Blair

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Alan DeKok
Sent: Monday, October 25, 2004 3:12 PM
To: radiusext@ops.ietf.org
Subject: Re: Clearinghouse/Aggregator Support for CUI

Avi Lior <avi@bridgewatersystems.com> wrote:
> Operators and SDO that would use the Opaque value would typically have

> their own security review.

  Which is precisely my concern.

  IMHO, for "hidden" data in CUI, inter-operability is less of a
requirement than is "best practices".  The IETF has a history of
accepting both in documents, and sometimes even in the same document.

> Furthermore when thinking about how one might do this, there are many 
> factors to consider and these factors are specific to deployments.  So

> I am not sure if we came up with an example it would have general
applicability.

  A well-known method which hides the CUI data from all but the users
home system would cover many common cases.

  Since the CUI is encrypted in a TLS tunnel, but is visible to the end
system, then there is value in continuing that practice when the CUI is
carried an attribute.

  Having a CUI which is private, and requires minimal state keeping by
the home server seems to me to be a good solution.

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