Subject: Chargeable-User-Identity and Operator-Name

From: Tomasz Wolniewicz <[email-masked]>
Date: Mon, 10 Aug 2009 13:04:04 +0200

There is one more issue about the CUI.
The RFC states:

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request packet containing a CUI (set to nul or otherwise), it
   MUST include the CUI attribute in the Access-Accept packet.

As Stefan has described, the information about the visited institution
may be important for the CUI generation. In our (eduroam) case we would
want to generate different CUI values for different visited networks,
but in scenarios described by Stefan, the information about the visited
institution is also crucial. Therefore I would see it as completely
justified to say, that a server supporting the CUI can refrain from
sending it, if some of additional policy-related conditions have not
been met (for instance there is no business agreement stating that this
should be done for a particular visited network or that the
Access-Request does not carry an additional attribute required by this
business agreement).

The unconditional MUST in the quoted paragraph seems to be too strong.

Greetings
Tomasz Wolniewicz

-- 
Tomasz Wolniewicz    
          [email-masked]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 08:25:30 -0400

Tomasz Wolniewicz writes...

> The unconditional MUST in the quoted paragraph seems

MUST makes for highly predictable behavior in a protocol and leads to
interoperable implementations.

There is an implicit assumption of trust between a NAS and RADIUS server
that's central to the RADIUS architecture.  I understand that proxies and
roaming consortia may have business, legal, privacy and other non-protocol
concerns that make RADIUS a less than ideal protocol for such use cases.

The problem is that, in the absence of a real capabilities negotiation
feature in RADIUS, SHOULD and other forms of variable behavior make the
implementation and error recovery design needlessly complicated.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Mon, 10 Aug 2009 20:39:02 +0200

> implementation and error recovery design needlessly complicated.
  I understand the technical perspective of this reasoning, but this 
particular RFC is very much policy related.
Observe, that the RFC allows the visited institution to turn an 
Access-Accept into and Access-Reject if the reply does not contain the 
CUI. Now *this* is something that is very likely to interoperability, if 
the parties have not agreed on the principles first.

In order for the CUI to be usable, there always has to be a business 
agreement between the parties even if, as in eduroam case, it is not 
direct. Since the CUI support is optional anyway, I do not see any real 
danger that not responding to a CUI request can seriously harm the 
RADIUS protocol.

Some of our concerns are not about trust in the eduroam infrastructure, 
but about making our lives easier by convincing our site lawyers that 
the amount of opacity introduced by our procedures is high enough to 
state that the CUI is not personal data of our guests.

Tomasz

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 14:56:41 -0400

> Observe, that the RFC allows the visited institution
> to turn an Access-Accept into and Access-Reject if the
> reply does not contain the CUI. Now *this* is something
> that is very likely to [impact] interoperability, if

Umm.  No.

First, the RFC says that's the expected / required behavior, so from an
implementation design perspective, it *can't* come as a surprise -- except
to someone who didn't read the RFC carefully.

Second, that's the way that RADIUS has traditionally implemented the notion
of a "mandatory" attribute.  If an attribute is considered "mandatory", the
RADIUS client either effectuates it faithfully or treats the entire message
as if it had been an Access-Reject.  It's an all or nothing proposition.
You'll find this behavior required in a number of RADIUS RFCs.

> Some of our concerns are not about trust in the eduroam
> infrastructure, but about making our lives easier by 
> convincing our site lawyers that the amount of opacity
> introduced by our procedures is high enough to state that
> the CUI is not personal data of our guests.

I hear you.  ;-)

CUI as originally defined certainly passed that litmus test.  How far you
can go with turning it into a secondary form of user identity understood by
multiple parties while claiming it's not personal information is an open
question, I think.