Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 31 Jul 2004 08:26:06 +0000 Message-ID: <035c01c476d8$9160f300$020aa8c0@FATCAT> From: "Randy Chou" To: "Barney Wolff" Cc: Subject: Re: Submission for RADIUS extensions working group Date: Sat, 31 Jul 2004 01:29:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Post under a pseudonym to bugtraq, Great. Now every anonymous post on bugtraq related to RADIUS will be blamed on me :). Seriously though, I'm looking for a way to get the vendors to understand the severity of not being compliant and also educate the consumer on the best practices when implementing Radius. > IPsec with a 6 byte shared key is not very secure either. :) > > There's no excuse for a vendor's not allowing an adequately long shared > secret. If RADIUS is actually insecure with a shared secret with at > least 128 bits of entropy, we need to hear about it and take action, > but unless I'm missing something that's not the case. That's the thing. How secure something is also depends on what and how it's used. By not incorporating IPSEC as a requirement, too many of the security decisions IMO are left to the consumer who a lot of times is not knowledgeable enough to make an educated decision. Not that I'm suggesting people to use 6-byte shared keys, but using it as an example...If I had an offline sniff of a RADIUS handshake that was encrypted with a 6-byte RADIUS shared key, I'd be able to decrypt that very easily. On the other hand, if I had the same handshake over IPSEC w/ a 6-byte IKE pre-shared key, I would never be able to decrypt that assuming DH is used (as it typically is). That's just one of the properties of IPSEC. Another example would be the case where a good enterprise uses RADIUS and rotates the RADIUS shared secret diligently say once every week. If a hacker sniffed RADIUS packets, stored it, and say somehow gets the shared secret 12 weeks later, he would still be able to get the contents. On the other hand if IPSEC was used in this case, the hacker would not be able to decrypt the contents even after he knew the IKE pre-shared key. This problem may or may not be serious depending on the application. If the contents were the keys that secured financial reports from a company, the decryption of the report 12 weeks later would matter much less (public knowledge by then) than compared to data that contained employee compensation. By not using IPSEC, we're settling for the lowest common denominator. But most consumers don't know the implications of that decision. Again, there are many other properties of IPSEC that are missing in RADIUS. To get to the same level of security would be re-inventing the wheel. I would assume this conclusion was reached back when RADIUS over IPSEC was already recommended in the RFC. However, few NAS vendors follow such recommendation. Anyways, let me know if you think we're still wasting your time. If not, we'd really like more feedback. We chose what we considered a set of examples that illustrated the severity of the problems. Regards, -- Randy ----- Original Message ----- From: "Barney Wolff" To: "Randy Chou" Cc: Sent: Saturday, July 31, 2004 12:00 AM Subject: Re: Submission for RADIUS extensions working group > On Fri, Jul 30, 2004 at 11:12:56PM -0700, Randy Chou wrote: > > Thanks for the feedback. Here are my comments... > > > > > A draft discussing faulty implementations, by name, would be useful. > > > So would problem reports to the vendors/authors of said faulty > > > implementations. > > > > A CERT was already sent. Unfortunately, discussion of the vendors by name > > is not a good way to approach this for hopefully obvious reasons. On the > > other hand, as you said, many of these vulnerabilities have been known for a > > while. If you have any other creative ideas on how to approach this, please > > do share. > > Post under a pseudonym to bugtraq, if you have actually notified the > vendor(s) and gotten no satisfactory response in a reasonable time. > Why on earth should RADIUS vendors be immune from having security > vulnerabilities pointed out when everybody else in the world is not? > > > > If one were going to expound on RADIUS vulnerabilities, the most > > > serious one in my opinion is that the CHAP response is unencrypted > > > > Everyone has their favorite one. I actually don't consider these > > vulnerabilities in RADIUS, but the lack of compliance to the standard itself > > in many NAS devices. If everyone ran RADIUS over IPSEC as recommended in > > the RFC, most of these issues would go away. Sometimes I wonder if it > > would've been better if none of the RADIUS handshakes were hashed. Then > > maybe people would've stopped using it to send keys around until they made > > sure the mechanism to transport it was truly secure. > > RADIUS hashing predates IPsec. One might argue that it should have been > dropped when IPsec became practical to run on all new equipment, but > just this week I saw somebody wanting to acquire a Portmaster to use for > multiple remote console access. Customers do tend to get upset when > equipment that still works is obsoleted by fiat, much as protocol > designers and developers might wish otherwise. > > IPsec with a 6 byte shared key is not very secure either. :) > > There's no excuse for a vendor's not allowing an adequately long shared > secret. If RADIUS is actually insecure with a shared secret with at > least 128 bits of entropy, we need to hear about it and take action, > but unless I'm missing something that's not the case. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 31 Jul 2004 07:01:33 +0000 Date: Sat, 31 Jul 2004 03:00:50 -0400 From: Barney Wolff To: Randy Chou Cc: radiusext@ops.ietf.org Subject: Re: Submission for RADIUS extensions working group Message-ID: <20040731070050.GA52366@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Fri, Jul 30, 2004 at 11:12:56PM -0700, Randy Chou wrote: > Thanks for the feedback. Here are my comments... > > > A draft discussing faulty implementations, by name, would be useful. > > So would problem reports to the vendors/authors of said faulty > > implementations. > > A CERT was already sent. Unfortunately, discussion of the vendors by name > is not a good way to approach this for hopefully obvious reasons. On the > other hand, as you said, many of these vulnerabilities have been known for a > while. If you have any other creative ideas on how to approach this, please > do share. Post under a pseudonym to bugtraq, if you have actually notified the vendor(s) and gotten no satisfactory response in a reasonable time. Why on earth should RADIUS vendors be immune from having security vulnerabilities pointed out when everybody else in the world is not? > > If one were going to expound on RADIUS vulnerabilities, the most > > serious one in my opinion is that the CHAP response is unencrypted > > Everyone has their favorite one. I actually don't consider these > vulnerabilities in RADIUS, but the lack of compliance to the standard itself > in many NAS devices. If everyone ran RADIUS over IPSEC as recommended in > the RFC, most of these issues would go away. Sometimes I wonder if it > would've been better if none of the RADIUS handshakes were hashed. Then > maybe people would've stopped using it to send keys around until they made > sure the mechanism to transport it was truly secure. RADIUS hashing predates IPsec. One might argue that it should have been dropped when IPsec became practical to run on all new equipment, but just this week I saw somebody wanting to acquire a Portmaster to use for multiple remote console access. Customers do tend to get upset when equipment that still works is obsoleted by fiat, much as protocol designers and developers might wish otherwise. IPsec with a 6 byte shared key is not very secure either. :) There's no excuse for a vendor's not allowing an adequately long shared secret. If RADIUS is actually insecure with a shared secret with at least 128 bits of entropy, we need to hear about it and take action, but unless I'm missing something that's not the case. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 31 Jul 2004 06:09:13 +0000 Message-ID: <026801c476c5$6d13de30$020aa8c0@FATCAT> From: "Randy Chou" To: "Barney Wolff" , "Bernard Aboba" Cc: Subject: Re: Submission for RADIUS extensions working group Date: Fri, 30 Jul 2004 23:12:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for the feedback. Here are my comments... > A draft discussing faulty implementations, by name, would be useful. > So would problem reports to the vendors/authors of said faulty > implementations. A CERT was already sent. Unfortunately, discussion of the vendors by name is not a good way to approach this for hopefully obvious reasons. On the other hand, as you said, many of these vulnerabilities have been known for a while. If you have any other creative ideas on how to approach this, please do share. > A draft pointing out, yet again, that shared-secret crypto depends > on an adequately long and not widely shared key, is not. We also wanted to point out the practicality of attacking and consequences of faulty implementations. > If one were going to expound on RADIUS vulnerabilities, the most > serious one in my opinion is that the CHAP response is unencrypted Everyone has their favorite one. I actually don't consider these vulnerabilities in RADIUS, but the lack of compliance to the standard itself in many NAS devices. If everyone ran RADIUS over IPSEC as recommended in the RFC, most of these issues would go away. Sometimes I wonder if it would've been better if none of the RADIUS handshakes were hashed. Then maybe people would've stopped using it to send keys around until they made sure the mechanism to transport it was truly secure. Regards, -- Randy ----- Original Message ----- From: "Barney Wolff" To: "Bernard Aboba" Cc: Sent: Friday, July 30, 2004 9:40 AM Subject: Re: Submission for RADIUS extensions working group > On Fri, Jul 30, 2004 at 07:48:03AM -0700, Bernard Aboba wrote: > > We have had a late submission relating to RADIUS security vulnerabilities. > > I've allocated time for discussion of this within the Thursday session. > > > > Since the draft submission deadline has closed, the document is available > > for examination here: > > http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt > > Since I won't be at the meeting, I'll make my comments here. > > A draft discussing faulty implementations, by name, would be useful. > So would problem reports to the vendors/authors of said faulty > implementations. > > A draft pointing out, yet again, that shared-secret crypto depends > on an adequately long and not widely shared key, is not. > > If one were going to expound on RADIUS vulnerabilities, the most > serious one in my opinion is that the CHAP response is unencrypted, > thus exposing users' secrets to offline attack. That makes user-chosen > CHAP secrets very risky. Hardly new news. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > > -- > 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: > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 30 Jul 2004 17:37:44 +0000 Date: Fri, 30 Jul 2004 10:33:47 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Radius MIBs statistics misunderstandings (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Wed, 28 Jul 2004 17:25:53 +0200 From: Nagi Reddy Jonnala To: gwz@cisco.com, radiusext@ops.ietf.org Cc: stefaan.de_cnodder@alcatel.be, 'Bernard Aboba' Subject: Radius MIBs statistics misunderstandings As suggested by Bernard, since the WG is revising the MIBs, this discussion might be generally useful. Glen, I would like to resolve these statistics misunderstandings once and for all. Could you please review if my understanding match with your interpretations. Issue-1: Stefaan asked: > Some questions we have regarding the existing RFCs (since you are > updating these) we found while writing our draft: > > 1) Is the definition o TotalIncomingPackets in RFC2618 on page 6 > correct? I believe there is something wrong with it. Glen replied: I think that you are right. With the curent definition, it appears that "Successfully Received" could be negative, since we're subtracting counters from TotalIncomingPackets that were not include in the sum. Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts = Successfully Received" just below should read "AccessRequests + PendingRequests + ClientTimeouts = Successfully Transmitted". Nagi commented: My understanding is that RFC-2618 considers that an Access Response (Accept or Reject or Challenge) counter MUST be incremented before it is validated. i.e., Either one of Malformed responses or bad authenticators or packets dropped counters will be incremented if the packet is invalid. Do you interpret the same from the RFC-2618. If yes, I would like to know what are the reasons for this. Isn't that an Access Response counter MUST be incremented only after the packet is found *valid*. If you are convinced that the approach in RFC-2618 is OK, then I would say that the first two equations hold good. i.e., Your statement above (saying Successfully_Received could be negative) is incorrect. Am I right? or missing something? Issue-2: Stefaan asked: > 3) radiusAuthClientPendingRequests: upon retransmission this counter > is decremented. So a retransmitted packet is not considered as being > pending, although such restransmissions can still be considered as > being pending requests. Glen replied: Yup, it probably shouldn't be decremented on retransmissions, especially since it's already decremented on timeouts. Nagi commented: My understanding is that Pending requests should be decremented on receiving an Access response and on an expiry of timeout. It looks obvious to me that Pending requests should be incremented on a retransmission (to the same server). Please see the text "This variable is incremented when an Access-Request is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout or retransmission." I suspect that the text is misleading. The text should be like "This variable is incremented when an Access-Request and retransmission is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout " Do you guys agree? Issue-3: See the equation: AccessRequests + PendingRequests + ClientTimeouts = Successfully Received I agree with you that left hand side value should be equal to "Successfully Transmitted". Also "AccessRequests + AccessRetransmissions = Successfully Transmitted" equation holds good. Right? Thanks & regards Nagi. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 30 Jul 2004 16:41:31 +0000 Date: Fri, 30 Jul 2004 12:40:30 -0400 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Submission for RADIUS extensions working group Message-ID: <20040730164030.GA64874@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Fri, Jul 30, 2004 at 07:48:03AM -0700, Bernard Aboba wrote: > We have had a late submission relating to RADIUS security vulnerabilities. > I've allocated time for discussion of this within the Thursday session. > > Since the draft submission deadline has closed, the document is available > for examination here: > http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt Since I won't be at the meeting, I'll make my comments here. A draft discussing faulty implementations, by name, would be useful. So would problem reports to the vendors/authors of said faulty implementations. A draft pointing out, yet again, that shared-secret crypto depends on an adequately long and not widely shared key, is not. If one were going to expound on RADIUS vulnerabilities, the most serious one in my opinion is that the CHAP response is unencrypted, thus exposing users' secrets to offline attack. That makes user-chosen CHAP secrets very risky. Hardly new news. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 30 Jul 2004 14:52:38 +0000 Date: Fri, 30 Jul 2004 07:48:03 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Submission for RADIUS extensions working group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We have had a late submission relating to RADIUS security vulnerabilities. I've allocated time for discussion of this within the Thursday session. Since the draft submission deadline has closed, the document is available for examination here: http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt ------------------------------------------------------------------- IETF Secretariat, Working Group Chairs, Please accept this draft submission for consideration as a working group document. Thank you, - -Josh - -- - -Joshua Wright The SANS Institute jwright@sans.org http://home.jwu.edu/jwright/ -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 30 Jul 2004 14:52:22 +0000 Date: Fri, 30 Jul 2004 07:48:20 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Thursday Agenda, Take One Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The Secretariat has been kind enough to allocate another session to the RADEXT WG. Below find our preliminary plan for the Thursday slot. RADIUS Extensions WG (radext) Thursday, August 5, 2004 0900 - 1130 (Marina 5) ================================================== CHAIRS: Bernard Aboba David Nelson AGENDA: Preliminaries (5 minutes) Bluesheets Meeting Minutes Agenda Bashing RADIUS Implementation Issues and Fixes (20 minutes) Various short (1-2 slide) presentations. If you're interested in presenting, send email to the chairs. RADIUS Data Model Issues (40 minutes) RADIUS RFC Data Model, Bernard Aboba, 10 minutes TBD RADIUS attributes extension, Farid Adrangi, 10 minutes http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-01.txt Diameter/RADIUS Compatibility Issues - Jari Arkko, 10 minutes http://ops.ietf.org/lists/radiusext/2004/msg00441.html http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-01.txt (Appendix A) Discussion, 10 minutes RADIUS Security Issues (30 minutes) RADIUS Security Vulnerability - Randy Chou, 10 minutes http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 10 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt Discussion, 10 minutes Wrap-Up (10 minutes) -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 29 Jul 2004 19:00:24 +0000 Date: Thu, 29 Jul 2004 11:56:06 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Slides for IETF 60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If you are presenting at IETF 60, please send your slides to David and myself. The schedule is packed so we are going to preload the slides on the laptop so as to avoid switching delays. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 21:41:13 +0000 Date: Tue, 27 Jul 2004 14:37:54 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: RE: Issue with 3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Actually, we are got another slot from the Secretariat, so we can give you separate time for this (on Thursday). So there is no need to cramp your other presentation to squeeze this in. On Tue, 27 Jul 2004, Avi Lior wrote: > Yes I will Bernard. Unfortunately we need to address the semantics issue. > I will include it as part of my slot. I don't think additional time will be > needed. I am going last anyway. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 21:32:20 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Issue with 3576 Date: Tue, 27 Jul 2004 17:31:59 -0400 MIME-Version: 1.0 Content-Type: text/plain Yes I will Bernard. Unfortunately we need to address the semantics issue. I will include it as part of my slot. I don't think additional time will be needed. I am going last anyway. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, July 27, 2004 3:30 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: RE: Issue with 3576 > > > > Okay I see my confusion: > > > > 1) Message-Authenticator SHOULD be included in an > Access-Request that > > does not contain....EAP-Message, > > > > 2) Message-Authenticator MUST be included in an Access-Request that > > contains EAP-Message. > > > > I am aware of item 2 but somehow when I read item 1) it seemed to > > exclude item 2). So I am okay now. > > I think the confusion with respect to the "Authorize Only" > semantics remain though, right? Would you be willing to > prepare a slide or two for IETF 60 to describe the issues? > > > > > It should be more explicit what the behavior is. For > example, we > > > > should state what happens when the Access-Accept with an > > > > Authorize-Only is received that doesn't contain attributes > > > that were > > > > previously received in an Access-Accept message. This is cause > > > > for lots of discussion. > > > > > > Yes, I do think we need to be more explicit on this. This can be > > > put into an errata (or the "implementations and fixes" > > > doc) once we figure this out. > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 20:08:22 +0000 Date: Tue, 27 Jul 2004 13:00:52 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT Monday Agenda, Take Seven Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The folks at the Secretariat have been generous enough to grant our request for an additional RADEXT session (on Thursday morning). As a result, we're in the process of reformulating our agenda. Here is a fresh take at the potential Monday agenda. The potential Thursday agenda is a work in progress at this point. RADIUS Extensions WG (radext) Monday, August 2, 2004 1300-1500 (Marina 5) ======================================== CHAIRS: Bernard Aboba David Nelson AGENDA: Preliminaries (15 minutes) Bluesheets Meeting Minutes Agenda Bashing Liaison Requests See: http://www.drizzle.com/~aboba/RADEXT/liaisons/ Issues List Review Procedures Document Status Management Issues (30 minutes) IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 10 min http://www.ietf.org/rfc/rfc2618.txt http://www.ietf.org/rfc/rfc2619.txt http://www.ietf.org/rfc/rfc2620.txt http://www.ietf.org/rfc/rfc2621.txt RFC 3576 MIBs - M. Chiba, 10 minutes http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt RADIUS Management Issues - David Nelson, 10 minutes http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-00.txt SIP-RADIUS (10 minutes) Digest Authentication in RADIUS - W, Beck, 10 minutes http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt (W)LAN applications (45 minutes) RFC 2486bis - Jari Arkko, 10 minutes http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt EAP lower layer attribues for AAA protocols - David Mariblanca, 10 minutes http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt IEEE 802 attributes - Paul Congdon, 10 minutes http://www.drizzle.com/~aboba/IEEE/draft-congdon-radext-ieee802-01.txt Re-direction Support - Avi Lior, 5 minutes http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt Bandwidth Attributes - Farid Adrangi, 10 minutes http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt Pre-Paid (20 minutes) RADIUS Prepaid - Avi Lior, 10 minutes http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-05.txt Prepaid Extensions to RADIUS for Event-Based Charging - H. Tschofenig, 10 minutes http://www.ietf.org/internet-drafts/draft-guenther-radext-ppebc-00.txt -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 19:41:02 +0000 Date: Tue, 27 Jul 2004 12:37:42 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Presentations on Interoperability Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII During the last few months we have talked about a number of interoperability issues that have arisen. For example, Avi has mentioned some lack of clarity in RFC 3576, we've talked about problems with the use of User-Name for accounting identification, etc. I have set aside some time on the RADEXT WG Agenda for discussion of "RADIUS Implementation Issues". If you have something that fits in this category that can be presented in a few slides with say, 5 minutes of airtime, send email to myself or David. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 19:33:56 +0000 Date: Tue, 27 Jul 2004 12:30:29 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: RE: Issue with 3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Okay I see my confusion: > > 1) Message-Authenticator SHOULD be included in an Access-Request that does > not contain....EAP-Message, > > 2) Message-Authenticator MUST be included in an Access-Request that contains > EAP-Message. > > I am aware of item 2 but somehow when I read item 1) it seemed to exclude > item 2). So I am okay now. I think the confusion with respect to the "Authorize Only" semantics remain though, right? Would you be willing to prepare a slide or two for IETF 60 to describe the issues? > > > It should be more explicit what the behavior is. For example, we > > > should state what happens when the Access-Accept with an > > > Authorize-Only is received that doesn't contain attributes > > that were > > > previously received in an Access-Accept message. This is cause for > > > lots of discussion. > > > > Yes, I do think we need to be more explicit on this. This > > can be put into an errata (or the "implementations and fixes" > > doc) once we figure this out. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 19:13:21 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: Murtaza Chiba , david@mitton.com, radiusext@ops.ietf.org Subject: RE: Issue with 3576 Date: Tue, 27 Jul 2004 15:13:03 -0400 MIME-Version: 1.0 Content-Type: text/plain Okay I see my confusion: 1) Message-Authenticator SHOULD be included in an Access-Request that does not contain....EAP-Message, 2) Message-Authenticator MUST be included in an Access-Request that contains EAP-Message. I am aware of item 2 but somehow when I read item 1) it seemed to exclude item 2). So I am okay now. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, July 27, 2004 10:49 AM > To: Avi Lior > Cc: Murtaza Chiba; david@mitton.com; radiusext@ops.ietf.org > Subject: Re: Issue with 3576 > > > > I found a minor bug in 3576 ( I don't know if this one was reported > > yet) > > > > Deep down in Note[6] it says: > > > > a Message-Authenticator attribute SHOULD be included in an > > Access-Request that does not contain a User-Password, > CHAP-Password, > > ARAP-Password or EAP-Message Attribute. > > The complete quote is: > > As noted in [RFC2869] Section 5.19, a Message-Authenticator > attribute SHOULD be included in an Access-Request that does > not contain a User-Password, CHAP-Password, ARAP-Password or > EAP-Message Attribute. > > Note [6] applied to the Service-Type attribute, in order to > remind implementers that Service-Type="Authorize Only" could > not be sent in an Access-Request without a > Message-Authenticator attribute. > > > The inclusion of EAP-Message in an Access-Request however > does require > > Message-Authenticator. > > Yes, that is required (in [RFC2869] and [RFC3579]). Since > the quote references those documents, I don't think there is > a contradiction. > > > As well, unless I am missing something, 3576 does not say what the > > semantics of the Re-authorization Access-Request message. > > Note [6] says: > > "the NAS should attempt reauthorization by sending an Access- > Request with a Service-Type Attribute with value "Authorize > Only". The (perhaps naive) assumption is that these > Access-Request messages would otherwise obey RFC 2865. > > > It just eludes to the fact > > that it is there to ease interop between RADIUS and > DIAMETER. Reading > > between the line then one would conclude that they have to read > > diameter to understand the semantics. In fact NASREQ right? > > NASREQ does contain the discussion on the translation of > server-initiated messages between RADIUS and Diameter. Among > other things, we discovered in the process of writing those > sections that the RFC 3579 discussion of translation of > Disconnect-Request messages is wrong; Diameter supports the > Disconnect-Request/ACK model, so that an "Authorize Only" > Disconnect-Request is not necessary. That is a pretty > significant error, so an errata is probably needed for that. > > > It should be more explicit what the behavior is. For example, we > > should state what happens when the Access-Accept with an > > Authorize-Only is received that doesn't contain attributes > that were > > previously received in an Access-Accept message. This is cause for > > lots of discussion. > > Yes, I do think we need to be more explicit on this. This > can be put into an errata (or the "implementations and fixes" > doc) once we figure this out. > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 17:53:10 +0000 Date: Tue, 27 Jul 2004 10:49:25 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: Murtaza Chiba , david@mitton.com, radiusext@ops.ietf.org Subject: Re: Issue with 3576 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I found a minor bug in 3576 ( I don't know if this one was reported yet) > > Deep down in Note[6] it says: > > a Message-Authenticator attribute SHOULD be included in an Access-Request > that does not contain a > User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The complete quote is: As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. Note [6] applied to the Service-Type attribute, in order to remind implementers that Service-Type="Authorize Only" could not be sent in an Access-Request without a Message-Authenticator attribute. > The inclusion of EAP-Message in an Access-Request however does require > Message-Authenticator. Yes, that is required (in [RFC2869] and [RFC3579]). Since the quote references those documents, I don't think there is a contradiction. > As well, unless I am missing something, 3576 does not say what the semantics > of the Re-authorization Access-Request message. Note [6] says: "the NAS should attempt reauthorization by sending an Access- Request with a Service-Type Attribute with value "Authorize Only". The (perhaps naive) assumption is that these Access-Request messages would otherwise obey RFC 2865. > It just eludes to the fact > that it is there to ease interop between RADIUS and DIAMETER. Reading > between the line then one would conclude that they have to read diameter to > understand the semantics. In fact NASREQ right? NASREQ does contain the discussion on the translation of server-initiated messages between RADIUS and Diameter. Among other things, we discovered in the process of writing those sections that the RFC 3579 discussion of translation of Disconnect-Request messages is wrong; Diameter supports the Disconnect-Request/ACK model, so that an "Authorize Only" Disconnect-Request is not necessary. That is a pretty significant error, so an errata is probably needed for that. > It should be more explicit what the behavior is. For example, we should > state what happens when the Access-Accept with an Authorize-Only is received > that doesn't contain attributes that were previously received in an > Access-Accept message. This is cause for lots of discussion. Yes, I do think we need to be more explicit on this. This can be put into an errata (or the "implementations and fixes" doc) once we figure this out. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 27 Jul 2004 15:34:49 +0000 Message-ID: From: Avi Lior To: Bernard Aboba , Murtaza Chiba , david@mitton.com Cc: radiusext@ops.ietf.org Subject: Issue with 3576 Date: Tue, 27 Jul 2004 11:34:09 -0400 MIME-Version: 1.0 Content-Type: text/plain Bernard, Murtaza, I found a minor bug in 3576 ( I don't know if this one was reported yet) Deep down in Note[6] it says: a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The inclusion of EAP-Message in an Access-Request however does require Message-Authenticator. As well, unless I am missing something, 3576 does not say what the semantics of the Re-authorization Access-Request message. It just eludes to the fact that it is there to ease interop between RADIUS and DIAMETER. Reading between the line then one would conclude that they have to read diameter to understand the semantics. In fact NASREQ right? It should be more explicit what the behavior is. For example, we should state what happens when the Access-Accept with an Authorize-Only is received that doesn't contain attributes that were previously received in an Access-Accept message. This is cause for lots of discussion. ----------------------------- Avi Lior Bridgewater Systems Corp. Phone: 613.591.9104 x 6417 Cell : 613.297.2177 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 26 Jul 2004 19:49:07 +0000 Date: Mon, 26 Jul 2004 12:45:35 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: AAA WG last call on Diameter SIP Application Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of AAA WG Last Call on the "Diameter SIP Application" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.txt AAA WG Last Call will complete on August 26, 2004. Please send comments to the AAA WG mailing list (aaa-wg@merit.edu), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 26 Jul 2004 15:10:33 +0000 Date: Mon, 26 Jul 2004 08:07:23 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG last call on RADIUS Extension for Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG Last Call on the "RADIUS Extension for Digest Authentication" specification, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard. The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 26 Jul 2004 15:07:56 +0000 Date: Mon, 26 Jul 2004 08:04:10 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG last call on RFC 2486bis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG Last Call on "The Network Access Identifier" specification, RFC 2486bis, prior to sending the draft on to the IESG for consideration as an IETF Proposed Standard (recycled). The draft is available for inspection at: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt RADEXT WG Last Call will complete on August 26, 2004. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org), using the issue format described at http://www.drizzle.com/~aboba/AAA/issues.html. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 25 Jul 2004 23:40:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments/questions about bandwidth draft Date: Sun, 25 Jul 2004 16:39:41 -0700 Message-ID: Thread-Topic: Comments/questions about bandwidth draft Thread-Index: AcRu+jET+ZyVhYrWRdmgHzioXdwtbAA0j2NwALKFk8A= From: "Adrangi, Farid" To: "BOURDON Gilles RD-CORE-ISS" Cc: Hi Gilles, Thanks for reading the draft and your comments. Please see my responses inline. BR, Farid > -----Original Message----- > From: BOURDON Gilles RD-CORE-ISS=20 > [mailto:gilles.bourdon@francetelecom.com]=20 > Sent: Thursday, July 22, 2004 2:43 AM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > Subject: Comments/questions about bandwidth draft >=20 >=20 > I have some comments and questions about the bandwidth draft: >=20 > 1) As far as I understand, the NAS behaves differently when receiving > invalid selection of bandwidth parameter: in push mode, a COA NAK is > sent but nothing happens to the session, and in pull mode the user > session is terminated.=20 Your observation is correct, but I don't think there is an inconsistency here. In pull mode, when the NAS advertises its bandwidth capabilities, the AAA server is expected to do the selection within the boundary of the advertised bandwidth parameters. In the absence of the advertisement, the NAS does not drop the session if it cannot honor the "Selection" specified by the AAA server. > I think it would be better to adopt the same > behaviour in both cases. In the same idea, no specific behaviour is > defined in pull mode in case the NAS cannot comply with the request > ("resources unavailable" error cause is sent in push mode). >=20 That would be nice - but how can we do that in the pull model after receiving an Access-Accept? =20 > 2) Maybe the four bandwidth parameters could be aggregated in a unique > attribute, since all are required in a message ? Or the rule can be > loosen a little bit in allowing transmission of a composed set of > attribute... Non present attributes could be interpreted as=20 > "default" or > "unchanged". But maybe there is a specific explanation to=20 > this choice ? >=20 As you are aware, we had a long discussion on this topic -- I think the consenus was to use individual attributes but we are okay with using a single attribute here as well. How do you suggest we should close on this subjet? > 3) About the "Don't care" value, I think it requires more precision. > Should we understand "don't care" as a infinite (line-rate)=20 > bandwidth ? > Or a default bandwidth already set in the NAS ? >=20 Ok. It refers to the default bandwidth already set in the NAS -- you are right the draft is not specific about it; will fix it. Thanks. > 4) In section 4, shouldn't Note 1 include Access-Accept messages, not > only COA ? >=20 You are right -- it should apply to both! Again, thank you for comments and your help. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 23 Jul 2004 23:25:12 +0000 Date: Fri, 23 Jul 2004 16:22:03 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Agenda, Take Four Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADIUS Extensions WG (radext) Monday, August 2 at 1300-1500 ============================== CHAIRS: Bernard Aboba David Nelson AGENDA: Preliminaries (15 minutes) Bluesheets Meeting Minutes Agenda Bashing Liaison Requests See: http://www.drizzle.com/~aboba/RADEXT/liaisons/ Issues List Review Procedures Document Status Basic RADIUS work (25 minutes) IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 5 min http://www.ietf.org/rfc/rfc2618.txt http://www.ietf.org/rfc/rfc2619.txt http://www.ietf.org/rfc/rfc2620.txt http://www.ietf.org/rfc/rfc2621.txt RFC 3576 MIBs - M. Chiba, 5 minutes http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt EAP lower layer attribues for AAA protocols - David Mariblanca, 5 minutes http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt RADIUS Management Issues - David Nelson, 5 minutes TBD RADIUS Security Issues - Randy Chou, 5 minutes TBD SIP-RADIUS (10 minutes) Digest Authentication in RADIUS - W, Beck, 10 minutes http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt (W)LAN applications (20 minutes) RFC 2486bis - Jari Arkko, 5 minutes http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt IEEE 802 attributes - Paul Congdon, 10 minutes http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-00.txt Bandwidth Attributes - Farid Adrangi, 5 minutes http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt RADIUS Data Model Issues (30 minutes) Diameter/RADIUS compatibility - Jari Arkko, 10 minutes TBD RADIUS attributes extension, Farid Adrangi, 10 minutes http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-01.txt Discussion (10 minutes) Pre-Paid (10 minutes) RADIUS Prepaid - Avi Lior, 10 minutes http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-05.txt http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt Wrap-Up (10 minutes) -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 22 Jul 2004 09:44:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Comments/questions about bandwidth draft Date: Thu, 22 Jul 2004 11:43:11 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B0D7506B@ftrdmel3.rd.francetelecom.fr> Thread-Topic: Comments/questions about bandwidth draft Thread-Index: AcRu+jET+ZyVhYrWRdmgHzioXdwtbAA0j2Nw From: "BOURDON Gilles RD-CORE-ISS" To: "Adrangi, Farid" Cc: I have some comments and questions about the bandwidth draft: 1) As far as I understand, the NAS behaves differently when receiving invalid selection of bandwidth parameter: in push mode, a COA NAK is sent but nothing happens to the session, and in pull mode the user session is terminated. I think it would be better to adopt the same behaviour in both cases. In the same idea, no specific behaviour is defined in pull mode in case the NAS cannot comply with the request ("resources unavailable" error cause is sent in push mode). 2) Maybe the four bandwidth parameters could be aggregated in a unique attribute, since all are required in a message ? Or the rule can be loosen a little bit in allowing transmission of a composed set of attribute... Non present attributes could be interpreted as "default" or "unchanged". But maybe there is a specific explanation to this choice ? 3) About the "Don't care" value, I think it requires more precision. Should we understand "don't care" as a infinite (line-rate) bandwidth ? Or a default bandwidth already set in the NAS ? 4) In section 4, shouldn't Note 1 include Access-Accept messages, not only COA ? Thank you. Gilles. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 08:11:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Version 1 of bandwidth draft for your review Date: Wed, 21 Jul 2004 01:10:32 -0700 Message-ID: Thread-Topic: Version 1 of bandwidth draft for your review Thread-Index: AcRu+jET+ZyVhYrWRdmgHzioXdwtbA== From: "Adrangi, Farid" To: Hi, I have submitted version 1 of the bandwidth draft. It does not appear in the ID directories yet - but here is the url to access it: http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-bandwidth-capa bility-01.txt - Incorporated comments and feedback from Jari. Jari pointed out several issues with the draft and helped us with Diameter aspect of the draft. =20 - Incorporated comments and feedback form Stefan. We are still discussing Stefan's suggestion on adding burst size and perhaps algorithms or profile ID for handling the parameters. BR, Farid -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 03:17:40 +0000 Message-ID: From: Avi Lior To: Ignacio Goyret , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Redirection Draft v1 is now available for review Date: Tue, 20 Jul 2004 23:17:13 -0400 MIME-Version: 1.0 Content-Type: text/plain I agree. I basically stole these definition or this style from Diameter see RFC3588 We could do a better job but I was hoping that if they got away with it so could we. But perhaps not. Lets see what others say. > -----Original Message----- > From: Ignacio Goyret [mailto:igoyret@lucent.com] > Sent: Tuesday, July 20, 2004 7:38 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Redirection Draft v1 is now available for review > > > At 21:35 7/20/2004 -0400, Avi Lior wrote: > > > >Subject: I-D ACTION:draft-lior-radius-redirection-01.txt > > Avi, > The format to be used for NAS-Filter-Rule at the top of page > 13 is not very clear to me from reading this doc. In > particular, it is not clear to me: > - whether the words 'from' and 'to' should or should not be used > - if the '/' character in the port spec is a character to be inserted > or it means alternate choices (as in 'port' or 'port-port'). > - is the '!' character allowed before port specs (to indicate > "everything except these ports"). > - are the "from" and "to" parts always required? Is either > one optional? > If so, is the other mandatory? (eg, if the "to" part is optional, > is the "from" part mandatory?) > - which words are keywords that must be entered as is and which ones > are tokens. > - for "ipoptions": is the comma-separated list an AND-condition (where > all the listed options must be present) or an OR-condition > (where any > of the listed options must be present). Same for "tcpoptions" and > "tcpflags". > > Similar questions rise from reading the other rules > (IP-Redirection-Rule and HTTP-Redirection-Rule). > > Please consider clarifying them. Examples are not necessarily > needed but can definitely help convey the idea. > > Best regards, > -Ignacio > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 03:17:32 +0000 Message-ID: From: Avi Lior To: Barney Wolff , Avi Lior Cc: Jari Arkko , Lothar Reith , "'radiusext@ops.ietf.org'" Subject: RE: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Tue, 20 Jul 2004 23:13:43 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi See inline... > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, July 20, 2004 6:16 PM > To: Avi Lior > Cc: Jari Arkko; Lothar Reith; 'radiusext@ops.ietf.org' > Subject: Re: AW: Privacy (Was: Re: NAI decoration: User > Identity issues) > > > On Tue, Jul 20, 2004 at 08:09:18PM -0400, Avi Lior wrote: > > In proxy scenarios a RADIUS intermediary acts as a server and a > > client. > > > > The Intermediary (acting as a server) can *completely* re-write the > > username attribute as it sends the access accept message to its > > client. > > > > The only requirement is that a Client (in this case the > intermediary ) > > replace the username that it received from it's server in the > > Acccounting Messages that it sends to that server. > > > > Because of this behavior it is *not* guaranteed that RADIUS > > Intermediaries or the NAS will actually see what the home > network has > > placed in the username attribute in the access request. > > > > User-Identity-Alias seperates the routing out and allows us to have > > cleaner solutions. > > I think you're confusing IETF standards with laws of nature. > If an intermediary wants to conceal the user's "true" > identity, it will rewrite User-Identity-Alias no matter what > an RFC says. For that matter, if the home server wants to > conceal the identity, it can put random garbage into > User-Identity-Alias. Intermediary could even leave it out. I understand this all too well. > Surely business models depend on contracts, not just RFCs. > Since this is a matter of a business model, not of the > technical operation of RADIUS, I don't see any difference > between a contract that requires certain treatment of > User-Name in Access-Accepts vs one that requires a stable > medium-to-long-term User-Identity-Alias. In the draft we have taken comments (From Nelson and others) that says that intermediaries MUST not modify the User-Identity-Alias. So we are trying to clean up the issues. Cause some roaming relationships are very complex and involve brokers etc.... > Regards, > Barney > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via > the 'Net. > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 02:39:04 +0000 Message-Id: <200407210238.TAA08394@grigri.eng.ascend.com> Date: Tue, 20 Jul 2004 19:38:06 -0700 To: Avi Lior From: Ignacio Goyret Subject: Re: Redirection Draft v1 is now available for review Cc: radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 21:35 7/20/2004 -0400, Avi Lior wrote: > >Subject: I-D ACTION:draft-lior-radius-redirection-01.txt Avi, The format to be used for NAS-Filter-Rule at the top of page 13 is not very clear to me from reading this doc. In particular, it is not clear to me: - whether the words 'from' and 'to' should or should not be used - if the '/' character in the port spec is a character to be inserted or it means alternate choices (as in 'port' or 'port-port'). - is the '!' character allowed before port specs (to indicate "everything except these ports"). - are the "from" and "to" parts always required? Is either one optional? If so, is the other mandatory? (eg, if the "to" part is optional, is the "from" part mandatory?) - which words are keywords that must be entered as is and which ones are tokens. - for "ipoptions": is the comma-separated list an AND-condition (where all the listed options must be present) or an OR-condition (where any of the listed options must be present). Same for "tcpoptions" and "tcpflags". Similar questions rise from reading the other rules (IP-Redirection-Rule and HTTP-Redirection-Rule). Please consider clarifying them. Examples are not necessarily needed but can definitely help convey the idea. Best regards, -Ignacio -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 01:35:47 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Redirection Draft v1 is now available for review Date: Tue, 20 Jul 2004 21:35:27 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C46EC3.00871F70" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C46EC3.00871F70 Content-Type: text/plain -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 20, 2004 1:04 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-lior-radius-redirection-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Authentication Dial In User Service (RADIUS) Redirection Author(s) : A. Lior, F. Adrangi Filename : draft-lior-radius-redirection-01.txt Pages : 25 Date : 2004-7-20 In certain scenarios there needs to be a method to force the users traffic to a specific location. This document describes several methods that are available to be used with Remote Authentication Dial In User Service (RADIUS) Protocol and defines three new RADIUS attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lior-radius-redirection-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lior-radius-redirection-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C46EC3.00871F70 Content-Type: message/rfc822 To: Subject: Date: Tue, 20 Jul 2004 19:31:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C46EC3.00871F70" ------_=_NextPart_002_01C46EC3.00871F70 Content-Type: text/plain ------_=_NextPart_002_01C46EC3.00871F70 Content-Type: application/octet-stream; name="ATT59499.txt" Content-Disposition: attachment; filename="ATT59499.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lior-radius-redirection-01.txt ------_=_NextPart_002_01C46EC3.00871F70 Content-Type: message/external-body; site="internet-drafts"; dir="draft-lior-radius-redirection-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C46EC3.00871F70-- ------_=_NextPart_000_01C46EC3.00871F70 Content-Type: text/plain; name="ATT59500.txt" Content-Disposition: attachment; filename="ATT59500.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C46EC3.00871F70-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 01:35:41 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Prepaid draft v5 is available for review Date: Tue, 20 Jul 2004 21:35:31 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C46EC3.029F9F30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C46EC3.029F9F30 Content-Type: text/plain Hi In this version: -we have cleaned up the architecture to make it more vendor neutral. -we introduce multi-services prepaid which lines up with Diameter concepts. -addressed other issues and clean up. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 20, 2004 1:01 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-lior-radius-prepaid-extensions-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) Author(s) : A. Lior, et al. Filename : draft-lior-radius-prepaid-extensions-05.txt Pages : 48 Date : 2004-7-20 The draft presents an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to support Prepaid data services for a wide range of deployments such as Dial, Wireless, WLAN. Consideration for roaming using mobile-ip is also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-05. txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lior-radius-prepaid-extensions-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lior-radius-prepaid-extensions-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C46EC3.029F9F30 Content-Type: message/rfc822 To: Subject: Date: Tue, 20 Jul 2004 19:31:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C46EC3.029F9F30" ------_=_NextPart_002_01C46EC3.029F9F30 Content-Type: text/plain ------_=_NextPart_002_01C46EC3.029F9F30 Content-Type: application/octet-stream; name="ATT59428.txt" Content-Disposition: attachment; filename="ATT59428.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-20155700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lior-radius-prepaid-extensions-05.txt ------_=_NextPart_002_01C46EC3.029F9F30 Content-Type: message/external-body; site="internet-drafts"; dir="draft-lior-radius-prepaid-extensions-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C46EC3.029F9F30-- ------_=_NextPart_000_01C46EC3.029F9F30 Content-Type: text/plain; name="ATT59429.txt" Content-Disposition: attachment; filename="ATT59429.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C46EC3.029F9F30-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 01:15:59 +0000 Date: Tue, 20 Jul 2004 21:15:35 -0400 From: Barney Wolff To: Avi Lior Cc: Jari Arkko , Lothar Reith , "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Message-ID: <20040721011535.GA96314@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jul 20, 2004 at 08:09:18PM -0400, Avi Lior wrote: > In proxy scenarios a RADIUS intermediary acts as a server and a client. > > The Intermediary (acting as a server) can *completely* re-write the username > attribute as it sends the access accept message to its client. > > The only requirement is that a Client (in this case the intermediary ) > replace the username that it received from it's server in the Acccounting > Messages that it sends to that server. > > Because of this behavior it is *not* guaranteed that RADIUS Intermediaries > or the NAS will actually see what the home network has placed in the > username attribute in the access request. > > User-Identity-Alias seperates the routing out and allows us to have cleaner > solutions. I think you're confusing IETF standards with laws of nature. If an intermediary wants to conceal the user's "true" identity, it will rewrite User-Identity-Alias no matter what an RFC says. For that matter, if the home server wants to conceal the identity, it can put random garbage into User-Identity-Alias. Surely business models depend on contracts, not just RFCs. Since this is a matter of a business model, not of the technical operation of RADIUS, I don't see any difference between a contract that requires certain treatment of User-Name in Access-Accepts vs one that requires a stable medium-to-long-term User-Identity-Alias. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 00:10:03 +0000 Message-ID: From: Avi Lior To: Barney Wolff , Jari Arkko Cc: Lothar Reith , "'radiusext@ops.ietf.org'" Subject: RE: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Tue, 20 Jul 2004 20:09:18 -0400 MIME-Version: 1.0 Content-Type: text/plain In proxy scenarios a RADIUS intermediary acts as a server and a client. The Intermediary (acting as a server) can *completely* re-write the username attribute as it sends the access accept message to its client. The only requirement is that a Client (in this case the intermediary ) replace the username that it received from it's server in the Acccounting Messages that it sends to that server. Because of this behavior it is *not* guaranteed that RADIUS Intermediaries or the NAS will actually see what the home network has placed in the username attribute in the access request. User-Identity-Alias seperates the routing out and allows us to have cleaner solutions. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 21 Jul 2004 00:09:56 +0000 Message-ID: From: Avi Lior To: Lothar Reith , 'Bernard Aboba' Cc: "'radiusext@ops.ietf.org'" Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Tue, 20 Jul 2004 20:09:19 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46EB6.F7F94BF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46EB6.F7F94BF0 Content-Type: text/plain Lothar and all, In the draft we call this attribute User Identity Alias. This makes it billing nautral. As well there maybe more then one use for this attribute. Lothar wrote: Please note that I meanwhile would propose to refer to the new attribute which we are discussing as "accountable-identity". ------_=_NextPart_001_01C46EB6.F7F94BF0 Content-Type: text/html Message
Lothar and all,
 
In the draft we call this attribute  User Identity Alias.  This makes it billing nautral.
 
As well there maybe more then one use for this attribute.
 
 Lothar wrote:  Please note that I meanwhile would propose to refer to the new attribute which we are discussing as "accountable-identity".  
 
 
 
 
------_=_NextPart_001_01C46EB6.F7F94BF0-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 20 Jul 2004 15:41:05 +0000 Date: Tue, 20 Jul 2004 11:40:41 -0400 From: Barney Wolff To: Jari Arkko Cc: Lothar Reith , "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Message-ID: <20040720154041.GA71263@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jul 20, 2004 at 02:03:50PM +0300, Jari Arkko wrote: > > And I didn't mean to imply that Klaas' requirement is bad either. > I'm just trying to collect possible requirements, and the tracking > requirement is reasonable enough to be considered -- though it may well > be that the privacy requirements conflict with it or that there's > no need for a real-time real-identity tracking. More discussion > is needed on that. If a persistent alias is not required, an abusive user can be identified via Acct-Session-Id, provided of course that the user's home auth server also gets acct requests and stores them. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 20 Jul 2004 11:09:21 +0000 Message-ID: <40FCFC16.8020801@piuha.net> Date: Tue, 20 Jul 2004 14:03:50 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Lothar Reith Cc: "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lothar Reith wrote: > please note that there appears to be a serious misunderstanding of my > statements. > > In no way did I propose anything that would compromise privacy - in the > opposite I am proposing that the attribute > "privacy-protected-identity"/"billable identity"/"user-alias" may be > considered *essential* to enable privacy by means of using an anonymous > NAI for routing the authentication request and a billable-identity only > resolvable by the home network for accounting. (snip) > I never stated what you linked with my name: > > "Get the user's "trackable" identity for the access > network so that fraudulent users can be tracked down and > acted upon without involving home operator (possibly in > another timezone and government etc)." > > The opposite is true: Provide a > "billable-identity"/"privacy-protected-identity" which on one hand does > not allow any tracking by any intermediary or access-network under > normal circumstances, but on the other hand allows billing (normal > circumstances) and - in case of abuse, i.e. in rare circumstances - > tracking down the abusive user. > > I suggested the use of the billing-identity attribute for "tracking" in > response to the requirement stated by Klaas Wierenga: > > "Some universities want to know the real identity of a user in case of > abuse" which he made in the context of the following NAI: > "anonymous@university-a.nl" which implies that the NAI can not be used > for this purpose. > > The point is, that I do not beleive that these universities require the > real identity "in real time" - rather I assume it would be perfectly > sufficient to be able to track down the real identity of an abusive > anonymous user after the fact of abuse. In this case, the university > would have to request the resolution of the anonymous user-name from the > home network providing evidence that the request is legitimate. Ok. Sorry for mixing up who said what. What you say above about non-real-time does make sense to me. And I didn't mean to imply that Klaas' requirement is bad either. I'm just trying to collect possible requirements, and the tracking requirement is reasonable enough to be considered -- though it may well be that the privacy requirements conflict with it or that there's no need for a real-time real-identity tracking. More discussion is needed on that. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 19 Jul 2004 12:36:48 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462C359BF@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" Cc: "'radiusext@ops.ietf.org'" Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Mon, 19 Jul 2004 13:36:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46D8C.FC4FC312" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46D8C.FC4FC312 Content-Type: text/plain Bernard, let me answer your question if username-rewrite could do the job as follows: context (lothar wrote) > "privacy-protected-identity", which - when present - is used instead > of the NAI for all kinds of purposes normally the NAI is used for, > including billing, re-authorization, abuse tracking etc. Bernhard wrote: Can't that function be handled by sending a User-Name attribute in the Access-Accept? Why would another attribute be needed? Lothar responds: I think the answer lies in Blair Bullocks mail in the below appendix. Blair's mail has led me to believe that username rewrite may not be suitable in all cases. Also, it would be less overloading of the NAI and therefore more expandable if we introduce a "privacy protected identity" which can be uses as "billable identity" as well, compared to overloading the already overloaded NAI even more (with privacy feature). This should allow more flexibility by virtue of being able to separate the "routing" function of the NAI from the "accountability" function which for privacy purposes may be "hidden" and home-resolvable only. Please note that I meanwhile would propose to refer to the new attribute which we are discussing as "accountable-identity". This attribute name is IMHO more suitable than "billing-identity", as it also includes the notion of a malicious user being held accountable for abuse, even if no accounting is taking place for billing purposes, just logging of RADIUS accounting messages for abuse trackability purposes. It also covers the "privacy-protected-identity" as even though the identity is privacy protected, it is still accountable - but not without cooperation of the home network which may not be willing to share the true identity with all access networks and intermediaries. Best Regards, Lothar Appendix: Blair Bullock wrote on 15.7.2004 "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. " Assumes that all routing is suffix based in a direct peer-to-peer relationship. We don't route every domain to every other domain. The constant realm add/remove process is a total nightmare! Therefore a chained suffix or prefix is typically used to aggregate unknown suffixes under a roaming agency: user@enterprise@ipass.com Or IPASS/user@enterprise.com Either way, if the Access-Accept returns User-Name=user@enterprise.com and the accounting is re-written with this User-Name value, it will not route to the proper AAA exchange. To reiterate some from my last email: 1- maintaining the re-decoration of the User-Name of the Access-Accept User-Name by the intermediary proxy requires statefulness of all AAA events. 2- To have the Access-Accept username return the decorated NAI from the Home AS requires knowledge of the aggregation principles (suffix or prefix) and provisioning of that information at the Home Authentication Server so it will normalize the user-name and won't mess-up local requests. (not to mention what if the Home Network uses multiple aggregators with different aggregation suffixes and/or prefix). 3 - To route via suffix only with a root NAI as per the RFC user@realm requires realm add/deletes ad nauseum from now until the end of time. A reseller adds a new enterprise realm and we have to update every RADIUS proxy in the system to tell them it should be routed to our exchange?! When you have hundreds of networks it is untenable. Also, what if that realm can be routed via multiple intermediaries?! Thus the intermediary decoration of user@enterprise@ipass.com or user@enterprise@gric.com (or IPASS/user@enterprise.com or even IPASS/user@enterprise.com@reseller.com) is necessary to address these footprint aggregation, routing, reselling and billable user resolution requirements for roaming. Prefixes and suffix chains serve a very valid business functions. NAI decoration must be inclusive of all service models and is primarily used to eliminate the constant ongoing provisioning requirements of direct suffix peering. User@realm is too simplistic and doesn't reflect all of the business models that have emerged in our space over the past eight years. On a side note, what if the inner method authentication simply uses "john" with no suffix in the user-name? Accounting will be re-written as just "john" and it will not route at all, even if there is a direct suffix relationship between two networks. Position swapping of any NAI element is right-out bad. Blair ------_=_NextPart_001_01C46D8C.FC4FC312 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: Privacy (Was: Re: NAI decoration: User Identity = issues)

Bernard,

let me answer your question if username-rewrite could = do the job as follows:

context (lothar wrote)
> "privacy-protected-identity", which - = when present - is used instead
> of the NAI for all kinds of purposes normally = the NAI is used for,
> including billing, re-authorization, abuse = tracking etc.

Bernhard wrote:
Can't that function be handled by sending a = User-Name attribute in the Access-Accept?  Why would another = attribute be needed?

Lothar responds:
I think the answer lies in Blair Bullocks mail in = the below appendix.

Blair's mail has led me to believe that username = rewrite may not be suitable in all cases. Also, it would be less = overloading of the NAI and therefore more expandable if we introduce a = "privacy protected identity" which can be uses as = "billable identity" as well, compared to overloading the = already overloaded NAI even more (with privacy feature).

This should allow more flexibility by virtue of being = able to separate the "routing" function of the NAI from the = "accountability" function which for privacy purposes may be = "hidden" and home-resolvable only.

Please note that I meanwhile would propose to refer = to the new attribute which we are discussing as = "accountable-identity". This attribute name is IMHO more = suitable than "billing-identity", as it also includes the = notion of a malicious user being held accountable for abuse, even if no = accounting is taking place for billing purposes, just logging of RADIUS = accounting messages for abuse trackability purposes. It also covers the = "privacy-protected-identity" as even though the identity is = privacy protected, it is still accountable - but not without = cooperation of the home network which may not be willing to share the = true identity with all access networks and intermediaries.


Best Regards, Lothar



Appendix:

Blair Bullock wrote on 15.7.2004
"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. "

Assumes that all routing is suffix based in a direct = peer-to-peer relationship.  We don't route every domain to every = other domain.  The constant realm add/remove process is a total = nightmare!  Therefore a chained suffix or prefix is typically used = to aggregate unknown suffixes under a roaming agency:

user@enterprise@ipass.com
Or
IPASS/user@enterprise.com

Either way, if the Access-Accept returns = User-Name=3Duser@enterprise.com and the accounting is re-written with = this User-Name value, it will not route to the proper AAA = exchange. 

To reiterate some from my last email:

1- maintaining the re-decoration of the User-Name of = the Access-Accept User-Name by the intermediary proxy requires = statefulness of all AAA events.

2- To have the Access-Accept username return the = decorated NAI from the Home AS requires knowledge of the aggregation = principles (suffix or

prefix) and provisioning of that information at the = Home Authentication Server so it will normalize the user-name and won't = mess-up local requests. (not to mention what if the Home Network uses = multiple aggregators with different aggregation suffixes and/or = prefix). 3 - To route via suffix only with a root NAI as per the RFC = user@realm requires realm add/deletes ad nauseum from now until the end = of time.  A reseller adds a new enterprise realm and we have to = update every RADIUS proxy in the system to tell them it should be = routed to our exchange?! When you have hundreds of networks it is = untenable.  Also, what if that realm can be routed via multiple = intermediaries?! 

Thus the intermediary decoration of = user@enterprise@ipass.com or user@enterprise@gric.com (or = IPASS/user@enterprise.com or even

IPASS/user@enterprise.com@reseller.com) is necessary = to address these footprint aggregation, routing, reselling and billable = user resolution requirements for roaming.  Prefixes and suffix = chains serve a very valid business functions.  NAI decoration must = be inclusive of all service models and is primarily used to eliminate = the constant ongoing provisioning requirements of direct suffix = peering.  User@realm is too simplistic and doesn't reflect all of = the business models that have emerged in our space over the past eight = years.

On a side note, what if the inner method = authentication simply uses "john" with no suffix in the = user-name?  Accounting will be re-written as just "john" = and it will not route at all, even if there is a direct suffix = relationship between two networks.

Position swapping of any NAI element is right-out = bad.

Blair


------_=_NextPart_001_01C46D8C.FC4FC312-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 19 Jul 2004 09:10:02 +0000 Message-ID: <40FB8FD9.6010206@surfnet.nl> Date: Mon, 19 Jul 2004 11:09:45 +0200 From: Klaas Wierenga User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) MIME-Version: 1.0 To: Lothar Reith CC: "'jari.arkko@piuha.net'" , "'Bernard Aboba'" , "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Lothar, > I suggested the use of the billing-identity attribute for "tracking" in > response to the requirement stated by Klaas Wierenga: > > "Some universities want to know the real identity of a user in case of > abuse" which he made in the context of the following NAI: > "anonymous@university-a.nl" which implies that the NAI can not be used > for this purpose. > > The point is, that I do not beleive that these universities require the > real identity "in real time" - rather I assume it would be perfectly > sufficient to be able to track down the real identity of an abusive > anonymous user after the fact of abuse. In this case, the university > would have to request the resolution of the anonymous user-name from the > home network providing evidence that the request is legitimate. Actually, currently this is exactly the path we are following. We have a project (http://www.sourceforge.net/projects/usertracking) that tries to gather all the relevant data to do this. And I agree completely with you that this is in general the desired behaviour. However I believe there are 2 buts: - Sometimes you do want to track down realtime the abusive user, if some user from university-a is sending lots of spam via university-b, are you going to shutdown all users from university-a (since they are all anonymous@university-a to university-b) or just badguy@university-a? Just as a user has the right to only connect via a provider that guards their privacy I believe a visited institution should have the right to refuse anonymous users, it's after all their infrastructure they are giving access too. - Universities or other entities may be in some kind of federation where they agree to share user data with eachother. Either the low level attributes of a user or some aggregated form of it. As I mentioned before, I am not sure whether this kind of authorisation should be carried on this layer or on some other like EAP. I think however that there is value in giving the *possibility* to reveal the real identity of a user, this 'real identiy' may also be some kind of pseudonymous id, but it is useful to be able to distinguish individual users. > > In my mind, the real problem is to find the right balance between the > valid privacy and security requirements of the user, and the valid > privacy and security requirements of the home-network povider, the > intermediaries, the access provider and the Internet at large. agreed > A privacy conscious user may contract only with a home-network that > cares about privacy and resolves his true identity only to a legimitate > requester providing strong evidence of abuse and of course only on the > basis of local legislation of the home network anyway. > > By the way: A privacy conscious home-network provider may not want to > expose his customer's clear-text user-names to access-networks and > intermediaries. Yes, within the TERENA (the 'club' of european research and education networks) Taskforce Mobility (http://www.terena.nl/mobility) we try to do this by defining policies for the european toplevel RADIUS-server, the country level toplevel server and the institutional RADIUS-servers. Here we try to state what users can expect and also what 1 NREN can expect from the other NRENs. > > In a nutshell, my proposal was actually aimed at avoiding the below > cited horror scenario that Jari has put in the context of my name (much > to my dislike): Actually I'm trying to do the same. I have noticed that candidate participants to this hierarchy often are afraid they lack the tools to exclude abusive users/institutions and countries. By providing them the tools to exclude whoever they feel like the reality is that they don't bother to take any of these measures, just having the tools is enough insurance. Klaas -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 19 Jul 2004 08:28:09 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462C3577B@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'jari.arkko@piuha.net'" , "'Bernard Aboba'" Cc: "'radiusext@ops.ietf.org'" Subject: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Mon, 19 Jul 2004 09:27:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46D6A.32231A3E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46D6A.32231A3E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jari, please note that there appears to be a serious misunderstanding of my statements.=20 In no way did I propose anything that would compromise privacy - in the opposite I am proposing that the attribute "privacy-protected-identity"/"billable identity"/"user-alias" may be considered *essential* to enable privacy by means of using an anonymous = NAI for routing the authentication request and a billable-identity only resolvable by the home network for accounting. I never stated what you linked with my name: "Get the user's "trackable" identity for the access network so that fraudulent users can be tracked down and acted upon without involving home operator (possibly in another timezone and government etc)." The opposite is true: Provide a "billable-identity"/"privacy-protected-identity" which on one hand = does not allow any tracking by any intermediary or access-network under normal circumstances, but on the other hand allows billing (normal = circumstances) and - in case of abuse, i.e. in rare circumstances - tracking down the abusive user. I suggested the use of the billing-identity attribute for "tracking" in response to the requirement stated by Klaas Wierenga: "Some universities want to know the real identity of a user in case of abuse" which he made in the context of the following NAI: "anonymous@university-a.nl" which implies that the NAI can not be used = for this purpose. The point is, that I do not beleive that these universities require the = real identity "in real time" - rather I assume it would be perfectly = sufficient to be able to track down the real identity of an abusive anonymous user after the fact of abuse. In this case, the university would have to = request the resolution of the anonymous user-name from the home network = providing evidence that the request is legitimate. In my mind, the real problem is to find the right balance between the = valid privacy and security requirements of the user, and the valid privacy = and security requirements of the home-network povider, the intermediaries, = the access provider and the Internet at large. =20 A privacy conscious user may contract only with a home-network that = cares about privacy and resolves his true identity only to a legimitate = requester providing strong evidence of abuse and of course only on the basis of = local legislation of the home network anyway. By the way: A privacy conscious home-network provider may not want to = expose his customer's clear-text user-names to access-networks and = intermediaries. In a nutshell, my proposal was actually aimed at avoiding the below = cited horror scenario that Jari has put in the context of my name (much to my dislike): =20 Jari wrote start: > No hotspot access in the Big Brother > Republic unless your home ISP sends your passport number, > snail address, and biometric data in an Access-Accept. Hmm... > I think we are going to get here sooner or later :-(=20 Jari wrote end. Business reality appears to me to be very different: The home-network = may NOT want to provide any resolvable identity data, because they may be = afraid that someone else in the food-chain could steal their customer. Best Regards, Lothar -----Urspr=FCngliche Nachricht----- Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Im Auftrag von Jari Arkko Gesendet: Freitag, 16. Juli 2004 20:27 An: Bernard Aboba Cc: 'radiusext@ops.ietf.org' Betreff: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Bernard Aboba wrote: > It seems like everyone is seeing a different application for the=20 > attribute > -- and that is why it is so hard to come to agreement on the problem > statement. Right. I think we have seen the following applications or individual requirements: 1. Lothar: Get the user's "trackable" identity for the access network so that fraudulent users can be tracked down and acted upon without involving home operator (possibly in another timezone and government etc). Note 1: This requires some sort of real identity, just stable but opaque identifier would be insufficient. Or its sufficient for denying further service, but not for taking some action against the user. Note 2: I'm not sure I want to think about the privacy implications of this. No hotspot access in the Big Brother Republic unless your home ISP sends your passport number, snail address, and biometric data in an Access-Accept. Hmm... I think we are going to get here sooner or later :-( 2. Avi: Controlling a policy for the user, such as limits on the number of simultaneous sessions per user. Note 3: This is only useful if the home network's policy is different from the access network's policy. For instance, home network has unlimited access while access network allows at most one access at a time. Note 4: Even if the policies are different, home networks could still apply the policy on a per-visited network basis. This could be problematic for provisioning, however. Note 5: Even if the access network applies the policy, it has no guarantee that the identity given to it is correct. A fraudulent home network could claim that all sessions come from a different user, whereas in reality they actually are from one user. Does this matter? 3. Farid: Retrieve real identity when tunneled or pseudonym-based EAP methods are used. 4. Blair: Correlate accounting records with an identifier so that fixed price billing models can be applied at a service provider. Note 6: This requires a stable (~ month) identity, but it does not have to be a "real" identity. Compare to requirement 1! 5. Farid: Provide a new format to carry non-NAI identities, such as IMSI or E.164 numbers. 6. Farid: Provide an alternate, second identifier in addition to the NAI. Note 7: I am presuming that this is a requirement. Is it? 7. Jari: Carry a privacy-protected "handle" instead of the "real" identity when returning User-Name/ Class/User-Alias. Anything else? --Jari -- 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: ------_=_NextPart_001_01C46D6A.32231A3E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Privacy (Was: Re: NAI decoration: User Identity = issues)

Jari,

please note that there appears to be a serious = misunderstanding of my statements.

In no way did I propose anything that would = compromise privacy - in the opposite I am proposing that the attribute = "privacy-protected-identity"/"billable = identity"/"user-alias" may be considered *essential* to = enable privacy by means of using an anonymous NAI for routing the = authentication request and a billable-identity only resolvable by the = home network  for accounting.

I never stated what you linked with my name:

"Get the user's "trackable" identity = for the access
    network so that fraudulent users = can be tracked down and
    acted upon without involving home = operator (possibly in
    another timezone and government = etc)."

The opposite is true:   Provide a = "billable-identity"/"privacy-protected-identity"&nbs= p; which on one hand does not allow any tracking by any intermediary or = access-network under normal circumstances, but on the other hand allows = billing (normal circumstances) and - in case of abuse, i.e. in rare = circumstances  - tracking down the abusive user.

I suggested the use of the billing-identity attribute = for "tracking" in response to the requirement stated by Klaas = Wierenga:

"Some universities want to know the real = identity of a user in case of abuse" which he made in the context = of the following NAI: "anonymous@university-a.nl"  which = implies that the NAI can not be used for this purpose.

The point is, that I do not beleive that these = universities require the real identity "in real time" - = rather I assume it would be perfectly sufficient to be able to track = down the real identity of an abusive anonymous user after the fact of = abuse. In this case, the university would have to request the = resolution of the anonymous user-name from the home network providing = evidence that the request is legitimate.

In my mind, the real problem is to find the right = balance between the valid privacy and security requirements of the = user, and the valid privacy and security requirements of the = home-network povider, the intermediaries, the access provider and the = Internet at large.

 
A privacy conscious user may contract only with a = home-network that cares about privacy and resolves his true identity = only to a legimitate requester providing strong evidence of abuse and = of course only on the basis of local legislation of the home network = anyway.

By the way: A privacy conscious home-network provider = may not want to expose his customer's clear-text user-names to = access-networks and intermediaries.

In a nutshell, my proposal was actually aimed at = avoiding the below cited horror scenario that Jari has put in the = context of my name (much to my dislike):

  
Jari wrote start:
>    No hotspot access in the Big = Brother
>    Republic unless your home ISP = sends your passport number,
>   snail address, and biometric data = in an Access-Accept. Hmm...
>    I think we are going to get = here sooner or later :-(
Jari wrote end.

Business reality appears to me to be very different: = The home-network may NOT want to provide any resolvable identity data, = because they may be afraid that someone else in the food-chain could = steal their customer.

Best Regards, Lothar







-----Urspr=FCngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org] Im Auftrag von Jari Arkko
Gesendet: Freitag, 16. Juli 2004 20:27
An: Bernard Aboba
Cc: 'radiusext@ops.ietf.org'
Betreff: Re: Privacy (Was: Re: NAI decoration: User = Identity issues)


Bernard Aboba wrote:

> It seems like everyone is seeing a different = application for the
> attribute
> -- and that is why it is so hard to come to = agreement on the problem
> statement.

Right. I think we have seen the following = applications
or individual requirements:

1. Lothar: Get the user's "trackable" = identity for the access
    network so that fraudulent users = can be tracked down and
    acted upon without involving home = operator (possibly in
    another timezone and government = etc).

    Note 1: This requires some sort of = real identity, just
    stable but opaque identifier = would be insufficient. Or
    its sufficient for denying = further service, but not for
    taking some action against the = user.

    Note 2: I'm not sure I want to = think about the privacy
    implications of this. No hotspot = access in the Big Brother
    Republic unless your home ISP = sends your passport number,
    snail address, and biometric data = in an Access-Accept. Hmm...
    I think we are going to get here = sooner or later :-(

2. Avi: Controlling a policy for the user, such as = limits
    on the number of simultaneous = sessions per user.

    Note 3: This is only useful if the = home network's policy
    is different from the access = network's policy. For instance,
    home network has unlimited access = while access network
    allows at most one access at a = time.

    Note 4: Even if the policies are = different, home networks
    could still apply the policy on a = per-visited network
    basis. This could be problematic = for provisioning,
    however.

    Note 5: Even if the access network = applies the policy,
    it has no guarantee that the = identity given to it is
    correct. A fraudulent home = network could claim that
    all sessions come from a = different user, whereas in
    reality they actually are from = one user. Does this
    matter?

3. Farid: Retrieve real identity when tunneled = or
    pseudonym-based EAP methods are = used.

4. Blair: Correlate accounting records with
    an identifier so that fixed = price
    billing models can be applied at = a service
    provider.

    Note 6: This requires a stable (~ = month)
    identity, but it does not have to = be a "real"
    identity. Compare to requirement = 1!

5. Farid: Provide a new format to carry = non-NAI
    identities, such as IMSI or E.164 = numbers.

6. Farid: Provide an alternate, second = identifier
    in addition to the NAI.

    Note 7: I am presuming that this = is a requirement.
    Is it?

7. Jari: Carry a privacy-protected "handle" = instead
    of the "real" identity = when returning User-Name/
    Class/User-Alias.

Anything else?

--Jari

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

------_=_NextPart_001_01C46D6A.32231A3E-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 17 Jul 2004 14:40:40 +0000 Date: Sat, 17 Jul 2004 07:37:58 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > But since they do exist, we are not going to do extensions that > break backwards compatibility without a very good reason. This > I believe is independent of any potential attempts to extend > the data model: data model extensions, if any, would only apply > to new attributes. Right. There is a proposal on the table to provide a well-defined data model (including sub-attribute support) within an extended attribute space, whose use will be explicitly negotiated between the RADIUS client and server. However, the charter explicitly forbids any non-backward compatible changes within the standard RADIUS attribute space. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 17 Jul 2004 10:07:04 +0000 Message-ID: <40F8F8F9.2020908@piuha.net> Date: Sat, 17 Jul 2004 13:01:29 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "'radiusext@ops.ietf.org'" Subject: naibis-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have submitted the -02 version of my draft, draft-arkko-roamops-rfc2486bis-02.txt. Here's the draft and the diff: http://www.arkko.com/publications/nai/naibis.txt http://www.arkko.com/publications/nai/naibisdiff.html There is only one modification: Per Farid's request it is now clarified that the '!' syntax can be applied multiple times. No one seems to need more than one '!' but it is actually hard to limit this given that the rest of the username should be opaque to the intermediary. We have also had a discussion of whether the User-Name attribute coming back in an Access-Accept should get the reverse conversion. Based on the input on the list, I currently don't see a lot of support for this so I decided to leave it out. But we could discuss it at IETF 60. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 20:01:23 +0000 Date: Fri, 16 Jul 2004 16:00:46 -0400 From: Barney Wolff To: Jari Arkko Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues) Message-ID: <20040716200046.GA41120@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Fri, Jul 16, 2004 at 08:57:12PM +0300, Jari Arkko wrote: > > Perhaps the answer lies in the definition of the > business model. Is it > > (a) Access provider MUST present a fixed cost bill > per user per month, and MUST ensure that a given > user is logged on at most once at any given time. Let me ask the standard security question: What's the threat model? If the fear is that the intermediary's customer itself may cheat, by trying to get away with paying for fewer users than it actually has, the business model is non-viable, because the customer's server can keep track of how many simultaneous sessions there are and generate fake User-Aliases user0001, user0002 etc. So we decide to trust the customer's server. But in that case, we may just as well rely on having the server rewrite User-Name in the Accept, as the only risk is that the server will fake the realm. But such fakery can be detected by the intermediary, because it's capable of logging both the request and the accept, or even doing a real-time check. As a side note, since detection of session-end is not always completely reliable (modems can be slow to drop DCD, and similar issues apply to newer access technologies or (heaven forfend!) the NAS may silently die) limiting the user to at most 1 simultaneous login can generate annoyance and/or help-desk calls on false positives. A brilliant product-line manager at the ISP with which I was once associated changed the limit to two, which made that problem disappear without reducing protection against massive abuse. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 19:24:39 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 12:21:10 -0700 Message-ID: Thread-Topic: Privacy (Was: Re: NAI decoration: User Identity issues) Thread-Index: AcRrZbulTtCUbxanTK2yTCF1HsYeigAA/4oQ From: "Roy Albert" To: jari.arkko@piuha.net cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable We do this today as an intermediary. The home networks are mostly enterprises and have no facilities for doing this.=20 -Roy Roy D. Albert ralbert@ipass.com =20 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Friday, July 16, 2004 11:48 AM To: Roy Albert Cc: radiusext@ops.ietf.org Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Thanks. Would this be done by the home networks or the intermediaries? Are you willing to say if something like this is currently done in your organization, acting as an intermediary? --Jari Roy Albert wrote: > In the case where someone's credentials have been compromised, it is > necessary to have a unique per-user identifier to help detect this (much > as credit card companies do) by monitoring for unusual activity. This is > not quite covered by your points below. >=20 > -Roy >=20 > Roy D. Albert > ralbert@ipass.com > =20 >=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, July 16, 2004 11:27 AM > To: Bernard Aboba > Cc: 'radiusext@ops.ietf.org' > Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) >=20 > Bernard Aboba wrote: >=20 >=20 >>It seems like everyone is seeing a different application for the >=20 > attribute >=20 >>-- and that is why it is so hard to come to agreement on the problem >>statement. >=20 >=20 > Right. I think we have seen the following applications > or individual requirements: >=20 > 1. Lothar: Get the user's "trackable" identity for the access > network so that fraudulent users can be tracked down and > acted upon without involving home operator (possibly in > another timezone and government etc). >=20 > Note 1: This requires some sort of real identity, just > stable but opaque identifier would be insufficient. Or > its sufficient for denying further service, but not for > taking some action against the user. >=20 > Note 2: I'm not sure I want to think about the privacy > implications of this. No hotspot access in the Big Brother > Republic unless your home ISP sends your passport number, > snail address, and biometric data in an Access-Accept. Hmm... > I think we are going to get here sooner or later :-( >=20 > 2. Avi: Controlling a policy for the user, such as limits > on the number of simultaneous sessions per user. >=20 > Note 3: This is only useful if the home network's policy > is different from the access network's policy. For instance, > home network has unlimited access while access network > allows at most one access at a time. >=20 > Note 4: Even if the policies are different, home networks > could still apply the policy on a per-visited network > basis. This could be problematic for provisioning, > however. >=20 > Note 5: Even if the access network applies the policy, > it has no guarantee that the identity given to it is > correct. A fraudulent home network could claim that > all sessions come from a different user, whereas in > reality they actually are from one user. Does this > matter? >=20 > 3. Farid: Retrieve real identity when tunneled or > pseudonym-based EAP methods are used. >=20 > 4. Blair: Correlate accounting records with > an identifier so that fixed price > billing models can be applied at a service > provider. >=20 > Note 6: This requires a stable (~ month) > identity, but it does not have to be a "real" > identity. Compare to requirement 1! >=20 > 5. Farid: Provide a new format to carry non-NAI > identities, such as IMSI or E.164 numbers. >=20 > 6. Farid: Provide an alternate, second identifier > in addition to the NAI. >=20 > Note 7: I am presuming that this is a requirement. > Is it? >=20 > 7. Jari: Carry a privacy-protected "handle" instead > of the "real" identity when returning User-Name/ > Class/User-Alias. >=20 > Anything else? >=20 > --Jari >=20 > -- > 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: >=20 >=20 >=20 >=20 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 18:53:11 +0000 Message-ID: <40F822CD.4030100@piuha.net> Date: Fri, 16 Jul 2004 21:47:41 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Roy Albert Cc: radiusext@ops.ietf.org Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks. Would this be done by the home networks or the intermediaries? Are you willing to say if something like this is currently done in your organization, acting as an intermediary? --Jari Roy Albert wrote: > In the case where someone's credentials have been compromised, it is > necessary to have a unique per-user identifier to help detect this (much > as credit card companies do) by monitoring for unusual activity. This is > not quite covered by your points below. > > -Roy > > Roy D. Albert > ralbert@ipass.com > > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, July 16, 2004 11:27 AM > To: Bernard Aboba > Cc: 'radiusext@ops.ietf.org' > Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) > > Bernard Aboba wrote: > > >>It seems like everyone is seeing a different application for the > > attribute > >>-- and that is why it is so hard to come to agreement on the problem >>statement. > > > Right. I think we have seen the following applications > or individual requirements: > > 1. Lothar: Get the user's "trackable" identity for the access > network so that fraudulent users can be tracked down and > acted upon without involving home operator (possibly in > another timezone and government etc). > > Note 1: This requires some sort of real identity, just > stable but opaque identifier would be insufficient. Or > its sufficient for denying further service, but not for > taking some action against the user. > > Note 2: I'm not sure I want to think about the privacy > implications of this. No hotspot access in the Big Brother > Republic unless your home ISP sends your passport number, > snail address, and biometric data in an Access-Accept. Hmm... > I think we are going to get here sooner or later :-( > > 2. Avi: Controlling a policy for the user, such as limits > on the number of simultaneous sessions per user. > > Note 3: This is only useful if the home network's policy > is different from the access network's policy. For instance, > home network has unlimited access while access network > allows at most one access at a time. > > Note 4: Even if the policies are different, home networks > could still apply the policy on a per-visited network > basis. This could be problematic for provisioning, > however. > > Note 5: Even if the access network applies the policy, > it has no guarantee that the identity given to it is > correct. A fraudulent home network could claim that > all sessions come from a different user, whereas in > reality they actually are from one user. Does this > matter? > > 3. Farid: Retrieve real identity when tunneled or > pseudonym-based EAP methods are used. > > 4. Blair: Correlate accounting records with > an identifier so that fixed price > billing models can be applied at a service > provider. > > Note 6: This requires a stable (~ month) > identity, but it does not have to be a "real" > identity. Compare to requirement 1! > > 5. Farid: Provide a new format to carry non-NAI > identities, such as IMSI or E.164 numbers. > > 6. Farid: Provide an alternate, second identifier > in addition to the NAI. > > Note 7: I am presuming that this is a requirement. > Is it? > > 7. Jari: Carry a privacy-protected "handle" instead > of the "real" identity when returning User-Name/ > Class/User-Alias. > > Anything else? > > --Jari > > -- > 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: > > > > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 18:40:40 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 11:36:28 -0700 Message-ID: Thread-Topic: Privacy (Was: Re: NAI decoration: User Identity issues) Thread-Index: AcRrYxPN1wNc5CvBQ4mp3FBsPSPOTwAAHMcQ From: "Roy Albert" To: jari.arkko@piuha.net, "Bernard Aboba" cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In the case where someone's credentials have been compromised, it is necessary to have a unique per-user identifier to help detect this (much as credit card companies do) by monitoring for unusual activity. This is not quite covered by your points below. -Roy Roy D. Albert ralbert@ipass.com =20 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Friday, July 16, 2004 11:27 AM To: Bernard Aboba Cc: 'radiusext@ops.ietf.org' Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Bernard Aboba wrote: > It seems like everyone is seeing a different application for the attribute > -- and that is why it is so hard to come to agreement on the problem > statement. Right. I think we have seen the following applications or individual requirements: 1. Lothar: Get the user's "trackable" identity for the access network so that fraudulent users can be tracked down and acted upon without involving home operator (possibly in another timezone and government etc). Note 1: This requires some sort of real identity, just stable but opaque identifier would be insufficient. Or its sufficient for denying further service, but not for taking some action against the user. Note 2: I'm not sure I want to think about the privacy implications of this. No hotspot access in the Big Brother Republic unless your home ISP sends your passport number, snail address, and biometric data in an Access-Accept. Hmm... I think we are going to get here sooner or later :-( 2. Avi: Controlling a policy for the user, such as limits on the number of simultaneous sessions per user. Note 3: This is only useful if the home network's policy is different from the access network's policy. For instance, home network has unlimited access while access network allows at most one access at a time. Note 4: Even if the policies are different, home networks could still apply the policy on a per-visited network basis. This could be problematic for provisioning, however. Note 5: Even if the access network applies the policy, it has no guarantee that the identity given to it is correct. A fraudulent home network could claim that all sessions come from a different user, whereas in reality they actually are from one user. Does this matter? 3. Farid: Retrieve real identity when tunneled or pseudonym-based EAP methods are used. 4. Blair: Correlate accounting records with an identifier so that fixed price billing models can be applied at a service provider. Note 6: This requires a stable (~ month) identity, but it does not have to be a "real" identity. Compare to requirement 1! 5. Farid: Provide a new format to carry non-NAI identities, such as IMSI or E.164 numbers. 6. Farid: Provide an alternate, second identifier in addition to the NAI. Note 7: I am presuming that this is a requirement. Is it? 7. Jari: Carry a privacy-protected "handle" instead of the "real" identity when returning User-Name/ Class/User-Alias. Anything else? --Jari -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 18:32:24 +0000 Message-ID: <40F81DF9.9050508@piuha.net> Date: Fri, 16 Jul 2004 21:27:05 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: "'radiusext@ops.ietf.org'" Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > It seems like everyone is seeing a different application for the attribute > -- and that is why it is so hard to come to agreement on the problem > statement. Right. I think we have seen the following applications or individual requirements: 1. Lothar: Get the user's "trackable" identity for the access network so that fraudulent users can be tracked down and acted upon without involving home operator (possibly in another timezone and government etc). Note 1: This requires some sort of real identity, just stable but opaque identifier would be insufficient. Or its sufficient for denying further service, but not for taking some action against the user. Note 2: I'm not sure I want to think about the privacy implications of this. No hotspot access in the Big Brother Republic unless your home ISP sends your passport number, snail address, and biometric data in an Access-Accept. Hmm... I think we are going to get here sooner or later :-( 2. Avi: Controlling a policy for the user, such as limits on the number of simultaneous sessions per user. Note 3: This is only useful if the home network's policy is different from the access network's policy. For instance, home network has unlimited access while access network allows at most one access at a time. Note 4: Even if the policies are different, home networks could still apply the policy on a per-visited network basis. This could be problematic for provisioning, however. Note 5: Even if the access network applies the policy, it has no guarantee that the identity given to it is correct. A fraudulent home network could claim that all sessions come from a different user, whereas in reality they actually are from one user. Does this matter? 3. Farid: Retrieve real identity when tunneled or pseudonym-based EAP methods are used. 4. Blair: Correlate accounting records with an identifier so that fixed price billing models can be applied at a service provider. Note 6: This requires a stable (~ month) identity, but it does not have to be a "real" identity. Compare to requirement 1! 5. Farid: Provide a new format to carry non-NAI identities, such as IMSI or E.164 numbers. 6. Farid: Provide an alternate, second identifier in addition to the NAI. Note 7: I am presuming that this is a requirement. Is it? 7. Jari: Carry a privacy-protected "handle" instead of the "real" identity when returning User-Name/ Class/User-Alias. Anything else? --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 18:02:30 +0000 Message-ID: <40F816F8.9000209@piuha.net> Date: Fri, 16 Jul 2004 20:57:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > It's only a problem if the RADIUS server requires this behavior. But > we've already said that from the RADIUS server point of view, there is no > distinction between Billable Identity and Class. They provide the same > functionality. So a RADIUS server can send *both* Class and > Billable-Identity and be ensured that at least one of these will be > understood. This is OK, but one may wonder whether Class alone would suffice all the time, if it suffices for some cases. I do see the problems in using Class -- there are many. But if you are saying its OK for some subset of the cases... what's the difference that the new attribute would give in the rest of the cases? And presuming that there is a difference, how is it that the service providers are going to live with the restrictions of the Class attribute _and_ keep their fixed price business model? Perhaps the answer lies in the definition of the business model. Is it (a) Access provider MUST present a fixed cost bill per user per month, and MUST ensure that a given user is logged on at most once at any given time. or (b) Access provider SHOULD present a fixed cost bill per user per month, and SHOULD ensure that a given is logged on at most once at any given time. However, if the peer equipment indicates that it does not support this feature, then a per-session bill MAY also be presented, and session limits MAY be ignored. Note that if the answer is "a", then we have two ways of achieving it: we can either try to achieve it at the protocol level or through some sort of roamaing agreements (e.g., GSMA). --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:42:12 +0000 Message-ID: <40F81232.90200@piuha.net> Date: Fri, 16 Jul 2004 20:36:50 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: NAIbis effects (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > This is functionality that has been in place for many years and so I'm not > sure we can mandate new behavior. My assumption has been that User-Name > attributes returned in the Access-Accept are not handled the same way that > User-Name attributes in an Access-Request are. I can do this in either way, but let me just dig a bit deeper into the above. Why do you think Access-Accept is handled in a different way? Its certainly handled by a different piece of code, but I would assume that there has to be some state associated with the Access-Reques/Accept pair, otherwise retransmission would not be possible. So, given that the '!' conversion already needs new code for the Access-Request, it seems that all that is needed is that the Access-Accept part of the code looks into the stored state and sees that it needs to insert back something. (Note: I'd like to find out whether I will leave this out from naibis-02 by tomorrow, because I will submit the revision then, as I'm going to be away from the net a couple of days after that.) --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:26:03 +0000 Date: Fri, 16 Jul 2004 10:23:24 -0700 (PDT) From: Bernard Aboba To: Lothar Reith cc: "'Klaas Wierenga'" , "'radiusext@ops.ietf.org'" Subject: Re: AW: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > "privacy-protected-identity", which - when present - is used instead of the > NAI for all kinds of purposes normally the NAI is used for, including > billing, re-authorization, abuse tracking etc. Can't that function be handled by sending a User-Name attribute in the Access-Accept? Why would another attribute be needed? > seems to be federated identity management (with privacy). Is anybody seeing > a different application for this new attribute ? It seems like everyone is seeing a different application for the attribute -- and that is why it is so hard to come to agreement on the problem statement. The proposal on the table only uses the new attribute for accounting, not for authentication. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:18:04 +0000 Date: Fri, 16 Jul 2004 10:15:43 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: Barney Wolff , radiusext@ops.ietf.org Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The primary problem is that RFC 2866 did not require that unrecognized > attributes be copied verbatim to the accounting request packets. (Or > am I missing some text somewhere?) No you're not missing something. Since unrecognized attributes can be ignored entirely, it's possible that nothing at all may happen as a result of sending them. > So I agree that the NAS support for a new attribute which would have > to be copied from Access-Accept to Accounting-Request is a problem. It's only a problem if the RADIUS server requires this behavior. But we've already said that from the RADIUS server point of view, there is no distinction between Billable Identity and Class. They provide the same functionality. So a RADIUS server can send *both* Class and Billable-Identity and be ensured that at least one of these will be understood. > bit mask) which would enable the server to know what the NAS > can do. This only helps if the attribute in question is really Mandatory. But Billable-Identity seems like it is optional. > it isn't clear what to _do_ in the case when the NAS does > not support it. It's only a problem if the attribute MUST be supported by the NAS or service cannot be provided (such as security-critical functionality). So far quite a few attributes in the LAN attributes document fit in this category (such as VLAN-related attributes or IP filters). So that document appears dependent on the resolution of this issue. Note that in this particular case the "RFC Compliance" argument doesn't hold. It's one thing to assume that a NAS with NAS-Port-Type of 802.11 or 802 is compliant with RFC 3580; it's another thing to assume that they're compliant with an extension document that may only reach a fraction of the installed base. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:11:55 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462C3563F@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" , "'Klaas Wierenga'" Cc: "'radiusext@ops.ietf.org'" Subject: AW: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 18:11:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46B57.EEB997E6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46B57.EEB997E6 Content-Type: text/plain Klaas wrote: > Possibly. In the Netherlands most universities are in such a 'roaming > consortium' to provide guest access to eachothers wireless LANs based > on 802.1X+RADIUS. Some universities want to know the real identity of > a user in case of abuse. The alternative is to agree on a logging > format so that abuse can be tracked down by contacting the home > organisation of the user, but this may be difficult (many log entries > for > anonymous@university-a.nl) and requires in any case a lot of coordination. > And a bit further along the road, possibly the visited institution wants > to do more advance authorisation based on the identity of the user (did > he complete math101, is he a staff member etc.) Bernard wrote: Can this particular scenario be handled by the attributes that exist (User-Name, Class) or are being discussed (Billable-Identity)? Lothar writes: I would think yes, e.g. by combining all 3 of them, the privacy requesting NAI "anonymous@university-a.nl" with a privacy granting "Billable identity" issued by a trusted party (the home university), combined with Class attribute which by some bilateral agreement between participating universities could use the Class attribute to communicate membership in a certain group, such as university-staff-member or advanced-student-of-mathematics. I would however suggest to be very careful with the name of the "billable-identity" attribute - after all these students probably do not receive a bill at all, therefor the notion of "billable identity" may be misleading. I think we are really talking about a "privacy-protected-identity", which - when present - is used instead of the NAI for all kinds of purposes normally the NAI is used for, including billing, re-authorization, abuse tracking etc. Simply because the NAI is not unique and in this case appears to only serve the routing of the initial access request to the home network and back. Of course the home network MUST be able to assert and resolve the privacy-protected-identity to the true identity of the user. And the notion of "logging format" leads me to the suggestion, that if the logging is not done via RADIUS accounting, than it must include the "privacy-protected-identity" otherwise there would be no way to track down the true identity of an abusive user. I guess at the end of the day, the one key application for this new RADIUS attribute sofar called either "billable-identity"- or "alius-username" seems to be federated identity management (with privacy). Is anybody seeing a different application for this new attribute ? Regards, Lothar ------_=_NextPart_001_01C46B57.EEB997E6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable AW: AW: Privacy (Was: Re: NAI decoration: User Identity = issues)

Klaas wrote:
> Possibly. In the Netherlands most universities = are in such a 'roaming
> consortium' to provide guest access to = eachothers wireless LANs based
> on 802.1X+RADIUS. Some universities want to = know the real identity of
> a user in case of abuse. The alternative is to = agree on a logging
> format so that abuse can be tracked down by = contacting the home
> organisation of the user, but this may be = difficult (many log entries
> for
> anonymous@university-a.nl) and requires in any = case a lot of coordination.
> And a bit further along the road, possibly the = visited institution wants
> to do more advance authorisation based on the = identity of the user (did
> he complete math101, is he a staff member = etc.)


Bernard wrote:
Can this particular scenario be handled by the = attributes that exist (User-Name, Class) or are being discussed = (Billable-Identity)?

Lothar writes:
I would think yes, e.g. by combining all 3 of them, = the privacy requesting NAI "anonymous@university-a.nl" with a = privacy granting "Billable identity" issued by a trusted = party (the home university), combined with Class attribute which by = some bilateral agreement between participating universities could use = the Class attribute to communicate membership in a certain group, such = as university-staff-member or advanced-student-of-mathematics. =

I would however suggest to be very careful with the = name of the "billable-identity" attribute - after all these = students probably do not receive a bill at all, therefor the notion of = "billable identity" may be misleading.  I think we are = really talking about a "privacy-protected-identity", which - = when present - is used instead of the NAI for all kinds of purposes = normally the NAI is used for, including billing, re-authorization, = abuse tracking etc. Simply because the NAI is not unique and in this = case appears to only serve the routing of the initial access request to = the home network and back.  Of course the home network MUST be = able to assert and resolve the privacy-protected-identity to the true = identity of the user. 

And the notion of "logging format" leads me = to the suggestion, that if the logging is not done via RADIUS = accounting, than it must include the = "privacy-protected-identity" otherwise there would be no way = to track down the true identity of an abusive user.

I guess at the end of the day, the one key = application for this new RADIUS attribute sofar called either = "billable-identity"- or "alius-username"  = seems to be federated identity management (with privacy).  Is = anybody seeing a different application for this new attribute = ?

Regards, Lothar

------_=_NextPart_001_01C46B57.EEB997E6-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:08:22 +0000 Date: Fri, 16 Jul 2004 10:06:06 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org Subject: Re: Class vs. UserAlias (Was: Re: NAI decoration: User Identity issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One could perhaps argue that if there's a business relationship > between X and Y, they should agree that a Class attribute is used, > and that the bytes 1-20 represent the true identity. This kind of thing is fine on the RADIUS server. However, it doesn't work on the RADIUS client, which needs to contain code to parse the Class attribute in order to determine if it has a billable identity or not. In many cases, this is not possible. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 17:06:50 +0000 Date: Fri, 16 Jul 2004 10:04:28 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org Subject: Re: NAIbis effects (Was: Re: NAI decoration: User Identity issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > But don't you think the reader > should be alerted to this potential feature interaction in some > document? Yes, we do need to address it somewhere. Perhaps the "RADIUS implementation issues and fixes" document is the place for this. > Maybe in the naibis document? In fact, we have two > choices: > > 1) Warn the reader about this interaction, and suggest not > using returned user name and routing syntax at the same > time. I think we need to alert the reader to the consequences. Not every setup involves roaming, so it may not be an issue. > 2) Require intermediaries to redo the routing syntax > when the user name comes back in an Access-Accept. This is functionality that has been in place for many years and so I'm not sure we can mandate new behavior. My assumption has been that User-Name attributes returned in the Access-Accept are not handled the same way that User-Name attributes in an Access-Request are. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 16:48:20 +0000 Message-ID: <40F806EB.4010302@SURFnet.nl> Date: Fri, 16 Jul 2004 18:48:43 +0200 From: Klaas Wierenga User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) MIME-Version: 1.0 To: Bernard Aboba CC: "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: Bernard, >>Possibly. In the Netherlands most universities are in such a 'roaming >>consortium' to provide guest access to eachothers wireless LANs based on >>802.1X+RADIUS. Some universities want to know the real identity of a >>user in case of abuse. The alternative is to agree on a logging format >>so that abuse can be tracked down by contacting the home organisation of >>the user, but this may be difficult (many log entries for >>anonymous@university-a.nl) and requires in any case a lot of coordination. >>And a bit further along the road, possibly the visited institution wants >>to do more advance authorisation based on the identity of the user (did >>he complete math101, is he a staff member etc.) > > > Can this particular scenario be handled by the attributes that exist > (User-Name, Class) or are being discussed (Billable-Identity)? To be totally honest, I don't know. I hope to get some students to investigate this. I really don't know what would be best/possible, use RADIUS for this or perhaps keep the RADIUS infrastructure relatively stupid and try to solve this in EAP (talking SAML over EAP??). Any thoughts on this would be appreciated. Klaas -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 16:36:57 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Deployment (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 12:36:32 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Jari, > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, July 16, 2004 10:55 AM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Deployment (Was: Re: NAI decoration: User > Identity issues) > > > Avi Lior wrote: > > > I think the MUST should be changed to SHOULD and thus not requiring > > any changes to NASes. > > I can see the "legal" distinction between a MUST and a > SHOULD, but wouldn't the change still be needed in practise > on the NASes, before this functionality becomes operational? There are two general uses for User-Alias. 1) One is the case where Intermediaries or Access network etc are trying to control policy such as how many times a user can connect to the network. (Appatently this is the case in some deployements) 2) The other is the case where it is needed during accounting. So to have the functionality operational in somecases it doesn't have to be a MUST. > In fact, I'd be happy even with a MUST -- NASes that don't > support that MUST don't support this particular RFC, which is > of course perfectly legal... We could do that. My prefence is to use MUSTs whenever I can so if there were no objections then leave it as a MUST. But its not allways necessary as pointed above. > > In a situtaion where a NAS does not support this attribute yet an > > Intermediary needed to correlate accounting to the > > User-Alias-Identity, the Intermediary would insert the > Class attribute > > in the Access Accept and if the NAS supported the Class attribute, > > problem solved. > > I think the NASes must support the Class attribute if they > are compliant with RFC 2865/66. In 2865 Class is a SHOULD not a MUST. "This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server." And while I am at the section - just in case some are thinking that its okay to have the client interpret Class: "The client MUST NOT interpret the attribute locally." > Anyway, I think your compatibility scheme works. I just wish > we didn't need to have alternative modes of operation. Me too. > --Jari > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 16:14:53 +0000 Date: Fri, 16 Jul 2004 09:12:33 -0700 (PDT) From: Bernard Aboba To: Klaas Wierenga cc: "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Possibly. In the Netherlands most universities are in such a 'roaming > consortium' to provide guest access to eachothers wireless LANs based on > 802.1X+RADIUS. Some universities want to know the real identity of a > user in case of abuse. The alternative is to agree on a logging format > so that abuse can be tracked down by contacting the home organisation of > the user, but this may be difficult (many log entries for > anonymous@university-a.nl) and requires in any case a lot of coordination. > And a bit further along the road, possibly the visited institution wants > to do more advance authorisation based on the identity of the user (did > he complete math101, is he a staff member etc.) Can this particular scenario be handled by the attributes that exist (User-Name, Class) or are being discussed (Billable-Identity)? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 15:52:14 +0000 Message-ID: <40F7F9BB.7070103@SURFnet.nl> Date: Fri, 16 Jul 2004 17:52:27 +0200 From: Klaas Wierenga User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) MIME-Version: 1.0 To: Lothar Reith CC: "'jarkko@piuha.net'" , 'Barney Wolff' , 'Bernard Aboba' , 'Avi Lior' , "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lothar Reith wrote: Lothar, > Is there any reason that the roaming consortium or the local access > network *needs* to know the *true" user identity, in case of the > authenticating user (or the home network) requesting privacy ? Possibly. In the Netherlands most universities are in such a 'roaming consortium' to provide guest access to eachothers wireless LANs based on 802.1X+RADIUS. Some universities want to know the real identity of a user in case of abuse. The alternative is to agree on a logging format so that abuse can be tracked down by contacting the home organisation of the user, but this may be difficult (many log entries for anonymous@university-a.nl) and requires in any case a lot of coordination. And a bit further along the road, possibly the visited institution wants to do more advance authorisation based on the identity of the user (did he complete math101, is he a staff member etc.) Klaas -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 15:52:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: MUST vs. SHOULD, Mandatory vs. Optional Date: Fri, 16 Jul 2004 11:51:01 -0400 Message-ID: Thread-Topic: MUST vs. SHOULD, Mandatory vs. Optional Thread-Index: AcRrS0XACm1NTWm+TXqQmYGpiUU7sQAAELOw From: "Nelson, David" To: "Bernard Aboba" , > >RADIUS has never had a protocol-based notion of Mandatory vs. Optional > Attributes. >=20 > In RFC 2865, it says that attributes that aren't understood may be treated > as optional. It says that they may be ignored, which means the same thing. > On the other hand, a RADIUS client that receives a request > for a service it does not implement must not provide that service. So the > question comes down to what attributes define a service (mandatory) and > which don't (optional). One take on this is that Service-Type is a > mandatory attribute. That is, if a NAS doesn't support the Service-Type > value requested by the server, then it has to act as if an Access-Reject > was sent. I agree. What I meant by "protocol-based notion" was an attribute by attribute flagging mechanism, such as we have in Diameter. > >I think that the most that can be said of an existing NAS that is > RFC2865 compliant, but does not implement a new attribute is that it is > not RFCxxxx compliant. >=20 > That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC > 3580, etc.). But if each attribute is published in a separate RFC then we > end up with a tower of Babel -- creating lots of new RADIUS dialects. > That's not helpful. Um... Yes, there is that practical side to the issue. I would hope that the number of new features (I'm explicitly avoiding the word "application" because of the debate that's been going on over on the AAA WG list), would be small, such that it might be practical to have an RFC per feature. Certainly not an RFC per attribute, as I see each new feature as requiring a set of new attributes. -- Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 15:41:06 +0000 Message-Id: <200407161538.i6GFcrb13559@internaut.com> To: radiusext@ops.ietf.org Subject: Re: MUST vs. SHOULD, Mandatory vs. Optional Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 16 Jul 2004 08:38:52 -0700 From: Bernard Aboba >RADIUS has never had a protocol-based notion of >Mandatory vs. Optional Attributes. In RFC 2865, it says that attributes that aren't understood may be treated as optional. On the other hand, a RADIUS client that receives a request for a service it does not implement must not provide that service. So the question comes down to what attributes define a service (mandatory) and which don't (optional). One take on this is that Service-Type is a mandatory attribute. That is, if a NAS doesn't support the Service-Type value requested by the server, then it has to act as if an Access-Reject was sent. >I think that the most that can be said of an existing >NAS that is RFC2865 compliant, but does not implement >a new attribute is that it is not RFCxxxx compliant. That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC 3580, etc.). But if each attribute is published in a separate RFC then we end up with a tower of Babel -- creating lots of new RADIUS dialects. That's not helpful. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 15:40:57 +0000 Message-Id: <200407161538.i6GFcZd13525@internaut.com> To: radiusext@ops.ietf.org, Nelson@internaut.com, David Subject: Re: MUST vs. SHOULD, Mandatory vs. Optional Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 16 Jul 2004 08:38:35 -0700 From: Bernard Aboba >RADIUS has never had a protocol-based notion of >Mandatory vs. Optional Attributes. In RFC 2865, it says that attributes that aren't understood may be treated as optional. On the other hand, a RADIUS client that receives a request for a service it does not implement must not provide that service. So the question comes down to what attributes define a service (mandatory) and which don't (optional). One take on this is that Service-Type is a mandatory attribute. That is, if a NAS doesn't support the Service-Type value requested by the server, then it has to act as if an Access-Reject was sent. >I think that the most that can be said of an existing >NAS that is RFC2865 compliant, but does not implement >a new attribute is that it is not RFCxxxx compliant. That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC 3580, etc.). But if each attribute is published in a separate RFC then we end up with a tower of Babel -- creating lots of new RADIUS dialects. That's not helpful. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 15:23:58 +0000 Message-Id: <200407161521.i6GFLP612479@internaut.com> To: jari.arkko@piuha.net Cc: radiusext@ops.ietf.org Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 16 Jul 2004 08:21:25 -0700 From: Bernard Aboba >the Intermediary would insert the Class attribute in To the RADIUS server, the "Intermediary" is just another RADIUS client. So the question still exists. How does the server know the RADIUS client supports this? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 14:59:55 +0000 Message-ID: <40F7EC33.4060400@piuha.net> Date: Fri, 16 Jul 2004 17:54:43 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > I think the MUST should be changed to SHOULD and thus not requiring any > changes to NASes. I can see the "legal" distinction between a MUST and a SHOULD, but wouldn't the change still be needed in practise on the NASes, before this functionality becomes operational? In fact, I'd be happy even with a MUST -- NASes that don't support that MUST don't support this particular RFC, which is of course perfectly legal... > In a situtaion where a NAS does not support this attribute yet an > Intermediary needed to correlate accounting to the User-Alias-Identity, the > Intermediary would insert the Class attribute in the Access Accept and if > the NAS supported the Class attribute, problem solved. I think the NASes must support the Class attribute if they are compliant with RFC 2865/66. Anyway, I think your compatibility scheme works. I just wish we didn't need to have alternative modes of operation. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 14:59:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: MUST vs. SHOULD, Mandatory vs. Optional Date: Fri, 16 Jul 2004 10:57:57 -0400 Message-ID: Thread-Topic: MUST vs. SHOULD, Mandatory vs. Optional Thread-Index: AcRrRUfdDLjASgXUSFWBy4tSWlsmnQ== From: "Nelson, David" To: RADIUS has never had a protocol-based notion of Mandatory vs. Optional Attributes. There is a proposal to add this feature, by means of an explicit "M" bit in the format of certain classes of extended attributes. I'm going to withhold substantive comment on that proposal, until I have had more time to contemplate the all implications. This would be a useful feature. OTOH, our charter is not to evolve RADIUS into Diameter. There has also been some discussion as to when to use MUST and when to use SHOULD in describing new attributes defined within RADEXT documents. One issue is with respect to conformance and whether a MUST implies that existing NASes must be upgraded to implement the feature to be "RADIUS compliant" or be useful in environment where the new attribute is in use. I think that the most that can be said of an existing NAS that is RFC2865 compliant, but does not implement a new attribute is that it is not RFCxxxx compliant (where RFCxxx defines the new feature and its attributes). RFCxxxx can specify a MUST only with respect to implementation of the feature described in the document. I think of this as a "conditional MUST", which means MUST if and only if the underlying extended feature has been implemented.=20 If the MUST language is appropriate to describing the need for specific attribute handling or implementation with respect to the new feature, then the language ought not to be softened to SHOULD, just because some NASes will not implement the new feature. The scope of applicability of the RFC should clearly indicate that the requirements of the document apply to NASes that implement the feature described in the document. The capabilities announcement functionality should be sufficient to address global interoperability issues with respect to NASes that do and do not implement the new feature. These considerations should be part of the respective document. -- Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 14:43:31 +0000 Message-ID: <40F7E839.9040200@piuha.net> Date: Fri, 16 Jul 2004 17:37:45 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > So potentially (if you didn't have the legacy issue with EAP), you would want to have an "EAP attribute" with all the related info as sub-attributes, no? Right. If current protocols did not exist, we could design a new one :-) But since they do exist, we are not going to do extensions that break backwards compatibility without a very good reason. This I believe is independent of any potential attempts to extend the data model: data model extensions, if any, would only apply to new attributes. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 14:20:53 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Barney Wolff , "'Adrangi, Farid'" Cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Fri, 16 Jul 2004 10:20:34 -0400 MIME-Version: 1.0 Content-Type: text/plain Bernard, Barney and Farid, Bernard's point is well taken. I checked the latest posted draft and it says that the User-Alias-Identity MUST be placed in Accounting if it was received in an Access Accept. I think the MUST should be changed to SHOULD and thus not requiring any changes to NASes. In a situtaion where a NAS does not support this attribute yet an Intermediary needed to correlate accounting to the User-Alias-Identity, the Intermediary would insert the Class attribute in the Access Accept and if the NAS supported the Class attribute, problem solved. Avi. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, July 16, 2004 1:21 AM > To: Barney Wolff > Cc: radiusext@ops.ietf.org > Subject: Re: NAI decoration: User Identity issues > > > > > Class attributes could change over the lifetime of even a session > > > because class attribute may store stuff other then just the User > > > Alias. So you cant use it as the User's Identity. > > Depends who "you" is. Presumably, the RADIUS server can use > it, since it sent the Class attribute. But I think the point > is that the RADIUS client can't be sure that the Class > attribute contains a billable identity. If in addition the > User-Name does not contain a billable identity (e.g. > privacy) then the RADIUS client has no assurance of billability. > > > all the world's NAS's have to be upgraded? > > This raises the question about whether the billable-identity > is an optional or mandatory attribute. My take is that it is > optional. Here's why. If it is sent by the RADIUS server and > not understood by the NAS, RFC 2865 states clearly that it > MAY be ignored. > > My understanding is that the issue here is on the RADIUS > client side, because if the RADIUS server wanted to make sure > that got the opaque string back in the accounting record, it > could always send that opaque blob *both* in the > billable-identity attribute and in Class. That way, if the > RADIUS client cared about billable-identity, it would have > it; if not, it would ignore it. > > If you buy this logic, then no NAS upgrade is required. > > > If all NAS's are not forced to upgrade, how will the server know > > whether it can include User-Alias? > > If the above argument isn't convincing, and we conclude that > this attribute is Mandatory, then we have an issue. RFC 2865 > doesn't support Mandatory attributes. There are a number of > proposals on the table to fix this, however (e.g. Jari's > proposal for a new attribute format with an 'M' bit). > > -- > 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: > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 13:08:43 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Barney Wolff Cc: radiusext@ops.ietf.org Subject: RE: RFC 2865 compatibility Date: Fri, 16 Jul 2004 09:08:33 -0400 MIME-Version: 1.0 Content-Type: text/plain Bernard, Barney, > > b) Respecify the attribute in a way that its use can be > negotiated and the RADIUS server can be guaranteed that if > sent and not understood, the right thing will happen (e.g. no > service will be granted to the user). There are proposals on > the table that provide for this (e.g. Jari's proposal for > extended attributes). And also the capability exchange that is also on the table would help here. Also note that the NAS may not support the extended attributes. > -- > 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: > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 12:46:22 +0000 Message-ID: From: Avi Lior To: "'jarkko@piuha.net'" , Barney Wolff Cc: Bernard Aboba , Avi Lior , radiusext@ops.ietf.org Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 08:46:16 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Jari and Barney, See comments inserted > -----Original Message----- > From: Jari Arkko [mailto:jarkko@piuha.net] > Sent: July 16, 2004 3:13 AM > To: Barney Wolff > Cc: Bernard Aboba; Avi Lior; radiusext@ops.ietf.org > Subject: Privacy (Was: Re: NAI decoration: User Identity issues) > > > Barney Wolff wrote: > > > I guess the question is whether there is a long-term one-to-one > > relationship between User-Alias and the user's "true" identity. If > > there is, then attackers can gain information of some value by > > correlating different accesses resulting in the same User-Alias. Absolutely. > This is an interesting issue. There is a very valid reason > for employing privacy at the network access protocol level > (say, in 802.1X/EAP/NAI). This is primarily to avoid being > exposed to other clients on the same network. Not so much > against the service provider. > > But I think there is also interest in ensuring some level of > protection against the service provider, or at least parts of > it. Clearly, the home network is going to know who you are. > Maybe even the roaming consortium and the local access > network. But I'd rather not reveal my true identity to the > access point on the coffee shop wall. It is in an insecure > environment, often uses a wireless uplink or other weakly > protected physical medium. And if it runs RADIUS, the chances > are that its not running ESP so the contents of any new AVP > being returned from the home network would be relatively > easily visible to those who wanted to look. > > On the other hand, there is also a valid business reason for > some intermediaries to relate different sessions to the same > entity so that fixed price model can be applied. Yes this is the requirement that we received. Some intermediaries are indeed charged with ensuring policies such as the user is only logged in once. > One way to resolve these conflicting requirements is to (a) > explain that the attribute (be it Class or something new) is > to be returned with fixed contents only if the particular > business situation requires it, Agreed. The operator will put it in if it needs it in. >(b) in the proxy, strip off > the attribute from the packets going to the NAS and insert a > Class attribute with opaque and not-fixed contents instead, > and It is possible that the proxy may know that the User-Alias is not needed past a particular point. It could strip it off and insert it back in accounting. This is a normal behavior for some proxies already. How it does it is not important. It could use class. >(c) when the accounting request comes back from the NAS, > take away the inserted Class and replace with the original attribute. > But this is complicated. Feel free to suggests a more optimal > scheme :-) Proxies already do this type of operations. It is complicated and may not be necessary if the User-Alias contained a short lived handle to the user. Long enough to support the business needs but not long enough to function as a user identity. I think if security was an issue that is the way to do this. Avi > --Jari > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 12:36:09 +0000 Message-ID: From: Avi Lior To: "'jarkko@piuha.net'" , Avi Lior Cc: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: RE: Class vs. UserAlias (Was: Re: NAI decoration: User Identity i ssues) Date: Fri, 16 Jul 2004 08:35:40 -0400 MIME-Version: 1.0 Content-Type: text/plain Jari, I don't think it would be wise to specify what Class should or should not contain. IMO we must not touch class. It will break too many implementations. User-Alias or Billable-Identity whatever you want to call it containing a long lived or short lived handle to the user (depending on the privacy need) is the way to go. > -----Original Message----- > From: Jari Arkko [mailto:jarkko@piuha.net] > Sent: July 16, 2004 3:14 AM > To: Avi Lior > Cc: 'Bernard Aboba'; radiusext@ops.ietf.org > Subject: Class vs. UserAlias (Was: Re: NAI decoration: User > Identity issues) > > > Avi Lior wrote: > > A UserAlias can contain some opaque value provided that the > > HomeNetwork asserts that it represents a user for a period > of time. > > That is it will not change over a period of time. The > period of time > > could be a month or even longer. > > > > Class attributes could change over the lifetime of even a session > > because class attribute may store stuff other then just the User > > Alias. > > One of the problems is indeed that the Class attribute may > contain a lot of data, some of which could vary from message > to message. And there may be multiple Class attributes. > > One could perhaps argue that if there's a business > relationship between X and Y, they should agree that a Class > attribute is used, and that the bytes 1-20 represent the true > identity. Not sure if that's reasonable, however. Particular > server implementations might currently use Class in ways that > are not compatible with this approach. > > --Jari > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 10:43:24 +0000 Message-ID: <40F7B013.4080908@piuha.net> Date: Fri, 16 Jul 2004 13:38:11 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Lothar Reith Cc: "'radiusext@ops.ietf.org'" Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lothar Reith wrote: > Is there any reason that the roaming consortium or the local access > network *needs* to know the *true" user identity, in case of the > authenticating user (or the home network) requesting privacy ? I don't think so (except maybe for some some legal interception purposes). In any case, the discussion has focused around giving some stable identity (not necessarily the true identity) to the access network. The purpose of this is to implement some business models where there's per-user fixed price for roaming. So, it is not necessary to give the true identity but even having a stable identity will make it possible to do some correlation of the user's movements, *assiming* access to NASes or cleartext RADIUS traffic from them. Of course, the main problem of revealing the user's identity to everyone on the access link is already solved, if the identity does not appear in clear on the access link. Typical EAP methods handle this with tunneling or temporary pseudonyms. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 10:33:53 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E75462C353FE@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'jarkko@piuha.net'" , "'Barney Wolff'" Cc: "'Bernard Aboba'" , "'Avi Lior'" , "'radiusext@ops.ietf.org'" Subject: AW: Privacy (Was: Re: NAI decoration: User Identity issues) Date: Fri, 16 Jul 2004 11:33:06 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46B20.4839B626" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C46B20.4839B626 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there any reason that the roaming consortium or the local access = network *needs* to know the *true" user identity, in case of the = authenticating user (or the home network) requesting privacy ? Lothar -----Urspr=FCngliche Nachricht----- Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Im Auftrag von Jari Arkko Gesendet: Freitag, 16. Juli 2004 09:13 An: Barney Wolff Cc: Bernard Aboba; Avi Lior; radiusext@ops.ietf.org Betreff: Privacy (Was: Re: NAI decoration: User Identity issues) Barney Wolff wrote: > I guess the question is whether there is a long-term one-to-one=20 > relationship between User-Alias and the user's "true" identity. If=20 > there is, then attackers can gain information of some value by=20 > correlating different accesses resulting in the same User-Alias. This is an interesting issue. There is a very valid reason for = employing privacy at the network access protocol level (say, in 802.1X/EAP/NAI). = This is primarily to avoid being exposed to other clients on the same = network. Not so much against the service provider. But I think there is also interest in ensuring some level of protection against the service provider, or at least parts of it. Clearly, the = home network is going to know who you are. Maybe even the roaming consortium = and the local access network. But I'd rather not reveal my true identity to = the access point on the coffee shop wall. It is in an insecure environment, often uses a wireless uplink or other weakly protected physical medium. = And if it runs RADIUS, the chances are that its not running ESP so the = contents of any new AVP being returned from the home network would be relatively easily visible to those who wanted to look. On the other hand, there is also a valid business reason for some intermediaries to relate different sessions to the same entity so that = fixed price model can be applied. One way to resolve these conflicting requirements is to (a) explain = that the attribute (be it Class or something new) is to be returned with fixed contents only if the particular business situation requires it, (b) in = the proxy, strip off the attribute from the packets going to the NAS and = insert a Class attribute with opaque and not-fixed contents instead, and (c) = when the accounting request comes back from the NAS, take away the inserted = Class and replace with the original attribute. But this is complicated. Feel free to suggests a more optimal scheme = :-) --Jari -- 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: ------_=_NextPart_001_01C46B20.4839B626 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Privacy (Was: Re: NAI decoration: User Identity = issues)

Is there any reason that the roaming consortium or = the local access network *needs* to know the  *true" user = identity, in case of the authenticating user (or the home network) = requesting privacy ?

Lothar

-----Urspr=FCngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org] Im Auftrag von Jari Arkko
Gesendet: Freitag, 16. Juli 2004 09:13
An: Barney Wolff
Cc: Bernard Aboba; Avi Lior; = radiusext@ops.ietf.org
Betreff: Privacy (Was: Re: NAI decoration: User = Identity issues)


Barney Wolff wrote:

> I guess the question is whether there is a = long-term one-to-one
> relationship between User-Alias and the user's = "true" identity.  If
> there is, then attackers can gain information = of some value by
> correlating different accesses resulting in the = same User-Alias.

This is an interesting issue. There is a very valid = reason for employing privacy at the network access protocol level (say, = in 802.1X/EAP/NAI). This is primarily to avoid being exposed to other = clients on the same network. Not so much against the service = provider.

But I think there is also interest in ensuring some = level of protection against the service provider, or at least parts of = it. Clearly, the home network is going to know who you are. Maybe even = the roaming consortium and the local access network. But I'd rather not = reveal my true identity to the access point on the coffee shop wall. It = is in an insecure environment, often uses a wireless uplink or other = weakly protected physical medium. And if it runs RADIUS, the chances = are that its not running ESP so the contents of any new AVP being = returned from the home network would be relatively easily visible to = those who wanted to look.

On the other hand, there is also a valid business = reason for some intermediaries to relate different sessions to the same = entity so that fixed price model can be applied.

One way to resolve these conflicting requirements is = to (a) explain that the attribute (be it Class or something new) is to = be returned with fixed contents only if the particular business = situation requires it, (b) in the proxy, strip off the attribute from = the packets going to the NAS and insert a Class attribute with opaque = and not-fixed contents instead, and (c) when the accounting request = comes back from the NAS, take away the inserted Class and replace with = the original attribute.

But this is complicated. Feel free to suggests a more = optimal scheme :-)

--Jari

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

------_=_NextPart_001_01C46B20.4839B626-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 09:22:18 +0000 Message-ID: <40F7806C.20607@piuha.net> Date: Fri, 16 Jul 2004 10:14:52 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Barney Wolff , Bernard Aboba CC: radiusext@ops.ietf.org Subject: Deployment (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barney Wolff wrote: > So, to support a particular business model, namely fixed per-user billing, > all the world's NAS's have to be upgraded? The business model could be > accomodated by a private agreement on the use of Class between the > intermediary and its customers, with no impact on the NAS. > > If all NAS's are not forced to upgrade, how will the server know whether > it can include User-Alias? The primary problem is that RFC 2866 did not require that unrecognized attributes be copied verbatim to the accounting request packets. (Or am I missing some text somewhere?) So I agree that the NAS support for a new attribute which would have to be copied from Access-Accept to Accounting-Request is a problem. There are proposals on the table (such as Radius capabilities bit mask) which would enable the server to know what the NAS can do. The question is if this helps. What if the NAS does not support this capability? Perhaps you could switch to sending a Class attribute instead. But it isn't clear to me what value there would be in doing the same thing in two ways. Why not do it just in one way then, if that one way has to be done in certain cases anyway? Or are we going to accept this because it provides better functionality at least in those cases that the NAS supports this new functionality? There are also proposals on the table that would make it possible to mark attributes as mandatory. Here too we have a question: what to do if the NAS does not support the attribute? Obviously we could fail the session, or fall back to an easier business model. But the latter is hard to achieve in an Access-Accept that gets rejected by the NAS; it seems that we have to make the decision earlier, based on NAS capabilities. In conclusion a new copied attribute is possible, but it isn't clear what to _do_ in the case when the NAS does not support it. I think this is a problem. (Unfortunately, also the use of the Class attribute seems problematic as has been pointed out in other e-mails.) --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 07:39:06 +0000 Message-ID: <40F784DA.9050609@piuha.net> Date: Fri, 16 Jul 2004 10:33:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Barney Wolff , Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Deployment (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barney Wolff wrote: > So, to support a particular business model, namely fixed per-user billing, > all the world's NAS's have to be upgraded? The business model could be > accomodated by a private agreement on the use of Class between the > intermediary and its customers, with no impact on the NAS. > > If all NAS's are not forced to upgrade, how will the server know whether > it can include User-Alias? The primary problem is that RFC 2866 did not require that unrecognized attributes be copied verbatim to the accounting request packets. (Or am I missing some text somewhere?) So I agree that the NAS support for a new attribute which would have to be copied from Access-Accept to Accounting-Request is a problem. There are proposals on the table (such as Radius capabilities bit mask) which would enable the server to know what the NAS can do. The question is if this helps. What if the NAS does not support this capability? Perhaps you could switch to sending a Class attribute instead. But it isn't clear to me what value there would be in doing the same thing in two ways. Why not do it just in one way then, if that one way has to be done in certain cases anyway? Or are we going to accept this because it provides better functionality at least in those cases that the NAS supports this new functionality? There are also proposals on the table that would make it possible to mark attributes as mandatory. Here too we have a question: what to do if the NAS does not support the attribute? Obviously we could fail the session, or fall back to an easier business model. But the latter is hard to achieve in an Access-Accept that gets rejected by the NAS; it seems that we have to make the decision earlier, based on NAS capabilities. In conclusion a new copied attribute is possible, but it isn't clear what to _do_ in the case when the NAS does not support it. I think this is a problem. (Unfortunately, also the use of the Class attribute seems problematic as has been pointed out in other e-mails.) --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 07:19:10 +0000 Message-ID: <40F78036.4000406@piuha.net> Date: Fri, 16 Jul 2004 10:13:58 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Class vs. UserAlias (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > A UserAlias can contain some opaque value provided that the HomeNetwork > asserts that it represents a user for a period of time. That is it will not > change over a period of time. The period of time could be a month or even > longer. > > Class attributes could change over the lifetime of even a session because > class attribute may store stuff other then just the User Alias. One of the problems is indeed that the Class attribute may contain a lot of data, some of which could vary from message to message. And there may be multiple Class attributes. One could perhaps argue that if there's a business relationship between X and Y, they should agree that a Class attribute is used, and that the bytes 1-20 represent the true identity. Not sure if that's reasonable, however. Particular server implementations might currently use Class in ways that are not compatible with this approach. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 07:18:39 +0000 Message-ID: <40F78017.2030506@piuha.net> Date: Fri, 16 Jul 2004 10:13:27 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Barney Wolff CC: Bernard Aboba , Avi Lior , radiusext@ops.ietf.org Subject: Privacy (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barney Wolff wrote: > I guess the question is whether there is a long-term one-to-one relationship > between User-Alias and the user's "true" identity. If there is, then > attackers can gain information of some value by correlating different > accesses resulting in the same User-Alias. This is an interesting issue. There is a very valid reason for employing privacy at the network access protocol level (say, in 802.1X/EAP/NAI). This is primarily to avoid being exposed to other clients on the same network. Not so much against the service provider. But I think there is also interest in ensuring some level of protection against the service provider, or at least parts of it. Clearly, the home network is going to know who you are. Maybe even the roaming consortium and the local access network. But I'd rather not reveal my true identity to the access point on the coffee shop wall. It is in an insecure environment, often uses a wireless uplink or other weakly protected physical medium. And if it runs RADIUS, the chances are that its not running ESP so the contents of any new AVP being returned from the home network would be relatively easily visible to those who wanted to look. On the other hand, there is also a valid business reason for some intermediaries to relate different sessions to the same entity so that fixed price model can be applied. One way to resolve these conflicting requirements is to (a) explain that the attribute (be it Class or something new) is to be returned with fixed contents only if the particular business situation requires it, (b) in the proxy, strip off the attribute from the packets going to the NAS and insert a Class attribute with opaque and not-fixed contents instead, and (c) when the accounting request comes back from the NAS, take away the inserted Class and replace with the original attribute. But this is complicated. Feel free to suggests a more optimal scheme :-) --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 07:16:01 +0000 Message-ID: <40F77F69.2090800@piuha.net> Date: Fri, 16 Jul 2004 10:10:33 +0300 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba CC: "Blair T. Bullock" , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: NAIbis effects (Was: Re: NAI decoration: User Identity issues) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>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? > > > I'd say that it is at the descretion of the RADIUS server whether to > return the User-Name in the Access-Accept or not. If it is returned, the > NAS includes it in accounting requests. If not, it uses the original > User-Name, + Class + Billable Identity if those are available. I don't > think there's any need for an RFC 3579 errata. Fair enough (and the document to change would be RFC 2865 as it specified the general behavior). But don't you think the reader should be alerted to this potential feature interaction in some document? Maybe in the naibis document? In fact, we have two choices: 1) Warn the reader about this interaction, and suggest not using returned user name and routing syntax at the same time. 2) Require intermediaries to redo the routing syntax when the user name comes back in an Access-Accept. I think the latter makes more sense. Here's the new text in 2486bis (7th paragraph): http://www.arkko.com/publications/nai/naibis.html#realmcons --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 06:07:30 +0000 Date: Thu, 15 Jul 2004 23:05:11 -0700 (PDT) From: Bernard Aboba To: Barney Wolff cc: radiusext@ops.ietf.org Subject: RFC 2865 compatibility Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If all NAS's are not forced to upgrade, how will the server know whether > it can include User-Alias? Thank you for bringing up this very important issue, Barney. RFC 2865 states in Section 5: A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type. This means that if a new attribute cannot be safely ignored there is a problem. An example would be a filter rule that if ignored, would result in a security vulnerability. In such a situation, the security-critical attribute could be ignored by the RADIUS client, granting the user filter-free access without the RADIUS server having any inkling what has happened. Not good. RADIUS client and server configuration cannot fix this problem in a scalable way. In a large network it is not always possible to keep track of the capabilities of every RADIUS client and if clients ignore security-critical attributes without sending an error message (as is allowable under RFC 2865), then some very ugly situations can arise. There are two possible avenues of repair: a) Describe how the attribute can be safely ignored. For example, the RADIUS server might send *both* a new and old attribute and be guaranteed some level of safety in case the new attribute is ignored. Or the RADIUS server could ignore the attribute when sent by a RADIUS client, with no ill effect. b) Respecify the attribute in a way that its use can be negotiated and the RADIUS server can be guaranteed that if sent and not understood, the right thing will happen (e.g. no service will be granted to the user). There are proposals on the table that provide for this (e.g. Jari's proposal for extended attributes). -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 05:23:32 +0000 Date: Thu, 15 Jul 2004 22:21:00 -0700 (PDT) From: Bernard Aboba To: Barney Wolff cc: radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Class attributes could change over the lifetime of even a session because > > class attribute may store stuff other then just the User Alias. So you > > cant use it as the User's Identity. Depends who "you" is. Presumably, the RADIUS server can use it, since it sent the Class attribute. But I think the point is that the RADIUS client can't be sure that the Class attribute contains a billable identity. If in addition the User-Name does not contain a billable identity (e.g. privacy) then the RADIUS client has no assurance of billability. > all the world's NAS's have to be upgraded? This raises the question about whether the billable-identity is an optional or mandatory attribute. My take is that it is optional. Here's why. If it is sent by the RADIUS server and not understood by the NAS, RFC 2865 states clearly that it MAY be ignored. My understanding is that the issue here is on the RADIUS client side, because if the RADIUS server wanted to make sure that got the opaque string back in the accounting record, it could always send that opaque blob *both* in the billable-identity attribute and in Class. That way, if the RADIUS client cared about billable-identity, it would have it; if not, it would ignore it. If you buy this logic, then no NAS upgrade is required. > If all NAS's are not forced to upgrade, how will the server know whether > it can include User-Alias? If the above argument isn't convincing, and we conclude that this attribute is Mandatory, then we have an issue. RFC 2865 doesn't support Mandatory attributes. There are a number of proposals on the table to fix this, however (e.g. Jari's proposal for a new attribute format with an 'M' bit). -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 16 Jul 2004 01:15:50 +0000 Date: Thu, 15 Jul 2004 21:15:27 -0400 From: Barney Wolff To: Avi Lior Cc: "'Bernard Aboba'" , "Nelson, David" , radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Message-ID: <20040716011527.GA1074@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Jul 15, 2004 at 04:39:22PM -0400, Avi Lior wrote: > A UserAlias can contain some opaque value provided that the HomeNetwork > asserts that it represents a user for a period of time. That is it will not > change over a period of time. The period of time could be a month or even > longer. > > Class attributes could change over the lifetime of even a session because > class attribute may store stuff other then just the User Alias. So you > cant use it as the User's Identity. So, to support a particular business model, namely fixed per-user billing, all the world's NAS's have to be upgraded? The business model could be accomodated by a private agreement on the use of Class between the intermediary and its customers, with no impact on the NAS. If all NAS's are not forced to upgrade, how will the server know whether it can include User-Alias? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 20:46:38 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Bernard Aboba Cc: Avi Lior , "Blair T. Bullock" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 16:46:26 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Barney, See my comments inline: > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Thursday, July 15, 2004 3:56 PM > To: Bernard Aboba > Cc: Avi Lior; Blair T. Bullock; radiusext@ops.ietf.org > Subject: Re: NAI decoration: User Identity issues > > > On Thu, Jul 15, 2004 at 12:06:36PM -0700, Bernard Aboba wrote: > > > The intent of User-Alias in the draft (note the draft calls it > > > User-Alias as opposed to Billable-Identity) is to allow > > > intermediaries to associate this AAA transaction with an > actual User > > > without revealing the identity of the user. It's a handle to a > > > user. > > > > So this atribute is only for use by proxies? > > > > > Note the draft allows the home network to put anything it > wants in > > > there including the true identity of the user. > > > > If there is no guarantee that this is a billable identity, it is > > indistinguishable from the Class atribute. > > I guess the question is whether there is a long-term > one-to-one relationship between User-Alias and the user's > "true" identity. If there is, then attackers can gain > information of some value by correlating different accesses > resulting in the same User-Alias. If not, then indeed > User-Alias is no different than Class. This is up to the home operator to determine. He can put in the User-Alias a long lived identity or he can choose a short lived on so that it becomes more difficult to correlate between the User-Alias and the true identity. > > > Class attribute would not work because Intermediaries > can't use the > > > class attribute generated by a server. > > > > Why can't they use it? There is no obstacle. > > I think the resistance is that Class is opaque. But if > User-Alias is opaque too, in the sense that the server can > put anything in it, that might change from one access to the > next for the same user, then User-Alias is not useful for > aggregating session statistics. Well Class is not usable because one the specification say that it should not be used but also it can contain other things in it so that it can not be used as a User-Alias. For example on one invocation: Class=123.45.234.134,JOE234 On another AAA transaction on behalf to the same user: Class=789.34.453.122,JOE234 So although it's the same user the class attribute has some different values in it. The only way that class could be used is to specify what should go in it and how it should be formatted. I don't think we want to go there. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 20:39:28 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 16:39:22 -0400 MIME-Version: 1.0 Content-Type: text/plain A UserAlias can contain some opaque value provided that the HomeNetwork asserts that it represents a user for a period of time. That is it will not change over a period of time. The period of time could be a month or even longer. Class attributes could change over the lifetime of even a session because class attribute may store stuff other then just the User Alias. So you cant use it as the User's Identity. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, July 15, 2004 3:37 PM > To: Nelson, David > Cc: radiusext@ops.ietf.org > Subject: RE: NAI decoration: User Identity issues > > > > It would seem to me that in order to function as a billing > > reconciliation mechanism (see Roy Albert's response) such > an attribute > > (User-Alias) MUST NOT be decorated or modified by intermediaries. > > Yes. > > > Could someone please review the technical (and business) > reasons that > > State could not serve this requirement? Is it that State > is supposed > > to be an opaque object? Is it that State is not required > to contain > > printable ASCII suitable for inclusion on billing statements? > > I think that's the reason. Basically, the local operator > needs to be assured that it has a billable identity on hand > before providing service. If privacy is being used, the > User-Name may not contain a billable identity, and the local > operator may not be able to determine from the Class, State, > etc. attribute whether a billable identity is present or not. > > For example, what if the NAS receives 3 Class/State attributes: > > dnelson@enterasys.com > 82673F0D2745037126@BH239487sdkd2jd > ToBeOrNotToBe.Shakespeare > > Which one of these 3 attribute is the billable identity? > Does the NAS have to parse the attributes and determine > which, if any, comply with the grammar of RFC 2486bis? > Remember, the problem exists not on the RADIUS server (which > presumably can sort things out) but on the RADIUS client that > is trying to figure out if it is going to get paid. > > Of course, exactly the same problems occur if a new attribute > is defined that can contain "anything", and can be sent > multiple times by the RADIUS server. > > In summary: > > * The problem occurs when Privacy is used and the User-Name > cannot be used > as a billable identity by the local operator. > > * If sent in the Access-Accept, the User-Name attribute is > included in the > accounting record. > > * Since the User-Name attribute sent by the RADIUS server is > undecorated, > it may cause mis-routing of accounting packets. So the > RADIUS server may not wish to send the User-Name attribute. > > * The Billable-Identity attribute if sent by the RADIUS server, is > guaranteed to contain a billable identity. It MUST NOT be modified > by intermediaries, and if received, is placed in the > accounting record > by the NAS. > > * In all cases, the User-Name MUST be included in the > Accounting-Record. > > -- > 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: > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 20:33:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Extension for Management Authorization Draft Date: Thu, 15 Jul 2004 16:33:43 -0400 Message-ID: Thread-Topic: RADIUS Extension for Management Authorization Draft Thread-Index: AcRqo4ORshha1YKASwuqSK9z5QkObwABr3/A From: "Nelson, David" To: "Barney Wolff" Cc: Barney Wolff writes...=20 > I agree completely with split-horizon. That's why I'm uncomfortable with > SSO. I'd be much happier if the outside user had to go through two > stages, one to get "inside" and the next to do things on the NAS. I agree that three are potential security issues with SSO in a multi-party proxy RADIUS environment. I also believe that SSO has real value and applicability in enterprise environments, which typically have a single administrative domain. For that reason, I think it is worthy of consideration. The issues you raise can be addressed effectively using the split-horizon approach. -- Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 20:33:11 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Bernard Aboba , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 16:33:08 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi David, As related to my previous comments, RADIUS is a hop by hop protocol not an end to end protocol. So a MUST may not work here. A SHOULD would probably work. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, July 15, 2004 3:23 PM > To: Bernard Aboba; Avi Lior > Cc: radiusext@ops.ietf.org > Subject: RE: NAI decoration: User Identity issues > > > > And if intermediaries decorate this attribute then you have > > re-introduced all the problems that already existed with User-Name. > > It would seem to me that in order to function as a billing > reconciliation mechanism (see Roy Albert's response) such an attribute > (User-Alias) MUST NOT be decorated or modified by intermediaries. > > Could someone please review the technical (and business) > reasons that State could not serve this requirement? Is it > that State is supposed to be an opaque object? Is it that > State is not required to contain printable ASCII suitable for > inclusion on billing statements? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 20:31:16 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 16:30:50 -0400 MIME-Version: 1.0 Content-Type: text/plain See inline. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, July 15, 2004 3:14 PM > To: Avi Lior > Cc: 'Nelson, David'; radiusext@ops.ietf.org > Subject: RE: NAI decoration: User Identity issues > > > > The details of what is placed in the User-Alias will be worked out > > between the operators when they negotiate their roaming agreements. > > If this were the case then the Class attribute would suffice. > To distinguish itself from Class, the local operator MUST be > sure that a billable identity is contained within the > attribute. If it "could be anything" then this assurance > does not exist (as it does not exist for Class). Introducing > multiple attribute also clouds the picture. How does the > operator know which one (if any) of the operators contains a > billable identity? Class attribute cannot function as the User Alias. Intermediaries should not look at the contents of the class attribute. Or am I missing something? So if I cant look inside it how can I use it to represent the User-Alias? > And if intermediaries decorate this attribute then you have > re-introduced all the problems that already existed with User-Name. I never said that intermediaries should decorate this attribute. But remember that RADIUS is a hop by hop protocol and Intermediaries are allowed to make changes to the packet (in either direction) as it progress between the NAS and the Home server. Related to this Bernard also stated: >No. The User-Name attribute is not re-written by intermediaries when sent in an Access-Accept. I disagree. Can you show me where this is specified? -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:56:43 +0000 Date: Thu, 15 Jul 2004 15:56:27 -0400 From: Barney Wolff To: Bernard Aboba Cc: Avi Lior , "Blair T. Bullock" , radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Message-ID: <20040715195627.GA89703@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Jul 15, 2004 at 12:06:36PM -0700, Bernard Aboba wrote: > > The intent of User-Alias in the draft (note the draft calls it User-Alias as > > opposed to Billable-Identity) is to allow intermediaries to associate this > > AAA transaction with an actual User without revealing the identity of the > > user. It's a handle to a user. > > So this atribute is only for use by proxies? > > > Note the draft allows the home network to put anything it wants in there > > including the true identity of the user. > > If there is no guarantee that this is a billable identity, it is > indistinguishable from the Class atribute. I guess the question is whether there is a long-term one-to-one relationship between User-Alias and the user's "true" identity. If there is, then attackers can gain information of some value by correlating different accesses resulting in the same User-Alias. If not, then indeed User-Alias is no different than Class. > > Class attribute would not work because Intermediaries can't use the class > > attribute generated by a server. > > Why can't they use it? There is no obstacle. I think the resistance is that Class is opaque. But if User-Alias is opaque too, in the sense that the server can put anything in it, that might change from one access to the next for the same user, then User-Alias is not useful for aggregating session statistics. > > The user-name can't be used because in an Access-Request it may contain no > > useful information and in an Access- Accept it could be completely > > re-written by intermediaries. > > No. The User-Name attribute is not re-written by intermediaries when sent > in an Access-Accept. If it were, then Blair's problem wouldn't exist > (mis-routing), and there would be no need for another attribute. > > Bottom line: User-Alias does not appear to meet the requirements of the > problem that has been posed, and seems to introduce lots of new issues. Agreed. Barney -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:40:01 +0000 Date: Thu, 15 Jul 2004 15:39:57 -0400 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Extension for Management Authorization Draft Message-ID: <20040715193957.GB88195@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Jul 15, 2004 at 10:48:41AM -0400, Nelson, David wrote: > A follow-up thought... > > > > Suppose we're in a proxy situation and the user's home > > > RADIUS server decides to grant administrative access to > > > a provider's NAS? > > > > There may be additional text required in the Proxy Considerations > > portion of the draft. However, today we have the Admin Service-Type > that > > grants "super-user" or privileged access to the management CLI of the > > NAS. How would the issues you raise be different for that attribute? > > There's another way to think about this problem. That is the concept of > "split-horizon" RADIUS authentication, wherein one RADIUS server [farm] > is used to provision network access through a NAS and a second RADIUS > server [farm] is used to provision management access into the NAS. The > issue you raise is certainly valid in various Proxy RADIUS, multi-party > environments. It would likely not be an issue in most enterprise > environments. I do think the issue exists today with the NAS-Prompt and > Admin Service-Types. I agree completely with split-horizon. That's why I'm uncomfortable with SSO. I'd be much happier if the outside user had to go through two stages, one to get "inside" and the next to do things on the NAS. Regards, Barney -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:39:00 +0000 Date: Thu, 15 Jul 2004 12:36:47 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It would seem to me that in order to function as a billing > reconciliation mechanism (see Roy Albert's response) such an attribute > (User-Alias) MUST NOT be decorated or modified by intermediaries. Yes. > Could someone please review the technical (and business) reasons that > State could not serve this requirement? Is it that State is supposed to > be an opaque object? Is it that State is not required to contain > printable ASCII suitable for inclusion on billing statements? I think that's the reason. Basically, the local operator needs to be assured that it has a billable identity on hand before providing service. If privacy is being used, the User-Name may not contain a billable identity, and the local operator may not be able to determine from the Class, State, etc. attribute whether a billable identity is present or not. For example, what if the NAS receives 3 Class/State attributes: dnelson@enterasys.com 82673F0D2745037126@BH239487sdkd2jd ToBeOrNotToBe.Shakespeare Which one of these 3 attribute is the billable identity? Does the NAS have to parse the attributes and determine which, if any, comply with the grammar of RFC 2486bis? Remember, the problem exists not on the RADIUS server (which presumably can sort things out) but on the RADIUS client that is trying to figure out if it is going to get paid. Of course, exactly the same problems occur if a new attribute is defined that can contain "anything", and can be sent multiple times by the RADIUS server. In summary: * The problem occurs when Privacy is used and the User-Name cannot be used as a billable identity by the local operator. * If sent in the Access-Accept, the User-Name attribute is included in the accounting record. * Since the User-Name attribute sent by the RADIUS server is undecorated, it may cause mis-routing of accounting packets. So the RADIUS server may not wish to send the User-Name attribute. * The Billable-Identity attribute if sent by the RADIUS server, is guaranteed to contain a billable identity. It MUST NOT be modified by intermediaries, and if received, is placed in the accounting record by the NAS. * In all cases, the User-Name MUST be included in the Accounting-Record. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:37:10 +0000 Date: Thu, 15 Jul 2004 15:36:55 -0400 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Extension for Management Authorization Draft Message-ID: <20040715193655.GA88195@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Jul 15, 2004 at 09:37:09AM -0400, Nelson, David wrote: > Barney Wolff writes... > > > It seems to in effect provide single-sign-on for NAS administration. > > I had not thought of this proposal in terms of single-sign-on, as it > does not include additional authentication elements, but rather > additional authorization elements, but, that may indeed be a valid way > to think about the issue. > > > I infer > > this, because if there were further authentication steps intended > after > > the user was communicating with the NAS, that could be accomplished > > simply with an appropriate Filter-Id which allowed the necessary > packets > > to pass - on the assumption, which I consider the only sane one, that > > ordinary users are prevented from sending any packets whatsoever to > > the NAS itself. > > One *could* implement such functionality (at least in part) using the > Filter-ID attribute. IMHO, this would be over-loading the Filter-ID > semantics with additional functionality. My interpretation is that the > Filter-ID attribute provisions the packet forwarding service of the NAS. > One *could* decide that the local management interfaces (e.g. the local > IP stack) exist behind the filter, from any port on the NAS (Console, > WAN, LAN, WLAN, etc). I think it would be better to introduce explicit > attributes to authorize various forms and levels of management access, > rather than over-loading the definition of Filter-ID. I'm not proposing overloading the definition of Filter-ID, simply that filters can exist that allow access to nas-ip/udp/161, nas-ip/tcp/443, etc. That is a simple and straightforward use of Filter-Id without changing its meaning. > > But SSO for NAS administration strikes me as a bad idea. The NAS > already > > has authentication and authorization procedures in place to enable and > > control administration from within the network. > > Yes, but at the level of granularity I'm proposing those control and > authorization functions are entirely local to the NAS. The intent of > this proposal is to allow those local functions to be performed by > RADIUS remote AAA. The same reasons we found RADIUS was useful in the > initial instance, e.g. network scalability and centralized control of > access, motivate this proposal. > > > Why should these be > > bypassed simply because the user has "dialed" in? > > I'm confused about two points in this question. First, the access > control is being "bypassed" solely to the extent that RADIUS, as > currently defined, "bypasses" local password authentication and moves it > to a server-based system. I think there is agreement that that is a > Good Thing (tm). Second, none of the elements of the proposal are tied > in any way, that I can see, to "dial-in". Could you please elaborate? Ok, what I missed in reading the draft was that the NAS can send stuff in the Access-Request to indicate what service is being requested. That covers the scenario where the user is inside, accesses the NAS via telnet/ssh/http/ssl/snmpv{1,3} and the NAS uses RADIUS rather than eg TACACS to authenticate+authorize the user. I agree that extending the service types to indicate how the user got to the NAS is helpful. My concern is really in the access from outside scenario. I have a superstitious fear of SSO. > > Do we really trust > > RADIUS authentication as much as the NAS's native procedures? > > I would *hope* so. Isn't that level of trust fundamental to the RADIUS > model? > > > Suppose > > we're in a proxy situation and the user's home RADIUS server decides > to > > grant administrative access to a provider's NAS? > > There may be additional text required in the Proxy Considerations > portion of the draft. However, today we have the Admin Service-Type that > grants "super-user" or privileged access to the management CLI of the > NAS. How would the issues you raise be different for that attribute? The issues would be identical. As I recall, the Admin service types go back to a time before people had thought seriously about proxies. I wonder how many existing proxies check for servers authorizing more than the access network owner would like. > > Is dialup administration so common that it's important to allow SSO? > > I did not have "dial-up" access in mind. In fact, the primary driver is > LAN access via Telnet, SSH, SNMPv3, etc. Although the draft would apply > to local console access and dial-up access, that isn't the design > center. Inside access seems fine, and reflects the reality that lots of people have written RADIUS clients to do such things as Unix login validation. Regards, Barney -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:23:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 15:22:38 -0400 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRqoD20VpYFPJhzT42OnA6kqa5EowAACnzA From: "Nelson, David" To: "Bernard Aboba" , "Avi Lior" Cc: > And if intermediaries decorate this attribute then you have > re-introduced all the problems that already existed with User-Name. It would seem to me that in order to function as a billing reconciliation mechanism (see Roy Albert's response) such an attribute (User-Alias) MUST NOT be decorated or modified by intermediaries. Could someone please review the technical (and business) reasons that State could not serve this requirement? Is it that State is supposed to be an opaque object? Is it that State is not required to contain printable ASCII suitable for inclusion on billing statements? -- Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:16:43 +0000 Date: Thu, 15 Jul 2004 12:14:21 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The details of what is placed in the User-Alias will be worked out between > the operators when they negotiate their roaming agreements. If this were the case then the Class attribute would suffice. To distinguish itself from Class, the local operator MUST be sure that a billable identity is contained within the attribute. If it "could be anything" then this assurance does not exist (as it does not exist for Class). Introducing multiple attribute also clouds the picture. How does the operator know which one (if any) of the operators contains a billable identity? And if intermediaries decorate this attribute then you have re-introduced all the problems that already existed with User-Name. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:08:52 +0000 Date: Thu, 15 Jul 2004 12:06:36 -0700 (PDT) From: Bernard Aboba To: Avi Lior cc: "'Barney Wolff'" , "Blair T. Bullock" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The intent of User-Alias in the draft (note the draft calls it User-Alias as > opposed to Billable-Identity) is to allow intermediaries to associate this > AAA transaction with an actual User without revealing the identity of the > user. It's a handle to a user. So this atribute is only for use by proxies? > Note the draft allows the home network to put anything it wants in there > including the true identity of the user. If there is no guarantee that this is a billable identity, it is indistinguishable from the Class atribute. > Class attribute would not work because Intermediaries can't use the class > attribute generated by a server. Why can't they use it? There is no obstacle. > The user-name can't be used because in an Access-Request it may contain no > useful information and in an Access- Accept it could be completely > re-written by intermediaries. No. The User-Name attribute is not re-written by intermediaries when sent in an Access-Accept. If it were, then Blair's problem wouldn't exist (mis-routing), and there would be no need for another attribute. Bottom line: User-Alias does not appear to meet the requirements of the problem that has been posed, and seems to introduce lots of new issues. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 19:04:29 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 15:04:21 -0400 MIME-Version: 1.0 Content-Type: text/plain The Home Network can set the User Alias to a number of values depending on the business need. The User-Alias could be a long lived billing account or it could be the subscribers phone number etc. But if privacy is an issue it can be set to some unique short lived value that the home network asserts represents the user for a some period of time. Long enough to serve the business purpose, short enough to offer privacy protection. This information can be used for business purposes that you have described while maintain privacy. The details of what is placed in the User-Alias will be worked out between the operators when they negotiate their roaming agreements. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, July 15, 2004 2:19 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: RE: NAI decoration: User Identity issues > > > > The intent of User-Alias in the draft (note the draft calls it > User-Alias > > as opposed to Billable-Identity) is to allow intermediaries to > associate > > this AAA transaction with an actual User without revealing the > identity > > of the user. It's a handle to a user. > > And from a business perspective the intermediates do what > with the User-Alias? Use it to prepare a detailed monthly > billing statement for each home entity, including session > times for all the User-Aliases? Just curious. > > -- Dave > > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 18:56:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 11:53:03 -0700 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRqlwFS1e0GDl+NRfie7QjgAe7s3wAAH/BAAAD0TVA= From: "Roy Albert" To: "Nelson, David" , "Avi Lior" cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Speaking as a trusted intermediary: iPass supports a variety of billing models including usage based, per-user flat rate, and pooled flat rate. The flat rate billing plans require that each unique user be identifiable, with the identification being persistent over a billing period (most often a month). Even for straight usage based billing plans, it is necessary to have a unique persistent identification for each user in order to detect unusual roaming patterns such as concurrent sessions or someone's credentials being used in geographically distributed locations. To specifically answer your question below, we produce detailed call records for every session that runs across our network. Many of our customers correlate the information we give them down to the individual user level. Enterprises use this to understand what their power-users are up to and ISPs use this to bill from. In summary, whatever mechanisms are adopted for privacy protection need to support persistent unique identification of a given user over an arbitrary billing period/usage period and also need to maintain the integrity of the routing information in the original NAI. -Roy=20 Roy D. Albert ralbert@ipass.com =20 -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Thursday, July 15, 2004 11:19 AM To: Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues > The intent of User-Alias in the draft (note the draft calls it User-Alias > as opposed to Billable-Identity) is to allow intermediaries to associate > this AAA transaction with an actual User without revealing the identity > of the user. It's a handle to a user. And from a business perspective the intermediates do what with the User-Alias? Use it to prepare a detailed monthly billing statement for each home entity, including session times for all the User-Aliases? Just curious. -- Dave -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 18:18:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 14:18:47 -0400 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRqlwFS1e0GDl+NRfie7QjgAe7s3wAAH/BA From: "Nelson, David" To: "Avi Lior" Cc: > The intent of User-Alias in the draft (note the draft calls it User-Alias > as opposed to Billable-Identity) is to allow intermediaries to associate > this AAA transaction with an actual User without revealing the identity > of the user. It's a handle to a user. And from a business perspective the intermediates do what with the User-Alias? Use it to prepare a detailed monthly billing statement for each home entity, including session times for all the User-Aliases? Just curious. -- Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 18:10:03 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Bernard Aboba Cc: "Blair T. Bullock" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 14:09:48 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Barney, Let me offer an explanation. The intent of User-Alias in the draft (note the draft calls it User-Alias as opposed to Billable-Identity) is to allow intermediaries to associate this AAA transaction with an actual User without revealing the identity of the user. It's a handle to a user. Note the draft allows the home network to put anything it wants in there including the true identity of the user. Class attribute would not work because Intermediaries can't use the class attribute generated by a server. The user-name can't be used because in an Access-Request it may contain no useful information and in an Access- Accept it could be completely re-written by intermediaries. Hope this helps, Avi > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Thursday, July 15, 2004 1:53 PM > To: Bernard Aboba > Cc: Blair T. Bullock; radiusext@ops.ietf.org > Subject: Re: NAI decoration: User Identity issues > > > On Thu, Jul 15, 2004 at 09:38:12AM -0700, Bernard Aboba wrote: > > > > In addition to the billable identity attribute though, I > think we will > > probably need to explain the logic behind it and provide > advice on how > > User-Name and Class can/should be used, to make sure people > understand > > the issues. That might go in the "RADIUS issues and > solutions" draft. > > I'm a little confused. Can someone state clearly what > problem is being solved by Billing-Identity that would not > just as well be solved by leaving User-Name alone and putting > any altered name in Class? Is it just that people perceive a > need for entities other than the home authentication and > accounting servers to know the "true" identity of the user? > If that were all, I'd push back, asking why it's anybody's > business other than those home servers'. > > If Billing-Identity is intended for detailed cost > accumulation, perhaps it should be called > Billing-Accumulator-Id instead. But in any case, it would > seem that it has meaning only within the scope of the server > that generates it; otherwise, ford.com's server can routinely > generate Billing-Identities that say @chevy.com. Presumably > that's why we don't want to overwrite the original User-Id. > Is leaving User-Id alone enough to provide auditability, or > should we introduce a Diameter-style audit trail that records > how the Access-Accept got back to the NAS? > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via > the 'Net. > > -- > 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: > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 17:53:39 +0000 Date: Thu, 15 Jul 2004 13:53:27 -0400 From: Barney Wolff To: Bernard Aboba Cc: "Blair T. Bullock" , radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Message-ID: <20040715175327.GA82315@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Jul 15, 2004 at 09:38:12AM -0700, Bernard Aboba wrote: > > In addition to the billable identity attribute though, I think we will > probably need to explain the logic behind it and provide advice on how > User-Name and Class can/should be used, to make sure people understand the > issues. That might go in the "RADIUS issues and solutions" draft. I'm a little confused. Can someone state clearly what problem is being solved by Billing-Identity that would not just as well be solved by leaving User-Name alone and putting any altered name in Class? Is it just that people perceive a need for entities other than the home authentication and accounting servers to know the "true" identity of the user? If that were all, I'd push back, asking why it's anybody's business other than those home servers'. If Billing-Identity is intended for detailed cost accumulation, perhaps it should be called Billing-Accumulator-Id instead. But in any case, it would seem that it has meaning only within the scope of the server that generates it; otherwise, ford.com's server can routinely generate Billing-Identities that say @chevy.com. Presumably that's why we don't want to overwrite the original User-Id. Is leaving User-Id alone enough to provide auditability, or should we introduce a Diameter-style audit trail that records how the Access-Accept got back to the NAS? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 17:04:19 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Blair T. Bullock'" , "Adrangi, Farid" , Bernard Aboba 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: -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 16:40:24 +0000 Date: Thu, 15 Jul 2004 09:38:12 -0700 (PDT) From: Bernard Aboba To: "Blair T. Bullock" cc: radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Does everyone else have the distinct feeling we just avoided a huge train wreck? In this case, I think there is an existing problem that people are just beginning to appreciate. So perhaps the train wreck hasn't happened yet. In addition to the billable identity attribute though, I think we will probably need to explain the logic behind it and provide advice on how User-Name and Class can/should be used, to make sure people understand the issues. That might go in the "RADIUS issues and solutions" draft. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 15:54:08 +0000 Date: Thu, 15 Jul 2004 08:51:32 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: "Blair T. Bullock" , Nakhjiri Madjid-MNAKHJI1 , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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? I'd say that it is at the descretion of the RADIUS server whether to return the User-Name in the Access-Accept or not. If it is returned, the NAS includes it in accounting requests. If not, it uses the original User-Name, + Class + Billable Identity if those are available. I don't think there's any need for an RFC 3579 errata. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 14:49:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Extension for Management Authorization Draft Date: Thu, 15 Jul 2004 10:48:41 -0400 Message-ID: Thread-Topic: RADIUS Extension for Management Authorization Draft Thread-Index: AcRqDA1pZyVFqno+Q/OTyoWaDxuoRQAYZNRAAAMBE2A= From: "Nelson, David" To: "Barney Wolff" Cc: A follow-up thought... > > Suppose we're in a proxy situation and the user's home=20 > > RADIUS server decides to grant administrative access to > > a provider's NAS? >=20 > There may be additional text required in the Proxy Considerations > portion of the draft. However, today we have the Admin Service-Type that > grants "super-user" or privileged access to the management CLI of the > NAS. How would the issues you raise be different for that attribute? There's another way to think about this problem. That is the concept of "split-horizon" RADIUS authentication, wherein one RADIUS server [farm] is used to provision network access through a NAS and a second RADIUS server [farm] is used to provision management access into the NAS. The issue you raise is certainly valid in various Proxy RADIUS, multi-party environments. It would likely not be an issue in most enterprise environments. I do think the issue exists today with the NAS-Prompt and Admin Service-Types. Regards, Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 13:37:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS Extension for Management Authorization Draft Date: Thu, 15 Jul 2004 09:37:09 -0400 Message-ID: Thread-Topic: RADIUS Extension for Management Authorization Draft Thread-Index: AcRqDA1pZyVFqno+Q/OTyoWaDxuoRQAYZNRA From: "Nelson, David" To: "Barney Wolff" Cc: Barney Wolff writes... > It seems to in effect provide single-sign-on for NAS administration. I had not thought of this proposal in terms of single-sign-on, as it does not include additional authentication elements, but rather additional authorization elements, but, that may indeed be a valid way to think about the issue. > I infer > this, because if there were further authentication steps intended after > the user was communicating with the NAS, that could be accomplished > simply with an appropriate Filter-Id which allowed the necessary packets > to pass - on the assumption, which I consider the only sane one, that > ordinary users are prevented from sending any packets whatsoever to > the NAS itself. One *could* implement such functionality (at least in part) using the Filter-ID attribute. IMHO, this would be over-loading the Filter-ID semantics with additional functionality. My interpretation is that the Filter-ID attribute provisions the packet forwarding service of the NAS. One *could* decide that the local management interfaces (e.g. the local IP stack) exist behind the filter, from any port on the NAS (Console, WAN, LAN, WLAN, etc). I think it would be better to introduce explicit attributes to authorize various forms and levels of management access, rather than over-loading the definition of Filter-ID. > But SSO for NAS administration strikes me as a bad idea. The NAS already > has authentication and authorization procedures in place to enable and > control administration from within the network. Yes, but at the level of granularity I'm proposing those control and authorization functions are entirely local to the NAS. The intent of this proposal is to allow those local functions to be performed by RADIUS remote AAA. The same reasons we found RADIUS was useful in the initial instance, e.g. network scalability and centralized control of access, motivate this proposal.=20 > Why should these be > bypassed simply because the user has "dialed" in? I'm confused about two points in this question. First, the access control is being "bypassed" solely to the extent that RADIUS, as currently defined, "bypasses" local password authentication and moves it to a server-based system. I think there is agreement that that is a Good Thing (tm). Second, none of the elements of the proposal are tied in any way, that I can see, to "dial-in". Could you please elaborate? > Do we really trust > RADIUS authentication as much as the NAS's native procedures? I would *hope* so. Isn't that level of trust fundamental to the RADIUS model? > Suppose > we're in a proxy situation and the user's home RADIUS server decides to > grant administrative access to a provider's NAS? There may be additional text required in the Proxy Considerations portion of the draft. However, today we have the Admin Service-Type that grants "super-user" or privileged access to the management CLI of the NAS. How would the issues you raise be different for that attribute? > Is dialup administration so common that it's important to allow SSO? I did not have "dial-up" access in mind. In fact, the primary driver is LAN access via Telnet, SSH, SNMPv3, etc. Although the draft would apply to local console access and dial-up access, that isn't the design center. Thanks for your time to review the draft and for your thoughtful comments. Regards, Dave -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 08:52:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: NAI decoration: User Identity issues Date: Thu, 15 Jul 2004 01:47:22 -0700 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRqKpqTezBjqoLiRK2SNLKUs/ymfQAGcUD2 From: "Blair T. Bullock" To: jari.arkko@piuha.net, "Bernard Aboba" cc: "Nakhjiri Madjid-MNAKHJI1" , "Adrangi, Farid" , radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46A48.5819CA28" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46A48.5819CA28 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBkbyBiZWxpZXZlIHRoZSBhcHByb2FjaCB5J2FsbCBoYXZlIHByZXNlbnRlZCBzb2x2ZXMgdGhl IHByb3h5IHN0cmlwcGluZywgcGVlcmluZyBhbmQgYWNjb3VudGluZyBldmVudCBjb3JyZWxhdGlv biBwcm9ibGVtICh0byB0aGUgc29sdXRpb24pIG9mIHJld3JpdGluZyB0aGUgb3JpZ2luYWxseSBw cmVzZW50ZWQgTkFJIGZyb20gdGhlIEFjY2Vzcy1BY2NlcHQgVXNlci1OYW1lLiAgSXQgb2J2aWF0 ZXMgdGhlIHByZXNlbnQgbmVlZCB0byBvdmVybG9hZCBhbm90aGVyIGF0dHJpYnV0ZSB0byBmaWxs IHRoZSBpZGVudGl0eSBnYXAgcHJvYmxlbSAodG8gdGhlIHNvbHV0aW9uKSBvZiBUdW5uZWxlZCBF QVAgbWV0aG9kcyAodGhlIGJlc3QgdGhpbmcgc2luY2Ugc2xpY2VkIGJyZWFkIElNTykuDQogDQpU aGlzIHdpbGwgYWxsb3cgZm9yIHRydWx5IGFub255bW91cywgYWxpYXMtYmFzZWQgYmlsbGluZyBm ZWF0dXJlcyB3aGlsZSBtYWludGFpbmluZyBzdXBwb3J0IGZvciBzZXJ2aWNlIG92ZXJzaWdodCwg Y29uY3VycmVuY3kgY2hlY2tpbmcgYW5kIGZyYXVkIGRldGVjdGlvbiAobm90IHRvIG1lbnRpb24g bWFraW5nIGlzb2xhdGlvbiBvZiBjb21wcm9taXNlZCB1c2VyIHByb2ZpbGVzIHRoYXQgbXVjaCBl YXNpZXIpIGJ5IGRyYXdpbmcgYSBkaXJlY3QgcGVyLXNlc3Npb24gY29ycmVsYXRpb24gYmV0d2Vl biBhbiBhdXRoZW50aWNhdGVkIHByb2ZpbGUgYW5kIHNvdXJjZSByb3V0ZWQgYWNjb3VudGluZyBl dmVudHMuDQogDQpCdXQgSSBhbSBwcmVhY2hpbmcgdG8gdGhlIGNob2lyLi4uLiAgQmVpbmcgdGhl IElFVEYgbmV3YmllLCBJJ20gZWFnZXIgdG8gc2VlIGhvdyB0aGlzIGNvYWxlc2Nlcw0KIA0KRG9l cyBldmVyeW9uZSBlbHNlIGhhdmUgdGhlIGRpc3RpbmN0IGZlZWxpbmcgd2UganVzdCBhdm9pZGVk IGEgaHVnZSB0cmFpbiB3cmVjaz8NCiANCkJsYWlyDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSANCglGcm9tOiBKYXJpIEFya2tvIFttYWlsdG86amFyaS5hcmtrb0BwaXVoYS5uZXRdIA0K CVNlbnQ6IFdlZCA3LzE0LzIwMDQgMTA6MTEgUE0gDQoJVG86IEJlcm5hcmQgQWJvYmEgDQoJQ2M6 IEJsYWlyIFQuIEJ1bGxvY2s7IE5ha2hqaXJpIE1hZGppZC1NTkFLSEpJMTsgQWRyYW5naSwgRmFy aWQ7IHJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcgDQoJU3ViamVjdDogUmU6IE5BSSBkZWNvcmF0aW9u OiBVc2VyIElkZW50aXR5IGlzc3Vlcw0KCQ0KCQ0KDQoJSSBoYXZlIG5vdyBiZWVuIGNvbnZpbmNl ZCB0aGF0IHRoZSBzZXBhcmF0aW9uIG9mIGJpbGxhYmxlDQoJYW5kIHJvdXRpbmcgaWRlbnRpdGll cyBpcyBuZWNlc3NhcnkuIFNvLCBJIHN1cHBvcnQgdGhlDQoJY3JlYXRpb24gb2YgYW4gYXR0cmli dXRlIHRoYXQgcmVwcmVzZW50cyBhIGJpbGxhYmxlDQoJaWRlbnRpdHkuIEEgbnVtYmVyIG9mIGRl dGFpbHMgc3RpbGwgbmVlZHMgdG8gYmUgd29ya2VkDQoJb24sIHN1Y2ggYXMgZXhhY3RseSB3aGF0 IGRvIHdlIHNheSBhYm91dCBwcml2YWN5LCB3aGF0DQoJZm9ybWF0KHMpIGFyZSBzdXBwb3J0ZWQg Zm9yIHRoZSBpZGVudGl0eSBldGMuDQoJDQoJQW5kIHRoZW4gYSBxdWVzdGlvbiBmcm9tIHlvdXIg TkFJYmlzIGRyYWZ0IGVkaXRvcjogZG9lcw0KCXRoaXMgcmVzb2x2ZSB0aGUgaXNzdWUgdGhhdCBG YXJpZCByYWlzZWQgZWFybGllciBhYm91dA0KCXN1ZmZpeC1iYXNlZCBkZWNvcmF0aW9uIGJlaW5n IHJld3JpdHRlbiBieSBwcm94aWVzIGFuZA0KCXRoZW4gcmV0dXJuZWQgaW4gYW4gQWNjZXNzLUFj Y2VwdCwgY2F1c2luZyBwcm9ibGVtcyBmb3INCgl0aGUgYWNjb3VudGluZyByZXF1ZXN0cz8gSSB0 aGluayBpdCBkb2VzLCBidXQgaXQgc2VlbXMNCgl0aGF0IHdlIG1heSBoYXZlIHRvLCBpbiBhZGRp dGlvbiwgcHVibGlzaCBhbiBSRkMgMzU3OSBlcnJhdGENCgl0byBpbmRpY2F0ZSB0aGF0IHJldHVy bmVkIFVzZXItTmFtZSBhdHRyaWJ1dGVzIHNob3VsZCBub3QNCgliZSB1c2VkIGZvciBhY2NvdW50 aW5nIHJlcXVlc3RzLiBDb21tZW50cz8NCgkNCgktLUphcmkNCgkNCglCZXJuYXJkIEFib2JhIHdy b3RlOg0KCT4+SGFsbGVsdWphaCwgSSB3aG9sZWhlYXJ0ZWRseSBjb25jdXIgd2l0aCB0aGlzIHN0 YXRlbWVudC4gIEl0IGlzDQoJPj5iYXNpY2FsbHkgdGhlIHNhbWUgY29uY2VwdCBhcyB0aGUgcHJv cG9zZWQgQ2xhc3MgdXNhZ2UgZm9yIHRoZSBwdXJwb3Nlcw0KCT4+b2YgdXNlci1uYW1lIGFjY291 bnRpbmcgZGF0YSByZWZsZWN0aW9uLCBidXQgc3BlY2lmaWNhbGx5IGRlZGljYXRlZCB0bw0KCT4+ dGhlIHJlc29sdXRpb24gb2YgUkFESVVTLXJvdXRhYmxlIGFuZCBiaWxsYWJsZSBpZGVudGl0aWVz IGluIFR1bm5lbGVkDQoJPj5FQVAgbWV0aG9kcy4NCgk+DQoJPg0KCT4gVGhpcyBpcyBhbiBpbXBv cnRhbnQgZGlzdGluY3Rpb24gYmVjYXVzZSBpdCBhbGxvd3MgdGhlIGxvY2FsIElTUCB0byBrbm93 DQoJPiB0aGF0IGEgYmlsbGFibGUgaWRlbnRpdHkgaGFzIGJlZW4gcmV0dXJuZWQgd2l0aG91dCBo YXZpbmcgdG8gcGFyc2UgdGhlDQoJPiBDbGFzcyBhdHRpYnV0ZSB3aGljaCBpcyBzdXBwb3NlZCB0 byBiZSB0cmVhdGVkIGxpa2Ugb3BhcXVlIHRleHQuICBBZnRlcg0KCT4gYWxsLCBtdWx0aXBsZSBD bGFzcyBhdHRyaWJ1dGVzIGNhbiBiZSByZXR1cm5lZCwgc29tZSBvZiB3aGljaCBtaWdodA0KCT4g cmVwcmVzZW50IGEgYmlsbGFibGUgaWRlbnRpdHksIHNvbWUgbWlnaHQgbm90LiAgSG93IGlzIHRo ZSBsb2NhbCBvcGVyYXRvcg0KCT4gdG8ga25vdz8gIFNvIEkgdGhpbmsgYSBiaWxsYWJsZSBpZGVu dGl0eSBhdHRyaWJ1dGUgaXMgcmVxdWlyZWQgaGVyZS4NCgk+DQoJPg0KCT4+dGhlIE5BUyBhbmQg YW4gQXV0aGVudGljYXRlZC1Vc2VyIHdoaWNoIGlzIHRoZSBCaWxsYWJsZSBhdXRoZW50aWNhdGVk DQoJPg0KCT4NCgk+IFRoZSBCaWxsYWJsZSBJZGVudGl0eSBpcyBhbiBpZGVudGl0eSB1c2VkIGZv ciBhY2NvdW50aW5nIHB1cnBvc2VzLCBub3QNCgk+IGF1dGhlbnRpY2F0aW9uLiAgSSBob3BlIHdl J3JlIGNsZWFyIG9uIHRoYXQuDQoJPg0KCT4NCgk+PmZyb20gYSBSQURJVVMgc3RhbmRwb2ludC4u LiAgV2hpbGUgYWxzbyBtYWludGFpbmluZyBhbiBBdXRoZW50aWNhdG9yDQoJPj5wcm90ZWN0ZWQg YmlsbGFibGUgaWRlbnRpdHkgKG9yIGFsaWFzKSB3aGljaCBpcyBub3QgdHJhbnNtaXR0ZWQgb3Zl ciB0aGUNCgk+PmFpciwgYnV0IHJlcHJlc2VudGVkIGJ5IHRoZSBOQVMgZnJvbSB0aGUgdmFsdWUg b2YgdGhlIFVzZXItTmFtZSBpbiB0aGUNCgk+PkFjY2Vzcy1BY2NlcHQuDQoJPg0KCT4NCgk+IElu IHRoZSBjYXNlIG9mIFByaXZhY3ksIGl0IG1pZ2h0IG5vdCByZWxhdGUgdG8gdGhlIFVzZXItTmFt ZSBhdHRyaWJ1dGUgYXQNCgk+IGFsbC4gIFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRoYXQgdGhl eSBtYXRjaCBpbiBhbnkgd2F5Lg0KCT4NCgk+DQoJPj5ub3QgcGFzcyB0aGUgdXNlci1uYW1lIGJh Y2sgaW4gdGhlIEFjY2Vzcy1hY2NlcHQgdG8gbWFpbnRhaW4gdGhlDQoJPg0KCT4NCgk+IFRoYXQg aXMgYWx3YXlzIHRoZSBSQURJVVMgc2VydmVyIGNob2ljZSwgYmVjYXVzZSBpdCBpcyBvcHRpb25h bC4NCgk+DQoJPg0KCT4+Y2hlY2tpbmcgdG8gZW5zdXJlIHRoYXQgdGhlIElubmVyIGFuZCBPdXRl ciBpZGVudGl0aWVzIGFyZSBpZGVudGljYWwgYXQNCgk+PmEgJ3Jvb3QnIE5BSSBsZXZlbCAocmVn YXJkbGVzcyBvZiBhZGRpdGlvbmFsIGNoYWluZWQgc3VmZml4ZXMgb3INCgk+DQoJPg0KCT4gQ2Fy ZWZ1bC4gIFRoZXNlIGlkZW50aXRpZXMgbWF5IG5vdCByZWxhdGUgdG8gZWFjaCBvdGhlci4NCgk+ DQoJPg0KCT4gLS0NCgk+IHRvIHVuc3Vic2NyaWJlIHNlbmQgYSBtZXNzYWdlIHRvIHJhZGl1c2V4 dC1yZXF1ZXN0QG9wcy5pZXRmLm9yZyB3aXRoDQoJPiB0aGUgd29yZCAndW5zdWJzY3JpYmUnIGlu IGEgc2luZ2xlIGxpbmUgYXMgdGhlIG1lc3NhZ2UgdGV4dCBib2R5Lg0KCT4gYXJjaGl2ZTogPGh0 dHA6Ly9wc2cuY29tL2xpc3RzL3JhZGl1c2V4dC8+DQoJPg0KCT4NCgkNCgkNCgkNCg0K ------_=_NextPart_001_01C46A48.5819CA28 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SZTogTkFJIGRlY29yYXRp b246IFVzZXIgSWRlbnRpdHkgaXNzdWVzPC9USVRMRT4KPC9IRUFEPgo8Qk9EWSBkaXI9bHRyPgo8 RElWPkkgZG8gYmVsaWV2ZSB0aGUgYXBwcm9hY2ggeSdhbGwgaGF2ZSBwcmVzZW50ZWQmbmJzcDtz b2x2ZXMgdGhlIHByb3h5IApzdHJpcHBpbmcsIHBlZXJpbmcgYW5kIGFjY291bnRpbmcgZXZlbnQg Y29ycmVsYXRpb24gcHJvYmxlbSAodG8gdGhlIHNvbHV0aW9uKSBvZiAKcmV3cml0aW5nIHRoZSBv cmlnaW5hbGx5IHByZXNlbnRlZCBOQUkgZnJvbSB0aGUgQWNjZXNzLUFjY2VwdCBVc2VyLU5hbWUu Jm5ic3A7IApJdCBvYnZpYXRlcyB0aGUgcHJlc2VudCBuZWVkIHRvIG92ZXJsb2FkIGFub3RoZXIg YXR0cmlidXRlIHRvIGZpbGwgdGhlIGlkZW50aXR5IApnYXAgcHJvYmxlbSAodG8gdGhlIHNvbHV0 aW9uKSZuYnNwO29mIFR1bm5lbGVkIEVBUCBtZXRob2RzICh0aGUgYmVzdCB0aGluZyBzaW5jZSAK c2xpY2VkIGJyZWFkIElNTykuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhpcyB3aWxs IGFsbG93IGZvciB0cnVseSBhbm9ueW1vdXMsIGFsaWFzLWJhc2VkIGJpbGxpbmcgZmVhdHVyZXMg d2hpbGUgCm1haW50YWluaW5nIHN1cHBvcnQgZm9yIHNlcnZpY2Ugb3ZlcnNpZ2h0LCBjb25jdXJy ZW5jeSBjaGVja2luZyBhbmQgZnJhdWQgCmRldGVjdGlvbiAobm90IHRvIG1lbnRpb24gbWFraW5n IGlzb2xhdGlvbiBvZiBjb21wcm9taXNlZCB1c2VyIHByb2ZpbGVzIHRoYXQgCm11Y2ggZWFzaWVy KSBieSBkcmF3aW5nIGEgZGlyZWN0IHBlci1zZXNzaW9uIGNvcnJlbGF0aW9uIGJldHdlZW4gYW4g CmF1dGhlbnRpY2F0ZWQgcHJvZmlsZSBhbmQgc291cmNlIHJvdXRlZCBhY2NvdW50aW5nIGV2ZW50 cy48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5CdXQgSSBhbSBwcmVhY2hpbmcgdG8gdGhl IGNob2lyLi4uLiZuYnNwOyZuYnNwO0JlaW5nIHRoZSBJRVRGIApuZXdiaWUsJm5ic3A7SSdtIGVh Z2VyIHRvIHNlZSBob3cgdGhpcyBjb2FsZXNjZXM8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJ Vj5Eb2VzIGV2ZXJ5b25lIGVsc2UmbmJzcDtoYXZlIHRoZSBkaXN0aW5jdCBmZWVsaW5nIHdlIGp1 c3QgYXZvaWRlZCBhIGh1Z2UgCnRyYWluIHdyZWNrPzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8 RElWPkJsYWlyPC9ESVY+CjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1SSUdIVDog MHB4Ij4KICA8RElWPjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSA8QlI+ PEI+RnJvbTo8L0I+IEphcmkgQXJra28gCiAgW21haWx0bzpqYXJpLmFya2tvQHBpdWhhLm5ldF0g PEJSPjxCPlNlbnQ6PC9CPiBXZWQgNy8xNC8yMDA0IDEwOjExIFBNIAogIDxCUj48Qj5Ubzo8L0I+ IEJlcm5hcmQgQWJvYmEgPEJSPjxCPkNjOjwvQj4gQmxhaXIgVC4gQnVsbG9jazsgTmFraGppcmkg CiAgTWFkamlkLU1OQUtISkkxOyBBZHJhbmdpLCBGYXJpZDsgcmFkaXVzZXh0QG9wcy5pZXRmLm9y ZyA8QlI+PEI+U3ViamVjdDo8L0I+IAogIFJlOiBOQUkgZGVjb3JhdGlvbjogVXNlciBJZGVudGl0 eSBpc3N1ZXM8QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8UD48Rk9OVCBzaXplPTI+SSBoYXZlIG5v dyBiZWVuIGNvbnZpbmNlZCB0aGF0IHRoZSBzZXBhcmF0aW9uIG9mIAogIGJpbGxhYmxlPEJSPmFu ZCByb3V0aW5nIGlkZW50aXRpZXMgaXMgbmVjZXNzYXJ5LiBTbywgSSBzdXBwb3J0IHRoZTxCUj5j cmVhdGlvbiAKICBvZiBhbiBhdHRyaWJ1dGUgdGhhdCByZXByZXNlbnRzIGEgYmlsbGFibGU8QlI+ aWRlbnRpdHkuIEEgbnVtYmVyIG9mIGRldGFpbHMgCiAgc3RpbGwgbmVlZHMgdG8gYmUgd29ya2Vk PEJSPm9uLCBzdWNoIGFzIGV4YWN0bHkgd2hhdCBkbyB3ZSBzYXkgYWJvdXQgcHJpdmFjeSwgCiAg d2hhdDxCUj5mb3JtYXQocykgYXJlIHN1cHBvcnRlZCBmb3IgdGhlIGlkZW50aXR5IGV0Yy48QlI+ PEJSPkFuZCB0aGVuIGEgCiAgcXVlc3Rpb24gZnJvbSB5b3VyIE5BSWJpcyBkcmFmdCBlZGl0b3I6 IGRvZXM8QlI+dGhpcyByZXNvbHZlIHRoZSBpc3N1ZSB0aGF0IAogIEZhcmlkIHJhaXNlZCBlYXJs aWVyIGFib3V0PEJSPnN1ZmZpeC1iYXNlZCBkZWNvcmF0aW9uIGJlaW5nIHJld3JpdHRlbiBieSAK ICBwcm94aWVzIGFuZDxCUj50aGVuIHJldHVybmVkIGluIGFuIEFjY2Vzcy1BY2NlcHQsIGNhdXNp bmcgcHJvYmxlbXMgZm9yPEJSPnRoZSAKICBhY2NvdW50aW5nIHJlcXVlc3RzPyBJIHRoaW5rIGl0 IGRvZXMsIGJ1dCBpdCBzZWVtczxCUj50aGF0IHdlIG1heSBoYXZlIHRvLCBpbiAKICBhZGRpdGlv biwgcHVibGlzaCBhbiBSRkMgMzU3OSBlcnJhdGE8QlI+dG8gaW5kaWNhdGUgdGhhdCByZXR1cm5l ZCBVc2VyLU5hbWUgCiAgYXR0cmlidXRlcyBzaG91bGQgbm90PEJSPmJlIHVzZWQgZm9yIGFjY291 bnRpbmcgcmVxdWVzdHMuIAogIENvbW1lbnRzPzxCUj48QlI+LS1KYXJpPEJSPjxCUj5CZXJuYXJk IEFib2JhIHdyb3RlOjxCUj4mZ3Q7Jmd0O0hhbGxlbHVqYWgsIEkgCiAgd2hvbGVoZWFydGVkbHkg Y29uY3VyIHdpdGggdGhpcyBzdGF0ZW1lbnQuJm5ic3A7IEl0IGlzPEJSPiZndDsmZ3Q7YmFzaWNh bGx5IAogIHRoZSBzYW1lIGNvbmNlcHQgYXMgdGhlIHByb3Bvc2VkIENsYXNzIHVzYWdlIGZvciB0 aGUgcHVycG9zZXM8QlI+Jmd0OyZndDtvZiAKICB1c2VyLW5hbWUgYWNjb3VudGluZyBkYXRhIHJl ZmxlY3Rpb24sIGJ1dCBzcGVjaWZpY2FsbHkgZGVkaWNhdGVkIAogIHRvPEJSPiZndDsmZ3Q7dGhl IHJlc29sdXRpb24gb2YgUkFESVVTLXJvdXRhYmxlIGFuZCBiaWxsYWJsZSBpZGVudGl0aWVzIGlu IAogIFR1bm5lbGVkPEJSPiZndDsmZ3Q7RUFQIG1ldGhvZHMuPEJSPiZndDs8QlI+Jmd0OzxCUj4m Z3Q7IFRoaXMgaXMgYW4gaW1wb3J0YW50IAogIGRpc3RpbmN0aW9uIGJlY2F1c2UgaXQgYWxsb3dz IHRoZSBsb2NhbCBJU1AgdG8ga25vdzxCUj4mZ3Q7IHRoYXQgYSBiaWxsYWJsZSAKICBpZGVudGl0 eSBoYXMgYmVlbiByZXR1cm5lZCB3aXRob3V0IGhhdmluZyB0byBwYXJzZSB0aGU8QlI+Jmd0OyBD bGFzcyBhdHRpYnV0ZSAKICB3aGljaCBpcyBzdXBwb3NlZCB0byBiZSB0cmVhdGVkIGxpa2Ugb3Bh cXVlIHRleHQuJm5ic3A7IEFmdGVyPEJSPiZndDsgYWxsLCAKICBtdWx0aXBsZSBDbGFzcyBhdHRy aWJ1dGVzIGNhbiBiZSByZXR1cm5lZCwgc29tZSBvZiB3aGljaCBtaWdodDxCUj4mZ3Q7IAogIHJl cHJlc2VudCBhIGJpbGxhYmxlIGlkZW50aXR5LCBzb21lIG1pZ2h0IG5vdC4mbmJzcDsgSG93IGlz IHRoZSBsb2NhbCAKICBvcGVyYXRvcjxCUj4mZ3Q7IHRvIGtub3c/Jm5ic3A7IFNvIEkgdGhpbmsg YSBiaWxsYWJsZSBpZGVudGl0eSBhdHRyaWJ1dGUgaXMgCiAgcmVxdWlyZWQgaGVyZS48QlI+Jmd0 OzxCUj4mZ3Q7PEJSPiZndDsmZ3Q7dGhlIE5BUyBhbmQgYW4gQXV0aGVudGljYXRlZC1Vc2VyIAog IHdoaWNoIGlzIHRoZSBCaWxsYWJsZSBhdXRoZW50aWNhdGVkPEJSPiZndDs8QlI+Jmd0OzxCUj4m Z3Q7IFRoZSBCaWxsYWJsZSAKICBJZGVudGl0eSBpcyBhbiBpZGVudGl0eSB1c2VkIGZvciBhY2Nv dW50aW5nIHB1cnBvc2VzLCBub3Q8QlI+Jmd0OyAKICBhdXRoZW50aWNhdGlvbi4mbmJzcDsgSSBo b3BlIHdlJ3JlIGNsZWFyIG9uIAogIHRoYXQuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7Jmd0O2Zy b20gYSBSQURJVVMgc3RhbmRwb2ludC4uLiZuYnNwOyBXaGlsZSBhbHNvIAogIG1haW50YWluaW5n IGFuIEF1dGhlbnRpY2F0b3I8QlI+Jmd0OyZndDtwcm90ZWN0ZWQgYmlsbGFibGUgaWRlbnRpdHkg KG9yIGFsaWFzKSAKICB3aGljaCBpcyBub3QgdHJhbnNtaXR0ZWQgb3ZlciB0aGU8QlI+Jmd0OyZn dDthaXIsIGJ1dCByZXByZXNlbnRlZCBieSB0aGUgTkFTIAogIGZyb20gdGhlIHZhbHVlIG9mIHRo ZSBVc2VyLU5hbWUgaW4gCiAgdGhlPEJSPiZndDsmZ3Q7QWNjZXNzLUFjY2VwdC48QlI+Jmd0OzxC Uj4mZ3Q7PEJSPiZndDsgSW4gdGhlIGNhc2Ugb2YgUHJpdmFjeSwgCiAgaXQgbWlnaHQgbm90IHJl bGF0ZSB0byB0aGUgVXNlci1OYW1lIGF0dHJpYnV0ZSBhdDxCUj4mZ3Q7IGFsbC4mbmJzcDsgVGhl cmUgaXMgCiAgbm8gcmVxdWlyZW1lbnQgdGhhdCB0aGV5IG1hdGNoIGluIGFueSB3YXkuPEJSPiZn dDs8QlI+Jmd0OzxCUj4mZ3Q7Jmd0O25vdCBwYXNzIAogIHRoZSB1c2VyLW5hbWUgYmFjayBpbiB0 aGUgQWNjZXNzLWFjY2VwdCB0byBtYWludGFpbiAKICB0aGU8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZn dDsgVGhhdCBpcyBhbHdheXMgdGhlIFJBRElVUyBzZXJ2ZXIgY2hvaWNlLCBiZWNhdXNlIAogIGl0 IGlzIG9wdGlvbmFsLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyZndDtjaGVja2luZyB0byBlbnN1 cmUgdGhhdCB0aGUgSW5uZXIgCiAgYW5kIE91dGVyIGlkZW50aXRpZXMgYXJlIGlkZW50aWNhbCBh dDxCUj4mZ3Q7Jmd0O2EgJ3Jvb3QnIE5BSSBsZXZlbCAKICAocmVnYXJkbGVzcyBvZiBhZGRpdGlv bmFsIGNoYWluZWQgc3VmZml4ZXMgb3I8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgCiAgQ2FyZWZ1 bC4mbmJzcDsgVGhlc2UgaWRlbnRpdGllcyBtYXkgbm90IHJlbGF0ZSB0byBlYWNoIAogIG90aGVy LjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyAtLTxCUj4mZ3Q7IHRvIHVuc3Vic2NyaWJlIHNlbmQg YSBtZXNzYWdlIHRvIAogIHJhZGl1c2V4dC1yZXF1ZXN0QG9wcy5pZXRmLm9yZyB3aXRoPEJSPiZn dDsgdGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNpbmdsZSAKICBsaW5lIGFzIHRoZSBtZXNz YWdlIHRleHQgYm9keS48QlI+Jmd0OyBhcmNoaXZlOiAmbHQ7PEEgCiAgaHJlZj0iaHR0cDovL3Bz Zy5jb20vbGlzdHMvcmFkaXVzZXh0LyI+aHR0cDovL3BzZy5jb20vbGlzdHMvcmFkaXVzZXh0Lzwv QT4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj48QlI+PEJSPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RF PgoKPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C46A48.5819CA28-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 05:17:04 +0000 Message-ID: <40F6120A.1010207@piuha.net> Date: Thu, 15 Jul 2004 08:11:38 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: "Blair T. Bullock" , Nakhjiri Madjid-MNAKHJI1 , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: Re: NAI decoration: User Identity issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: > > -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 15 Jul 2004 01:36:03 +0000 Date: Wed, 14 Jul 2004 21:35:44 -0400 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADIUS Extension for Management Authorization Draft Message-ID: <20040715013544.GA49925@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Wed, Jul 14, 2004 at 05:20:45PM -0400, Nelson, David wrote: > I have submitted an Internet-Draft entitled "RADIUS Extension for Management Authorization", located at the following URL: > > http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-00.txt > > This is based on work that I presented at the RADEXT BOF at IETF 58. Interest in this area of work was expressed at the BOF. I'd like to solicit comment on this initial draft on the list, and get an idea of the potential interest in making this a WG work item, and of others who may have an interest in contributing to the document. I was not at the BOF, so perhaps am misjudging the intent of the draft. It seems to in effect provide single-sign-on for NAS administration. That is, based on RADIUS authentication, the user will be authorized to administer the NAS without further authentication steps. I infer this, because if there were further authentication steps intended after the user was communicating with the NAS, that could be accomplished simply with an appropriate Filter-Id which allowed the necessary packets to pass - on the assumption, which I consider the only sane one, that ordinary users are prevented from sending any packets whatsoever to the NAS itself. But SSO for NAS administration strikes me as a bad idea. The NAS already has authentication and authorization procedures in place to enable and control administration from within the network. Why should these be bypassed simply because the user has "dialed" in? Do we really trust RADIUS authentication as much as the NAS's native procedures? Suppose we're in a proxy situation and the user's home RADIUS server decides to grant administrative access to a provider's NAS? Is dialup administration so common that it's important to allow SSO? Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 23:16:49 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: NAI decoration: User Identity issues Date: Wed, 14 Jul 2004 16:13:44 -0700 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRp80Ha0Mkf+Zt1SAGhv2uRzpW/dgABBxMg From: "Blair T. Bullock" To: "Bernard Aboba" cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Absolutely agreed, Bernard. Good deal.=20 What you describe makes loads of sense and provides a framework for the necessary flexibility, consistent behavior and reliability when using mixed standard and tunneled EAP methods. Thanks y'all for your consideration,=20 Blair -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Wednesday, July 14, 2004 3:39 PM To: Blair T. Bullock Cc: Nakhjiri Madjid-MNAKHJI1; Adrangi, Farid; radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues > Hallelujah, I wholeheartedly concur with this statement. It is=20 > basically the same concept as the proposed Class usage for the=20 > purposes of user-name accounting data reflection, but specifically=20 > 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=20 > protected billable identity (or alias) which is not transmitted over=20 > 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=20 > 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 22:41:13 +0000 Date: Wed, 14 Jul 2004 15:38:44 -0700 (PDT) From: Bernard Aboba To: "Blair T. Bullock" cc: Nakhjiri Madjid-MNAKHJI1 , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: RE: NAI decoration: User Identity issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 22:09:11 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: NAI decoration: User Identity issues Date: Wed, 14 Jul 2004 15:05:39 -0700 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRp2Oj+L2/soz4lRL2wXTmpBbGerAAEvW0w From: "Blair T. Bullock" To: "Nakhjiri Madjid-MNAKHJI1" cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable "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. " Assumes that all routing is suffix based in a direct peer-to-peer relationship. We don't route every domain to every other domain. The constant realm add/remove process is a total nightmare! Therefore a chained suffix or prefix is typically used to aggregate unknown suffixes under a roaming agency: user@enterprise@ipass.com Or IPASS/user@enterprise.com Either way, if the Access-Accept returns User-Name=3Duser@enterprise.com and the accounting is re-written with this User-Name value, it will not route to the proper AAA exchange. =20 To reiterate some from my last email: 1- maintaining the re-decoration of the User-Name of the Access-Accept User-Name by the intermediary proxy requires statefulness of all AAA events. 2- To have the Access-Accept username return the decorated NAI from the Home AS requires knowledge of the aggregation principles (suffix or prefix) and provisioning of that information at the Home Authentication Server so it will normalize the user-name and won't mess-up local requests. (not to mention what if the Home Network uses multiple aggregators with different aggregation suffixes and/or prefix). 3 - To route via suffix only with a root NAI as per the RFC user@realm requires realm add/deletes ad nauseum from now until the end of time. A reseller adds a new enterprise realm and we have to update every RADIUS proxy in the system to tell them it should be routed to our exchange?! When you have hundreds of networks it is untenable. Also, what if that realm can be routed via multiple intermediaries?! =20 Thus the intermediary decoration of user@enterprise@ipass.com or user@enterprise@gric.com (or IPASS/user@enterprise.com or even IPASS/user@enterprise.com@reseller.com) is necessary to address these footprint aggregation, routing, reselling and billable user resolution requirements for roaming. Prefixes and suffix chains serve a very valid business functions. NAI decoration must be inclusive of all service models and is primarily used to eliminate the constant ongoing provisioning requirements of direct suffix peering. User@realm is too simplistic and doesn't reflect all of the business models that have emerged in our space over the past eight years. On a side note, what if the inner method authentication simply uses "john" with no suffix in the user-name? Accounting will be re-written as just "john" and it will not route at all, even if there is a direct suffix relationship between two networks. Position swapping of any NAI element is right-out bad. Blair -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 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 >=20 > As Blair notes, there are cases where the Accounting data needs to=20 > follow the same path as Authorization, and User-Name rewriting can=20 > 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. =20 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=20 > compatibility or billing system compatibility since new attributes=20 > will also require changes to NASen and billing systems. >=20 > I'd suggest that we need a discussion of the issues so that we can=20 > understand when it is safe to do User-Name rewriting, and when this=20 > 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. =20 >=20 > The major impetus for User-Name rewrite as I understand it is for use=20 > in privacy. There are also the cosmetic cases that Dave Mitton has=20 > mentioned (e.g. changing case) but I think these are relatively=20 > benign. >=20 > 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=20 > somewhat misleading; User-Name rewriting is not required for the=20 > routing of the Access-Accept back to the NAS; Proxy State can handle=20 > this. >=20 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. =20 > I'd also like to understand if there are guidelines that a server can=20 > use to determine when User-Name rewrite is safe and when it isn't. =20 > For example, what if a user attempts to protect Privacy in a network=20 > set up as Blair has suggested? What breaks? Is there a way for the=20 > server to detect the situation and not cause problems? >=20 > I also think that we need to discuss this in the Network Discovery=20 > Problem Statement, since if a user desires to influence the mediating=20 > network, then accounting supporting that decision needs to be carried=20 > out. >=20 >=20 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: -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 21:45:30 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: NAI decoration: User Identity issues Date: Wed, 14 Jul 2004 14:41:54 -0700 Message-ID: Thread-Topic: NAI decoration: User Identity issues Thread-Index: AcRp2Oj+L2/soz4lRL2wXTmpBbGerAAD5o0w From: "Blair T. Bullock" To: "Nakhjiri Madjid-MNAKHJI1" , "Adrangi, Farid" , "Bernard Aboba" cc: radiusext@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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. =20 >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]=20 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 >=20 > As Blair notes, there are cases where the Accounting data needs to=20 > follow the same path as Authorization, and User-Name rewriting can=20 > 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. =20 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=20 > compatibility or billing system compatibility since new attributes=20 > will also require changes to NASen and billing systems. >=20 > I'd suggest that we need a discussion of the issues so that we can=20 > understand when it is safe to do User-Name rewriting, and when this=20 > 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. =20 >=20 > The major impetus for User-Name rewrite as I understand it is for use=20 > in privacy. There are also the cosmetic cases that Dave Mitton has=20 > mentioned (e.g. changing case) but I think these are relatively=20 > benign. >=20 > 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=20 > somewhat misleading; User-Name rewriting is not required for the=20 > routing of the Access-Accept back to the NAS; Proxy State can handle=20 > this. >=20 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. =20 > I'd also like to understand if there are guidelines that a server can=20 > use to determine when User-Name rewrite is safe and when it isn't. =20 > For example, what if a user attempts to protect Privacy in a network=20 > set up as Blair has suggested? What breaks? Is there a way for the=20 > server to detect the situation and not cause problems? >=20 > I also think that we need to discuss this in the Network Discovery=20 > Problem Statement, since if a user desires to influence the mediating=20 > network, then accounting supporting that decision needs to be carried=20 > out. >=20 >=20 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: -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 21:21:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RADIUS Extension for Management Authorization Draft Date: Wed, 14 Jul 2004 17:20:45 -0400 Message-ID: Thread-Topic: RADIUS Extension for Management Authorization Draft Thread-Index: AcRp6GzYAFZzgoD5T8W4RJJtRx5y1w== From: "Nelson, David" To: I have submitted an Internet-Draft entitled "RADIUS Extension for = Management Authorization", located at the following URL: http://www.ietf.org/internet-drafts/draft-nelson-radius-management-author= ization-00.txt This is based on work that I presented at the RADEXT BOF at IETF 58. = Interest in this area of work was expressed at the BOF. I'd like to = solicit comment on this initial draft on the list, and get an idea of = the potential interest in making this a WG work item, and of others who = may have an interest in contributing to the document. Thanks! -- Dave Nelson =A0 -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 19:41:46 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: Mobile IP support: draft-adrangi-radius-attributes-extension-00.t xt Date: Wed, 14 Jul 2004 14:41:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Hi, I have a question regarding the Mobile IP HA support in Farid's draft: Although adding attributes for carrying MIP HA address and IP addresses may be enough for support of base MIP RFC. Many other attributes would be required to support MIP-AAA specs are coming out. Given that Diameter-MIP application provides a large number of AVPs for this and it seems that Diameter compatibility is now a must for RADIUS extensions, shouldn't we allow for more MIP related information to be carried by RADIUS? Since new data models are being planned, may be we should allow a VSA type attribute that can carry multiple pieces of information for Mobile IP support. How does that sound? Regards, Madjid -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Jari Arkko Sent: Wednesday, June 02, 2004 8:27 AM To: Adrangi, Farid; radiusext@ops.ietf.org Subject: comments on draft-adrangi-radius-attributes-extension-00.txt Hi Farid et al, Most of the functions in this draft appear valid and useful. I do have a number of comments again, however ;-) Some of these comments have to do with the User Alias Identity. I'm uncertain whether it should be done like this, or if the existing User-Name AVP is sufficient. Certainly the way that its now specified in the draft appears to have some privacy issues. Other set of comments involves making these attributes work with Diameter too (surprisingly, even the RADIUS capabilities discovery may be useful for Diameter). I also have some issues with the 1-byte long enumerated fields. In more detail: Substantial: > This document describes additional Remote Authentication Dial In > User Service (RADIUS) [1] attributes for use of RADIUS AAA > (Authentication, Authorization, Accounting) in both Wireless and > wired networks. This is otherwise OK abstract, but I would like to have it say something more about what the attributes do. Also make it less-RADIUS specific. How about this: This document describes additional Authentication, Authorization, Accounting (AAA) attributes for network access. It provides an IPv4 address type control mechanism, mobile IPv4 home agent discovery mechanism, and a RADIUS capabilities discovery mechanism. > 2. Operation > > Operation is identical to that defined in [1] and [2]. Like in the other draft, this seems to say very little. How about deleting this and adding the following text to the end of the Introduction: "This document assumes that the RADIUS protocol operates as specified in [1, 2] and that the Diameter protocol operates as specified in [RFC 3588, NASREQ, EAP]. > This document describes a number of additional attributes that are > needed to enable use of RADIUS AAA in various types of access > network in an interoperable manner. First some editorials: s/access network/access networks/ and s/RADIUS AAA/the RADIUS and Diameter AAA protocols/. Then to the substantive comment: I'm not sure I understand what is claimed here. Is this the draft that makes RADIUS interoperable? I'm pretty sure it adds new features. It certainly is likely that this specification is more interoperable than the existing VSAs, but lets state that then: This document describes a number of additional attributes for the RADIUS and Diameter AAA protocols. These attributes are needed to provide for wired and wireless access networks. Some of these functions already exist as vendor-specific solutions, but it is expected that this draft makes these functions interoperable among different vendors. > 2.1 RADIUS Support for Specifying User Alias Identity > > Rationale > In certain authentication methods such as, EAP-PEAP or EAP- > TTLS, the true identity of the subscriber is hidden from the > RADIUS AAA infrastructure. In these methods the User-name(1) > attribute contains an anonymous identity sufficient to route > the RADIUS packets to the home network but otherwise > insufficient to identify the subscriber. While this mechanism > is good practice there are situations where this creates > problems. For example, in certain roaming situations > intermediaries and visited network require to be able to > correlate an authentication session with a user identity; A > broker may require to implement a policy where by only session > is allowed per user entity. Third party billing brokers may > require to match accounting records to a user identity. > > The User Identity Alias provides a solution to the above > problem. When the home network assigns a value to the User > Identity Alias it asserts that this value represents a user in > the home network. The assertion should be temporary. Long > enough to be useful for the external applications and not too > long to such that it can be used to identify the user. Here's what RFC 3579 says: "The User-Name attribute within the Access- Accept packet need not be the same as the User-Name attribute in the Access-Request." I wonder if this could be used to implement the functionality that you want, without adding a new attribute. But you could still include the explanation of the problem and guidelines for the servers. > When the home network assigns a value to the User > Identity Alias it asserts that this value represents a user in > the home network. The assertion should be temporary. Long > enough to be useful for the external applications and not too > long to such that it can be used to identify the user. (snip) > 00 � reserved > 01 � IMSI > 02 � NAI > 03 � E.164 number > 04 � SIP URL (as defined in [13]) > 05 � Opaque string I find the first statement and types 1, 3, and 4 contradictory. This appears to be another reason why the RFC 3579 approach might be better. Alternatively, define the opaque string case only. (Type 2 is problematic too if not constructed the right way.) > 2.2 RADIUS Support for Advertising Application-based capabilities I would add the following text somewhere: This discovery also enables a Diameter translation agent to discover whether it can initiate these functions and expect them to succeed when translated to RADIUS. This attribute SHOULD be translated as is to Diameter, to enable the server make these decisions as well. A translation agent converting a Diameter AAR command to a RADIUS Access-Request packet SHOULD include this attribute iwith the value to indicate that Diameter can support, for instance, dynamic authorization. > This attribute indicates IPv4 address type options. It can be > present in Access-Request, Access-Accept, and Accounting- > Request records where the Acc-Status-Type is set to Start or > Stop. When it is used in an Access-Accept and Accounting- > Request packets, the Address Type value MUST be 1 or 2. RADIUS-specific. Suggested rewrite: This attribute indicates IPv4 address type options. In RADIUS, it can be present in Access-Request, and Access-Accept messages. In Diameter, it can be present in AAR, AAA, and RAR commands. In both protocols, it can be present in Accounting-Request messages where the Acc-Status-Type is set to Start or Stop. When it is used in an Access-Accept and Accounting- Request packets, the Address Type value MUST be 1 or 2. > A RADIUS server includes > this attribute in the Access-Accept to specify an IP address > type option for the PWLAN client. Rewrite: A server includes this attribute in the RADIUS Access-Accept packet or Diameter AAA and RAR commands to specify an IP address type option for the PWLAN client. > A RADIUS server MUST NOT include this attribute in the Access- > Accept if the IP Address Type options were not advertised in Why? Seems like this adds a rule to the server side, but sending an attribute which the NAS will ignore does not seem to harm anyone. Or am I missing something? > the Access-Request. If an invalid IP Address Type option is > received in the Access-Accept, then the AN MUST use its default > IP Address Type option for the client. Otherwise, the AN MUST In the other document an invalid attribute resulted in an Access-Reject. Why is this different? > assign an IP address according to the specified type option. > In either case it MUST include this attribute in Accounting- > Request packets to indicate the used IP address type option. Which one? The one that the server sent, or the one that the NAS chose? > If an IP address type option is not specified in the Access- > Accept, the NAS MUST NOT include this attribute in Accounting- > Request packets. s/Access-Accept/RADIUS Access-Accept or Diameter RAR and AAA commands/ > This draft introduces new RADIUS Attributes. Therefore, there is > a need for obtaining new attribute TYPE numbers from IANA. I think the document should also say something about the future allocations in the defined enumerated spaces. How about this additional text: New enumerated values within the attributes defined here can be allocated using the policies defined in RFC 3575, i.e., Designated Expert. > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |IP Address Type| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (snip) > Length > > 1 This does not seem to match the usual (?) RADIUS style where integer/enumerated attributes have a 32-bit integer. > The format of this Integer is as follows: > > 0xCCCTSSSS > > Where: > CCC is a 12-bit indicator that identifies the capability ID. (snip) > SSSS is 16-bit indicator that identifies the sub-capabilities ID. Uh oh. This is getting pretty complicated, and requires server side code (not just regexp) to handle. Are we really, really sure that we couldn't survive without the sub-capability IDs? Editorial: > 4. Security Considerations > > The attributes in this document have no additional security > considerations beyond those already identified in [?]. Missing reference. > PWLAN client This seems a bit too WLAN specific. Just say network access client. (Multiple places.) > RADIUS Attributes Extension A bit generic name for the system. > and sever are s/sever/server/ > 2.1 RADIUS Support for Specifying User Alias Identity..............2 > 2.2 RADIUS Support for Advertising Application-based capabilities..4 > 2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 > 2.4 RADIUS Support for Specifying IP Address Type Options..........7 Suggest s/RADIUS Support for Specifying// and s/RADIUS Support for Advertising/ in order to make the titles short. > Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the > dominant Authentication, Authorization, and Accounting (AAA) > protocol in use across broadband wireless and wired networks > globally. True, but not really relevant to the specification task at hand. Suggestion: delete paragraph. Move references to the next paragraph. > user�s Non-ASCII char. > 00 � reserved > 01 � IMSI > 02 � NAI > 03 � E.164 number > 04 � SIP URL (as defined in [13]) > 05 � Opaque string > Non-ASCII char. > later be indicated to the client through several means � for > example, it can be relayed in the �home agent address� field of Non-ASCII chars. > Authors� Addresses Non-ASCII char. --Jari -- 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 19:30:40 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Adrangi, Farid'" , Bernard Aboba Cc: radiusext@ops.ietf.org Subject: NAI decoration: User Identity issues Date: Wed, 14 Jul 2004 14:30:22 -0500 MIME-Version: 1.0 Content-Type: text/plain 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: -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 14 Jul 2004 19:19:42 +0000 Date: Wed, 14 Jul 2004 12:17:24 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: WG Action: RADIUS Extensions (radext) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. RADIUS Extensions (radext) --------------------------- Current Status: Proposed Working Group Chair(s): Bernard Aboba David Nelson Operations and Management Area Director(s): David Kessens Bert Wijnen Operations and Management Area Advisor: David Kessens Technical Advisor(s): aaa-doctors@ops.ietf.org Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe Archive: http://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. In order to support the deployment of Diameter, and enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No new security mechanisms will be defined for protecting RADIUS. - No new commands will be defined. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS implementation issues and fixes. This document will address common RADIUS implementation issues and describe proposed solutions. - Revised NAI specification. This document, known as "RFC 2486bis" will revise the NAI specification to correct known errors, add support for privacy and internationalization, and provide more details on routing. - Pre-paid support. Prepaid services are contemplated in a number of potential applications, including wireless LAN access and IP telephony. In order to enable support of pre-paid services in an interoperable way, the WG will provide definitions of the attributes required to support operator service models for pre-paid, as documented in liaison communications. This document will include within it a specification for interoperation with Diameter Credit Control. - SIP support. RADIUS is currently used for SIP authentication, authorization and accounting. Standardization of these attributes will enable improved interoperability. This document will be upwards compatible with the Diameter SIP application, and conform to existing IETF RFCs on HTTP Digest, including RFC 2617, 3261, and 3310. - LAN attributes. New attributes have been proposed to enable use of authentication, authorization and accounting in wired and wireless LANs. Standardization of these attributes will enable improved interoperability. - RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest changes are required to address this issue. MIBs for RFC 3576 are also needed. Goals and Milestones: Dec 04 Updates to RFC 2618-2621 RADIUS MIBs submitted for publication. Dec 04 RADIUS design guidelines submitted as an Informational RFC. Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard RFC. Feb 05 RADIUS implementation issues and fixes submitted as an Informational RFC. Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard RFC. Dec 05 LAN attributes draft submitted as a Proposed Standard RFC. Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC. Dec 05 RFC 3576 MIBs submitted as an Informational RFC. -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 13 Jul 2004 19:21:13 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: RE: questions on draft-mariblanca-aaa-eap-lla-00.txt Date: Tue, 13 Jul 2004 14:20:37 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Jari, Well, I am not sure if I agree with all you say down there. Isn't the "Proposal for an IETF extended attribute space" as Bernard sent out a few weeks ago, an attempt to extend the type space? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) |M|R| Vendor type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I understand that the proposal also supports the need for sub-attributes (which by itself is an implicit way of saving attribute space?), but still... So potentially (if you didn't have the legacy issue with EAP), you would want to have an "EAP attribute" with all the related info as sub-attributes, no? The same goes with Farid's draft that suggests Mobile IP HA to be sent as a new attribute. I feel that Mobile IP may need a whole lot more info from the RADIUS server than just HA information. I will send another email about that to keep the threads separate, although thought process is similar. Regards, Madjid -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Tuesday, July 13, 2004 1:09 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org; David Mariblanca (EE/EEM) Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Nakhjiri Madjid-MNAKHJI1 wrote: > I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work. I believe there is sufficient attribute space available to complete all standards work currently on the table. The discussion about new attribute formats and datatypes was related more to the unification of vendor, SDO, and IETF spaces and datatypes than running out of numbers for immediate needs. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 13 Jul 2004 06:14:34 +0000 Message-ID: <40F37C85.3030504@piuha.net> Date: Tue, 13 Jul 2004 09:09:09 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work. I believe there is sufficient attribute space available to complete all standards work currently on the table. The discussion about new attribute formats and datatypes was related more to the unification of vendor, SDO, and IETF spaces and datatypes than running out of numbers for immediate needs. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 12 Jul 2004 20:08:26 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" , Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: RE: questions on draft-mariblanca-aaa-eap-lla-00.txt Date: Mon, 12 Jul 2004 15:08:15 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Jari, Thank you for your quick response. I guessed that the EAP-IKEv2 had some drafts behind it. Thank you for the links, I will look at those drafts. As far as the attribute format on the EAP-message attribute, I understand the legacy deployment issues. I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work. BR, Madjid -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, July 12, 2004 2:01 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org; David Mariblanca (EE/EEM) Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Nakhjiri Madjid-MNAKHJI1 wrote: > I can understand that one may want to signal the info on the > kind of L2 that is carrying the EAP messages over the link > from end device to Access node, so PPP and 802.1x make sense. Yes. > But what is the purpose of IKEv2 and PANA? Are we saying we > expanded the L2 concept to L3 and EAP is carried over IKEv2 > for protection over the single hop? The EAP concept has already been expanded from L2 to L3 with the introduction of things like IKEv2 or PANA. But this is really not related to David's draft -- the expansion comes from documents such as draft-ietf-ipsec-ikev2-nn.txt or draft-ietf- pana-pana-mm.txt. By the way, such usage of EAP in IKEv2 is not necessarily limited to a single hop. > If yes, then why nothing on IKEv1? Would you care to explain? Because there is no current specification which would extend IKEv1 so that it could use EAP authentication. (PIC did something like that but my understanding is that PIC work is no longer alive; please feel free to correct me if I have been mistaken.) > I also have a general question: RFC 3579 defines an EAP-message > attribute for RADIUS with an IANA type of 79. So far I have not > understood how grouping of attributes works for RADIUS, but it > feels like the EAP-message attribute and L2 info attribute > should be grouped together somehow, especially if the attribute > space is tight. Anybody cares to explain? The problem is that EAP-Message has already been implemented and deployed, so its hard to add anything into that attribute without breaking everyone's devices. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 12 Jul 2004 19:05:42 +0000 Message-ID: <40F2DFD1.4010303@piuha.net> Date: Mon, 12 Jul 2004 22:00:33 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Cc: radiusext@ops.ietf.org, "David Mariblanca (EE/EEM)" Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > I can understand that one may want to signal the info on the > kind of L2 that is carrying the EAP messages over the link > from end device to Access node, so PPP and 802.1x make sense. Yes. > But what is the purpose of IKEv2 and PANA? Are we saying we > expanded the L2 concept to L3 and EAP is carried over IKEv2 > for protection over the single hop? The EAP concept has already been expanded from L2 to L3 with the introduction of things like IKEv2 or PANA. But this is really not related to David's draft -- the expansion comes from documents such as draft-ietf-ipsec-ikev2-nn.txt or draft-ietf- pana-pana-mm.txt. By the way, such usage of EAP in IKEv2 is not necessarily limited to a single hop. > If yes, then why nothing on IKEv1? Would you care to explain? Because there is no current specification which would extend IKEv1 so that it could use EAP authentication. (PIC did something like that but my understanding is that PIC work is no longer alive; please feel free to correct me if I have been mistaken.) > I also have a general question: RFC 3579 defines an EAP-message > attribute for RADIUS with an IANA type of 79. So far I have not > understood how grouping of attributes works for RADIUS, but it > feels like the EAP-message attribute and L2 info attribute > should be grouped together somehow, especially if the attribute > space is tight. Anybody cares to explain? The problem is that EAP-Message has already been implemented and deployed, so its hard to add anything into that attribute without breaking everyone's devices. --Jari -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 12 Jul 2004 18:55:16 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: radiusext@ops.ietf.org Subject: questions on draft-mariblanca-aaa-eap-lla-00.txt Date: Mon, 12 Jul 2004 13:54:22 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi David and others, I am going through the draft that have slots for San Diego meeting, so I am sorry if there has been discussions regarding this draft and I have missed those threads. My question regarding the EAP lower layer attributes is: I can understand that one may want to signal the info on the kind of L2 that is carrying the EAP messages over the link from end device to Access node, so PPP and 802.1x make sense. But what is the purpose of IKEv2 and PANA? Are we saying we expanded the L2 concept to L3 and EAP is carried over IKEv2 for protection over the single hop? If yes, then why nothing on IKEv1? Would you care to explain? I also have a general question: RFC 3579 defines an EAP-message attribute for RADIUS with an IANA type of 79. So far I have not understood how grouping of attributes works for RADIUS, but it feels like the EAP-message attribute and L2 info attribute should be grouped together somehow, especially if the attribute space is tight. Anybody cares to explain? Thanks, Madjid -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 02 Jul 2004 18:03:17 +0000 Reply-To: From: "Glen Zorn" To: "'Ashwin Palekar'" , , "'Joseph Salowey'" , Subject: RE: issues about Keyreq/keywrap drafts Date: Fri, 2 Jul 2004 11:02:06 -0700 Organization: Cisco Systems Message-ID: <011101c4605e$c1bf0450$0202a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ashwin Palekar writes: > Some issues/questions about these drafts: > > http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-01.txt > > http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt > > > 1. How is support for the "applications" signaled between the peer > and NAS and between the NAS and AAA server? Without specifying the > signaling mechanisms, the end result is breaking interoperability > both in EAP and in AAA as well. For example, even if the NAS > Requests an application specific key via the Naming AVP Do you mean the EAP-Key-Name AVP? > in Diameter > or an equivalent in RADIUS, what happens if the server doesn't > support the particular naming scheme in use? As far as I can tell, > the Diameter EAP name request can only be used interoperably with a > standardized key naming mechanism, not with this "extension" > mechanism. The application ID may be specified in the Key attribute. It's format has been left unspecified both in the hope of sparking discussion and because it's not completely clear (to me, anyway) that binding the Key attribute to EAP is a good idea (there are currently no standard EAP methods that generate keys of any kind). > > 2. Why create new RADIUS codes - can't we use existing radius codes > (Access-request) with new service type? We're not requesting access (presumably access has already been granted). It just seems cleaner to me. > > Thanks, Ashwin Hope this helps, ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 "It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets." -- Voltaire -- 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: