Re: Chargeable-User-Identity

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

I should have been more verbose...

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

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.

> Well, if the home AAA server continually sends Access-Reject, the user would
> 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.

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

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

>> ...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?
>   

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

>   
>> ...since there is no reliable end-to-end identifier for
>> service providers...
>>     
>
> 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.

>> ... the home server may not know which business partner
>> it is talking to - it sees only the proxy's connection.
>>     
>
> 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.
>   

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.

>> 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.
>>     
>
> 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?
>   

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

-- 
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>