[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NAI decoration: User Identity issues
I must admit that some of that went over my head, but let me see if I understood the problem, I would appreciate it very much, if somebody can tell me if this is correct:
The user uses an aliased user-name (the decorated NAI) to hide its true identity from attackers. The decorated NAI (user-name (1), true?) is routable through AAA infrastructure.
However, the AAA server and its authentication and accounting mechanisms operate use a separate billable identity as the index to their record & databases.
The user originally does not know its billable identity or won't signal it in the clear.
A NAS receiving an authentication/ service request from the user, gets a decorated NAI from the user, builds an access request with that identity. A NAS in the roaming environment does not have any state on the user, who is contacting the NAS for the first time, neither does the NAS have a mapping rule, so the auth. request only includes the decorated NAI.
The AAA server based on its records finds the billable identity from the decorated NAI and responds with an access accept that includes the billable identity (either tunneled inside the NAI or along with that NAI, i.e. as two attributes).
I have a hard time seeing how anybody else but the AAA server can do this translation or rewrite (during the first authentication request) without having a state and without breaking the signaling. It seems that the access accept would have to send both identities to the NAS for future use and only then in the following access requests, the NAS can do the rewrites itself.
Is this understanding correct?
Thanks in advance,
Madjid
-----Original Message-----
From: Blair T. Bullock [mailto:bbullock@ipass.com]
Sent: Wednesday, July 14, 2004 4:42 PM
To: Nakhjiri Madjid-MNAKHJI1; Adrangi, Farid; Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: NAI decoration: User Identity issues
The problem with Home Authentication persistence of additional
decorations is that it must be provisioned that way from the start with
Aggregator and Reseller information in order to 'normalize' the
user-name. A provisioning nightmare.
For the Aggregation proxy systems to re-decorate the user-name as it
returns in the Access-Accept requires statefulness between auth and acct
events; undesirable.
Someone said:
"In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not. For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute."
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.
There needs to be a distinction between the User-Name used for RADIUS
routing which must go unmodified and appear as originally presented to
the NAS and an Authenticated-User which is the Billable authenticated
user applied to the accounting in a separate attribute with a value
derived from the User-Name in the Access-Accept. This way the OTA
transmitted routable user-name may be an anonymous/alias, decorated
promiscuously with no ill-effect and all AAA events take the same path
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.
From a Roaming Aggregation standpoint, the only other alternative is to
not pass the user-name back in the Access-accept to maintain the
originally presented NAI. Also, to maintain service oversight and fraud
detection with Tunneled-Methods, there will most likely need to be
checking to ensure that the Inner and Outer identities are identical at
a 'root' NAI level (regardless of additional chained suffixes or
prefixes to facilitate routing and session data) to protect against
hackers. Such equivalency checking would then preclude "anonymous"
transport unless specifically handled by the intermediary.
-Blair
-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
Sent: Wednesday, July 14, 2004 12:30 PM
To: 'Adrangi, Farid'; Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: NAI decoration: User Identity issues
Can somebody point me to a drafts/ literature describing different
methods of NAI decoration (prefix/ suffix based) and their rewrites by
the AAA infrastructure?
Thank you in advance,
Madjid
-----Original Message-----
From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: radiusext@ops.ietf.org
Subject: RE: User Identity issues
Hi Bernard,
Please see my responses inline.
BR,
Farid
>
> As Blair notes, there are cases where the Accounting data needs to
> follow the same path as Authorization, and User-Name rewriting can
> break that.
It depends. The routing is done based on the realm and/or prefix/suffix
used for NAI decoration. In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI. For example, if the AAA
server receives UserName value Ananymous@anyisp.com in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like 2345@anyisp.com , where 2345 is the billable
identity. This should cause the accounting packets follow the same path
as the authorization.
When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server. Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
home.com!Ananymous@intermediary.com. Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request. Therefore, the UserName received by the AAA server
will be Ananymous@home.com. In this case, even if the AAA server puts
the received UserName value as is (i.e., Ananymous@home.com) in the
Access-Accept, this will appear to NAS like UserName rewrite.
However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/Ananymous@home.com) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/joe@home.com. The AAA server can return
intermediary.com/Ananymous@home.com or preferably
intermediary.com/2345@home.com (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.
> This argument against User-Name rewrite is more compelling than NAS
> compatibility or billing system compatibility since new attributes
> will also require changes to NASen and billing systems.
>
> I'd suggest that we need a discussion of the issues so that we can
> understand when it is safe to do User-Name rewriting, and when this
> can cause problems.
In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not. For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute.
>
> The major impetus for User-Name rewrite as I understand it is for use
> in privacy. There are also the cosmetic cases that Dave Mitton has
> mentioned (e.g. changing case) but I think these are relatively
> benign.
>
> So how do we go forward? There may need to be an errata submitted for
> RFC 3579. As Barney Wolff pointed out, the text of RFC 3579 is
> somewhat misleading; User-Name rewriting is not required for the
> routing of the Access-Accept back to the NAS; Proxy State can handle
> this.
>
RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept.
> I'd also like to understand if there are guidelines that a server can
> use to determine when User-Name rewrite is safe and when it isn't.
> For example, what if a user attempts to protect Privacy in a network
> set up as Blair has suggested? What breaks? Is there a way for the
> server to detect the situation and not cause problems?
>
> I also think that we need to discuss this in the Network Discovery
> Problem Statement, since if a user desires to influence the mediating
> network, then accounting supporting that decision needs to be carried
> out.
>
>
Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.
--
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/>
--
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/>