RE: NAI decoration: User Identity issues
Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> Thu, 15 July 2004 17:03 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 15 Jul 2004 17:04:19 +0000
Message-ID: <EBF631554F9CD7118D0B00065BF34DCB09EA1254@il27exm03.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Blair T. Bullock'" <bbullock@ipass.com>, "Adrangi, Farid" <farid.adrangi@intel.com>, Bernard Aboba <aboba@internaut.com>
Cc: radiusext@ops.ietf.org
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 12:03:48 -0500
MIME-Version: 1.0
Content-Type: text/plain
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/>
- RE: NAI decoration: User Identity issues Avi Lior
- Re: NAI decoration: User Identity issues Bernard Aboba
- Re: NAI decoration: User Identity issues Barney Wolff
- RE: NAI decoration: User Identity issues Avi Lior
- RE: NAI decoration: User Identity issues Avi Lior
- RE: NAI decoration: User Identity issues Avi Lior
- RE: NAI decoration: User Identity issues Avi Lior
- Re: NAI decoration: User Identity issues Barney Wolff
- RE: NAI decoration: User Identity issues Bernard Aboba
- RE: NAI decoration: User Identity issues Nelson, David
- RE: NAI decoration: User Identity issues Bernard Aboba
- RE: NAI decoration: User Identity issues Bernard Aboba
- RE: NAI decoration: User Identity issues Avi Lior
- RE: NAI decoration: User Identity issues Roy Albert
- RE: NAI decoration: User Identity issues Nelson, David
- RE: NAI decoration: User Identity issues Avi Lior
- Re: NAI decoration: User Identity issues Barney Wolff
- RE: NAI decoration: User Identity issues Nakhjiri Madjid-MNAKHJI1
- RE: NAI decoration: User Identity issues Bernard Aboba
- Re: NAI decoration: User Identity issues Bernard Aboba
- RE: NAI decoration: User Identity issues Blair T. Bullock
- Re: NAI decoration: User Identity issues Jari Arkko
- RE: NAI decoration: User Identity issues Blair T. Bullock
- RE: NAI decoration: User Identity issues Bernard Aboba
- RE: NAI decoration: User Identity issues Blair T. Bullock
- RE: NAI decoration: User Identity issues Blair T. Bullock
- NAI decoration: User Identity issues Nakhjiri Madjid-MNAKHJI1