Subject: Chargeable-User-Identity

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Aug 2009 08:32:26 +0200

Hello,

in eduroam, we are just about starting to make real use of the
Chargeable-User-Identity (RFC4372). Our motivation is not billing, but
being able to recognise fraudulent users when they return, to have a
means of permanently banning them. E.g. a user could change his MAC and
outer identity on every re-connect, and evade blocking measures if no
permanent opaque handle identifies him on return.

We are mostly happy with the RFC, but one of my colleagues stumbled upon
something. The RFC says that the business agreement between service
provider and home server determines the lifetime of a CUI. While that's
correct, there is a problem when intermediate proxies are involved (like
a clearing-house): since there is no reliable end-to-end identifier for
service providers, the home server may not know which business partner
it is talking to - it sees only the proxy's connection.
A concrete example from the RFC is: "For example, the lifetime can be
set to one billing period." A home server H doing business with two
service providers S1 (billing period: end of month), S2 (billing period:
25th of every odd month) via a proxy P would need to see an identifier
for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
generates properly, and roll them over at the appropriate end of billing
period.

There is not currently a standard attribute to convey this information.
NAS-IP-Address and NAS-Identifier are semantically bound to a single
NAS. A service provider can operate multiple NASes, on the same or
different access media.

I'm not sure if there is much to do about this. I suppose a good
real-life way to do this is to set a VSA with the information, and make
sure that P sets it for its customers. I wonder if it's worth defining a
properly standardised attribute for this though (since implementing
RFC4372 seems to implicitly require its existence)...

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
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: <[email-masked]>
Date: Mon, 10 Aug 2009 08:41:50 +0200

Hi,

RFC 5580 does specify an "Operator-Name" attribute (to identify the
access network operator/"NAS owner") -- would it be useful in your
situation?

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of ext Stefan Winter
> Sent: 10 August, 2009 09:32
> To: [email-masked]
> Subject: Chargeable-User-Identity
> 
> Hello,
>

---

From: <[email-masked]>
Date: Mon, 10 Aug 2009 10:18:33 +0200

Hi Stephan,

It should be! The Operator-Name attribute was defined for that :)

Best Regards,

Lionel

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> Envoyé : lundi 10 août 2009 08:42
> À : [email-masked]; [email-masked]
> Objet : RE: Chargeable-User-Identity
> 
> Hi,
> 
> RFC 5580 does specify an "Operator-Name" attribute (to 
> identify the access network operator/"NAS owner") -- would it 
> be useful in your situation?
> 
> Best regards,
> Pasi
> 
> > means of permanently banning them. E.g. a user could change his MAC 
> > and outer identity on every re-connect, and evade blocking 
> measures if 
> > no permanent opaque handle identifies him on return.
> > 
> > We are mostly happy with the RFC, but one of my colleagues stumbled 
> > upon something. The RFC says that the business agreement between 
> > service provider and home server determines the lifetime of a CUI. 
> > While that's correct, there is a problem when intermediate 
> proxies are 
> > involved (like a clearing-house): since there is no reliable 
> > end-to-end identifier for service providers, the home 
> server may not 
> > know which business partner it is talking to - it sees only the 
> > proxy's connection.
> > generates properly, and roll them over at the appropriate end of 
> > billing period.
> > 
> > real-life way to do this is to set a VSA with the information, and 
> > make sure that P sets it for its customers. I wonder if it's worth 
> > defining a properly standardised attribute for this though (since 
> > implementing
> > Fondation RESTENA - Réseau Téléinformatique de l'Education 
> Nationale 
> > et de la Recherche 6, rue Richard Coudenhove-Kalergi
> > L-1359 Luxembourg
> > 
> > Tel: +352 424409 1
> > Fax: +352 422473
> > 
> > 
> > --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Aug 2009 10:54:49 +0200

Hi,

> access network operator/"NAS owner") -- would it be useful in your

Oh! Cute. That's exactly the thing. Thanks!

Now the only problem is to find RADIUS servers that support the unusual
encoding of 5580 attributes to parse the content of Operator-Name. But
that's not for this mailing list to solve :-)

Greetings,

Stefan Winter

>> upon
>> billing

Tel: +352 424409 1
Fax: +352 422473

---

From: <[email-masked]>
Date: Mon, 10 Aug 2009 11:03:48 +0200

> that's not for this mailing list to solve :-)

Many of the other attributes in RFC 5580 indeed have complex
encodings, but using Operator-Name doesn't necessarily require
anything new from the RADIUS server... The "Namespace ID" values 
are intentionally printable ASCII digits, so you could treat
the whole attribute as one string, and put something like
'if Operator-Name == "1example.com" then...' in your RADIUS
configuration.

Best regards,
Pasi

---

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Aug 2009 11:05:35 +0200

Hi,

> 'if Operator-Name == "1example.com" then...' in your RADIUS

Sure. Not exactly clean, but an acceptable workaround.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

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

Stefan Winter writes...

> The RFC says that the business agreement between service
> provider and home server determines the lifetime of a CUI.

Yes.  In drafting the document, support for anonymity of the user was a
requirement.  It was felt that a long-lived ID could be used to track the
user and violate his/her privacy, and thus the CUI *could* be short-lived.
IIRC, it need not be however.

Exactly what normative text of the RFC do you think prohibits you from using
long-lived IDs?

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 09:01:54 -0400

Stefan Winter writes...

Let me try to understand you usage a little better.

> Our motivation is not billing, but being able to recognize
> fraudulent users when they return...

By "fraudulent", do you mean a user that is unknown or invalid at the home
AAA server?  Or do you have some other thought in mind?

> ... to have a means of permanently banning them.

Well, if the home AAA server continually sends Access-Reject, the user would
be permanently banned.  No?

So, I'm thinking you likely have another idea in mind, such as protecting
from DoS attacks or use of resources in the roaming partner's network by
unauthorized users.  A pre-authentication sort of behavior, like Call-Check
used to provide in dial-up networks.

> .. E.g. a user could change his MAC and outer identity on every
> re-connect, and evade blocking measures ...

Blocking where, exactly? 

> ...if no permanent opaque handle identifies him on return.

Well, keep in mind that CUI was designed to be an opaque cookie of meaning
only to it's issuer, the home AAA server.  Edge devices, e.g. NASes could do
a binary comparison for equality to tell that one CUI is the same as
another. That much is feasible.  Are you suggesting that NASes keep a
"denied parties list" or "blacklist" of CUIs?

> ...since there is no reliable end-to-end identifier for
> service providers...

Nor has there event been one in RADIUS.

> ... the home server may not know which business partner

Well, it is in fact only "talking' to the immediate proxy.  It has to rely
on the chain of proxies to "do the right thing" on its behalf.  That's also
a central tenet of the RADIUS architecture, limiting as that my be in
certain circumstances.  You simply have to trust the proxies.

> generates properly, and roll them over at the appropriate end of billing

That assumes the home server tries to optimize its data storage and internal
state by the clever the "re-use" of CUIs.  The [unstated] idea behind CUI
was that it would be converted back to the true user identity when received
at the home RADIUS accounting server, as a trusted extension of the home
RADIUS server, it is entitled to know how to decode the CUI contents.

Are you saying that the home provider expects to get a detailed bill from
each remote partner that includes connect minutes associated with each
corresponding CUI and will attempt to reconcile that bill for potential
fraud?

---

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

Following up on my last posting...

> Are you suggesting that NASes keep a "denied parties list" or
> "blacklist" of CUIs?

Well, that clearly makes no sense.  What was I thinking?  The NAS would have
no CUI for comparison until the home AAA server round trip was completed.

I guess I'll stop hypothesizing and let you explain what it is you're trying
to accomplish. :-)

---

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Aug 2009 15:38:15 +0200

Hi,

I should have been more verbose...

> AAA server?  Or do you have some other thought in mind?

It is about proper, service-eligible users that conduct unappropriate
actions while logged in at some point of presence. Like, downloading
terabytes of data via peer to peer links on sites that have spelled out
to forbid this kind of usage. An access network may want to prevent this
user from re-entering the network; but that is a local decision of that
access network only.

> be permanently banned.  No?

That's correct. The user would be banned throughout the (potentially
huge) roaming infrastructure, since the home AAA's decision is a global
one. If other access networks in the infrastructure do allow
peer-to-peer traffic, it would be unjust to Reject the user from the
home AAA side.

>> re-connect, and evade blocking measures ...

With the (limited) user identification of RADIUS, a NAS can only act
upon properties like MAC address and EAP outer identity. This check
would be during the authentication phase. Since both parameters are
insufficient, a CUI would be transferred on Access-Accept as an opaque,
permanent, handle of the user, tied to (but to preserve privacy, not
reverse-calculatable to) the inner identity. Then the access network can ...

> "denied parties list" or "blacklist" of CUIs?

... do exactly that: blacklist the CUI in question.

> Nor has there event been one in RADIUS.

True. But when operating a clearing-house, it could be made one of the
duties of the clearing-house to tag incoming requests per service
provider according to the source.

> certain circumstances.  You simply have to trust the proxies.

Sure. The proxy is trusted, and in the particular case is trusted to add
the correct service provider identifier. This whole topic is *not* about
distrusting proxies, it's about distrusting end users and being able to
convey reliable information about them across the infrastructure.

> corresponding CUI and will attempt to reconcile that bill for potential

Since it's not my own example, merely a use-case quote from the RFC, I
can't say much more about the intent. The RFC says that a home server
might want to change the CUI per billing period; I say that there might
be different billing periods for multiple service providers hidden
behind the same proxy, and so the home server needs to know who exactly
asked for auth. And that's it.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 10 Aug 2009 15:47:54 +0200

Hi,

> Exactly what normative text of the RFC do you think prohibits you from using

It is of course possible to use long-lived IDs. Our concern comes from
using long-lived, *globally valid* IDs. If there are many service
providers in an infrastructure, and all get the same CUI, they could
co-operate and create a mobility profile for the user.
One approach is to keep a global CUI, but make its lifetime rather
short. That is not the intention of CUI as a semi-permanent identifier
though. So we are trying to pursue this other way; but then, a handle to
distinguish service providers from one another becomes necessary.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

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

Stefan Winter writes...

> It is of course possible to use long-lived IDs.

OK.

> Our concern comes from using long-lived, *globally
> valid* IDs.

Globally valid?  CUI was intended to be valid only to its issuer, i.e., it's
a "cookie".  All other bets are off.  I see that your use case requires a
globally unique surrogate user identifier that NASes and Proxies can use to
build user blacklists.  I'm not sure that the definition of CUI exactly fits
the bill, in that it's possible for two disjoint home AAA servers to issue
the same CUI for completely different users.  Unlikely, perhaps, but
possible.

> That is not the intention of CUI as a semi-permanent identifier
> though. 

Correct.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 11:05:21 -0400

Stefan Winter writes...

> It is about proper, service-eligible users that conduct
> unappropriate actions while logged in at some point of
> presence.

Ah.  Bad boys on vacation.  :-)

> The user would be banned throughout the (potentially
> huge) roaming infrastructure, since the home AAA's
> decision is a global one. If other access networks in 
> the infrastructure do allow peer-to-peer traffic, it 
> would be unjust to Reject the user from the home AAA side.

Unjust?  Well, that's a moral judgment.  Banning the user from *all*
networks in the consortium would certainly be an effective "punishment" to
incent the potentially errant user to carefully follow the rules of *any*
network that they choose to visit.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Mon, 10 Aug 2009 17:18:01 +0200

David,
  let me jump in here.
> the same CUI for completely different users.  Unlikely, perhaps, but
Well, CUI is intended for mainly accounting purposes, and it is passed
from the home AAA server of the user to the visited organisation, which
can then do its accounting based on the CUI value and pass the bill to
the home site. Right?

CUI is supposed to persistent (or semi-persistent) but in a structure
like eduroam, where the home institution does not know where the user
currently is, we would have no option but to set the CUI to the same
value (for a given amount of time), regardless of the user location.
This is what Stefan calls a "globally valid" CUI. For our needs (and
probably also for most other roaming scenarios) it only matters that the
CUI for a given user stays the same when communicated to the same
visited network. If it is another network, then we can use another CUI
value.
We do not want to have a chance of sites collecting their data together
and create user mobility profiles.
So, when we generate the CUI value we want to feed in the User-Name and
the visited network identifier and produce an opaque value.

This is why we want a visited network identifier passed to the home
institution.

Cheers
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

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 11:35:18 -0400

Thomas Wolniewicz writes...

> We do not want to have a chance of sites collecting
> their data together and create user mobility profiles.

Ah.  CUI can accommodate that, in terms of accounting behavior.  As long as
the home AAA server retains all bindings between CUI and the actual user
identity for as long as may be needed for billing reconciliation, it can
issue a unique CUI for every authenticated "session".

That would preclude third parties from tracking the user's roaming behaviors
based on matching up CUI values.  Of course, it would also preclude third
parties from building user blacklists based on CUI values.

> So, when we generate the CUI value we want to feed in the
> User-Name and the visited network identifier and produce an
> opaque value.

I see.  You want a CUI that is re-used for access via a single remote access
provider, for purposes of blacklisting, but not re-used across multiple
providers to prevent them from sharing data and tracking user roaming
patterns.

That much is now clear.

> This is why we want a visited network identifier passed to
> the home institution.

Yep.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Mon, 10 Aug 2009 19:21:56 +0200

David,
  user blacklisting based on and observed misbehaviour is just one of 
the use cases for CUI in eduroam, but there are more.

1. Timely reaction to incidents - if something happens the visited 
institution may have to react at once, by blocking the particular user. 
Going to the home institution and blocking the user there may be the 
next step, but this always takes time. Without CUI the visited site 
would have to block an entire realm until the incident is resolved.

2. Long-time associations. This is actually the case that got me started 
on this subject. eduroam has been created to enable user mobility and 
casual guest access. Now suppose we have two eduroam institutions in one 
city. A student of institution A may set up a permanent wireless link to 
the network of institution B.This is not the kind of guest access that 
most of educational institutions will find desirable. If the user keeps 
changing the MAC address then institution B will have a difficulty 
spotting the actual problem. With CUI in place it is possible to employ 
some QoS and limit the bandwidth after so many bytes transferred. No 
need to track the user or contact the home institution, just apply and 
automatic policy.

3. Promoting the user access rights. A positive example, for a change. 
Suppose we gave an official guest at the university and we want to 
provide him with some extra services. CUI will allow us to place the 
user in a special VLAN and allow printing, for instance. This is a lot 
easier then creating a local account and setting up the user access 
based on that.

4. Guest usage statistics. This is probably self-explanatory.

All these cases require a reasonably long-life CUI, actually we think of 
a permanent one (but changing from one visited institution to another).

> network that they choose to visit.
Indeed, but please observe that eduroam is a global project. Accessing a 
certain WWW site could be regarded unacceptable in one country, but 
quite OK in another. We do not want to place the home site administrator 
in a position where he has to take moral judgements whether to ban a 
user from entire eduroam or not. It really is a lot easier to allow the 
local site admin to block the user. Of course, it the user breakes the 
local law then this is another case, but then the law enforcement 
agencies should come in and it will be up to them to reach the home 
institution of the user in order to obtain the actual identity.

Greetings

Tomasz Wolniewicz

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 13:42:43 -0400

Tomasz Wolniewicz writes...

> ... user blacklisting based on and observed misbehaviour
> is just one of the use cases for CUI in eduroam, but there
> are more.

It's often very useful to enumerate and explain all the relevant use cases.

> 3. Promoting the user access rights. A positive example,
> for a change.  Suppose we gave an official guest at the 
> university and we want to provide him with some extra 
> services. CUI will allow us to place the user in a special
> VLAN and allow printing, for instance. This is a lot
> easier then creating a local account and setting up the
> user access based on that.

You're going to set up a local "shadow" user authorization database, keyed
on CUI values, to add, remove and modify user access permissions?  Hmmm.
Good luck managing that.  You potentially have no way to link the real user
identity to a CUI at the remote site, but you think it can be useful for
creating a supplementary authorization service?  I can foresee all sorts of
operational problems with such a scheme.  As I say, good luck with that.  I
see no direct conflict with RADIUS services or attributes.  It's just that
sometimes CUI can only be related to a specific session, and its
packet-level behaviors, and not to a person.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 10 Aug 2009 13:50:17 -0400

> I see no direct conflict with RADIUS services or attributes.

On the other hand, it does appear that your use cases place additional
requirements on the properties of CUI beyond what is defined in the RFC.
RADIUS Servers that are fully compliant to the RFC may not work well in the
eduroam scenarios you describe.

---

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

> packet-level behaviors, and not to a person.
I think these would be some fairly special cases. Having the MAC address 
of a user and his realm we may find out the CUI value. We can also ask 
the user to get the value form his home institution. All this sounds 
fairly clumsy, I agree. Perhaps it is not terribly useful, perhaps we 
will go for a more complicated system of sending additional user 
attributes by other means. I am not going to defend this user case too 
strongly, time will show if it holds water.

Tomasz

---

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

Pasi Eronen writes...
 
> Many of the other attributes in RFC 5580 indeed have
> complex encodings, but using Operator-Name doesn't
> necessarily require anything new from the RADIUS server...
> The "Namespace ID" values are intentionally printable ASCII
> digits, so you could treat the whole attribute as one string,
> and put something like 'if Operator-Name == "1example.com" 
> then...' in your RADIUS configuration.

Yeah.

At the risk of appearing to beat a very dead horse, I'll observe that the
notion of RADIUS attribute re-use, outside the original area of application,
is yet another reason to use simple attributes that comply with the RADIUS
Design Guidelines.

Sigh.

---

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

> The main reason why we have brought up this problem on this
> list was to draw attention to the fact that the standard
> could take our approach into account.

Well, we can't amend RFC 4372 (CUI), but you could write an Informational
RFC for eduroam usage that explains its additional requirements for CUI.
Implementers targeting eduroam usage could then take those requirements into
account.  There is a history of "RADIUS Usage" documents for specific
applications areas, such as RFC 3580 (802.1X), which do not re-define
attributes, but explain how they are used for a particular application.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Aug 2009 19:31:34 -0700

Stefan Winter [mailto://[email-masked]] writes:

> encoding of 5580 attributes to parse the content of Operator-Name. 

The encoding of the attributes in 5580 isn't really so unusual: similar
encodings have been around for years (see the CHAP-Password (RFC 3588) & the
tunnel attributes (RFC 2868)).  

...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Aug 2009 19:58:08 -0700

> is yet another reason to use simple attributes that comply with the

OK, I'll bite: why?  Either the server & client support the attributes in
question or not, regardless of whether they follow those guidelines.  

> Sigh.

Indeed.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Tue, 11 Aug 2009 08:06:54 +0200

> tunnel attributes (RFC 2868)).  
The expected use of the Operator-Name attribute is, obviously, to carry
a unique operator identifier, be it a registered domain name or some
officially assigned id. For some applications, a global identifier is
not required or perhaps even harmful. I do not feel too happy about
eduroam Access-Request packets possibly carrying a user certificate with
his real name, or an unhidden e-mail address, accompanied by the domain
name of the visited network. It's true, that home institutions should
take care that users do not display their true identity and one could
say, why should we be worried if they do not do that, but still, we
(eduroam) do not need this open identifier of the institution. In fact,
the visited network could produce a different identifier for every realm
it needs to contact.

So now a suggestion. Would it be acceptable to register a namespace ID
for "private" usage, Something like the private IP address classes.
Operator-Name value tagged this way, would then be known to contain
stuff, that is not guaranteed to be universally unique and does not
adhere to any universal syntax (except being ASCII text).

Regards
Tomasz Wolniewicz

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 11 Aug 2009 08:06:29 -0400

> So now a suggestion. Would it be acceptable to register a 
> namespace ID for "private" usage, something like the private
> IP address classes.  Operator-Name value tagged this way,
> would then be known to contain stuff, that is not guaranteed 
> to be universally unique and does not adhere to any universal
> syntax (except being ASCII text).

Wait.  Now you've got me confused.  I though that Operator-Name was being
proposed, in the eduroam usage scenario, to carry the name of the visited
network.  In other words, the name of a consortium member.  Do you mean to
convey that the names of the visited networks, the eduroam consortium
members, are also considered private and sensitive?  Gee...

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 11 Aug 2009 08:25:57 -0400

Glen,

> OK, I'll bite: why?

You I have always disagreed over what constitutes a clean and easily
re-usable format for attributes, and I wouldn't expect that to change
anytime soon.

My point here is that the "exclusion" in the RADIUS Design Guidelines draft
for certain classes of attributes (*) falls down when someone wants to
re-use one of the heretofore "excepted" attributes in another application
area, one which nicely fits into the traditional RADIUS data model (**).

(*) The "exclusion" is for any attribute that is related to "security", is
intended for parsing and action by some "plug-in" element that's outside the
RADIUS server proper (such as GEOPRIV), or in general for some application
where new code is absolutely required on the server.

(**)  The traditional RADIUS data model supports single-valued attributes
and data dictionary driven RADIUS Servers.  Yes, there are existing RFCs
that deviate from this model, slightly.  The idea here is to "protect" the
ability of data dictionary driven RADIUS server implementations to add new
attributes simply as dictionary entries.  Complex, multi-part "string"
attributes cannot be added in this fashion.  They require custom parsing
code.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Tue, 11 Aug 2009 14:25:55 +0200

> members, are also considered private and sensitive?  Gee...
Well, not the names of consortium members, but fact that a particular
user is in a particular location is, of course, private and sensitive.
Quoting from the abstract of RFC 5580:

   The distribution of location information is a privacy-sensitive task.
   Dealing with mechanisms to preserve the user's privacy is important
   and is addressed in this document.

Since the visited network does not bill us for our users, we have no
reason to know where our user is, but more importantly, we would not
want this information to travel in the open.

We want to have the Operator-Name (or equivalent) for just one reason -
when we generate the CUI we want to do something like:
md5(User-Name:Operator-Name:local_salt)
This way we will have different CUIs for the same user visiting
different networks and we will also be safe against a dictionary attack
against the User-Name when the Operator-Name is known).

Tomasz

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 11 Aug 2009 08:42:33 -0400

>    and is addressed in this document.

Well, GEOPRIV is all about specifying the rather react location of
particular users.  Certainly some of that level of concern spills over to
the eduroam use case, but I don't see them as analogous.  Still, that's
really none of my concern.  I'm only interested in how RADIUS attributes are
re-used in this case.

> want this information to travel in the open.

OK, that sounds a bit paranoid.  If the user wants to maintain true
anonymity, they will need to use EAP methods with an anonymous outer
identity.  In that case all that can be detected is the number of users
visiting a particular university on a particular day, not their identity.
I'll admit there is *some* information there, but if you're going to perform
traffic analysis of eduroam traffic, that kind of information is going to
come out anyway.

> md5(User-Name:Operator-Name:local_salt)

Sure.  You don't need it to be the actual name of an operator.  I
understand.  What I'm challenging is whether it's acceptable practice to
overload an existing RADIUS attribute to carry a new data object.  Including
a "unique but meaningless salt" in an attribute defined to hold a human
readable operator name sounds attribute overloading to me.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 11 Aug 2009 09:05:54 -0400

> particular users.

Arrgh!  s/react/exact/

(and damn the auto-spell-correct feature of my client, that I've forgotten
how to turn off)

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Tue, 11 Aug 2009 15:26:21 +0200

> traffic analysis of eduroam traffic, that kind of information is going to
It *is* paranoid. I quite agree. Personally, I do not mind if people
know where I am. But there are plenty of paranoid people out there and
we do not want to loose the potentially useful thing like an opaque user
identity by doing something that will be challenged.
> readable operator name sounds attribute overloading to me.
But this is exactly what I would want to avoid.

Frankly, I think that this  discussion is going in the wrong direction.
We definitely would not want to use any attributes in a way that they
have not been designed for.

Perhaps I should repeat our case.
We would like to use the Chargeable-User-Identity attribute and this
seems to fall within its expected usage.
We have found out that we would need some visited-network identifier to
be fed into the CUI generation algorithm.
While looking at that, we have also realised that this network
identifier could be relevant also for other possible CUI applications
and this is why Stefan asked the list. Then the Operator-Name was
suggested and this looked like just the thing. But now it looks like we
would want to overload the attribute, so probably we are back to square
one. :(
I still think that providing an option for the Operator-Name to carry
something Operator-Name related, but otherwise not obvious, could be
useful in various applications, but perhaps the future will show the
need for yet another attribute for this purpose.

Of course there is an option of using a new VSA and keep it all internal
to eduroam.

Tomasz

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 11 Aug 2009 10:52:21 -0400

> I still think that providing an option for the Operator-Name
> to carry something Operator-Name related, but otherwise not
> obvious, could be useful in various applications...

In other words, an obfuscated name for the operator.  From a security
(privacy protection) perspective, simply using an obfuscated name for each
visited network won't provide very much protection if the same name string
is used in each request, as the operator's name can likely be derived by
correlating the source of the messages with the obfuscated name.  If the
messages are originating from an IP address assigned to foo.edu, it's a safe
bet that the obfuscated name stands for Foo University.  :-)

I think you may want to create a threat model to enumerate the adversaries
that can discover and misuse personal information, and then see how to
design the protocol to address the attack opportunities presented in that
threat model.
  
> Of course there is an option of using a new VSA and keep it
> all internal to eduroam.

You could also do that.

---

From: Tomasz Wolniewicz <[email-masked]>
Date: Tue, 11 Aug 2009 17:18:22 +0200

> bet that the obfuscated name stands for Foo University.  :-)
Not quite :). The messages carry the NAS-IP-Address, which (in very many
cases) can be something like 192.168..,
but I admit that this can be a give away. Since the messages pass
thorough proxies the actual source of the request is lost on the way.
> design the protocol to address the attack opportunities presented in that
Let's say that we want to use a best effort here. We do not want to
transport and collect data that we do not need for the system to work.
The current eduroam structure is not perfect in many respects. The next
model should be direct server connections based on RadSec, without any
proxy structure. In this model, the Operator-Name will not be needed, as
the peers will know each other and the AAA server will be able to
generate the CUI differentiating between the networks. Therefore we are
discussing a temporary model here, however this temporary state may take
several years.

RADIUS over UDP is not a very secure transport, while RadSec will be. So
we do not want to invest too much time designing something perfect, when
we already have the candidate.

While I am at it, I should perhaps add, that the entire project is based
on CUI implemented in the server and not in the NAS. With help from Alan
DeKok we have a working FreeRADIUS implementation. This way we are able
to introduce CUI on a large scale, in spite of the lack of NAS-based
support.

Tomasz

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 10:19:48 -0700

> where new code is absolutely required on the server.

This is very a very interesting statement.  
> that deviate from this model, slightly.  

2865, 2868, 3162, 4675.  The "tradition" you venerate seems to be of fairly
recent vintage... 

> The idea here is to "protect"
> the
> attributes simply as dictionary entries.  

What is being "protected" seem not to be so much the _idea_ of data-driven
dictionaries but the existing, simplistic _implementations_ thereof...

> Complex, multi-part "string"

If, after 9+ years of the existence of so-called "complex" attributes, your
programmers haven't managed to create a simple data-driven machine to parse
them, maybe you need new programmers...

---

From: Alan DeKok <[email-masked]>
Date: Tue, 11 Aug 2009 21:00:50 +0200

> dictionaries but the existing, simplistic _implementations_ thereof...

  Let's look at the statistics.  For the dictionaries I have:

attributes:		4294
	integer		2045
	text		1606
	ipaddr		278
	string		259
	byte		40	(unsigned 8-bit integer)
	date		30
 	ipv6addr	15
	short		14	(unsigned 16-bit integer)
	ascend filter	6	(Ascend)
	ipv4/ipv6addr	5	(ipv4 or ipv6 address)
	ifid		4
	ipv6prefix	3
	signed		1	(signed 32-bit int)

  13 data types in wide use, of which 5 are vendor extensions.

  The "complex" attributes have all been lumped together into the
"string" category.  All together, they account for about 6% of attributes.

  This means that about 95% of the attributes in wide use follow the
RADIUS data model, as described in the guidelines document.

  That's good evidence that the data model is not only in wide use, but
that it is widely useful.

> them, maybe you need new programmers...

  The design guidelines is opposed to the *gratuitous* use of complex
types.  Such use indicates that you've hired people who prefer complex
solutions to simple ones.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Aug 2009 15:18:17 -0700

> that it is widely useful.

What does this have to do with whether or not "complex" attributes can be
handled by a dictionary-based server?  

> solutions to simple ones.

I'm unaware of any technical usage for the word "gratuitous"; it seems most
useful in the context of a value judgment.  Aside from that, your response
seems to be (again) utterly disconnected from my assertion.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 12 Aug 2009 07:27:23 +0200

Glen Zorn wrote:
>Alan DeKok wrote:
>> types. ...
> I'm unaware of any technical usage for the word "gratuitous";

  The design guidelines document clearly states when complex attributes
are necessary, and when they are not.  The unnecessary use of something
fits the common meaning of the word "gratuitous".

  If you like, we could update the design guidelines document to use the
word "gratuitous".

> it seems most

  You're playing word games, and claiming to not understand things that
have been explained and well understood for years.  If you think this
means I'm avoiding your assertion, fine.

  It seems like you're trying to win a logical argument by re-defining
the words "logic" and "argument".

  Alan DeKok.