RE: Scope of applicability for CUI

[Avi Lior <avi@bridgewatersystems.com>]

Jari, David, et al

To your last part....
> Is this
> the reason why we have non-opaque values in the document
> too? Or is there some other reason, such as tracing/
> legal interception/logging need to see actual user identities?

As I recall, the non-opaque values came about from GSMA and also to align
this attribute with Diameter CC.

Opaque CUI was solving the original problem just fine.

I think the other values were added in cases where user privacy was not
required and EAP was used. So let me give an example.

In WiFi EAP is very important to use EAP because the security issues over
the air. But in the AAA infrastructure it may not be that important because
AAA infrastructure typically runs over a secure network.  So you could use a
CUI that reveals the identity of the user (IMSI etc) in the AAA
infrastructure.  Now you can actaully use a more "concrete" identity for the
user.

Also note another "feature" is that even when using the SIP URI forms and
the NAI form you may still hide the true identity of the user.  That is the
NAI form could be 12345@west.example.com revealing the realm of the user
(west coast of example.com organization) but hiding the identity of the
user.

I belive in the latest version we give examples of these.

Regarding legal interception:

Yes they may want certain CUI forms but Opaque may also sufficie.  For
example, with Opaque values they may insist that the issuer of the opaque
CUI not reuse any of the values for six months. That is, they may issue a
new opaque value for the a identity every month. But will freeze the value
for 6 months.

Then the law enforcement agency (LEA) can then issue a court order and
require that the issuer of the opaque value resolve it back to the user
identity.

Avi 


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Thursday, December 23, 2004 8:25 AM
> To: Barney Wolff; Nelson, David
> Cc: radiusext@ops.ietf.org
> Subject: Re: Scope of applicability for CUI
> 
> 
> Barney Wolff wrote in response to David Nelson:
> 
> >>Given this description of CUI, what is the utility of the
> opaque data
> >>format of CUI?  I understand that opaqueness can be rendered
> >>transparent with the bilateral sharing of proprietary information, 
> >>pursuant to a business contract.  However, that exception 
> >>notwithstanding, if the intent of CUI is visibility and 
> utility to the
> >>NAS and to the Proxies, I suggest that the opaque data format be
> >>removed from the draft.
> > 
> > 
> > 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.
> 
> And then David Nelson responded:
> 
> > Well, you and Avi seem to agree on this, but if that is the case, 
> > how is CUI different from Class?
> 
> As others have pointed out, CUI contents are still meant to
> be looked at, just that the only basic operation expected to 
> be done for them is equality test.
> 
> But this brings me to a new issue. Remember how we agreed
> that CUI helps in policy decisions, such as the 
> one-session-at-a-time rule. My question is whether there's a 
> second utility which is not quite as apparent because it 
> operates again at the "billing layer" which is not 
> standardized. We can make CUI an opaque entity, only designed 
> for the equality test. An opaque CUI can also be used as a 
> billing handle, as long as organizations X and Y agree that 
> they are using the CUIs in this process, either in the RADIUS 
> accounting messages or in the postprocessing/billing 
> transactions or in both.
> 
> However, looking at the definition of the CUI, it seems
> that people want *also* the ability to use a cleartext
> user handle of a specific format. One reason for wanting
> to do this would be to, say, be able to feed the identity
> to an existing roaming/accounting/billing system that can only support 
> a specific type of an identity. Is this the reason why we have 
> non-opaque values in the document too? Or is there some other reason, 
> such as tracing/ legal interception/logging need to see actual user
> identities?
> 
> --Jari
> 
> --
> 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/>