|
I do believe the approach y'all have presented solves the proxy
stripping, peering and accounting event correlation problem (to the solution) of
rewriting the originally presented NAI from the Access-Accept User-Name.
It obviates the present need to overload another attribute to fill the identity
gap problem (to the solution) of Tunneled EAP methods (the best thing since
sliced bread IMO).
This will allow for truly anonymous, alias-based billing features while
maintaining support for service oversight, concurrency checking and fraud
detection (not to mention making isolation of compromised user profiles that
much easier) by drawing a direct per-session correlation between an
authenticated profile and source routed accounting events.
But I am preaching to the choir.... Being the IETF
newbie, I'm eager to see how this coalesces
Does everyone else have the distinct feeling we just avoided a huge
train wreck?
Blair
-----Original Message-----
From: Jari Arkko
[mailto:jari.arkko@piuha.net]
Sent: Wed 7/14/2004 10:11 PM
To: Bernard Aboba
Cc: Blair T. Bullock; Nakhjiri
Madjid-MNAKHJI1; Adrangi, Farid; radiusext@ops.ietf.org
Subject:
Re: NAI decoration: User Identity issues
I have now been convinced that the separation of
billable
and routing identities is necessary. So, I support the
creation
of an attribute that represents a billable
identity. A number of details
still needs to be worked
on, such as exactly what do we say about privacy,
what
format(s) are supported for the identity etc.
And then a
question from your NAIbis draft editor: does
this resolve the issue that
Farid raised earlier about
suffix-based decoration being rewritten by
proxies and
then returned in an Access-Accept, causing problems for
the
accounting requests? I think it does, but it seems
that we may have to, in
addition, publish an RFC 3579 errata
to indicate that returned User-Name
attributes should not
be used for accounting requests.
Comments?
--Jari
Bernard Aboba wrote:
>>Hallelujah, I
wholeheartedly concur with this statement. It is
>>basically
the same concept as the proposed Class usage for the purposes
>>of
user-name accounting data reflection, but specifically dedicated
to
>>the resolution of RADIUS-routable and billable identities in
Tunneled
>>EAP methods.
>
>
> This is an important
distinction because it allows the local ISP to know
> that a billable
identity has been returned without having to parse the
> Class attibute
which is supposed to be treated like opaque text. After
> all,
multiple Class attributes can be returned, some of which might
>
represent a billable identity, some might not. How is the local
operator
> to know? So I think a billable identity attribute is
required here.
>
>
>>the NAS and an Authenticated-User
which is the Billable authenticated
>
>
> The Billable
Identity is an identity used for accounting purposes, not
>
authentication. I hope we're clear on
that.
>
>
>>from a RADIUS standpoint... While also
maintaining an Authenticator
>>protected billable identity (or alias)
which is not transmitted over the
>>air, but represented by the NAS
from the value of the User-Name in
the
>>Access-Accept.
>
>
> In the case of Privacy,
it might not relate to the User-Name attribute at
> all. There is
no requirement that they match in any way.
>
>
>>not pass
the user-name back in the Access-accept to maintain
the
>
>
> That is always the RADIUS server choice, because
it is optional.
>
>
>>checking to ensure that the Inner
and Outer identities are identical at
>>a 'root' NAI level
(regardless of additional chained suffixes or
>
>
>
Careful. These identities may not relate to each
other.
>
>
> --
> 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/>
>
>
|