Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 Oct 2005 21:04:10 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Protocol Action: 'Chargeable User Identity' to Proposed Standard (fwd) Date: Mon, 31 Oct 2005 13:03:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >---------- Forwarded message ---------- >Date: Mon, 31 Oct 2005 15:52:55 -0500 >From: The IESG >To: IETF-Announce >Cc: Internet Architecture Board , > RFC Editor , > radext mailing list , > radext chair , radext chair > >Subject: Protocol Action: 'Chargeable User Identity' to Proposed > Standard > >The IESG has approved the following document: > >- 'Chargeable User Identity ' > as a Proposed Standard > >This document is the product of the RADIUS EXTensions Working Group. > >The IESG contact persons are David Kessens and Bert Wijnen. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-06.txt > >Technical Summary > > This document describes a new RADIUS attribute, Chargeable-User- > Identity. This attribute can be used by a home network to identify a > user for the purpose of roaming transactions that occur outside of > the home network. > >Working Group Summary > > The RADEXT Working Group came to consensus on this document. > >Protocol Quality > > This document was reviewed for the IESG by David Kessens. -- 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, 31 Oct 2005 15:07:53 +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: AW: Draft update: draft-lior-radius-prepaid-extensions-09.txt Date: Mon, 31 Oct 2005 16:07:34 +0100 Message-ID: Thread-Topic: Draft update: draft-lior-radius-prepaid-extensions-09.txt Thread-Index: AcXbOLIXg+i/STx1T2GepbOloaf9kQC8O4UgAACe/fA= From: "Tschofenig, Hannes" To: "Pashalidis, Andreas" , hi david,=20 hi bernard,=20 hi all,=20 i think we should also spend a few minutes to discuss this work at the = next ietf meeting since this is part of the charter: " Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC =20 " ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von=20 > Pashalidis, Andreas > Gesendet: Montag, 31. Oktober 2005 15:56 > An: radiusext@ops.ietf.org > Betreff: Draft update: draft-lior-radius-prepaid-extensions-09.txt >=20 >=20 > Dear all, >=20 > A new update of the "Prepaid extensions for RADIUS" Internet draft is > available at > http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid- extensions -09.txt Changes from the previous version include the following (not exhaustive list). =3D> The functionality of RADIUS prepaid has been aligned with that of = the Diameter Credit Control application, as discussed at IETF #63. In particular, RADIUS prepaid now supports "balance check" and "price enquiry" (in addition to what what supported in the previous version of the draft). =3D> Several worked through example flows appear in the appendix. =3D> RADIUS prepaid / Diameter Credit Control translation function has been partially specified. =3D> Various issues have been fixed. Your comments are solicited. Best Regards, Andreas Pashalidis -- 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: Mon, 31 Oct 2005 14:56:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Draft update: draft-lior-radius-prepaid-extensions-09.txt Date: Mon, 31 Oct 2005 15:55:44 +0100 Message-ID: Thread-Topic: Draft update: draft-lior-radius-prepaid-extensions-09.txt Thread-Index: AcXbOLIXg+i/STx1T2GepbOloaf9kQC8O4Ug From: "Pashalidis, Andreas" To: Dear all, A new update of the "Prepaid extensions for RADIUS" Internet draft is available at http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions -09.txt Changes from the previous version include the following (not exhaustive list). =3D> The functionality of RADIUS prepaid has been aligned with that of = the Diameter Credit Control application, as discussed at IETF #63. In particular, RADIUS prepaid now supports "balance check" and "price enquiry" (in addition to what what supported in the previous version of the draft). =3D> Several worked through example flows appear in the appendix. =3D> RADIUS prepaid / Diameter Credit Control translation function has been partially specified. =3D> Various issues have been fixed. Your comments are solicited. Best Regards, Andreas Pashalidis -- 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, 27 Oct 2005 20:54:51 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: FW: New Version Notification - draft-ietf-radext-digest-auth-06.txt Date: Thu, 27 Oct 2005 13:54:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >From: ID Tracker >To: dnelson@enterasys.com, aboba@internaut.com, >bernard_aboba@hotmail.com,david.kessens@nokia.com >Subject: New Version Notification - draft-ietf-radext-digest-auth-06.txt >Date: Thu, 27 Oct 2005 15:50:02 -0400 > >New version (-06) has been submitted for >draft-ietf-radext-digest-auth-06.txt. >http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt > > > >IETF Secretariat. > -- 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, 27 Oct 2005 06:33:01 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for pre-work item review: RADIUS Issues & Fixes Date: Wed, 26 Oct 2005 23:32:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is a request for pre-work item review of "RADIUS Issues & Fixes". The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt Please post your comments to the RADEXT WG mailing list by November 13, 2005. -- 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, 27 Oct 2005 06:32:25 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for Pre-Work Item Review of RADIUS Design Guidelines Date: Wed, 26 Oct 2005 23:31:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is a request for a pre-work item review of "RADIUS Design Guidelines". The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt Please post your comments to the RADEXT WG mailing list by November 13, 2005. -- 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, 26 Oct 2005 22:34:29 +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: capabilities problem Date: Wed, 26 Oct 2005 18:34:59 -0400 Message-ID: Thread-Topic: capabilities problem Thread-Index: AcXaTzvk24Wdon4GS7qxi4HrJwUn3gALi4tA From: "Avi Lior" To: "Alan DeKok" Cc: "Emile van Bergen" , Okay good. Then I think I am happy. =20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Wednesday, October 26, 2005 1:05 PM > To: Avi Lior > Cc: Emile van Bergen; radiusext@ops.ietf.org > Subject: Re: capabilities problem >=20 > "Avi Lior" wrote: > > The second round trip should not happen unless the NAS=20 > indicates that=20 > > it supports location fetching via a challenge. >=20 > Yes, that's what I intended to communicate. >=20 > Alan DeKok. >=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: Wed, 26 Oct 2005 17:02:45 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: capabilities problem Cc: "Emile van Bergen" , radiusext@ops.ietf.org Date: Wed, 26 Oct 2005 13:05:28 -0400 Message-Id: <20051026170528.2196917122@mail.nitros9.org> "Avi Lior" wrote: > The second round trip should not happen unless the NAS indicates that it > supports location fetching via a challenge. Yes, that's what I intended to communicate. Alan DeKok. -- 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, 26 Oct 2005 11:47:31 +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: capabilities problem Date: Wed, 26 Oct 2005 07:48:21 -0400 Message-ID: Thread-Topic: capabilities problem Thread-Index: AcXWacLB/2itz1fsTpSxx2hE1ro/nADt3hmA From: "Avi Lior" To: "Alan DeKok" , "Emile van Bergen" Cc: See inline please: I think we are darn close.... > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Friday, October 21, 2005 2:02 PM > To: Emile van Bergen > Cc: radiusext@ops.ietf.org > Subject: Re: capabilities problem >=20 > Emile van Bergen wrote: > > Ok. So can we conclude that the inefficiency objection of a second=20 > > round trip in case of GEOPRIV is moot, because it's needed=20 > anyway, and=20 > > that this is solved perfectly by your proposal with my refinements? >=20 > Yes. Unless I am missing something I don't agree. The second round trip should not happen unless the NAS indicates that it supports location fetching via a challenge. If the NAS happens to supported fetching of location via challenge then its everything is okay. But if the NAS did not support fetching of location via challenge then the challenge was wasteful, and worse, it can result in the termination of the session which may not be desired. Therefore an initial advertizement will give the RADIUS server an indication whether a challenge for location will be fruitfull. > > Agreed. Problably the misunderstanding lies in that I take=20 > > 'advertising a capability', as 'This party implements standards=20 > > document X, containing numberous clauses with musts, shoulds and=20 > > mays', which I find problematic. That's perhaps my biggest=20 > objection. >=20 > Which is why I avoided implementation and semantic=20 > problems, by saying "advertises a capability". Yes. > First, we can decide what we need from capabilities and=20 > their advertisement, independent of the definitions for each=20 > capability. > Then, we can define the capabilities. Finally, we can=20 > describe their on-wire formate. Agreed. =20 > > But I want to get rid of the explosion of possible states that a=20 > > system can get when two parties state their abilities,=20 > their wishes,=20 > > and then have to do a form of negotiation. > >=20 > > It took numerous endless looping implementations of PPP to get that=20 > > right in PPP. >=20 > Agreed. I vew capability negotiations a bit like the final=20 > "show of hands" in poker. Everyone's cards go on the table,=20 > and everyone runs the same algorithm on the available data. Once. Agreed....Nobody has suggested a multi-round negotiation. =20 > > If the use of challenges to get at information that can be=20 > put in the=20 > > first access request was Avi's worry too, then I completely agree. >=20 > To put it more strongly, if we don't have *any* capability=20 > advertisement in the first packet, we're back to today's=20 > RADIUS, and we can't break that by changing server behavior. Yes. Thankyou. > > Luckily here, you've misunderstood. I'm surprised. Am I=20 > really so bad=20 > > at explaining my position clearly? >=20 > There was significant opposition to allowing Avi's scenario. >=20 > > So I think we may have complete agreement on the problem=20 > and abstract=20 > > solution for GEOPRIV and alike future cases, at least=20 > between you, Avi=20 > > and myself. > >=20 > > We only need to work out the attributes and values >=20 > I disagree. I think we're pretty close, but I don't think=20 > we're ready to design a solution based on the stated=20 > requirements. I would like to ensure that *all* capability=20 > requirements are spelled out, to ensure that the solution is=20 > applicable to later capabilities. I agree. And unless I am missing something the first issue above is still problematic. > Alan DeKok. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Wed, 26 Oct 2005 10:57:18 +0000 MIME-Version: 1.0 Date: Wed, 26 Oct 2005 12:56:38 +0200 To: "Bernard Aboba" , radiusext@ops.ietf.org Subject: Re: ISSUE, SIP, authentication parameters (fwd) From: "wolfgang.beck01@t-online.de" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1EUixS-0Jeiky0@fwd34.aul.t-online.de> See inline > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > > Sent: 25 October, 2005 15:19 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: ISSUE, SIP, authentication parameters > > > > > > Description of issue: Authentication parameters > > Submitter name: Mikko Aittola > > Submitter email address: mikko.aittola@nokia.com > > Date first submitted: 25 Oct 05 > > Document: sip (v. 10) > > Comment type: T > > Priority: S > > Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5 > > Rationale/Explanation of issue: > > > > SIP-Method is defined to be required AVP in MAR-command. > > Is there really need for this to be required AVP? > > I think Diameter server doesn't necessarily need to consider > > what is the SIP-method the SIP-server is asking to authenticate. > > > > Furthermore, there is already optional Digest-Method AVP > > in SIP-Authorization grouped AVP. This can be used for > > the same purpose as SIP-Method AVP. > > The radext draft defines only Digest-Method, not SIP method. > > SIP-Authorization grouped AVP contains required AVP > > Digest-Username. This is duplicate information with > > the User-Name AVP sent in the MAR-command. > > I am not sure wether the User-Name syntax (think of NAI) won't interfere with the syntax of Digest-Username (white space?). Let's keep them separate. > > PS. Sorry for the late submission.. > > http://en.wikipedia.org/wiki/Sisyphos Wolfgang -- 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, 26 Oct 2005 10:04: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: IETF 64 RADEXT WG Agenda, Take 1 Date: Wed, 26 Oct 2005 06:04:40 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D92CC@ames.starentnetworks.com> Thread-Topic: IETF 64 RADEXT WG Agenda, Take 1 thread-index: AcXZ7t5Dn63hS1BRRqC1N+enyzThTwADuuGQAAFjrUAABCcdUA== From: "Chowdhury, Kuntal" To: , , Cc: BTW, we looked at RFC3575 for guidance regarding IANA allocation of new values for Framed-Compression attribute and it was not clear what we had to do. -Kuntal > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, October 26, 2005 3:02 AM > To: Chowdhury, Kuntal; bernard_aboba@hotmail.com; dnelson@enterasys.com > Cc: radiusext@ops.ietf.org > Subject: RE: IETF 64 RADEXT WG Agenda, Take 1 >=20 > Kuntal, >=20 > >http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu > tes-00.txt >=20 > I gave this a quick read, but I actually don't understand what this > attribute would be used for. Could you explain a little bit about what > it does, some examples of signaling, etc? >=20 > What is the NAS & RADIUS server signaling - is there any reason for them > to be involved in ROHC? >=20 > thanks, > John "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- 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, 26 Oct 2005 09:57:20 +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: IETF 64 RADEXT WG Agenda, Take 1 Date: Wed, 26 Oct 2005 05:56:52 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D92CB@ames.starentnetworks.com> Thread-Topic: IETF 64 RADEXT WG Agenda, Take 1 thread-index: AcXZ7t5Dn63hS1BRRqC1N+enyzThTwADuuGQAAFjrUAAA5MP0A== From: "Chowdhury, Kuntal" To: , , Cc: Hi John, The idea is to additional value for the already existing Framed-Compression attribute that is defined in 2865. The attribute is used by the NAS to give a hint to the RADIUS server about its capability to support a particular type of compression. The RADIUS server returns this attribute to indicate which compression scheme needs to be used by the NAS for bearer flows of the user. Here is the description from RFC 2865: " This Attribute indicates a compression protocol to be used for the link. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint. More than one compression protocol Attribute MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic. " Note that we are not changing this definition in our draft. We are just defining a new value for it for ROHC. Hope this clarifies your question. -Kuntal > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, October 26, 2005 3:02 AM > To: Chowdhury, Kuntal; bernard_aboba@hotmail.com; dnelson@enterasys.com > Cc: radiusext@ops.ietf.org > Subject: RE: IETF 64 RADEXT WG Agenda, Take 1 >=20 > Kuntal, >=20 > >http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu > tes-00.txt >=20 > I gave this a quick read, but I actually don't understand what this > attribute would be used for. Could you explain a little bit about what > it does, some examples of signaling, etc? >=20 > What is the NAS & RADIUS server signaling - is there any reason for them > to be involved in ROHC? >=20 > thanks, > John "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- 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, 26 Oct 2005 08:02:25 +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: IETF 64 RADEXT WG Agenda, Take 1 Date: Wed, 26 Oct 2005 11:02:04 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D013D4673@esebe100.NOE.Nokia.com> Thread-Topic: IETF 64 RADEXT WG Agenda, Take 1 Thread-Index: AcXZ7t5Dn63hS1BRRqC1N+enyzThTwADuuGQAAFjrUA= From: To: , , Cc: Kuntal, >http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu tes-00.txt I gave this a quick read, but I actually don't understand what this attribute would be used for. Could you explain a little bit about what it does, some examples of signaling, etc? What is the NAS & RADIUS server signaling - is there any reason for them to be involved in ROHC? thanks, John -- 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, 26 Oct 2005 07:30:42 +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: IETF 64 RADEXT WG Agenda, Take 1 Date: Wed, 26 Oct 2005 03:30:13 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D92CA@ames.starentnetworks.com> Thread-Topic: IETF 64 RADEXT WG Agenda, Take 1 thread-index: AcXZ7t5Dn63hS1BRRqC1N+enyzThTwADuuGQ From: "Chowdhury, Kuntal" To: "Bernard Aboba" , "Nelson, David" Cc: Chairs, Would you please assign slots for the following? http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-00.txt http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribut es-00.txt Both were submitted before the (-00) cutoff date. Please note that I made request for slots earlier when topics for the agenda were solicited. Thank you very much. Kuntal > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Bernard Aboba > Sent: Wednesday, October 26, 2005 12:29 AM > To: radiusext@ops.ietf.org > Subject: IETF 64 RADEXT WG Agenda, Take 1 >=20 > IETF-64 RADEXT WG Agenda >=20 > Chairs: Bernard Aboba > David Nelson >=20 > Preliminaries (10 minutes) > Bluesheets > Agenda Bash > Document Status > Open Issue Summary: > http://www.drizzle.com/~aboba/RADEXT > Presentations and agenda online at: > http://www.drizzle.com/~aboba/IETF64/radext/ >=20 > WORK ITEMS IN IETF Last Call >=20 > - Digest Authentication, Wolfgang Beck (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt >=20 > WORK ITEMS COMPLETING WG LAST CALL >=20 > - Dynamic Authorization MIBs, Greg Weber (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib - > 02.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib - > 02.txt >=20 > - RADIUS IPv6 MIBs, Dave Nelson (10 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt >=20 > - VLAN/Priority, Paul Congdon (30 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-02.txt >=20 > - Common Radius Implementation Issues and Suggested Fixes, Bernard Aboba > (10 > minutes) > http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt >=20 > - Design Guidelines, Greg Weber (20 minutes) > http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines- > 01.txt >=20 > - RADIUS NAS-Management Authorization, Greg Weber (10 minutes) > http://www.ietf.org/internet-drafts/draft-nelson-radius-management- > authorization-02.txt >=20 > - RADIUS/GEOPRIV, Hannes Tschofenig (20 minutes) > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt >=20 > - RADIUS Capabilities Problem Statement, Emile Van Bergen (20 minutes) >=20 > - RADIUS/MIPv4 Extensions, Madjid Nakhjiri (10 minutes) > http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.txt >=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: "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- 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, 26 Oct 2005 05:48:30 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: IETF 64 Registration Cutoff Date: Tue, 25 Oct 2005 22:48:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >From: IETF Registrar >To: IETF Announcement list >Subject: 64th IETF - Pre-registration/payment Cut Off >Date: Mon, 24 Oct 2005 12:06:29 -0400 > >The cutoff to pre-register and pre-pay for the 64th IETF Meeting in >Vancouver, >BC is this Wednesday, October 26 at 12:00 noon ET. If you do not >pre-register >and pre-pay by this time, you will need to register onsite in Vancouver and >pay >the onsite registration fee of $650.00 > >You can register on line at: http://www.ietf.org/meetings/notewell.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: Wed, 26 Oct 2005 05:29:01 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: IETF 64 RADEXT WG Agenda, Take 1 Date: Tue, 25 Oct 2005 22:28:31 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed IETF-64 RADEXT WG Agenda Chairs: Bernard Aboba David Nelson Preliminaries (10 minutes) Bluesheets Agenda Bash Document Status Open Issue Summary: http://www.drizzle.com/~aboba/RADEXT Presentations and agenda online at: http://www.drizzle.com/~aboba/IETF64/radext/ WORK ITEMS IN IETF Last Call - Digest Authentication, Wolfgang Beck (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt WORK ITEMS COMPLETING WG LAST CALL - Dynamic Authorization MIBs, Greg Weber (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt - RADIUS IPv6 MIBs, Dave Nelson (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt - VLAN/Priority, Paul Congdon (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-02.txt - Common Radius Implementation Issues and Suggested Fixes, Bernard Aboba (10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt - Design Guidelines, Greg Weber (20 minutes) http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt - RADIUS NAS-Management Authorization, Greg Weber (10 minutes) http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-02.txt - RADIUS/GEOPRIV, Hannes Tschofenig (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt - RADIUS Capabilities Problem Statement, Emile Van Bergen (20 minutes) - RADIUS/MIPv4 Extensions, Madjid Nakhjiri (10 minutes) http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.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, 25 Oct 2005 21:43:44 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: ISSUE, SIP, authentication parameters (fwd) Date: Tue, 25 Oct 2005 14:42:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Does compatibility with this issue require any changes in the RADIUS Digest document? >---------- Forwarded message ---------- >Date: Tue, 25 Oct 2005 15:19:05 +0300 >From: mikko.aittola@nokia.com >To: aaa-wg@merit.edu >Subject: [AAA-WG]: ISSUE, SIP, authentication parameters > >Description of issue: Authentication parameters >Submitter name: Mikko Aittola >Submitter email address: mikko.aittola@nokia.com >Date first submitted: 25 Oct 05 >Document: sip (v. 10) >Comment type: T >Priority: S >Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5 >Rationale/Explanation of issue: > >SIP-Method is defined to be required AVP in MAR-command. >Is there really need for this to be required AVP? >I think Diameter server doesn't necessarily need to consider >what is the SIP-method the SIP-server is asking to authenticate. > >Furthermore, there is already optional Digest-Method AVP >in SIP-Authorization grouped AVP. This can be used for >the same purpose as SIP-Method AVP. > >SIP-Authorization grouped AVP contains required AVP >Digest-Username. This is duplicate information with >the User-Name AVP sent in the MAR-command. > >It seems the case where Diameter server sends HA1 in MAA >and client calculates and checks the response has not been >taken into account when the required contents of SIP-Authorization, >SIP-Authenticate, and SIP-Authentication-Info AVP have been defined. > >It is not clear what is included to MAA message in case >Diameter server has checked the response successfully. >It might be useful if the Diameter client receives a confirmation >of the auth-scheme applied by the Diameter-server. > > >Requested changes: > >1. Remove SIP-Method AVP from the spec >2. Remove Digest-Username from the spec. (If needed add text where > it is explained that Digest-Username is translated to > User-Name in the case of Radius-Diameter translation.) >3. Change Digest-Nonce to optional in SIP-Authenticate >4. Change the following AVPs to optional in SIP-Authorization AVP: > Digest-Nonce, Digest-URI, Digest-Response >5. Change Digest-Nextnonce to optional in SIP-Authentication-Info AVP >6. After Diameter server has checked that the response is ok > it returns MAA where result-code is SUCCESS, and SIP-Auth-Data-Item > with the SIP-Authentication-Scheme AVP. > >7. Change the following text in Section 7.8: > If the SIP-Methods AVP value of the Diameter MAR message is set to > REGISTER and a User-Name AVP is present, then the Diameter server > MUST authorize that User-Name AVP value is able to use the URI > included in the SIP-AOR AVP. If this authorization fails, the > Diameter server must set the Result-Code AVP to > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > Multimedia-Auth-Answer (MAA) message. > To: > If the Digest-Method AVP value is either absent or received with a > value REGISTER in the Diameter MAR message and a User-Name AVP is > present, then the Diameter server MUST authorize that User-Name AVP > value is able to use the URI included in the SIP-AOR AVP. If this > authorization fails, the Diameter server must set the Result-Code AVP >to > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > Multimedia-Auth-Answer (MAA) message. > > >BR, >Mikko > > >PS. Sorry for the late submission.. -- 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, 25 Oct 2005 21:43:37 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: ISSUE, SIP, authentication parameters (fwd) Date: Tue, 25 Oct 2005 14:42:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed More below. >---------- Forwarded message ---------- >Date: Tue, 25 Oct 2005 15:32:16 +0300 >From: mikko.aittola@nokia.com >To: aaa-wg@merit.edu >Subject: RE: [AAA-WG]: ISSUE, SIP, authentication parameters > >Hi, > >There is an error in the proposed text in my previous message. >The corrected version is: > >If the Digest-Method AVP is either absent or received with a >value REGISTER in the Diameter MAR message and a User-Name AVP is >present, then the Diameter server MUST authorize that User-Name AVP >value is able to use the URI included in the SIP-AOR AVP. If this >authorization fails, the Diameter server must set the Result-Code AVP to >DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter >Multimedia-Auth-Answer (MAA) message. > > >BR, >Mikko > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > > Sent: 25 October, 2005 15:19 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: ISSUE, SIP, authentication parameters > > > > > > Description of issue: Authentication parameters > > Submitter name: Mikko Aittola > > Submitter email address: mikko.aittola@nokia.com > > Date first submitted: 25 Oct 05 > > Document: sip (v. 10) > > Comment type: T > > Priority: S > > Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5 > > Rationale/Explanation of issue: > > > > SIP-Method is defined to be required AVP in MAR-command. > > Is there really need for this to be required AVP? > > I think Diameter server doesn't necessarily need to consider > > what is the SIP-method the SIP-server is asking to authenticate. > > > > Furthermore, there is already optional Digest-Method AVP > > in SIP-Authorization grouped AVP. This can be used for > > the same purpose as SIP-Method AVP. > > > > SIP-Authorization grouped AVP contains required AVP > > Digest-Username. This is duplicate information with > > the User-Name AVP sent in the MAR-command. > > > > It seems the case where Diameter server sends HA1 in MAA > > and client calculates and checks the response has not been > > taken into account when the required contents of SIP-Authorization, > > SIP-Authenticate, and SIP-Authentication-Info AVP have been defined. > > > > It is not clear what is included to MAA message in case > > Diameter server has checked the response successfully. > > It might be useful if the Diameter client receives a confirmation > > of the auth-scheme applied by the Diameter-server. > > > > > > Requested changes: > > > > 1. Remove SIP-Method AVP from the spec > > 2. Remove Digest-Username from the spec. (If needed add text where > > it is explained that Digest-Username is translated to > > User-Name in the case of Radius-Diameter translation.) > > 3. Change Digest-Nonce to optional in SIP-Authenticate > > 4. Change the following AVPs to optional in SIP-Authorization AVP: > > Digest-Nonce, Digest-URI, Digest-Response > > 5. Change Digest-Nextnonce to optional in SIP-Authentication-Info AVP > > 6. After Diameter server has checked that the response is ok > > it returns MAA where result-code is SUCCESS, and SIP-Auth-Data-Item > > with the SIP-Authentication-Scheme AVP. > > > > 7. Change the following text in Section 7.8: > > If the SIP-Methods AVP value of the Diameter MAR message is set to > > REGISTER and a User-Name AVP is present, then the Diameter server > > MUST authorize that User-Name AVP value is able to use the URI > > included in the SIP-AOR AVP. If this authorization fails, the > > Diameter server must set the Result-Code AVP to > > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > > Multimedia-Auth-Answer (MAA) message. > > To: > > If the Digest-Method AVP value is either absent or received with a > > value REGISTER in the Diameter MAR message and a User-Name AVP is > > present, then the Diameter server MUST authorize that User-Name AVP > > value is able to use the URI included in the SIP-AOR AVP. If this > > authorization fails, the Diameter server must set the > > Result-Code AVP to > > DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter > > Multimedia-Auth-Answer (MAA) message. > > > > > > BR, > > Mikko > > > > > > PS. Sorry for the late submission.. > > -- 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, 25 Oct 2005 17:22: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: Issue 113: Attribute Concatenation Date: Tue, 25 Oct 2005 10:19:48 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482403B6BC0F@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue 113: Attribute Concatenation Thread-Index: AcW+CczGw3cnMB6vRbKkuAL4c77shAAM1mHQAAgOhNAAJOivcAEhiX/gAACvPdAFgzdzwA== From: "Congdon, Paul T (ProCurve)" To: "Glen Zorn (gwz)" Cc: , I'd like to revive this thread a bit. I never finished the response to Glenn about QoS-Filter-Rule for Radius... As a warm-up, remember, what we are trying to do is simply import the QoS-Filter-Rule AVP from Diameter into Radius. We felt since it was defined for Diameter (and presumable implemented), that we could easily define it for Radius by addressing the differences and missing funcationality. >=20 > > Taking Glen's suggested text, I'd like to close this issue out with=20 > > the following proposed text for the Text field in section 3.6. > > Please let me know if this will work. =20 > >=20 > >=20 > > Text > >=20 > > The Text field contains a QoS filter, utilizing the syntax > > defined for the QoSFilterRule derived data type defined in > > [RFC3588], Section 4.3. Note that this definition contained > > an error, so that the complete syntax is described in the > > definition of the QoS-Filter-Rule AVP, defined in [NASREQ]. >=20 > Are you _sure_ that you want to use this syntax? It's=20 > awfully verbose. Even if you really do want to use it, I=20 > would suggest that you reproduce it (or rather, adapt it to=20 > use w/RADIUS) in this document, rather than incorporating it=20 > by reference. There are several problems with the Diameter=20 > definitions, not least of which is that the definition of the=20 > QoS-Filter-Rule AVP depends upon the definition of=20 > IPFilterRule which is derived from OctetString which doesn't=20 > exist in RADIUS. >=20 Seems like we have a couple of options here: 1. completely define the attribute syntax, as we have done for NAS-Filter-Rule. Perhaps leveraging much of the same definition, but providing new actions that match QoS-Filter-Rule actions. The actions are mark and meter. The mark action could also take-on L2 functionality such as setting 802.1p bits in addition to setting DSCP. 2. provide text that defines the missing pieces from IPFilterRule, such as OctetString. 3. Drop the attribute all together. I don't believe any other SDOs are depending upon this attributre. I'm sure the TNC is not currently using it. Also, there have been a number of concerns with QoS functionality in general (as seen in the simple bandwidth draft). However, Diamater successfully has defined this AVP. Option 1 would be most consistent with the rest of the document. Option 3 is the easy way out. I'm not sure exactly what would be needed for option 2. Paul=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, 21 Oct 2005 17:59:52 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: capabilities problem Cc: radiusext@ops.ietf.org Date: Fri, 21 Oct 2005 14:02:17 -0400 Message-Id: <20051021180217.82F7816DD6@mail.nitros9.org> Emile van Bergen wrote: > Ok. So can we conclude that the inefficiency objection of a second > round trip in case of GEOPRIV is moot, because it's needed anyway, and > that this is solved perfectly by your proposal with my refinements? Yes. > Agreed. Problably the misunderstanding lies in that I take 'advertising > a capability', as 'This party implements standards document X, > containing numberous clauses with musts, shoulds and mays', which I find > problematic. That's perhaps my biggest objection. Which is why I avoided implementation and semantic problems, by saying "advertises a capability". First, we can decide what we need from capabilities and their advertisement, independent of the definitions for each capability. Then, we can define the capabilities. Finally, we can describe their on-wire formate. > But I want to get rid of the explosion of possible states that a system > can get when two parties state their abilities, their wishes, and then > have to do a form of negotiation. > > It took numerous endless looping implementations of PPP to get that > right in PPP. Agreed. I vew capability negotiations a bit like the final "show of hands" in poker. Everyone's cards go on the table, and everyone runs the same algorithm on the available data. Once. > If the use of challenges to get at information that can be put in the > first access request was Avi's worry too, then I completely agree. To put it more strongly, if we don't have *any* capability advertisement in the first packet, we're back to today's RADIUS, and we can't break that by changing server behavior. > Luckily here, you've misunderstood. I'm surprised. Am I really so bad at > explaining my position clearly? There was significant opposition to allowing Avi's scenario. > So I think we may have complete agreement on the problem and abstract > solution for GEOPRIV and alike future cases, at least between you, Avi > and myself. > > We only need to work out the attributes and values I disagree. I think we're pretty close, but I don't think we're ready to design a solution based on the stated requirements. I would like to ensure that *all* capability requirements are spelled out, to ensure that the solution is applicable to later capabilities. Alan DeKok. -- 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, 21 Oct 2005 10:48:14 +0000 MIME-Version: 1.0 Date: Fri, 21 Oct 2005 12:47:32 +0200 To: "Emile van Bergen" , "wolfgang.beck01@t-online.de"@t-online.de Subject: Re: draft-ietf-radext-digest-auth-06, secure connection Cc: radiusext@ops.ietf.org From: "wolfgang.beck01@t-online.de" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1ESuQu-1JVLlo0@fwd16.aul.t-online.de> Emile, several versions ago I've used "secure connection" instead of IPsec. This was considered as too vague. Is an unencrypted MPLS VPN secure? How secure is a dedicated leased line, if you don't know how it is implemented? Wolfgang -- 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, 21 Oct 2005 09:28:34 +0000 Date: Fri, 21 Oct 2005 11:27:30 +0200 From: Emile van Bergen To: Alan DeKok Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: capabilities problem Message-ID: <20051021092730.GE3608@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , Bernard Aboba , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Oct 20, 2005 at 07:01:22PM -0400, Alan DeKok wrote: > > > Indeed. To put the point more forcefully -- continued attempts to advocate > > for the original capabilities advertisement draft are not productive. > > I don't understand. > > From my reading of recent messages and the draft, even Avi isn't > advocating the solution proposed in the draft. And I'm certainly > opposed to much of what the draft says, for reasons I've articulated > previously. > > To address one of Emile's points: > > > In the case of GEOPRIV, and we've been at this at length, the case > > of service being dependent on Location information CANNOT be > > implemented in a single round trip AT ALL, because the NAS first > > needs to be informed of the user's privacy policy -- in short, > > whether or not that NAS is allowed to send the user's Location at > > all. > > There is no conflict that I can see between this requirement and my > position, or Avi's position. Ok. So can we conclude that the inefficiency objection of a second round trip in case of GEOPRIV is moot, because it's needed anyway, and that this is solved perfectly by your proposal with my refinements? (In short, the NAS indicates (let's go of advertise for a moment, as that has a broadcasting association with it) in its access request support for Access-Challenges containing the Challenge-Cause attribute, telling the server it can send a Challenge without fear of rejection, and that the NAS will repeat its original access request if it doesn't understand the Challenge-Cause). Note that I'm not saying this solves the /other/ issue, that of mandatory session limiting attributes ('prepaid'). There we /do/ want to avoid a second round trip if possible, because its necessity has not been demonstrated on other grounds. > The ability to perform multi-round negotiation of data to include in > a packet is itself a capability that can be advertised. That > capability MUST (IMHO) be advertised in the first packet, otherwise > the server may send an Access-Challenge to a NAS that doesn't support > it. The user then ends up with no service rather than limited service. Agreed. Problably the misunderstanding lies in that I take 'advertising a capability', as 'This party implements standards document X, containing numberous clauses with musts, shoulds and mays', which I find problematic. That's perhaps my biggest objection. If you understand the advertised capability as semantically narrow as I explained it ('the capability indicates that the NAS will behave as follows when presented with information as follows'), then we are on the same page. > The only disagreement I can see is that Avi and I believe that > multi-round capability negotiation is itself a capability that has to > be advertised, and others believe it's OK to send Access-Challenge > without knowing if the NAS supports it. I agree that it has to be advertised. In numerous messages about this subject, including the one where I expanded on your suggestion that for GEOPRIV, the NAS mainly has to advertise that it won't reject on challenges that are properly labeled, I've said so. > For the record, my original position was that I was OK with blindly > sending Access-Challenge, as it was fail safe. But if there are > use-cases where it's useful to offer limited services, then sending > Access-Challenge is itself a capability that has to be negotiated or > advertised. The alternative is to make it impossible to "fail > gracefully", and offer limited service. The choice will be all or > nothing. We completely agree. I just want to make the semantics of the advertisement as narrow as possible, without loss of generality (even gaining it, because this support for 'reason-explained challenges' can also be used for future things). But I want to get rid of the explosion of possible states that a system can get when two parties state their abilities, their wishes, and then have to do a form of negotiation. It took numerous endless looping implementations of PPP to get that right in PPP. If not absolutely needed, I definitely don't want negotiation, and I want advertisements to be very narrow and with very well defined results in case it does not sent or is not understood by the receiver, and so on. > To put it another way: > > If Emile's NAS supports multi-round negotiation, then it advertises > that, and the NAS and server perform the negotiation that Emile wants. Inquiries, using particularly formed challenges, not negotiation. My mechanism (Challenge-Supported = Yes and Challenge-Cause) could be used for multi-round negotiation, but I'm not proposing that. It's wasteful to use inquiries for information that can be included in the first and final access request. It's only needed where the NAS MUST withhold information from the first access request, as is the case with GEOPRIV. If the use of challenges to get at information that can be put in the first access request was Avi's worry too, then I completely agree. I'm NOT proposing these challenges as the mechanism for all cases where the server requires information from the NAS it currently doesn't have. I am ONLY proposing these challenges as a mechanism for the cases where the server requires information from the NAS that the NAS IS NOT ABLE to send in its first Access-Request. Case in point: GEOPRIV, reason: location privacy. The 'advertisement' of support of a certain set of session limiting attributes (and this is only a single bit of information per attribute at most and a single bit of information per set of attributes at minimum) can be done in the first access request. No extra roundtrips necessary. > If Avi's NAS doesn't support multi-round negotiation, then it > advertises that, and rather than doing negotiation, the server offers > limited service, which is what Avi wants. That phrase, 'multi-round negotiation', sends shivers down my spine as it evokes the thought of endlessly debugging negotiations that don't converge in certain implementations due to /very/ subtle bugs, and admins having to fine tuning the advertisements so that the other side responds correctly, and on and on. > I don't see any disagreement between the two positions, and I don't > see how this relates to the original draft, which didn't talk about > these issues. > > Avi's position (I believe), and mine, is to allow both scenarios. > Emile's position (from what I can understand) would appear to prevent > Avi from deploying his scenario. Luckily here, you've misunderstood. I'm surprised. Am I really so bad at explaining my position clearly? I totally agree that the NAS must advertise that it will respond in a certain defined way to challenges, for them to be useful as a mechanism for GEOPRIV and related things. (And to prevent all misunderstanding here: 'related things' DOES NOT include CUI, session limiting attributes and and other static information about the NAS!). So I think we may have complete agreement on the problem and abstract solution for GEOPRIV and alike future cases, at least between you, Avi and myself. We only need to work out the attributes and values, but I suggest we postpone that for a second and work on the problem statement for servers requiring advance knowledge about the NAS' response to certain session limiting attributes. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 21 Oct 2005 01:28: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: capabilities problem Date: Thu, 20 Oct 2005 21:28:39 -0400 Message-ID: Thread-Topic: capabilities problem Thread-Index: AcXVwykSdwdlusyOQ5+DPiFVIoJFTwAGgPwg From: "Avi Lior" To: "Bernard Aboba" , This email and the previous one from Emile seems to be suggesting that I am promoting a solution -- That I am "pounding on it" I resent that strongly.=20 Since Bernard's email I have been discussion only requirements!!! But I also want to point out for the record that it is only few that are opposing the solution proposed in the draft.=20 For example, in Paris there was lots of support and I don't belive anyone rejected it. But be that as it may, as I have demonstrated I am willing to shed the old and discuss requirements. So lets move on and both Emile and Bernard stop the presonal attacks!!! > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, October 20, 2005 6:08 PM > To: radiusext@ops.ietf.org > Subject: Re: capabilities problem >=20 > Emile Bergen said: >=20 > "Few seem to have joined you in blessing the original=20 > capabilities advertising draft as a candidate for a solution=20 > that even reaches the required level of precision and generality. >=20 > To do so is premature, and it would help if you didn't keep=20 > pounding on it." >=20 > Indeed. To put the point more forcefully -- continued=20 > attempts to advocate for the original capabilities=20 > advertisement draft are not productive. >=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: >=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: Thu, 20 Oct 2005 22:58:26 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: capabilities problem Cc: radiusext@ops.ietf.org Message-Id: <20051020230122.48EA217122@mail.nitros9.org> Date: Thu, 20 Oct 2005 19:01:22 -0400 (EDT) > Indeed. To put the point more forcefully -- continued attempts to advocate > for the original capabilities advertisement draft are not productive. I don't understand. From my reading of recent messages and the draft, even Avi isn't advocating the solution proposed in the draft. And I'm certainly opposed to much of what the draft says, for reasons I've articulated previously. To address one of Emile's points: > In the case of GEOPRIV, and we've been at this at length, the case > of service being dependent on Location information CANNOT be > implemented in a single round trip AT ALL, because the NAS first > needs to be informed of the user's privacy policy -- in short, > whether or not that NAS is allowed to send the user's Location at > all. There is no conflict that I can see between this requirement and my position, or Avi's position. The ability to perform multi-round negotiation of data to include in a packet is itself a capability that can be advertised. That capability MUST (IMHO) be advertised in the first packet, otherwise the server may send an Access-Challenge to a NAS that doesn't support it. The user then ends up with no service rather than limited service. The only disagreement I can see is that Avi and I believe that multi-round capability negotiation is itself a capability that has to be advertised, and others believe it's OK to send Access-Challenge without knowing if the NAS supports it. For the record, my original position was that I was OK with blindly sending Access-Challenge, as it was fail safe. But if there are use-cases where it's useful to offer limited services, then sending Access-Challenge is itself a capability that has to be negotiated or advertised. The alternative is to make it impossible to "fail gracefully", and offer limited service. The choice will be all or nothing. To put it another way: If Emile's NAS supports multi-round negotiation, then it advertises that, and the NAS and server perform the negotiation that Emile wants. If Avi's NAS doesn't support multi-round negotiation, then it advertises that, and rather than doing negotiation, the server offers limited service, which is what Avi wants. I don't see any disagreement between the two positions, and I don't see how this relates to the original draft, which didn't talk about these issues. Avi's position (I believe), and mine, is to allow both scenarios. Emile's position (from what I can understand) would appear to prevent Avi from deploying his scenario. Alan DeKok. -- 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, 20 Oct 2005 22:30:28 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG last call on RFC 3576 MIBs Date: Thu, 20 Oct 2005 15:30:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is an announcement of RADEXT WG last call on the RFC 3576 MIBs, prior to sending the documents on to the IESG for publication as Informational RFCs. The documents will be available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt RADEXT WG last call will last until Monday, November 14, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described in the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- 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, 20 Oct 2005 22:08:56 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: capabilities problem Date: Thu, 20 Oct 2005 15:08:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Emile Bergen said: "Few seem to have joined you in blessing the original capabilities advertising draft as a candidate for a solution that even reaches the required level of precision and generality. To do so is premature, and it would help if you didn't keep pounding on it." Indeed. To put the point more forcefully -- continued attempts to advocate for the original capabilities advertisement draft are not productive. -- 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, 20 Oct 2005 21:05:22 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: Capabilities: Moving forward - to the problem, please Cc: radiusext@ops.ietf.org Date: Thu, 20 Oct 2005 17:08:15 -0400 Message-Id: <20051020210815.37FAB16DD6@mail.nitros9.org> Emile van Bergen wrote: > But for the life of me, I did not see any connection between the two > problematic scenarios and even C1, leave alone the rest. I tried to explain the connection. Avi's requirement is that we can't send Access-Challenge unless we *know* the NAS won't treat it as Access-Reject. That pretty much forces some kind of capability advertisement in the first Access-Request. Add to that the belief that multiple round trips are inefficient, and you have C1. > If that's deduction, then I'm missing it, but I sure could do with some > more steps in the line of reasoning there. It doesn't help to say, we've > want GEOPRIV, we want mandatory session limiting, therefore all > capabilties need to be advertised. QED. My previous proposal of a "challenge-capable" attribute minimizes the capability advertisements in the first packet, and maximizes the resulting traffic. If that's fine for you, OK. But it's not fine for Avi, and I agree with him here. > Agreed. I'll do my best, but I was really surprised at what I saw as > your complete ignoring of Bernard's suggestion to leave the solutions > aside for a while and to focus on the problem first. I wasn't proposing a solution. I was proposing a list of requirements that would enable a capability solution to be implemented. My $0.02 is that if one of those requirements is not satisfied, we probably will not be able to implement *any* interoperable solution. There is a very big difference between saying "bits on the wire look like X", and saying "in order for two parties to agree, they have to exchange information". Bernard wanted to avoid the first kind of discussion, and I agree with him. My requirements were solely of the second kind. > You repeated the two problems I've described too, without responding > to my description of them, without adding any detail, scope or > implications, and then skipping straight to a set of requirements > for a solution. Uh, no. I responded to Bernard's post, not yours. The list archives indicate that there have been no followups to your response. > Not in a vague, general sense; but as in "for GEOPRIV, the NAS needs to > know a single bit that says whether a user's privacy policy allows it to > send Location information. The NAS currently has no way of obtaining > that bit. In most cases the RADIUS server will have it, because that's > generally where the user's profile is stored. Therefore GEOPRIV requires > a roundtrip to the RADIUS server before an access request containing > Location information can be sent, to obtain the bit. One way, but > perhaps not the only way, of implementing that first roundtrip is as an > Access-Request/Access-Challenge transaction". That contains a lot of implementation details, and is substantially a proposed solution. My preference is to discuss the *concept* of capability exchange and advertisement. i.e. how two parties can mutually agree on *any* capabilities via some general method. i.e. what are the minimum requirements for that agreement to be reached, like "the parties must communicate". Alan DeKok. -- 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, 20 Oct 2005 20:54:52 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG last call on RFC 2618bis-2621bis Date: Thu, 20 Oct 2005 13:54:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is an announcement of RADEXT WG last call on RFC 2618bis-2621bis, prior to sending the documents on to the IESG for consideration as Proposed Standards (2618bis, 26819bis) and Informational (2620bis, 2621bis). The documents are available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt (Proposed Standard) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt (Proposed Standard) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt (Informational) http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt (Informational) RADEXT WG last call will last until Monday, November 14, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described in the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- 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, 20 Oct 2005 20:51:03 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward - to the problem, please Cc: Barney Wolff Date: Thu, 20 Oct 2005 16:53:43 -0400 Message-Id: <20051020205343.4570017122@mail.nitros9.org> Barney Wolff wrote: > If we want to solve the general problem that the NAS and server > belonging to two different administrations need to understand what > features of RADIUS each supports and requires, we should be looking > for solutions that solve the general problem, while also solving > the specific problems we know about today. I'm working on a "capabilities model" draft. It's pretty rough right now, but it should cover the general scenario. Some assumptions: Both NAS & server have capabilities. Each may try to discover the capabilities of each other. The capability information is exchanged via advertisements in packets. The NAS initiates the conversation. The server cannot negotiate capabilities with the NAS if the NAS capabilities do not include "capability negotiation". RADIUS conversations do not currently include capability advertisement. A *lot* of conclusions come from those assumptions, including the ones presented in my previous message. I also believe that those assumptions are reasonable, and are taken from discussions on this list. If anyone disagrees with one or more of those assumptions, I'd love to hear it. Alan DeKok. -- 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, 20 Oct 2005 20:02:03 +0000 Date: Thu, 20 Oct 2005 16:01:41 -0400 From: Barney Wolff To: Alan DeKok , Avi Lior , radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward - to the problem, please Message-ID: <20051020200141.GA99104@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Thu, Oct 20, 2005 at 09:50:14PM +0200, Emile van Bergen wrote: > > Unless we start doing that, explaining the *problem* at the bit level, > without immediately going to broad generalities, I don't think we'll > ever reach consensus about any solution. With all due respect, I think this approach is completely wrong. If we want to solve individual problems with individual solutions, fine and dandy, but we'll never be done. If we want to solve the general problem that the NAS and server belonging to two different administrations need to understand what features of RADIUS each supports and requires, we should be looking for solutions that solve the general problem, while also solving the specific problems we know about today. -- Barney Wolff I never met a computer I didn't like. -- 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, 20 Oct 2005 19:50:43 +0000 Date: Thu, 20 Oct 2005 21:50:14 +0200 From: Emile van Bergen To: Alan DeKok , Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward - to the problem, please Message-ID: <20051020195014.GA3608@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , Avi Lior , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Alan, Avi, On Thu, Oct 20, 2005 at 12:34:46PM -0400, Alan DeKok wrote: > Emile van Bergen wrote: > > Are you being serious? You're *seriously* claiming each item follows > > from the previous one? > > I would prefer that you discuss the content of my message, rather > than the manner in which it was presented. That would be much more > productive. I did. I read the content as a list of requirements for a solution to the two problems we seem to agree on. But for the life of me, I did not see any connection between the two problematic scenarios and even C1, leave alone the rest. If that's deduction, then I'm missing it, but I sure could do with some more steps in the line of reasoning there. It doesn't help to say, we've want GEOPRIV, we want mandatory session limiting, therefore all capabilties need to be advertised. QED. > > I think you missed Bernard's line that shopping lists make bad design > > documents. You seem to try and distill requirements from every shopping > > list item that has ever floated here. > > No. I started with the two scenairos as stated in my message. The > first requirement (C1) followed from that. You haven't presented > concrete objections to that, or any of the other statements. My concrete objection is that it's a /very/ broad statement, presented without much explanation as THE requirement for ANY sane solution to the two problems. The steps you took to arrive at that conclusion were perhaps present in one the 10-20 earlier attempts, but I didn't find them in the version you sent. > > So, if we FIRST get a SHORT list of real world problems that are > > currently fundamentally impossible to solve due to lack of information > > at the client or server AND clearly describe the decision that cannot be > > made correctly due to the lacking information, > > My message did so. You haven't responded to it. > > I think part of the problem here is that we're talking at cross > purposes. I've been reading the different posts, and trying to > distill a common set of scenarios. I presented those, and some > requirements in my post. Rather than address those, you've responded > with your own set of requirements. I didn't respond with my own set of requirements to the solution. I responded with a set of suggestions for the /process/ to arrive at a solution, starting from Bernard's suggestion to focus on a clear problem statement first. I also added the capabilities-related problems I've been able to gather from the discussion, and tried to describe them in terms of missing information at either party. > If the conversation is going to be nothing more than people > presenting what they want, and ignoring what other people say, I don't > see any point in continuing. Agreed. I'll do my best, but I was really surprised at what I saw as your complete ignoring of Bernard's suggestion to leave the solutions aside for a while and to focus on the problem first. You repeated the two problems I've described too, without responding to my description of them, without adding any detail, scope or implications, and then skipping straight to a set of requirements for a solution. My reaction is basically that you haven't demonstrated at all that those requirements follow from the problem. Avi, I also think it doesn't help to make broad references to features ('prepaid', 'cui', 'geopriv') to make a case for any capabilities design. What does help is to describe, in excruciating detail, who needs what information when (and why). Not in a vague, general sense; but as in "for GEOPRIV, the NAS needs to know a single bit that says whether a user's privacy policy allows it to send Location information. The NAS currently has no way of obtaining that bit. In most cases the RADIUS server will have it, because that's generally where the user's profile is stored. Therefore GEOPRIV requires a roundtrip to the RADIUS server before an access request containing Location information can be sent, to obtain the bit. One way, but perhaps not the only way, of implementing that first roundtrip is as an Access-Request/Access-Challenge transaction". Unless we start doing that, explaining the *problem* at the bit level, without immediately going to broad generalities, I don't think we'll ever reach consensus about any solution. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 20 Oct 2005 17:20: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: Capabilities: Moving forward - to the problem, please Date: Thu, 20 Oct 2005 13:21:50 -0400 Message-ID: Thread-Topic: Capabilities: Moving forward - to the problem, please Thread-Index: AcXVmhprUNB3bVsdT/uRaokYwK6TqwAAIMCA From: "Avi Lior" To: "Alan DeKok" Cc: Hi Alan,=20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, October 20, 2005 1:19 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Capabilities: Moving forward - to the problem, please >=20 > "Avi Lior" wrote: > > So how about the above as a concise package of requirements...... >=20 > I agree. I'd just add (D) as efficiency. Thanx... > I think my requirement list follows from yours. I'll=20 > update my list, and map it to your requirments. Great. =20 > My list was *not* intended to be a laundry list of requirements. > For example, if you look at the MUST's and SHOULD's in a=20 > standard, you could easily concluse that the spec is nothing=20 > more than a laundry list of requirements. Understood... =20 > My list was meant to satisfy another, unspoken requirement:=20 > we have to be able to deploy this, and to have interoperable=20 > implementations. I think we are on a convergent path... =20 > Alan DeKok. >=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: Thu, 20 Oct 2005 17:15:56 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: Capabilities: Moving forward - to the problem, please Cc: radiusext@ops.ietf.org Date: Thu, 20 Oct 2005 13:18:44 -0400 Message-Id: <20051020171844.8675A16DD6@mail.nitros9.org> "Avi Lior" wrote: > So how about the above as a concise package of requirements...... I agree. I'd just add (D) as efficiency. I think my requirement list follows from yours. I'll update my list, and map it to your requirments. My list was *not* intended to be a laundry list of requirements. For example, if you look at the MUST's and SHOULD's in a standard, you could easily concluse that the spec is nothing more than a laundry list of requirements. My list was meant to satisfy another, unspoken requirement: we have to be able to deploy this, and to have interoperable implementations. Alan DeKok. -- 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, 20 Oct 2005 16:31:56 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: Capabilities: Moving forward - to the problem, please Cc: radiusext@ops.ietf.org Date: Thu, 20 Oct 2005 12:34:46 -0400 Message-Id: <20051020163447.EAA3116DD6@mail.nitros9.org> Emile van Bergen wrote: > Are you being serious? You're *seriously* claiming each item follows > from the previous one? I would prefer that you discuss the content of my message, rather than the manner in which it was presented. That would be much more productive. > I think you missed Bernard's line that shopping lists make bad design > documents. You seem to try and distill requirements from every shopping > list item that has ever floated here. No. I started with the two scenairos as stated in my message. The first requirement (C1) followed from that. You haven't presented concrete objections to that, or any of the other statements. > So, if we FIRST get a SHORT list of real world problems that are > currently fundamentally impossible to solve due to lack of information > at the client or server AND clearly describe the decision that cannot be > made correctly due to the lacking information, My message did so. You haven't responded to it. I think part of the problem here is that we're talking at cross purposes. I've been reading the different posts, and trying to distill a common set of scenarios. I presented those, and some requirements in my post. Rather than address those, you've responded with your own set of requirements. If the conversation is going to be nothing more than people presenting what they want, and ignoring what other people say, I don't see any point in continuing. > Can we please, pretty please, get clarity about this? Do you, others, > agree that these are the only two real problems related to missing > information at either client or server side? Since you ignored my requirement statement, I'm not sure how my addressing yours would move the discussion forward. Alan DeKok. -- 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, 20 Oct 2005 16:07:51 +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: Capabilities: Moving forward - to the problem, please Date: Thu, 20 Oct 2005 12:08:21 -0400 Message-ID: Thread-Topic: Capabilities: Moving forward - to the problem, please Thread-Index: AcXVWqPWsB7xXiYLTxevW3/pz7DNJgANMrCQ From: "Avi Lior" To: "Emile van Bergen" , "Alan DeKok" Cc: , "Bernard Aboba" There are a minimum of three cases - all of which have been evident in recent work: A) One from Prepaid. B) One from Geopriv. C) One from CUI.=20 A) The AAA server needs to know what the NAS supports so that it can send the appropriate authorization attributes to the NAS or take other action (make adjustments). B) The AAA server needs to obtain some information form the NAS inorder to correctly authenticate and properly authorize the user session. C) The NAS needs some information from the AAA-Server inorder to satsify some business relationship requirements. Also I don't think your GEOPRIV is statement is stated correctly. It's the AAA server that needs the information, the NAS could careless. There are also other requiremetns that we cant forget and that is that we want to make sure that we don't use excessive messages to achieve these goals. So how about the above as a concise package of requirements...... > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Emile van Bergen > Sent: Thursday, October 20, 2005 5:39 AM > To: Alan DeKok > Cc: radiusext@ops.ietf.org; Bernard Aboba > Subject: Re: Capabilities: Moving forward - to the problem, please >=20 > Alan, >=20 > Are you being serious? You're *seriously* claiming each item=20 > follows from the previous one? >=20 > I think you missed Bernard's line that shopping lists make=20 > bad design documents. You seem to try and distill=20 > requirements from every shopping list item that has ever floated here. >=20 > I've understood Bernard's call for concentrating on "The=20 > Problem" as a request to weed out the ones that have real=20 > substance, in my mind the problems that fundamentally require=20 > information at either the client or server side that's=20 > currently missing. The ones where no implementation can=20 > currently behave correctly. >=20 > So, if we FIRST get a SHORT list of real world problems that=20 > are currently fundamentally impossible to solve due to lack=20 > of information at the client or server AND clearly describe=20 > the decision that cannot be made correctly due to the lacking=20 > information, we can THEN worry about where the information=20 > must come from, next about when it should be provided, and=20 > lastly how it should be represented on the wire. >=20 > So far, I've seen only two: >=20 > * A NAS that cannot decide what information it is allowed to=20 > put in the > access request because it first needs information about the user > (GEOPRIV); >=20 > * A server that cannot decide what information it must put in its > access accept, or whether to send an accept at all, because it does > not know if the NAS will act upon a set of session limiting > attributes deemed critical by the server ('prepaid'). >=20 > Can we please, pretty please, get clarity about this? Do you,=20 > others, agree that these are the only two real problems=20 > related to missing information at either client or server side? >=20 > Cheers, >=20 >=20 > Emile. >=20 > On Wed, Oct 19, 2005 at 07:26:40PM -0400, Alan DeKok wrote: >=20 > > "Bernard Aboba" wrote: > > > Rather, the hallmark of a good problem statement is=20 > brevity, leading=20 > > > to solutions which do what is necessary and little more. > >=20 > > << 10-20 attempts later >> > >=20 > > The server cannot send Access-Accept in some cases unless=20 > it is sure=20 > > that the NAS will behave appropriately (i.e. prepaid). Otherwise,=20 > > services may be offered, but not billed to someone. > >=20 > > The server cannot send Access-Challenge to the NAS, because it=20 > > doesn't know if the NAS will treat that as Access-Reject, or as=20 > > extended capability negotiation. > >=20 > > Therefore, the ONLY requirement that matters here is the=20 > first one=20 > > listed below. Later capabilites are follow-ons from it. These=20 > > requirements also avoid the issue raised on the capability=20 > draft of a=20 > > NAS "rejecting" a response from a server, which can't happen in=20 > > RADIUS. > >=20 > > C1: For new capabilities, Access-Request MUST ALWAYS contain a > > capability advertisement. > >=20 > > For efficiency, and to avoid unecessary Access-Challenge: > >=20 > > C2: The advertisement MUST include advertisement of all > > capabilities > >=20 > > For GEOPRIV and related issues: > >=20 > > C3: The advertisement MAY include data for only some of the > > capabilities (i.e. location capability, but no=20 > location data) > >=20 > > To later get GEOPRIV location data: > >=20 > > C4: The advertisement MUST include indication of support for > > Access-Challenge responses to Access-Request with PAP. > >=20 > > To deal with mandatory and requested capabilities: > >=20 > > C5: The advertisement implementation MUST support both mandatory > > and requested capabilities. > >=20 > > To deal with server's capabilities: > >=20 > > C6: A server MUST be able to send capabilities, just like a NAS > >=20 > > To deal with backwards compatibilty: > >=20 > > C7: A server MUST NOT send capability advertisement to a NAS > > if the Access-Request did not contain a capability=20 > advertisement > > (modulo EAP, etc, where capabilities can be cached=20 > per-session, > > and therefore don't have to be sent in each packet) > >=20 > > To deal with information leak: > >=20 > > C8: A server MUST NOT advertise to a NAS that the=20 > server is capable > > of services that the NAS did not advertise as being=20 > mandatory > > or requested > >=20 > > To ensure security: > >=20 > > C9: A server MUST send an Access-Reject if a capability it deems > > mandatory is not advertised by the NAS. > >=20 > > To help with debugging: > >=20 > > C10: A server MAY advertise mandatory capabilities in=20 > an Access-Reject, > > as a hint to the NAS about why the request was rejected. > >=20 > > To deal with per-capability data (also see C4). > >=20 > > C11: The capability negotiation MUST include support for > > per-capability data. > >=20 > > To deal with the content of the data: > >=20 > > C12: The capability negotiation MUST include the ability for > > the server to indicate to the NAS that the data supplied is > > inadequate or improper. > >=20 > > To deal with proxying: > >=20 > > C13: Packets containing capability advertisements MAY be proxied > >=20 > > To deal with proxy security: > >=20 > > C14: Proxied Access-Request packets MUST have their capability > > advertisements updated with the intersection of=20 > capabilities > > of the NAS and the proxying server. (i.e. the NAS supports > > CoA, but the proxy doesn't) > >=20 > > To deal with proxying by servers unaware of new capabilities: > >=20 > > C15: Capabilities MUST be validated per-hop. > > e.g. signed, or containing information that will not be > > updated by a capability un-aware proxy > >=20 > > Comments? Did anyone read this far? > >=20 > > That's all I have for now. I think it covers a lot of=20 > the problem=20 > > space and discussion. > >=20 > > Alan DeKok. > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: >=20 > --=20 > E-Advies - Emile van Bergen emile@e-advies.nl =20 > tel. +31 (0)78 6136282 http://www.e-advies.nl =20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Thu, 20 Oct 2005 09:39:56 +0000 Date: Thu, 20 Oct 2005 11:39:11 +0200 From: Emile van Bergen To: Alan DeKok Cc: radiusext@ops.ietf.org, Bernard Aboba Subject: Re: Capabilities: Moving forward - to the problem, please Message-ID: <20051020093911.GB3689@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , radiusext@ops.ietf.org, Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Alan, Are you being serious? You're *seriously* claiming each item follows from the previous one? I think you missed Bernard's line that shopping lists make bad design documents. You seem to try and distill requirements from every shopping list item that has ever floated here. I've understood Bernard's call for concentrating on "The Problem" as a request to weed out the ones that have real substance, in my mind the problems that fundamentally require information at either the client or server side that's currently missing. The ones where no implementation can currently behave correctly. So, if we FIRST get a SHORT list of real world problems that are currently fundamentally impossible to solve due to lack of information at the client or server AND clearly describe the decision that cannot be made correctly due to the lacking information, we can THEN worry about where the information must come from, next about when it should be provided, and lastly how it should be represented on the wire. So far, I've seen only two: * A NAS that cannot decide what information it is allowed to put in the access request because it first needs information about the user (GEOPRIV); * A server that cannot decide what information it must put in its access accept, or whether to send an accept at all, because it does not know if the NAS will act upon a set of session limiting attributes deemed critical by the server ('prepaid'). Can we please, pretty please, get clarity about this? Do you, others, agree that these are the only two real problems related to missing information at either client or server side? Cheers, Emile. On Wed, Oct 19, 2005 at 07:26:40PM -0400, Alan DeKok wrote: > "Bernard Aboba" wrote: > > Rather, the hallmark of a good problem statement is brevity, leading to > > solutions which do what is necessary and little more. > > << 10-20 attempts later >> > > The server cannot send Access-Accept in some cases unless it is sure > that the NAS will behave appropriately (i.e. prepaid). Otherwise, > services may be offered, but not billed to someone. > > The server cannot send Access-Challenge to the NAS, because it > doesn't know if the NAS will treat that as Access-Reject, or as > extended capability negotiation. > > Therefore, the ONLY requirement that matters here is the first one > listed below. Later capabilites are follow-ons from it. These > requirements also avoid the issue raised on the capability draft of a > NAS "rejecting" a response from a server, which can't happen in > RADIUS. > > C1: For new capabilities, Access-Request MUST ALWAYS contain a > capability advertisement. > > For efficiency, and to avoid unecessary Access-Challenge: > > C2: The advertisement MUST include advertisement of all > capabilities > > For GEOPRIV and related issues: > > C3: The advertisement MAY include data for only some of the > capabilities (i.e. location capability, but no location data) > > To later get GEOPRIV location data: > > C4: The advertisement MUST include indication of support for > Access-Challenge responses to Access-Request with PAP. > > To deal with mandatory and requested capabilities: > > C5: The advertisement implementation MUST support both mandatory > and requested capabilities. > > To deal with server's capabilities: > > C6: A server MUST be able to send capabilities, just like a NAS > > To deal with backwards compatibilty: > > C7: A server MUST NOT send capability advertisement to a NAS > if the Access-Request did not contain a capability advertisement > (modulo EAP, etc, where capabilities can be cached per-session, > and therefore don't have to be sent in each packet) > > To deal with information leak: > > C8: A server MUST NOT advertise to a NAS that the server is capable > of services that the NAS did not advertise as being mandatory > or requested > > To ensure security: > > C9: A server MUST send an Access-Reject if a capability it deems > mandatory is not advertised by the NAS. > > To help with debugging: > > C10: A server MAY advertise mandatory capabilities in an Access-Reject, > as a hint to the NAS about why the request was rejected. > > To deal with per-capability data (also see C4). > > C11: The capability negotiation MUST include support for > per-capability data. > > To deal with the content of the data: > > C12: The capability negotiation MUST include the ability for > the server to indicate to the NAS that the data supplied is > inadequate or improper. > > To deal with proxying: > > C13: Packets containing capability advertisements MAY be proxied > > To deal with proxy security: > > C14: Proxied Access-Request packets MUST have their capability > advertisements updated with the intersection of capabilities > of the NAS and the proxying server. (i.e. the NAS supports > CoA, but the proxy doesn't) > > To deal with proxying by servers unaware of new capabilities: > > C15: Capabilities MUST be validated per-hop. > e.g. signed, or containing information that will not be > updated by a capability un-aware proxy > > Comments? Did anyone read this far? > > That's all I have for now. I think it covers a lot of the problem > space and discussion. > > Alan DeKok. > > -- > 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: -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 19 Oct 2005 23:24:27 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward Cc: "Bernard Aboba" Date: Wed, 19 Oct 2005 19:26:40 -0400 Message-Id: <20051019232640.D1B1D16DD6@mail.nitros9.org> "Bernard Aboba" wrote: > Rather, the hallmark of a good problem statement is brevity, leading to > solutions which do what is necessary and little more. << 10-20 attempts later >> The server cannot send Access-Accept in some cases unless it is sure that the NAS will behave appropriately (i.e. prepaid). Otherwise, services may be offered, but not billed to someone. The server cannot send Access-Challenge to the NAS, because it doesn't know if the NAS will treat that as Access-Reject, or as extended capability negotiation. Therefore, the ONLY requirement that matters here is the first one listed below. Later capabilites are follow-ons from it. These requirements also avoid the issue raised on the capability draft of a NAS "rejecting" a response from a server, which can't happen in RADIUS. C1: For new capabilities, Access-Request MUST ALWAYS contain a capability advertisement. For efficiency, and to avoid unecessary Access-Challenge: C2: The advertisement MUST include advertisement of all capabilities For GEOPRIV and related issues: C3: The advertisement MAY include data for only some of the capabilities (i.e. location capability, but no location data) To later get GEOPRIV location data: C4: The advertisement MUST include indication of support for Access-Challenge responses to Access-Request with PAP. To deal with mandatory and requested capabilities: C5: The advertisement implementation MUST support both mandatory and requested capabilities. To deal with server's capabilities: C6: A server MUST be able to send capabilities, just like a NAS To deal with backwards compatibilty: C7: A server MUST NOT send capability advertisement to a NAS if the Access-Request did not contain a capability advertisement (modulo EAP, etc, where capabilities can be cached per-session, and therefore don't have to be sent in each packet) To deal with information leak: C8: A server MUST NOT advertise to a NAS that the server is capable of services that the NAS did not advertise as being mandatory or requested To ensure security: C9: A server MUST send an Access-Reject if a capability it deems mandatory is not advertised by the NAS. To help with debugging: C10: A server MAY advertise mandatory capabilities in an Access-Reject, as a hint to the NAS about why the request was rejected. To deal with per-capability data (also see C4). C11: The capability negotiation MUST include support for per-capability data. To deal with the content of the data: C12: The capability negotiation MUST include the ability for the server to indicate to the NAS that the data supplied is inadequate or improper. To deal with proxying: C13: Packets containing capability advertisements MAY be proxied To deal with proxy security: C14: Proxied Access-Request packets MUST have their capability advertisements updated with the intersection of capabilities of the NAS and the proxying server. (i.e. the NAS supports CoA, but the proxy doesn't) To deal with proxying by servers unaware of new capabilities: C15: Capabilities MUST be validated per-hop. e.g. signed, or containing information that will not be updated by a capability un-aware proxy Comments? Did anyone read this far? That's all I have for now. I think it covers a lot of the problem space and discussion. Alan DeKok. -- 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, 19 Oct 2005 21:40:52 +0000 Date: Wed, 19 Oct 2005 23:40:06 +0200 From: Emile van Bergen To: Avi Lior Cc: Alan DeKok , radiusext@ops.ietf.org Subject: Re: Capabilities: Summary - refined proposal Message-ID: <20051019214006.GA3793@note.evbergen.xs4all.nl> Mail-Followup-To: Avi Lior , Alan DeKok , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Oct 19, 2005 at 12:06:58PM -0400, Avi Lior wrote: > Alan and Emile see below: > > First of all you are advertizing but you are advertizing one capability. > > But the affect of doing what you suggest is to force a challenge > everytime. This is problematic since we try to reduce the number of > messages exchanged. > > Consider the prepaid case. Here the AAA-Server will need to send > attributes to the NAS to control the session. Simply sending the > prepaid attributes to the NAS could result in giving the user free > service. Since a NAS that does not understand the attributes will > simply ignore them. > > In the scheme proposed above the AAA-Server will always have to > challenge for the NAS to see if it supports Prepaid. So for the > millions of prepaid users that attempt to login we will have to send > millions of extra messages. > > In our proposal the NAS will simply indicate right up front whether it > supports prepaid or not. Saving millions of messages a day. I am not addressing prepaid here. Service limiting attributes are another discussion. Please see my post to the 'Problem statement' thread. > I strongly encourage all of us to be mindful of sending extra messages > because in large deployements this makes a big difference. What makes you think we're not? "Won't somebody please mind the roundtrips!" is getting, frankly, a bit repetitive. > Yes but your proposal requires extra messaging. And I think you are > being over dramatic about an infitie list of implementations to manage. My proposal is about the case where the NAS withholds information from the initial access request, for privacy reasons. I'm talking about GEOPRIV and related things, NOT prepaid. In the case of GEOPRIV, and we've been at this at length, the case of service being dependent on Location information CANNOT be implemented in a single round trip AT ALL, because the NAS first needs to be informed of the user's privacy policy -- in short, whether or not that NAS is allowed to send the user's Location at all. > > > The above proposal should keep all of the capability > > exchange within > > > the current RADIUS data model, and won't require a new bit-array. > > I don't see this. You still need to define attributes for each > capability. For example, you need to define an attribute for > Location-Required this is wasteful in two aspects: > 1) It is wasteful on the attribute space (which is limited) > 2) It is wasteful in the space required in the RADIUS messages. > 3) And back to your IANA issue, IANA still needs to manage a potentially > infinite number of attributes for this feature. In my proposal, and that was the 'refinement' you were replying to, there is no potentially infinite list of challenge cause attributes, because that has other problems (the NAS ignoring attributes it does not know about). See the mail you replied to. Rather, there is a /single/ Challenge-Cause attribute with a potentially 'infinite' list of values. There are 4294967296 challenge causes available, so I don't see the number space as a problem. > So while it works -- I don't think this is a better apporach then what > we have been proposing. Alan's first attempt may not be, and it does not address mandatory session limiting (can we please talk about that instead of including a whole range of other issues by reference to the prepaid draft), but the current proposal does solve GEOPRIV, in a generic way that also solves other issues /that would already need challenges anyway/. The best way to implement mandatory session limiting attributes is still to be discussed, however, let's try to get agreement on the problem statements first. It would be a good start if you'd separate the two issues of GEOPRIV and Prepaid. They have entirely different problem statements. I believe Bernard suggested we get the problems clearly enumerated and defined first, and then come up with precise, targeted solutions that are also as generic as possible. A proposed solution may, may cover both problems, but we're not nearly there yet. Few seem to have joined you in blessing the original capabilities advertising draft as a candidate for a solution that even reaches the required level of precision and generality. To do so is premature, and it would help if you didn't keep pounding on it. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 19 Oct 2005 16:06:31 +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: Capabilities: Summary - refined proposal Date: Wed, 19 Oct 2005 12:06:58 -0400 Message-ID: Thread-Topic: Capabilities: Summary - refined proposal Thread-Index: AcXUlxIMiU6a1NIxRLWsZ4jQZuXINQALb7Bg From: "Avi Lior" To: "Emile van Bergen" , "Alan DeKok" Cc: Alan and Emile see below:=20 > -----Original Message----- > From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl]=20 > Sent: Wednesday, October 19, 2005 6:22 AM > To: Alan DeKok > Cc: Avi Lior; radiusext@ops.ietf.org > Subject: Re: Capabilities: Summary - refined proposal >=20 > Alan, >=20 > On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote: >=20 > > The capability being advertised, then, isn't location, but "can=20 > > handled Access-Challenge responses to PAP, CHAP, MSCHAP requests". > >=20 > > Once an implementation supports that, any server can=20 > challenge the=20 > > client with "hints", as described above. A possible workflow is: > >=20 > > C -> S: Access-Request > > User-Name =3D foo > > User-Password =3D bar > > Capability =3D yes > > S -> C: Access-Challenge > > Require-Location =3D yes =20 > > State =3D abcd > > C -> S: Access-Request > > User-Name =3D foo > > User-Password =3D bar > > Capability =3D yes > > location =3D "moe's tavern" > > State =3D abcd > >=20 > > That proposal removes all of the functionality advertisement from=20 > > the capability exchange. I think the potentially infinite=20 > list of "I=20 > > support functionality foo" is the source of the disagreement. First of all you are advertizing but you are advertizing one capability. But the affect of doing what you suggest is to force a challenge everytime. This is problematic since we try to reduce the number of messages exchanged. =20 Consider the prepaid case. Here the AAA-Server will need to send attributes to the NAS to control the session. Simply sending the prepaid attributes to the NAS could result in giving the user free service. Since a NAS that does not understand the attributes will simply ignore them. In the scheme proposed above the AAA-Server will always have to challenge for the NAS to see if it supports Prepaid. So for the millions of prepaid users that attempt to login we will have to send millions of extra messages. In our proposal the NAS will simply indicate right up front whether it supports prepaid or not. Saving millions of messages a day. I strongly encourage all of us to be mindful of sending extra messages because in large deployements this makes a big difference. > > In most situations, one party or other other will care=20 > about 10% of=20 > > the advertised capabilities, meaning the other 90% are irrelevant. > > And having a potentially infinite list is problematic for=20 > > implementations to manage, to say nothing of IANA. Yes but your proposal requires extra messaging. And I think you are being over dramatic about an infitie list of implementations to manage. > > The above proposal should keep all of the capability=20 > exchange within=20 > > the current RADIUS data model, and won't require a new bit-array. I don't see this. You still need to define attributes for each capability. For example, you need to define an attribute for Location-Required this is wasteful in two aspects: 1) It is wasteful on the attribute space (which is limited) 2) It is wasteful in the space required in the RADIUS messages. 3) And back to your IANA issue, IANA still needs to manage a potentially infinite number of attributes for this feature. > > Comments? Does this match your needs? So while it works -- I don't think this is a better apporach then what we have been proposing. -- 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, 19 Oct 2005 10:21:52 +0000 Date: Wed, 19 Oct 2005 12:21:31 +0200 From: Emile van Bergen To: Alan DeKok Cc: Avi Lior , radiusext@ops.ietf.org Subject: Re: Capabilities: Summary - refined proposal Message-ID: <20051019102130.GA3948@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , Avi Lior , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Alan, On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote: > The capability being advertised, then, isn't location, but "can > handled Access-Challenge responses to PAP, CHAP, MSCHAP requests". > > Once an implementation supports that, any server can challenge the > client with "hints", as described above. A possible workflow is: > > C -> S: Access-Request > User-Name = foo > User-Password = bar > Capability = yes > S -> C: Access-Challenge > Require-Location = yes > State = abcd > C -> S: Access-Request > User-Name = foo > User-Password = bar > Capability = yes > location = "moe's tavern" > State = abcd > > That proposal removes all of the functionality advertisement from > the capability exchange. I think the potentially infinite list of "I > support functionality foo" is the source of the disagreement. > > In most situations, one party or other other will care about 10% of > the advertised capabilities, meaning the other 90% are irrelevant. > And having a potentially infinite list is problematic for > implementations to manage, to say nothing of IANA. > > The above proposal should keep all of the capability exchange within > the current RADIUS data model, and won't require a new bit-array. > > Comments? Does this match your needs? I think this is an excellent idea, but a problem arises where a NAS does support the 'Capability = Yes' (or more accurately, 'Challenge-Supported = Yes') scheme, but does not understand the particular cause for the challenge, which may be given in the challenge by an attribute or value it does not know about. If you create a generic mechanism for NASes to indicate their support for challenges for more information, then at some point NASes will exist that support the generic mechanism, but not the particular challenge cause. In your example, they will send Capability = Yes, but will not understand the Require-Location attribute and therefore ignore it. So, the question is what a NAS should do when it is challenged for something it does not know about or something it does not have for that particular session. It should definitely not reject, otherwise we're back to square one. My suggestion is that instead of a scheme-dependent and potentially unknown response attribute, a single response attribute must be used to describe the challenge cause, one that MUST be supported if Challenge-Supported = Yes is sent. The semantics for Challenge-Cause would be that *if and only if* a NAS sent Challenge-Supported, *and* it sees Challenge-Cause *and* it does not understand its value (eg. Location-Required), the NAS MUST repeat its initial access request (adding the received State and updating Authenticator and Id as per RFC 2865, of course), *without prompting the user*. This is quite specific, but it only has to be defined in a single document describing NAS inquiries using these two attributes, and does not require any retroactively updated behaviour to operate smoothly in a heterogenous environment. Note that a NAS that sends Challenge-Supported = Yes cannot always resend its access request if it does not understand from the response packet why it was challenged, because it needs to distinguish a challenge for information it does not have (resend as-is) from a classic one time password challenge (prompt user first). Hence Challenge-Cause. It also helps debugging by server administrators, I guess. When seeing State in an authentication request that still lacks the wanted information, the server can conclude that it won't get anymore information than it just got, and that it will have to make its decision based on what it has (modulo unfinished EAP conversations, of course). The server will only have to be careful to avoid sending a challenge for the missing information if the presence of State indicates that the challenge has already been done, to prevent endless ping-pongs. However, I think that with this addition, your idea completely solves the 'unknown NAS may withhold needed information' issue as present in GEOPRIV, and also paves an excellent way for future authentication or authorisation schemes that require tentative challenges. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 19 Oct 2005 08:37:45 +0000 Date: Wed, 19 Oct 2005 10:37:11 +0200 From: Emile van Bergen To: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward Message-ID: <20051019083710.GD3717@note.evbergen.xs4all.nl> Mail-Followup-To: Bernard Aboba , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sorry for following up to myself, but I made a few typo's that may cause confusion. On Wed, Oct 19, 2005 at 10:18:45AM +0200, Emile van Bergen wrote: > The rationale for a capabilities advertising capability in this > scenario is as follows: > > - A server needs to know in advance how the NAS will respond to a insert 'challenge' > for the withheld information, because a NAS may not support > challenges, causing premature rejection of the user per RFC 2685 > section 4.4 ([44]), or it may misunderstand the reason for the > challenge, causing other unintended behaviour. > > To expand on this, according to [44], a NAS that supports PAP but > that is not willing or able to forward the challenge in the of replace 'the of' with 'the form of a' > Reply-Message to the user, MUST treat the Access-Challenge as an > Access-Reject. A NAS that supports classic challenges for PAP > requests to implement one time passwords, would effectively forward > the challenge to the user, which is not intended here. [skipping] > 2. The second problem: some server policies require an Access-Accept insert 'to be' > conditional on the NAS' support for certain session limiting > attributes, and on the proxy chain's transparency for them. Thanks, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 19 Oct 2005 08:19:27 +0000 Date: Wed, 19 Oct 2005 10:18:45 +0200 From: Emile van Bergen To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Capabilities: Moving forward Message-ID: <20051019081844.GA3717@note.evbergen.xs4all.nl> Mail-Followup-To: Bernard Aboba , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Bernard, others, On Mon, Oct 17, 2005 at 09:14:15PM -0700, Bernard Aboba wrote: > After dozens and dozens of messages, there is very little to show for the > discussion of Capabilities Solutions, so it's time to take a step backward > and focus for a while on The Problem. Let's all take a breather from > solution discussions for a while. > > I'd note that we've taken this approach before in RADEXT WG, with > encouraging results. Discussion on the CUI document seemed hopelessly > wedged until we were able to focus on the problem statement, which turned > out to be relatively straight forward. > > A good problem statement is not just the union of all possible needs; > shopping lists make poor design documents. Rather, a good problem > statement seeks to get at the one or two core issues, which, if addressed, > will enable solution of mutiple important problems. > > As a result, the goal in coming up with a problem statement is not to > enumerate every possible corner condition and scenario, regardless of > relevance; doing so will merely drive the development of as complex and > unwieldly a solution as possible. > > Rather, the hallmark of a good problem statement is brevity, leading to > solutions which do what is necessary and little more. This is an excellent idea, and I'd be happy to provide a kickoff. >From the earlier exchanges here, I see two non-imaginary problems for which a form of capabilities advertising has been proposed. 1. A NAS may withhold information required for proper authorization from its access requests, because it is only allowed to provide that information after some indication from the server. (Case in point: GEOPRIV, where a NAS is only allowed to provide Location information if the RADIUS server indicates that the user allows that information to be transmitted; at all, or specifically from the specific NAS, RADIUS client or combination thereof). The problem is that a server that intends to make its response dependent on the initially withheld information cannot unconditionally challenge the NAS for it. (Note that this scenario only applies if the server's response to the Access-Request packet is in any way dependent on the information that's initially withheld. If only the sending of the information in accounting requests is to be controlled, the indication to allow sending it can simply be put in the Access-Accept). The rationale for a capabilities advertising capability in this scenario is as follows: - A server needs to know in advance how the NAS will respond to a for the withheld information, because a NAS may not support challenges, causing premature rejection of the user per RFC 2685 section 4.4 ([44]), or it may misunderstand the reason for the challenge, causing other unintended behaviour. To expand on this, according to [44], a NAS that supports PAP but that is not willing or able to forward the challenge in the of Reply-Message to the user, MUST treat the Access-Challenge as an Access-Reject. A NAS that supports classic challenges for PAP requests to implement one time passwords, would effectively forward the challenge to the user, which is not intended here. The required semantics for a capability advertisement capability in this scenario is that a NAS indicates: a. that it supports a challenge for withheld information, using a mutually understood mechanism for the server to identify the wanted information (eg. GEOPRIV information) b. the list of withheld information elements (eg. GEOPRIV Location attributes) -- it makes no sense to create this capability for one feature alone. (But on the other hand, I cannot think of any other case that desires that the NAS withholds available information from its initial access request). 2. The second problem: some server policies require an Access-Accept conditional on the NAS' support for certain session limiting attributes, and on the proxy chain's transparency for them. If the NAS and/or proxy chain are in an administrative domain that's different from the home AAA's, the home AAA has no way of knowing whether the NAS will implement a given session limit. This is a real world problem that I've had to deal with (if you're curious: the limited EUNet self-subscription accounts on Nokia 9110 communicators that would allow access through a large number of 3rd party dialup POPs, but only to access one particular web server. Ah, those were the days). Current examples of such session limiting attributes are packet filtering (Filter-Id and the new ones), bandwidth control (TBD), and volume capping attributes (currently vendor specific). An somewhat extensive analysis of this case has been posted earlier. The core issue here is that a response attribute filtering proxy must modify the NAS' advertisement in order for the advertisement to be correct when it is received by the home server. If advertising is be done using the well understood hints mechanism, response attribute filtering proxies are be required to reflect that in their request attribute filtering as well. The problem with that is that some attributes that a proxy may wish to filter from responses, cannot be filtered from Access-Requests. The most prominent case is User-Name, which may be present in responses to ask the NAS to change the User-Name to be used in accounting requests for the session. Many NASes support this, and some roaming contracts such as WISPr even require it. CUI or better use of Class may obsolete that practice, but both contracts with User-Name overwriting and NASes without CUI still exist. One point to add is that in the case of a server requiring certain Filter-Ids with certain names to be present, both the namespace (defining a name to semantics mapping) and the list of names will have to be advertised, in order for a NAS advertising its support for Filter-Id to be of any use. Modern server defined packet filters may be less problematic in this respect, but the advertising of values in addition to attributes may be required for other cases as well. A proposed mechanism should have provisions for that where that's required. It does not have to be complex, the hints mechanism eg. already allows a list of values to be sent by virtue of it using standard response A/V pairs in access requests. Of course, a well mapped migration path is crucial for capabilities advertising to offer any help in solving either of these problems, and some of the proposals seem to assume a magic big bang update. I hope that was brief enough. It would be great if followup posts would tell me whether I've missed a real problem or whether I'm stating either of the two incorrectly. Best regards, Emile van Bergen. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 18 Oct 2005 20:09:00 +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: Call for RADEXT submissions and agenda items for IETF-64 Date: Tue, 18 Oct 2005 16:08:39 -0400 Message-ID: Thread-Topic: Call for RADEXT submissions and agenda items for IETF-64 Thread-Index: AcXUB96bjKZTlPRwQCGqBsitLGaVRAAF1fEg From: "Nakhjiri Madjid-MNAKHJI1" To: "Nelson, David" , Cc: Hi David, The following draft (an upcoming V02 is to be uploaded in a few days) is on its way to become a working group item in MIPv4 WG.=20 http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-01.txt I think early reviews by RADEXT will help us create a better spec even before it comes to RADEXT for formal review. It would be nice to have 3-5 minutes to bring this to RADEXT attention at the next meeting. Thanks, Madjid Nakhjiri -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David Sent: Tuesday, October 18, 2005 12:12 PM To: radiusext@ops.ietf.org Cc: aboba@internaut.com Subject: RE: Call for RADEXT submissions and agenda items for IETF-64 This is the second call for RADEXT WG agenda items. WG agendas are being posted now, and MUST be posted by October 31. To date, the chairs have received three agenda slot requests. Please don't wait until the last minute. > This is a general call for WG submissions and WG agenda items for the=20 > RADEXT session at IETF-64 in Vancouver. >=20 > Please reply to the chairs if you would like to make a presentation to the > RADEXT WG, including the subject mater, Internet-Draft URL, and requested > time allocation. >=20 > Note that for IETF-64 we have on-line WG agendas, updatable by the WG=20 > chairs, located on the IETF web site: > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 4 -- 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: Tue, 18 Oct 2005 19:36:21 +0000 Message-ID: <43554E8A.7060207@nokia.com> Date: Tue, 18 Oct 2005 22:35:38 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Nelson, David" CC: radiusext@ops.ietf.org Subject: Re: draft-ietf-radext-digest-auth-06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As far as I know version -06 is not available yet. The latest available version is -05, where the issue is still present. Once we have seen version -06 or a preliminary version I can comment. /Miguel Nelson, David wrote: > Does this resolve RADEXT Issue 138? > > >>The latest version of the draft does no longer contain a link between >>sips/https and >>RADIUS. However, the Security Considerations section names refusing >>sips/https request as one non-normative option to avoid the security >>level mismatch of sips/https and unencrypted RADIUS: >> >>"To prevent RADIUS from representing the weak link, a RADIUS >>client receiving an HTTP-style request via TLS or IPsec could use an >>equally secure connection to the RADIUS server. There are several >>ways to achieve this, for example: >> o the RADIUS client may reject HTTP-style requests received over > > TLS > >> or IPsec >> o the RADIUS client require that traffic be sent and received over >> IPsec. >>RADIUS over IPsec, if used, MUST conform to the requirements >>described in [RFC3579] section 4.2." > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- 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, 18 Oct 2005 18:37:44 +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: Capabilities: Moving forward Date: Tue, 18 Oct 2005 14:38:24 -0400 Message-ID: Thread-Topic: Capabilities: Moving forward Thread-Index: AcXTmq+i7tpvPE2CRMaUoNiOxwDCCwAc781g From: "Avi Lior" To: "Bernard Aboba" , Here is the motivation statement for capabilities exchange with some added text to provide further explanations. There is a need for a RADIUS server to discover capabilities of a NAS that has initiated a connection to it. =20 The RADIUS server may require that the NAS supports a particular RADIUS application. =20 For example, if the user being authenticated and authorized is a prepaid user, then the RADIUS needs to be assured that the NAS supports prepaid capabilities as defined in [I-D.lior-radius-prepaid- extensions]. =20 This is critical to correct operation. Because if the user is a prepaid user, then the AAA server will reply back to the NAS with authroization attributes that are designed to control the prepaid session (see the prepaid work). If the NAS does not support these attributes the NAS will simply ignore the attributes. This will result with the prepaid user getting free service. *** Whether or not a NAS supports a particular capability could impact if the user is allowed on the network; or which attributes are delivered and perhaps the value of those attributes; We therefore need a mechansim for the NAS to indicate with Applications it supports. *** =20 Similarly, the network may need to know whether or not the NAS supports a particular RADIUS feature such as Dymanic Authorization Extensions as defined in [RFC3576]. =20 This is more from an efficiency point of view and may also be required for correct operation. Using 3576 as an example. AAA server may wish to terminate a session. If it knows that the NAS does not support 3576 it can use Session-Timeout to have the NAS periodically re-authenticate and those can control to some degree when it will terminate the session. However, if it knows that the NAS supports 3576 DM messages then the AAA server knows it can count on the DM message to percisely disconnect the session. Not having this knowledge if the AAA assumed that it can use 3576 it will issue a DM message and the NAS which does not support 3576 would reply back with an ICMP message indicating that that port is not in use (or something like that). This is information is not useful since the user session has already been allocated and we just found out that the NAS does not support DM messages. The same scenario could be used to illustrate why its important to know that the NAS supports 3576 CoA messages. *** Knowing the that a NAS supports a particular feature is very helpful. It helps the AAA determine which features can be used to control the session. We therefore need a mechanism for the NAS to indicate which RADIUS features it supports *** In some cases, the NAS itself may also need to communicate that it requires that the RADIUS server deliver a particular capability. For example, the *NAS* may require that the server deliver the Chargeable User Identity attribute as defined in [I-D.ietf-radext- chargeable-user-id]. Here the NAS not only indicates that it can support the CUI but requests that the CUI *MUST* be provided otherwise it will reject the session. *** Having a way for the NAS to specify that the Server needs to provide it with some infomration is also useful. We therefore need a scheme to have the NAS indicate to the Server that it needs particular infomration. *** Similarly, the RADIUS server may require that the NAS deliver certain feature that the RADIUS server requires for the session. =20 For example, the network may require that the NAS deliver location information as defined by [I-D.ietf-geopriv-radius-lo] before it can authenticate the session. In this case it the NAS would advertize support for particular application or information. The NAS does not have to provide that information in the Access-Request. A RADIUS server can then subscribe to the particular information by challenging the NAS to provide the information.=20 The NAS should be able to request the information either during the initial authentication -- since the availablity of the information may determine whether or not the user is authenticated or whether or not the user will be provided with a certain capabilities. =20 **** We therefore need a scheme to have the NAS indicate what it supports and a scheme for RADIUS Server to request that the NAS provide that information. This needs to be provided for during the initial access-request or subsequently by using CoA etc... **** In summary: o The NAS to specify which capabilities it supports. o The NAS to specify which capabilities that are required to be delivered by the RADIUS server. o The RADIUS server to express the capabilities desired from the NAS. o The RADIUS server to express the capabilities that the RADIUS server requires from the NAS. NOTE: The End-to-End-Capability is different then the capability exchange defined in Base Diameter [RFC3588]. The purpose of the Diameter based capability exchange is support routing of Diameter messages. Whereas, the functionality defined by here is designed to ensure whether we can send an attribute or command or expect a behavior relating to this specific user's session. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, October 18, 2005 12:14 AM > To: radiusext@ops.ietf.org > Subject: Capabilities: Moving forward >=20 > >I do agree with Bernard that we first need to come to=20 > consensus on the=20 > >problem statement. I think your summary, quoted above, is one=20 > >reasonable candidate. >=20 > After dozens and dozens of messages, there is very little to=20 > show for the discussion of Capabilities Solutions, so it's=20 > time to take a step backward and focus for a while on The=20 > Problem. Let's all take a breather from solution discussions=20 > for a while. >=20 > I'd note that we've taken this approach before in RADEXT WG,=20 > with encouraging results. Discussion on the CUI document=20 > seemed hopelessly wedged until we were able to focus on the=20 > problem statement, which turned out to be relatively straight forward. >=20 > A good problem statement is not just the union of all=20 > possible needs; =20 > shopping lists make poor design documents. Rather, a good problem=20 > statement seeks to get at the one or two core issues, which,=20 > if addressed, will enable solution of mutiple important problems. >=20 > As a result, the goal in coming up with a problem statement=20 > is not to enumerate every possible corner condition and=20 > scenario, regardless of relevance; doing so will merely=20 > drive the development of as complex and unwieldly a solution=20 > as possible. >=20 > Rather, the hallmark of a good problem statement is brevity,=20 > leading to solutions which do what is necessary and little more. >=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: >=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: Tue, 18 Oct 2005 17:35:03 +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: Call for RADEXT submissions and agenda items for IETF-64 Date: Tue, 18 Oct 2005 13:34:49 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F035D92A4@ames.starentnetworks.com> Thread-Topic: Call for RADEXT submissions and agenda items for IETF-64 thread-index: AcXLa+8VtHRuUqFzRDGXPAyPSoueoAImsrsQAABzhUA= From: "Chowdhury, Kuntal" To: "Nelson, David" , Cc: Dear Chairs, I request for two slots the following drafts: 1. Proposed update to Framed-Compression attribute to support ROHC: http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribut es-00.txt This is a short draft, so a 5 mins slot will suffice. 2. RADIUS MIP6 support: The draft is not yet posted on the IETF I-D repository, but it was submitted before the deadline (on 16th Oct).=20 http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-00.txt Here is the abstract: A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document defines the new attributes to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. This information exchange may take place as part of the initial network access authentication procedure or as part of a separate protocol exchange between the mobile node, the home agent and the AAA infrastructure. ----------------------------------------------------------------- A 10 mins slot is requested for this one. Regards, Kuntal > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Nelson, David > Sent: Tuesday, October 18, 2005 12:12 PM > To: radiusext@ops.ietf.org > Cc: aboba@internaut.com > Subject: RE: Call for RADEXT submissions and agenda items for IETF-64 >=20 > This is the second call for RADEXT WG agenda items. WG agendas are > being posted now, and MUST be posted by October 31. To date, the chairs > have received three agenda slot requests. Please don't wait until the > last minute. >=20 > > This is a general call for WG submissions and WG agenda items for the > > RADEXT session at IETF-64 in Vancouver. > > > > Please reply to the chairs if you would like to make a presentation to > the > > RADEXT WG, including the subject mater, Internet-Draft URL, and > requested > > time allocation. > > > > Note that for IETF-64 we have on-line WG agendas, updatable by the WG > > chairs, located on the IETF web site: > > > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 4 >=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: "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- 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, 18 Oct 2005 17:27:27 +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: Conclusion of Pre-Work Item Review on Bandwidth Document Date: Tue, 18 Oct 2005 13:28:20 -0400 Message-ID: Thread-Topic: Conclusion of Pre-Work Item Review on Bandwidth Document Thread-Index: AcXTmUl4sJj0GN9bQyekpF82ycnNTgAb3L9g From: "Avi Lior" To: "Bernard Aboba" , Bernard, Please don't forget the other use cases for the bandwidth attributes as well. As you correctly pointed out on the bandwidth teleconference call recently these attributes are needed for features such as bandwidth on demand. We deploy these capabilities today in the field and we would like to see this simple bandwidth model standerdized. The sense of frustration amongst us is that we keep getting instruction from the WG to keep it simple and then to make it more complex. This has been going on for the last year. > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, October 18, 2005 12:03 AM > To: radiusext@ops.ietf.org > Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document >=20 > >[FA] It is not deployed because we just started seeing WMM/802.11e=20 > >(with admission control) capable APs coming to the market. >=20 > With all due respect, that is *not* what the industry is telling us. > Almost two years ago, the WFA standardized bandwidth=20 > attributes, but we were unable to locate any vendor who had=20 > implemented those attributes, nor any customer who had deployed them. >=20 > The reason why the attributes have not been deployed is *not*=20 > merely because of lack of hardware support, though that is=20 > certainly part of the issue. 802.11 vendors who already=20 > support 802.11 QoS schemes also have not implemented the=20 > specification, and do not plan to do so in the future,=20 > because the current specification does not provide=20 > functionality equivalent to what is already supported on their APs. >=20 > Similarly, switch vendors who have support IEEE 802.1Q also=20 > have not implemented the specification -- and have indicated=20 > that they also do not plan to implement it in the future. >=20 > The "good news" is that there does appear to be significant=20 > interest in the general concept of bandwidth limitation, and=20 > were the document to be modified to address the issues=20 > developed in the review, it seems likely that vendor interest=20 > would increase substantially. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Tue, 18 Oct 2005 17:22:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Issues 134 and 135 Date: Tue, 18 Oct 2005 13:21:45 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325FF@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issues 134 and 135 Thread-Index: AcXUCGJo5Nb3MN51TQOMLKpcgBgz5g== From: "Nelson, David" To: I have just today submitted -01 revisions of the I-Ds for IPv6 compatible RADIUS MIBs: draft-ietf-radext-rfc26nnbis-01.txt, where nn = =3D {18, 19, 20, 21}. The -01 revision addresses the issues described in RADEXT Issues 134 and 135. I will post another notice when the drafts are in the I-D repository. If anyone wishes "advance" copies for review, please contact me directly. -- 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, 18 Oct 2005 17:16:32 +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: Call for RADEXT submissions and agenda items for IETF-64 Date: Tue, 18 Oct 2005 13:12:18 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325FE@MAANDMBX2.ets.enterasys.com> Thread-Topic: Call for RADEXT submissions and agenda items for IETF-64 Thread-Index: AcXLa+8VtHRuUqFzRDGXPAyPSoueoAImsrsQ From: "Nelson, David" To: Cc: This is the second call for RADEXT WG agenda items. WG agendas are being posted now, and MUST be posted by October 31. To date, the chairs have received three agenda slot requests. Please don't wait until the last minute. > This is a general call for WG submissions and WG agenda items for the > RADEXT session at IETF-64 in Vancouver. >=20 > Please reply to the chairs if you would like to make a presentation to the > RADEXT WG, including the subject mater, Internet-Draft URL, and requested > time allocation. >=20 > Note that for IETF-64 we have on-line WG agendas, updatable by the WG > chairs, located on the IETF web site: > https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 4 -- 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, 18 Oct 2005 14:58:03 +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: draft-ietf-radext-digest-auth-06 Date: Tue, 18 Oct 2005 10:56:34 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F7@MAANDMBX2.ets.enterasys.com> Thread-Topic: draft-ietf-radext-digest-auth-06 Thread-Index: AcXTAqnEMeAK+ZU7SHu4c48a+JmThwA8VDsg From: "Nelson, David" To: Cc: Does this resolve RADEXT Issue 138? > The latest version of the draft does no longer contain a link between > sips/https and > RADIUS. However, the Security Considerations section names refusing > sips/https request as one non-normative option to avoid the security > level mismatch of sips/https and unencrypted RADIUS: >=20 > "To prevent RADIUS from representing the weak link, a RADIUS > client receiving an HTTP-style request via TLS or IPsec could use an > equally secure connection to the RADIUS server. There are several > ways to achieve this, for example: > o the RADIUS client may reject HTTP-style requests received over TLS > or IPsec > o the RADIUS client require that traffic be sent and received over > IPsec. > RADIUS over IPsec, if used, MUST conform to the requirements > described in [RFC3579] section 4.2." -- 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, 18 Oct 2005 04:14:25 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Capabilities: Moving forward Date: Mon, 17 Oct 2005 21:14:15 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I do agree with Bernard that we first need to come to consensus on >the problem statement. I think your summary, quoted above, is one >reasonable candidate. After dozens and dozens of messages, there is very little to show for the discussion of Capabilities Solutions, so it's time to take a step backward and focus for a while on The Problem. Let's all take a breather from solution discussions for a while. I'd note that we've taken this approach before in RADEXT WG, with encouraging results. Discussion on the CUI document seemed hopelessly wedged until we were able to focus on the problem statement, which turned out to be relatively straight forward. A good problem statement is not just the union of all possible needs; shopping lists make poor design documents. Rather, a good problem statement seeks to get at the one or two core issues, which, if addressed, will enable solution of mutiple important problems. As a result, the goal in coming up with a problem statement is not to enumerate every possible corner condition and scenario, regardless of relevance; doing so will merely drive the development of as complex and unwieldly a solution as possible. Rather, the hallmark of a good problem statement is brevity, leading to solutions which do what is necessary and little more. -- 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, 18 Oct 2005 04:04:00 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document Date: Mon, 17 Oct 2005 21:03:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[FA] It is not deployed because we just started seeing WMM/802.11e (with >admission control) capable APs coming to the market. With all due respect, that is *not* what the industry is telling us. Almost two years ago, the WFA standardized bandwidth attributes, but we were unable to locate any vendor who had implemented those attributes, nor any customer who had deployed them. The reason why the attributes have not been deployed is *not* merely because of lack of hardware support, though that is certainly part of the issue. 802.11 vendors who already support 802.11 QoS schemes also have not implemented the specification, and do not plan to do so in the future, because the current specification does not provide functionality equivalent to what is already supported on their APs. Similarly, switch vendors who have support IEEE 802.1Q also have not implemented the specification -- and have indicated that they also do not plan to implement it in the future. The "good news" is that there does appear to be significant interest in the general concept of bandwidth limitation, and were the document to be modified to address the issues developed in the review, it seems likely that vendor interest would increase substantially. -- 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, 18 Oct 2005 00:16:07 +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: Conclusion of Pre-Work Item Review on Bandwidth Document Date: Mon, 17 Oct 2005 17:11:31 -0700 Message-ID: Thread-Topic: RE: Conclusion of Pre-Work Item Review on Bandwidth Document thread-index: AcXTeH5PfF+PhYiJQ6SEV0qKxBEBRw== From: "Adrangi, Farid" To: Cc: Thanks! Please see my comments inline. Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Bernard Aboba > Sent: Saturday, October 08, 2005 8:42 PM > To: radiusext@ops.ietf.org > Subject: Conclusion of Pre-Work Item Review on Bandwidth Document >=20 > Just to clarify the status of the Bandwidth Document=20 > deployment review. >=20 > The reponses appear to indicate there is interest in=20 > standardization of > Bandwidth-related attributes, particularly within the switch community > (IEEE 802.1). >=20 > However, the deployment review also concluded that this=20 > community would > not deploy the document as it currently exists. >=20 > Also, review from the IEEE 802.11 community indicates that legacy APs > are not capable of carrying out Bandwidth Limitation as=20 > specified in the > document, due to hardware limitations. This explains why the existing > WFA-defined VSAs have not been deployed. >=20 [FA] It is not deployed because we just started seeing WMM/802.11e (with admission control) capable APs coming to the market. IMO, these attributes make sense only for WMM/802.11e (with admission control) capable APs deployed in public hotspots to provide QoS w/admission for real-time services -- e.g., VoIP. For example, When the QoS capable AP receives a TSPEC request from a client, the AP can decide whether to accept or reject the TSPEC based the bandwidth attributes or Profile ID received in the Access-Accept. =20 > However, newer APs that are capable of carrying out Bandwidth=20 > Limitation > have adopted more sophisticated VSAs, and as a result, these newer APs > would also not be likely to adopt the approach described in=20 > the existing > document. [FA] Can you name these new AP vendors supporting BW VSAs? Using VSAs will not promote interoperability -- I thought the interoperability was one of the key goals that we wanted to accomplish in this WG - no? >=20 > Based on the responses, the authors of the document are urged to > incorporate the comments from the switch and 802.11 AP communities in > order to develop a document that is likely to be deployed and > implemented. >=20 > Once that revision has been completed, and deployment=20 > feedback indicates > that the revision addresses industry/customer needs, the=20 > RADEXT WG will > once again consider the document for adoption as a RADEXT WG=20 > work item. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: >=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: Mon, 17 Oct 2005 15:25:39 +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: Capabilities complexity summary Date: Mon, 17 Oct 2005 11:26:43 -0400 Message-ID: Thread-Topic: Capabilities complexity summary Thread-Index: AcXQz8MgQsliOb6eRZqd5kluY1UgFgCXSVoQ From: "Avi Lior" To: "Bernard Aboba" , , Hi Bernard, =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, October 14, 2005 10:56 AM > To: radiusext@ops.ietf.org > Subject: Re: Capabilities complexity summary >=20 > >I think that Avi's point is that the desired result is *not*=20 > >Access-Reject in the particular scenario he describes: a roaming=20 > >consortium which contains none legacy, non-GEOPRIV NASes. The home=20 > >provider would *like* to use GEOPRIV information to authorize its=20 > >roaming customers, but doesn't want to risk annoying the customer by=20 > >denying any form of access when they happen to be roaming via a=20 > >non-home ISP that has legacy NASes. >=20 > It would appear to me that there are multiple ways to address=20 > this scenario without additional complexity. At least four=20 > potential solutions come to mind. >=20 > As has been pointed out, this problem would not exist if=20 > location information were made available in the=20 > Access-Request. It's not clear to me that the granularity of=20 > information required to make authorization decisions=20 > represents a legitimate privacy concern. >=20 > It's worth pointing out that RFC 2865 requires that an=20 > Access-Request contain at least one NAS identificaiton=20 > attribute: NAS-Identifier, NAS-IP-Address, or=20 > NAS-IPv6-Address. Therefore some location-relevant=20 > information is always present in an Access-Request. It is=20 > fairly routine=20 > for providers to include location information in the=20 > NAS-Identifier attribute, or to include a PTR RR in the DNS=20 > that maps the NAS-IP-Address to a city, state and country. =20 > For example, "4.68.127.109" has a PTR RR for=20 > "so-3-2-0.gar1.Seattle1.Level3.net". >=20 > Given this, it would seem that course-grained location=20 > information (e.g.=20 > information at the state/city level) could be included in the=20 > Access-Request by default without representing an additional=20 > privacy risk. You would think so but this has been discussed in Geopriv at length and they felt that knowning the IP address of the NAS does not compromize the user's location. Note I am crossposting to Geopriv so that they can respond to your assertion. =20 > There are also ways to address the issue that do not require=20 > sending location in the initial Access-Request. Since=20 > location is not required for initial authorization, an=20 > Access-Accept is sent requesting location. This=20 > allows the user to access the network. Location information, if=20 > available, is then sent within the Accounting-Request and may=20 > be stored for the duration of the session. But what if an Authorization to use the network requires location information? =20 > Access to location services can then be made available by one=20 > of the following mechanisms: >=20 > 1. An application-specific request can then be sent for the=20 > location-aware services, which will be granted by a RADIUS=20 > server that has access to the location information sent in=20 > previous Accounting-Requests. =20 > 2. An RFC 3576 DAC can upgrade the user authorizations once=20 > location information is available. But what if I didn't want to authorize the user if I don't have location information? Or what if the NAS does not support 3576? =20 > 3. The original Access-Request can contain a Session-Timeout=20 > attribute, allowing re-authentication/re-authorization to=20 > occur once the location information has been made available. All of the above solution ignore the fact that we may need location information during authorization. In all the cases the user gets service while location is being sorted out. As well each method is complex requiring additional message exchanges and or schemes. I don't understand why you would suggest these schemes over the simplicity of Access-Request with an advertizement and Challenge mechanism. NAS --- Access-Request with indication to support location Server +---------------------------------------------------------->| | | | Acess-Challenge with request of location | |<----------------------------------------------------------| | Access-Request with Location Information | |---------------------------------------------------------->| | Access-Accept or Access-Reject | |<----------------------------------------------------------| Seems to me that the above callflow is pretty darn straightforward vs. the complexities of your proposals. =20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Mon, 17 Oct 2005 15:24:18 +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: Capabilities: Summary Date: Mon, 17 Oct 2005 11:22:58 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325F4@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXQXTEX5zTfI6YzQJ+/gu9rDEpRLgCzTZzQAACnTtA= From: "Nelson, David" To: Avi Lior writes... > Therefore, the conclusion that Farid and I came (and others) came to was > not to express capabilities as support for individual attributes but > rather as "features" and "modes" (I don't know how to express it). Then perhaps what is really needed is a single new attribute called Supported-Application-Environment which is an enumerated type, with an appropriate IANA registry. If SDOs, consortia, vendors and system operators can agree on a finite set of business scenarios or application environments (i.e. bundles of attributes, commands, and related values and feature support) they can name them. For example "3GPP2-Roaming-Feature-Set-One". Multiple instances of this attribute would be allowed in Access-request messages. The argument against this, of course, is that every consortia, vendor and system operator will want to create custom bundles of RADIUS behavior for their one "unique" environments and needs. I would like to suggest that the set of truly unique business scenarios is finite and fairly limited in number. Following the KISS philosophy, and resisting the urge to tweak and customize, I assert that this could be a viable solution. OTHO, I do agree with Bernard that we first need to come to consensus on the problem statement. I think your summary, quoted above, is one reasonable candidate. -- 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, 17 Oct 2005 15:07:33 +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: Capabilities: Summary Date: Mon, 17 Oct 2005 11:08:20 -0400 Message-ID: Thread-Topic: Capabilities: Summary Thread-Index: AcXQXTEX5zTfI6YzQJ+/gu9rDEpRLgCzTZzQ From: "Avi Lior" To: "Alan DeKok" , "Nelson, David" Cc: Alan, I don't think that Capabilities are always about support for a given attribute or attribute(s). Sometimes capabilities are about support for a feature like Disconnect Message or the ability to support change of authorization message. Note someone will surely remind me that a NAS that does not support DM or COA will respond negatively. But that "Negative" response comes after the fact --- after trying the command and way after authorizing the session. =20 In some cases we would like to know if the NAS supports these capabilities *during* authentication/authorization time. 3GPP2 for example have an VSA that communicates the NASes capability in an Access-Request. In other cases, it is not the support of the specific attribute but rather what type of values the attribute can take on. So its how the attribute is to be interpreted or assigned values. Therefore, the conclusion that Farid and I came (and others) came to was not to express capabilities as support for individual attributes but rather as "features" and "modes" (I don't know how to express it). =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Thursday, October 13, 2005 9:19 PM > To: Nelson, David > Cc: radiusext@ops.ietf.org > Subject: Re: Capabilities: Summary >=20 > "Nelson, David" wrote: > > This could be addressed by encapsulating the existing attributes in=20 > > the extended attribute format. >=20 > Ugh. >=20 > > > Or, *requested* information like location? > >=20 > > I wonder how many attributes will end up falling into this category? >=20 > Not many. See "hints" currently sent from NAS to server. >=20 > > I am operating under the impression that the Access-Challenge=20 > > mechanism was deemed to be a sufficient solution for the desired=20 > > attributes use cases. Is that not so? >=20 > Servers may offer limited services to clients that don't=20 > support Access-Challenge. Requiring Access-Challenge means=20 > offering *no* service to some clients, because they will=20 > treat it like Access-Reject. >=20 > > Well, yes, customers worry about functionality. OTOH, if=20 > we were to=20 > > communicate functionality, it would require a new IANA registry and=20 > > corresponding RFCs for each code point to define *exactly* what the=20 > > functionality was. The nice thing about attributes is that that (we > > expect) that the associated functionality is already well defined. >=20 > Yes. Which is why I proposed the "list of attributes"=20 > capability, which supports both client-server, and=20 > server-client exchanges, and the "mandatory versus requested"=20 > capability. >=20 > > > The mandatory bit in Diameter is nice, but I don't see it=20 > as being=20 > > > incredibly useful in deployments. > >=20 > > Given that Diameter interoperability is a charter requirement, what=20 > > does this say about the requirements for such a feature in RADIUS? >=20 > If we're extending RADIUS to have features diameter=20 > doesn't, then that would be a problem. >=20 > I'm not sure how Avi's deployment scenarios would work in Diameter. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Mon, 17 Oct 2005 10:31:18 +0000 Date: Mon, 17 Oct 2005 12:30:56 +0200 From: Emile van Bergen To: "wolfgang.beck01@t-online.de" Cc: radiusext@ops.ietf.org, aboba@internaut.com, miguel.an.garcia@nokia.com Subject: Re: draft-ietf-radext-digest-auth-06 Message-ID: <20051017103056.GB3858@note.evbergen.xs4all.nl> Mail-Followup-To: "wolfgang.beck01@t-online.de" , radiusext@ops.ietf.org, aboba@internaut.com, miguel.an.garcia@nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Mon, Oct 17, 2005 at 12:07:09PM +0200, wolfgang.beck01@t-online.de wrote: > The latest version of the draft does no longer contain a link between > sips/https and > RADIUS. However, the Security Considerations section names refusing > sips/https request as one non-normative option to avoid the security > level mismatch of sips/https and unencrypted RADIUS: > > "To prevent RADIUS from representing the weak link, a RADIUS > client receiving an HTTP-style request via TLS or IPsec could use an > equally secure connection to the RADIUS server. There are several > ways to achieve this, for example: > o the RADIUS client may reject HTTP-style requests received over TLS > or IPsec > o the RADIUS client require that traffic be sent and received over > IPsec. > RADIUS over IPsec, if used, MUST conform to the requirements > described in [RFC3579] section 4.2." s/weak/weakest, I guess? and I suggest another option: o the RADIUS traffic only passes networks secured by other means, eg. networks that are separated from the internet on the IP layer or below. Cheers, Emile -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- 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, 17 Oct 2005 10:07:43 +0000 MIME-Version: 1.0 Date: Mon, 17 Oct 2005 12:07:09 +0200 To: radiusext@ops.ietf.org Subject: draft-ietf-radext-digest-auth-06 Cc: aboba@internaut.com, miguel.an.garcia@nokia.com From: "wolfgang.beck01@t-online.de" Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <1ERRte-0ZvM9I0@fwd35.aul.t-online.de> The latest version of the draft does no longer contain a link between sips/https and RADIUS. However, the Security Considerations section names refusing sips/https request as one non-normative option to avoid the security level mismatch of sips/https and unencrypted RADIUS: "To prevent RADIUS from representing the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec could use an equally secure connection to the RADIUS server. There are several ways to achieve this, for example: o the RADIUS client may reject HTTP-style requests received over TLS or IPsec o the RADIUS client require that traffic be sent and received over IPsec. RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579] section 4.2." Wolfgang -- 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, 14 Oct 2005 14:55:59 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Capabilities complexity summary Date: Fri, 14 Oct 2005 07:55:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I think that Avi's point is that the desired result is *not* >Access-Reject in the particular scenario he describes: a roaming >consortium which contains none legacy, non-GEOPRIV NASes. The home >provider would *like* to use GEOPRIV information to authorize its >roaming customers, but doesn't want to risk annoying the customer by >denying any form of access when they happen to be roaming via a non-home >ISP that has legacy NASes. It would appear to me that there are multiple ways to address this scenario without additional complexity. At least four potential solutions come to mind. As has been pointed out, this problem would not exist if location information were made available in the Access-Request. It's not clear to me that the granularity of information required to make authorization decisions represents a legitimate privacy concern. It's worth pointing out that RFC 2865 requires that an Access-Request contain at least one NAS identificaiton attribute: NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address. Therefore some location-relevant information is always present in an Access-Request. It is fairly routine for providers to include location information in the NAS-Identifier attribute, or to include a PTR RR in the DNS that maps the NAS-IP-Address to a city, state and country. For example, "4.68.127.109" has a PTR RR for "so-3-2-0.gar1.Seattle1.Level3.net". Given this, it would seem that course-grained location information (e.g. information at the state/city level) could be included in the Access-Request by default without representing an additional privacy risk. There are also ways to address the issue that do not require sending location in the initial Access-Request. Since location is not required for initial authorization, an Access-Accept is sent requesting location. This allows the user to access the network. Location information, if available, is then sent within the Accounting-Request and may be stored for the duration of the session. Access to location services can then be made available by one of the following mechanisms: 1. An application-specific request can then be sent for the location-aware services, which will be granted by a RADIUS server that has access to the location information sent in previous Accounting-Requests. 2. An RFC 3576 DAC can upgrade the user authorizations once location information is available. 3. The original Access-Request can contain a Session-Timeout attribute, allowing re-authentication/re-authorization to occur once the location information has been made available. -- 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, 14 Oct 2005 07:27:32 +0000 Message-ID: <434F5DCA.8030408@nokia.com> Date: Fri, 14 Oct 2005 10:27:06 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "wolfgang.beck01@t-online.de" CC: radiusext@ops.ietf.org, bernard_aboba@hotmail.com Subject: Re: Issue 138 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Wolfgang. I think your proposed solution does not move in the direction where Bernard and me have been indicating: "the security of the RADIUS exchange is a somewhat orthogonal issue from the security of the HTTP/SIP Digest exchange." There are connections betweeen the secure URI (https or sips) and the presence/lack of security in the RADIUS interface. We indicated that ther is no such link. So, in my opinion, the issue is still open. /Miguel wolfgang.beck01@t-online.de wrote: > Proposed text in section "RADIUS Client Behavior": > "If all of the following conditions are true, the RADIUS client MUST > act as if it had sent an Access-Request and the RADIUS server had > rejected the credentials with an Access-Reject packet: > o the scheme in the digest-uri directive indicates a secure HTTP- > style connection (e.g. sip or https). > o the packets between RADIUS client and RADIUS server are not > protected with IPsec. > Under those conditions, a typical implementation would reject the > HTTP-style request." > > replaces: > "If the packets between RADIUS client and RADIUS server are not > protected with IPsec, the RADIUS client MUST NOT accept secured > connections (like https or sips) from its HTTP-style clients, so that > HTTP-style clients are not provided with a false sense of security." > > The Security Consideration section gives some additional explanations. > The section contains a part: > "There are two ways to achieve this: > o the RADIUS client may reject HTTP-style requests received over TLS > or IPsec > o the RADIUS client require that traffic be sent and received over > IPsec. > RADIUS over IPsec, if used, MUST conform to the requirements > described in [RFC3579] section 4.2. > > I think it's weak enough with respect to the "don't mandate SIP / HTTP > behaviour" requirement. > > > Wolfgang -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- 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, 14 Oct 2005 06:43:43 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Outcome of RADEXT WG Consensus call on draft-lior-radext-end-to-end-caps-01.txt Date: Thu, 13 Oct 2005 23:43:21 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is a summary of the RADEXT WG consensus call with respect to adoption of draft-lior-radext-end-to-end-caps-01.txt as a RADEXT WG work item. After analyzing the discussion on the RADEXT WG mailing list starting in January 2005 and going forward to the present time, it appears that there is NO CONSENSUS to adopt this document as a WG work item within the RADEXT WG. The mailing list discussion evidences both lack of consensus with respect to the problem statement, as well as the proposed solution to the problem. Since it is unlikely for consensus to be reached with respect to a solution without first coming to consensus about the problem statement, it is requested that short-term work focus on a problem statement document. Once the WG has come to consensus on a problem statement document, solutions to that problem statement will be solicited. -- 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, 14 Oct 2005 01:16:14 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Capabilities: Summary Cc: radiusext@ops.ietf.org Date: Thu, 13 Oct 2005 21:18:39 -0400 Message-Id: <20051014011839.965C316E0B@mail.nitros9.org> "Nelson, David" wrote: > This could be addressed by encapsulating the existing attributes in the > extended attribute format. Ugh. > > Or, *requested* information like location? > > I wonder how many attributes will end up falling into this category? Not many. See "hints" currently sent from NAS to server. > I am operating under the impression that the Access-Challenge mechanism > was deemed to be a sufficient solution for the desired attributes use > cases. Is that not so? Servers may offer limited services to clients that don't support Access-Challenge. Requiring Access-Challenge means offering *no* service to some clients, because they will treat it like Access-Reject. > Well, yes, customers worry about functionality. OTOH, if we were to > communicate functionality, it would require a new IANA registry and > corresponding RFCs for each code point to define *exactly* what the > functionality was. The nice thing about attributes is that that (we > expect) that the associated functionality is already well defined. Yes. Which is why I proposed the "list of attributes" capability, which supports both client-server, and server-client exchanges, and the "mandatory versus requested" capability. > > The mandatory bit in Diameter is nice, but I don't see it as being > > incredibly useful in deployments. > > Given that Diameter interoperability is a charter requirement, what does > this say about the requirements for such a feature in RADIUS? If we're extending RADIUS to have features diameter doesn't, then that would be a problem. I'm not sure how Avi's deployment scenarios would work in Diameter. Alan DeKok. -- 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, 13 Oct 2005 22:17:57 +0000 To: radiusext@ops.ietf.org cc: bernard_aboba@hotmail.com, Miguel.An.Garcia@nokia.com Subject: Issue 138 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2879.1129241584.1@big3> Date: Fri, 14 Oct 2005 00:13:04 +0200 From: wolfgang.beck01@t-online.de Message-ID: <1EQBOE-15rEHY0@fwd26.sul.t-online.de> Proposed text in section "RADIUS Client Behavior": "If all of the following conditions are true, the RADIUS client MUST act as if it had sent an Access-Request and the RADIUS server had rejected the credentials with an Access-Reject packet: o the scheme in the digest-uri directive indicates a secure HTTP- style connection (e.g. sip or https). o the packets between RADIUS client and RADIUS server are not protected with IPsec. Under those conditions, a typical implementation would reject the HTTP-style request." replaces: "If the packets between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients, so that HTTP-style clients are not provided with a false sense of security." The Security Consideration section gives some additional explanations. The section contains a part: "There are two ways to achieve this: o the RADIUS client may reject HTTP-style requests received over TLS or IPsec o the RADIUS client require that traffic be sent and received over IPsec. RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579] section 4.2. I think it's weak enough with respect to the "don't mandate SIP / HTTP behaviour" requirement. Wolfgang -- 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, 13 Oct 2005 21:24: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: RE: Capabilities: Summary Date: Thu, 13 Oct 2005 17:23:09 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325E8@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXQOF+wNW2suAsGQkmJRXhTqY8HmAAAd3Ig From: "Nelson, David" To: Alan DeKok writes... > Backwards compatibility in existing attributes being "mandatory" for > an implementation? Existing Vendor-Specific extensions that don't > have a mandatory bit? This could be addressed by encapsulating the existing attributes in the extended attribute format. > Or, *requested* information like location? I wonder how many attributes will end up falling into this category? That is to say, informative attributes that the server would like to see included in Access-Requests as hints to the authorization process. I am operating under the impression that the Access-Challenge mechanism was deemed to be a sufficient solution for the desired attributes use cases. Is that not so? I proposed the Mandatory bit to address the required (to be obeyed, feature to be implemented, service to be provided) attributes (server to client), not the required to be supplied attributes (client to server). > I don't think the issue is "required attribute support", so much as > "required and optional functionality support".=20 Well, yes, customers worry about functionality. OTOH, if we were to communicate functionality, it would require a new IANA registry and corresponding RFCs for each code point to define *exactly* what the functionality was. The nice thing about attributes is that that (we expect) that the associated functionality is already well defined. > The mandatory bit in Diameter is nice, but I don't see it as being > incredibly useful in deployments.=20 Given that Diameter interoperability is a charter requirement, what does this say about the requirements for such a feature in RADIUS? -- 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, 13 Oct 2005 20:55:24 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Capabilities: Summary Cc: radiusext@ops.ietf.org Date: Thu, 13 Oct 2005 16:57:46 -0400 Message-Id: <20051013205746.D37A416E0B@mail.nitros9.org> "Nelson, David" wrote: > What if we were to re-examine the extended RADIUS attribute format, > complete with a Mandatory bit? Could we then simplify the whole > capabilities issue down to detection of support for (a) Access-Challenge > and (b) Extended Attribute format? Backwards compatibility in existing attributes being "mandatory" for an implementation? Existing Vendor-Specific extensions that don't have a mandatory bit? Or, *requested* information like location? e.g. "If you have location, provide it, otherwise it's still OK". That appears to be the use-case Avi is addressing. A mandatory bit in an extended attribute doesn't support his use-case. Adding an "requested" bit does address it, though. You're then back to 2 bits per attribute, which is pretty much what Avi was suggesting in a different layout. To address your comments out of order: > While the syntax is concise, formal and parse-able, the overall level of > complexity to satisfy both clients and servers as to desired and > required attribute support is growing again. I don't think the issue is "required attribute support", so much as "required and optional functionality support". The mandatory bit in Diameter is nice, but I don't see it as being incredibly useful in deployments. Customers want functionality-based solutions, not attribute-based solutions. To that end, Avi's functionality-based capability draft addresses the problem directly. It's just the format and future concerns that concern me. If we focus on functionality support, two attributes would suffice: Mandatory-Functionality Requested-Functionality Make them enumerated int32's, and allow zero or more in Access-Request and Access-Challenge. Even allow them in Access-Reject, as a hint as to why the request was rejected. Start off with value 1 meaning "understands Access-Challenge for PAP, etc", and go on from there. This would be fully compatible with existing implementations, vendor-specific solutions, etc. The use cases Avi had in the end-to-end document looked like they would have a very limited number of functionality advertisements. So making them int32's versus bits would have little protocol impact. Alan DeKok. -- 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, 13 Oct 2005 17:29:22 +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: Capabilities: Summary Date: Thu, 13 Oct 2005 13:28:37 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325E5@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXQGKlyj1BRvXeUR5ilX7CZ0y1dvwAAhlMw From: "Nelson, David" To: Alan DeKok writes... > If this is satisfactory to the group, I'll write up something more > formal. While the syntax is concise, formal and parse-able, the overall level of complexity to satisfy both clients and servers as to desired and required attribute support is growing again. What if we were to re-examine the extended RADIUS attribute format, complete with a Mandatory bit? Could we then simplify the whole capabilities issue down to detection of support for (a) Access-Challenge and (b) Extended Attribute format? -- 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, 13 Oct 2005 17:08:16 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Capabilities: Summary Cc: radiusext@ops.ietf.org Date: Thu, 13 Oct 2005 13:10:45 -0400 Message-Id: <20051013171045.66C0816E0B@mail.nitros9.org> "Nelson, David" wrote: > Might I suggest one solution to this objection would be to create a > single new attribute called Required-Attribute, whose value is the > attribute ID of the required attribute. Zero or more instances of > Required-Attribute would be allowed in Access-Challenge messages. This was discussed earlier. We would also need to address the issue of required values. i.e. "Service-Type = foo" is required. And this wouldn't address functionality that requires multiple attributes, though one attribute could be used as a place-holder. My interest here is to get clarification of the requirements. If the sample exchange I gave satisfies the requirements, then that's a step forward. The next step is to determine what kinds of capabilities (or server-side hints) are needed. We could define an "attribute list" type, where the content would be a sequence of attribute numbers, possibly with VSA's in the vendor format. e.g. 0x50 Message-Authenticator 0x1a Vendor-Specific 0x00 00 00 09 Cisco 0x01 Cisco AVPair 0x1a Vendor-Specific 0x00 00 01 ad USR 0x00 00 00 66 Last number dialed out That would simple, clear, and wouldn't require IANA involvement. It would avoid the bitstrings of the current proposal, which scare me. We could then define: Necessary-Attributes of type "attribute number sequence" Requested-Attributes of type "attribute number sequence" I suggest "Necessary" rather than "required", because I can't think of another synonym for "requested". Having both "required" and "requests" is a recipe for confusion. We could so something similar for values. Extend the "attribute sequence list" idea by adding a 32-bit integer after each listed attribute. e.g. 0x06 Service-Type 0x00 00 00 0a Call Check 0x1a Vendor-Specific 0x00 00 01 ad USR 0x00 00 98 10 Bridging 0x00 00 00 02 disabled This proposal could take up more space than Avi's proposal, but it's clearer to parse and understand. And, it has the benefit that you can address capabilities directly by number, rather than giving a long string with one capability at the end. It also avoids the ACK problem I saw in the original proposal. There wasn't a way to ACK capabilities there, but in this proposal, the existing of an attribute is itself the ACK to the request. To get the functionality-based implementation that Avi suggested, we could add another attribute of type "enumeration": Supported-Functionality foo 1 bar 2 ... Which could be used as part of the above scheme to implement what Avi was suggesting. If this is satisfactory to the group, I'll write up something more formal. If Avi is OK with it, the text could go into the end-to-end capability draft. Alan DeKok. -- 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, 13 Oct 2005 16:14:11 +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: Capabilities: Summary Date: Thu, 13 Oct 2005 12:13:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325E3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXPh3hWNMT/JV+MTDGY0EIO1jHW0wAh9bBwAABVNFA= From: "Nelson, David" To: Further to my last comment... > > Once an implementation supports that, any server can challenge the > > client with "hints", as described above. A possible workflow is: > > > > C -> S: Access-Request > > User-Name =3D foo > > User-Password =3D bar > > Capability =3D yes > > S -> C: Access-Challenge > > Require-Location =3D yes > > State =3D abcd > > C -> S: Access-Request > > User-Name =3D foo > > User-Password =3D bar > > Capability =3D yes > > location =3D "moe's tavern" > > State =3D abcd >=20 > This works well, for the specific case of GEOPRIV. >=20 > For the general case of a server requiring a client to support > , this method would require a new attribute called > Require- for every value of > of interest. Surely this would lead to attribute bloat. Might I suggest one solution to this objection would be to create a single new attribute called Required-Attribute, whose value is the attribute ID of the required attribute. Zero or more instances of Required-Attribute would be allowed in Access-Challenge messages. -- 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, 13 Oct 2005 16:08:15 +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: Capabilities: Summary Date: Thu, 13 Oct 2005 12:06:54 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325E2@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXPh3hWNMT/JV+MTDGY0EIO1jHW0wAh9bBw From: "Nelson, David" To: Alan DeKok writes... > Once an implementation supports that, any server can challenge the > client with "hints", as described above. A possible workflow is: >=20 > C -> S: Access-Request > User-Name =3D foo > User-Password =3D bar > Capability =3D yes > S -> C: Access-Challenge > Require-Location =3D yes > State =3D abcd > C -> S: Access-Request > User-Name =3D foo > User-Password =3D bar > Capability =3D yes > location =3D "moe's tavern" > State =3D abcd This works well, for the specific case of GEOPRIV. For the general case of a server requiring a client to support , this method would require a new attribute called Require- for every value of of interest. Surely this would lead to attribute bloat. -- 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, 12 Oct 2005 23:48:17 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: Capabilities: Summary Cc: radiusext@ops.ietf.org Date: Wed, 12 Oct 2005 19:50:36 -0400 Message-Id: <20051012235036.51780170EA@mail.nitros9.org> "Avi Lior" wrote: > First, cap-advert is a way for the NAS to indicate to the server > what features it supports so the Server can return attribs to the > NAS and be assured that the NAS won't discard them. This has > nothing to do with challenge or the auth scheme. I agree. > Second the chalange issue does not arise from the cap-advert. In > one particular instance it arises from the way geopriv set up their > location exchange. That is, not sending the location info on the > original access request. Here the cap-advert helps the protocol by > informing the server that the NAS supports location (and challenge) > so that the server that requires (or needs) location does not > challenge a nas that doesn't support location and/or a challenge. The capability being advertised, then, isn't location, but "can handled Access-Challenge responses to PAP, CHAP, MSCHAP requests". Once an implementation supports that, any server can challenge the client with "hints", as described above. A possible workflow is: C -> S: Access-Request User-Name = foo User-Password = bar Capability = yes S -> C: Access-Challenge Require-Location = yes State = abcd C -> S: Access-Request User-Name = foo User-Password = bar Capability = yes location = "moe's tavern" State = abcd That proposal removes all of the functionality advertisement from the capability exchange. I think the potentially infinite list of "I support functionality foo" is the source of the disagreement. In most situations, one party or other other will care about 10% of the advertised capabilities, meaning the other 90% are irrelevant. And having a potentially infinite list is problematic for implementations to manage, to say nothing of IANA. The above proposal should keep all of the capability exchange within the current RADIUS data model, and won't require a new bit-array. Comments? Does this match your needs? Alan DeKok. -- 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, 12 Oct 2005 22:22:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CF7B.72C1F2FB" Subject: Re: Capabilities: Summary Date: Wed, 12 Oct 2005 18:22:36 -0400 Message-ID: Thread-Topic: Capabilities: Summary Thread-Index: AcXPXnwQVIxlJWIbShOFpAq8NwBqpAAHPair From: "Avi Lior" To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CF7B.72C1F2FB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGlzc3VlIHlvdSBhcmUgcmFpc2luZyBpcyB3aGV0aGVyIGNhcCBhZHZlcnQuIElzIHVzZWZ1 bCBvciBldmVuIHJlcXVpcmVkIGZvciBub24tY2hhbGxlbmdlIGF1dGggc2NoZW1lLiAgSSB0aGlu ayB0aGUgYW5zd2VyIGlzIHllcy4gIEhlcmUgaXMgd2h5Og0KDQpGaXJzdCwgY2FwLWFkdmVydCBp cyBhIHdheSBmb3IgdGhlIE5BUyB0byBpbmRpY2F0ZSB0byB0aGUgc2VydmVyIHdoYXQgZmVhdHVy ZXMgaXQgc3VwcG9ydHMgc28gdGhlIFNlcnZlciBjYW4gcmV0dXJuIGF0dHJpYnMgdG8gdGhlIE5B UyBhbmQgYmUgYXNzdXJlZCB0aGF0IHRoZSBOQVMgd29uJ3QgZGlzY2FyZCB0aGVtLiAgVGhpcyBo YXMgbm90aGluZyB0byBkbyB3aXRoIGNoYWxsZW5nZSBvciB0aGUgYXV0aCBzY2hlbWUuDQoNClNl Y29uZCB0aGUgY2hhbGFuZ2UgaXNzdWUgZG9lcyBub3QgYXJpc2UgZnJvbSB0aGUgY2FwLWFkdmVy dC4gIEluIG9uZSBwYXJ0aWN1bGFyIGluc3RhbmNlIGl0IGFyaXNlcyBmcm9tIHRoZSB3YXkgZ2Vv cHJpdiBzZXQgdXAgdGhlaXIgbG9jYXRpb24gZXhjaGFuZ2UuICBUaGF0IGlzLCBub3Qgc2VuZGlu ZyB0aGUgbG9jYXRpb24gaW5mbyBvbiB0aGUgb3JpZ2luYWwgYWNjZXNzIHJlcXVlc3QuICBIZXJl IHRoZSBjYXAtYWR2ZXJ0IGhlbHBzIHRoZSBwcm90b2NvbCBieSBpbmZvcm1pbmcgdGhlIHNlcnZl ciB0aGF0IHRoZSBOQVMgc3VwcG9ydHMgbG9jYXRpb24gKGFuZCBjaGFsbGVuZ2UpIHNvIHRoYXQg dGhlIHNlcnZlciB0aGF0IHJlcXVpcmVzIChvciBuZWVkcykgbG9jYXRpb24gZG9lcyBub3QgY2hh bGxlbmdlIGEgbmFzIHRoYXQgZG9lc24ndCBzdXBwb3J0IGxvY2F0aW9uIGFuZC9vciBhIGNoYWxs ZW5nZS4gIA0KDQpTbyBpaW4gZWl0aGVyIGNhc2UgaXQgZG9lcyBub3QgaHVydC4NCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpBdmkgTGlvciAgQnJpZGdld2F0ZXIgU3lzdGVtcw0K Y2VsbCArMSA2MTMgNzk2LTQxODMNCndvcmsgKzEgNjEzIDU5MS05MTA0IHggNjQxNw0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGFsYW5kQG5pdHJvczkub3JnIDxhbGFu ZEBuaXRyb3M5Lm9yZz4NClRvOiBBdmkgTGlvciA8YXZpQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20+ OyByYWRpdXNleHRAb3BzLmlldGYub3JnIDxyYWRpdXNleHRAb3BzLmlldGYub3JnPg0KU2VudDog V2VkIE9jdCAxMiAxNDo1NjozOSAyMDA1DQpTdWJqZWN0OiBSZTogQ2FwYWJpbGl0aWVzOiBTdW1t YXJ5DQoNCiJBdmkgTGlvciIgPGF2aUBicmlkZ2V3YXRlcnN5c3RlbXMuY29tPiB3cm90ZToNCj4g U28gZm9yZ2l2ZSBtZSBidXQsIHRoZSBhcHByb2FjaCBvZiBhZHZldGl6aW5nIHRha2VzIHRoZSBx dWVzcyB3b3JrIG91dA0KPiBvZiB0aGUgcHJvdG9jb2wgYW5kICBJIGRvbid0IHVuZGVyc3RhbmQg d2h5IHdlIG5lZWQgdG8gZGlzY3VzcyB0aGlzDQo+IGlzc3VlIG92ZXIgYW5kIG92ZXIgYWdhaW4u DQoNCiAgTXkgb25seSBjb25jZXJuIHdpdGggYWR2ZXJ0aXNpbmcgaXMgdGhlIHBvc3NpYmlsaXR5 IG9mIGFuIGVuZGxlc3MNCmxpc3Qgb2YgdGhpbmdzIHRvIGFkdmVydGlzZS4NCg0KICBBdXRoZW50 aWNhdGlvbiBwcm90b2NvbHMgdGhhdCBhbHJlYWR5IHVzZSBBY2Nlc3MtQ2hhbGxlbmdlIGNhbiBi ZQ0KZXh0ZW5kZWQgdG8gaGF2ZSB0aGUgc2VydmVyIHJlcXVlc3QgaW5mb3JtYXRpb24gaW4gYW4N CkFjY2Vzcy1DaGFsbGVuZ2UsIGFuZCB0aGUgTkFTIHN1cHBseSBpdCBpbiBhIGxhdGVyIEFjY2Vz cy1SZXF1ZXN0LiAgSQ0KZG9uJ3QgdGhpbmsgdGhlcmUncyBhbnkgYXJndW1lbnQgdGhlcmUuDQoN CiAgVGhlIG9ubHkgaXNzdWUsIHRoZW4sIGlzIGFyb3VuZCBhdXRoZW50aWNhdGlvbiBwcm90b2Nv bHMgc3VjaCBhcw0KUEFQLCBDSEFQLCBvciBNUy1DSEFQLiAgQWRkaW5nIGFuIGFkZGl0aW9uYWwg QWNjZXNzLUNoYWxsZW5nZSBzdGVwIGlzDQphd2t3YXJkLCBqdXN0IGFzIGFkZGluZyBjYXBhYmls aXR5IGFkdmVydGlzaW5nIGlzIGF3a3dhcmQuDQoNCiAgU28sIGlzIHVzaW5nIGNhcGFiaWxpdGll cyB3aXRoIFBBUCwgZXRjLiBhIHJlcXVpcmVtZW50Pw0KDQogIElmIHNvLCBpcyAqYW55KiBjYXBh YmlsaXR5IGFkdmVydGlzaW5nIHNjaGVtZSBhY2NlcHRhYmxlIHRvIHRoZSBXRz8NCihNeSAkMC4w MiBpcyB5ZXMpDQoNCiAgSWYgc28sIHdoYXQgc2hvdWxkIGl0IGxvb2sgbGlrZT8NCg0KICBBbGFu IERlS29rLg0K ------_=_NextPart_001_01C5CF7B.72C1F2FB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41LjcyMzIuMzYiPg0KPFRJVExFPlJlOiBDYXBhYmls aXRpZXM6IFN1bW1hcnk8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0tIENvbnZlcnRlZCBm cm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIGlzc3VlIHlv dSBhcmUgcmFpc2luZyBpcyB3aGV0aGVyIGNhcCBhZHZlcnQuIElzIHVzZWZ1bCBvciBldmVuIHJl cXVpcmVkIGZvciBub24tY2hhbGxlbmdlIGF1dGggc2NoZW1lLiZuYnNwOyBJIHRoaW5rIHRoZSBh bnN3ZXIgaXMgeWVzLiZuYnNwOyBIZXJlIGlzIHdoeTo8QlI+DQo8QlI+DQpGaXJzdCwgY2FwLWFk dmVydCBpcyBhIHdheSBmb3IgdGhlIE5BUyB0byBpbmRpY2F0ZSB0byB0aGUgc2VydmVyIHdoYXQg ZmVhdHVyZXMgaXQgc3VwcG9ydHMgc28gdGhlIFNlcnZlciBjYW4gcmV0dXJuIGF0dHJpYnMgdG8g dGhlIE5BUyBhbmQgYmUgYXNzdXJlZCB0aGF0IHRoZSBOQVMgd29uJ3QgZGlzY2FyZCB0aGVtLiZu YnNwOyBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggY2hhbGxlbmdlIG9yIHRoZSBhdXRoIHNj aGVtZS48QlI+DQo8QlI+DQpTZWNvbmQgdGhlIGNoYWxhbmdlIGlzc3VlIGRvZXMgbm90IGFyaXNl IGZyb20gdGhlIGNhcC1hZHZlcnQuJm5ic3A7IEluIG9uZSBwYXJ0aWN1bGFyIGluc3RhbmNlIGl0 IGFyaXNlcyBmcm9tIHRoZSB3YXkgZ2VvcHJpdiBzZXQgdXAgdGhlaXIgbG9jYXRpb24gZXhjaGFu Z2UuJm5ic3A7IFRoYXQgaXMsIG5vdCBzZW5kaW5nIHRoZSBsb2NhdGlvbiBpbmZvIG9uIHRoZSBv cmlnaW5hbCBhY2Nlc3MgcmVxdWVzdC4mbmJzcDsgSGVyZSB0aGUgY2FwLWFkdmVydCBoZWxwcyB0 aGUgcHJvdG9jb2wgYnkgaW5mb3JtaW5nIHRoZSBzZXJ2ZXIgdGhhdCB0aGUgTkFTIHN1cHBvcnRz IGxvY2F0aW9uIChhbmQgY2hhbGxlbmdlKSBzbyB0aGF0IHRoZSBzZXJ2ZXIgdGhhdCByZXF1aXJl cyAob3IgbmVlZHMpIGxvY2F0aW9uIGRvZXMgbm90IGNoYWxsZW5nZSBhIG5hcyB0aGF0IGRvZXNu J3Qgc3VwcG9ydCBsb2NhdGlvbiBhbmQvb3IgYSBjaGFsbGVuZ2UuJm5ic3A7PEJSPg0KPEJSPg0K U28gaWluIGVpdGhlciBjYXNlIGl0IGRvZXMgbm90IGh1cnQuPEJSPg0KPEJSPg0KPEJSPg0KPEJS Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+DQpBdmkgTGlvciZuYnNwOyBCcmlkZ2V3 YXRlciBTeXN0ZW1zPEJSPg0KY2VsbCArMSA2MTMgNzk2LTQxODM8QlI+DQp3b3JrICsxIDYxMyA1 OTEtOTEwNCB4IDY0MTc8QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj4NCkZyb206IGFsYW5kQG5pdHJvczkub3JnICZsdDthbGFuZEBuaXRyb3M5Lm9y ZyZndDs8QlI+DQpUbzogQXZpIExpb3IgJmx0O2F2aUBicmlkZ2V3YXRlcnN5c3RlbXMuY29tJmd0 OzsgcmFkaXVzZXh0QG9wcy5pZXRmLm9yZyAmbHQ7cmFkaXVzZXh0QG9wcy5pZXRmLm9yZyZndDs8 QlI+DQpTZW50OiBXZWQgT2N0IDEyIDE0OjU2OjM5IDIwMDU8QlI+DQpTdWJqZWN0OiBSZTogQ2Fw YWJpbGl0aWVzOiBTdW1tYXJ5PEJSPg0KPEJSPg0KJnF1b3Q7QXZpIExpb3ImcXVvdDsgJmx0O2F2 aUBicmlkZ2V3YXRlcnN5c3RlbXMuY29tJmd0OyB3cm90ZTo8QlI+DQomZ3Q7IFNvIGZvcmdpdmUg bWUgYnV0LCB0aGUgYXBwcm9hY2ggb2YgYWR2ZXRpemluZyB0YWtlcyB0aGUgcXVlc3Mgd29yayBv dXQ8QlI+DQomZ3Q7IG9mIHRoZSBwcm90b2NvbCBhbmQmbmJzcDsgSSBkb24ndCB1bmRlcnN0YW5k IHdoeSB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhpczxCUj4NCiZndDsgaXNzdWUgb3ZlciBhbmQgb3Zl ciBhZ2Fpbi48QlI+DQo8QlI+DQombmJzcDsgTXkgb25seSBjb25jZXJuIHdpdGggYWR2ZXJ0aXNp bmcgaXMgdGhlIHBvc3NpYmlsaXR5IG9mIGFuIGVuZGxlc3M8QlI+DQpsaXN0IG9mIHRoaW5ncyB0 byBhZHZlcnRpc2UuPEJSPg0KPEJSPg0KJm5ic3A7IEF1dGhlbnRpY2F0aW9uIHByb3RvY29scyB0 aGF0IGFscmVhZHkgdXNlIEFjY2Vzcy1DaGFsbGVuZ2UgY2FuIGJlPEJSPg0KZXh0ZW5kZWQgdG8g aGF2ZSB0aGUgc2VydmVyIHJlcXVlc3QgaW5mb3JtYXRpb24gaW4gYW48QlI+DQpBY2Nlc3MtQ2hh bGxlbmdlLCBhbmQgdGhlIE5BUyBzdXBwbHkgaXQgaW4gYSBsYXRlciBBY2Nlc3MtUmVxdWVzdC4m bmJzcDsgSTxCUj4NCmRvbid0IHRoaW5rIHRoZXJlJ3MgYW55IGFyZ3VtZW50IHRoZXJlLjxCUj4N CjxCUj4NCiZuYnNwOyBUaGUgb25seSBpc3N1ZSwgdGhlbiwgaXMgYXJvdW5kIGF1dGhlbnRpY2F0 aW9uIHByb3RvY29scyBzdWNoIGFzPEJSPg0KUEFQLCBDSEFQLCBvciBNUy1DSEFQLiZuYnNwOyBB ZGRpbmcgYW4gYWRkaXRpb25hbCBBY2Nlc3MtQ2hhbGxlbmdlIHN0ZXAgaXM8QlI+DQphd2t3YXJk LCBqdXN0IGFzIGFkZGluZyBjYXBhYmlsaXR5IGFkdmVydGlzaW5nIGlzIGF3a3dhcmQuPEJSPg0K PEJSPg0KJm5ic3A7IFNvLCBpcyB1c2luZyBjYXBhYmlsaXRpZXMgd2l0aCBQQVAsIGV0Yy4gYSBy ZXF1aXJlbWVudD88QlI+DQo8QlI+DQombmJzcDsgSWYgc28sIGlzICphbnkqIGNhcGFiaWxpdHkg YWR2ZXJ0aXNpbmcgc2NoZW1lIGFjY2VwdGFibGUgdG8gdGhlIFdHPzxCUj4NCihNeSAkMC4wMiBp cyB5ZXMpPEJSPg0KPEJSPg0KJm5ic3A7IElmIHNvLCB3aGF0IHNob3VsZCBpdCBsb29rIGxpa2U/ PEJSPg0KPEJSPg0KJm5ic3A7IEFsYW4gRGVLb2suPEJSPg0KPC9GT05UPg0KPC9QPg0KDQo8L0JP RFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C5CF7B.72C1F2FB-- -- 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, 12 Oct 2005 18:54:26 +0000 From: "Alan DeKok" To: "Avi Lior" , radiusext@ops.ietf.org Subject: Re: Capabilities: Summary Date: Wed, 12 Oct 2005 14:56:39 -0400 Message-Id: <20051012185639.D297316E0B@mail.nitros9.org> "Avi Lior" wrote: > So forgive me but, the approach of advetizing takes the quess work out > of the protocol and I don't understand why we need to discuss this > issue over and over again. My only concern with advertising is the possibility of an endless list of things to advertise. Authentication protocols that already use Access-Challenge can be extended to have the server request information in an Access-Challenge, and the NAS supply it in a later Access-Request. I don't think there's any argument there. The only issue, then, is around authentication protocols such as PAP, CHAP, or MS-CHAP. Adding an additional Access-Challenge step is awkward, just as adding capability advertising is awkward. So, is using capabilities with PAP, etc. a requirement? If so, is *any* capability advertising scheme acceptable to the WG? (My $0.02 is yes) If so, what should it look like? Alan DeKok. -- 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, 12 Oct 2005 15:15:51 +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: AW: Capabilities: Summary Date: Wed, 12 Oct 2005 11:14:41 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325DE@MAANDMBX2.ets.enterasys.com> Thread-Topic: AW: Capabilities: Summary Thread-Index: AcXPPf8SNAP1yobiSYqGqIN/gaxXDgAADssQ From: "Nelson, David" To: "Bernard Aboba" , , Bernard Aboba writes... > The problem with this is that it violates a MUST of RFC 2865. =20 > If the server is ok without location in the Access-Request, > then it can send an Access-Accept instead of a Challenge. Yes, I think it is appropriate for the server to make the decision to provide limited access or full access, using one of the existing or proposed attributes, such as including a Filter-ID attribute in the Access-Accept. The problem with this, however, is if the only way that the server can find out if a NAS has or supports location information is to send an Access-Challenge, there is no way for the server to make this informed decision in some scenarios, as the NAS will automatically treat an un-expected Access-Challenge as an Access-Reject. The server cannot know, from the initial Access-Request, whether to send an Access-Challenge or send an Access-Accept (possibly with a Filter-ID). This discussion presumes two facts: (a) the NAS never includes location information in its initial Access-Request and (b) RADIUS authentication mechanisms that do not already support Access-Challenge need to be use in conjunction with GEOPRIV. I think (a) is a requirement of GEOPRIV and (b) is something that needs to be validated. -- 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, 12 Oct 2005 15:03:01 +0000 Message-ID: From: "Bernard Aboba" To: hannes.tschofenig@siemens.com, dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: AW: Capabilities: Summary Date: Wed, 12 Oct 2005 08:02:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >this was actually one of the last bullets in my summary. in the usage >scenario avi described the outcome of this interaction would not be >equal to an access-reject. instead the aaa server would just grant >access to the basic services and access to enhanced services is offered >only if location information is provided. The problem with this is that it violates a MUST of RFC 2865. If the server is ok without location in the Access-Request, then it can send an Access-Accept instead of a Challenge. -- 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, 12 Oct 2005 07:33:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: Capabilities: Summary Date: Wed, 12 Oct 2005 09:30:55 +0200 Message-ID: Thread-Topic: Capabilities: Summary Thread-Index: AcXNyjOghRXgt1qyS9C0sK2Jc8lrEABMxPhg From: "Tschofenig, Hannes" To: "Bernard Aboba" , , hi bernard,=20 in a discussion with jouni i was told that in the 3GPP Rel-6 I-WLAN deployment scenario eap is mandatory.=20 for the GSMA IR.61 WLAN roaming scenario a challenge is not mandated but the specification requires that location information is sent to the home network. as such, there is no "capability negotiation" there. the work in wimax is in progress and therefore this issues can be dealt with.=20 for a further comment please see below:=20 > > > a) problems seem to appear if the nas does not support=20 > the challenge. > > > then the challenge will be treated as a reject. > > > >Yes. However, we know that the RADIUS EAP method requires support in > >the NAS for challenges. Are there any deployment scenarios=20 > of interest > >for GEOPRIV that expect to use the RADIUS PAP or CHAP=20 > methods? If not, > >this may well be a moot point. >=20 > PAP implementations may well support challenges, since the=20 > User-Password=20 > attribute has been used with token cards. >=20 > In any case, the issue only arises with NASes that don't=20 > support GEOPRIV,=20 > since presumably ones that do will support Challenges. In=20 > the case of=20 > legacy devices that support neither GEOPRIV nor Challenges,=20 > the issue is=20 > moot, because treating the Challenge as an Access-Reject is=20 > the desired=20 > result. this was actually one of the last bullets in my summary. in the usage scenario avi described the outcome of this interaction would not be equal to an access-reject. instead the aaa server would just grant access to the basic services and access to enhanced services is offered only if location information is provided.=20 ciao hannes -- 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, 11 Oct 2005 18:15:38 +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: Capabilities: Summary Date: Tue, 11 Oct 2005 14:15:27 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325D8@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcW1byG9gKFdOQ8kSGC/cREBUtBkbgWEV3gwAIxk7dAAM/JGUAADa2/A From: "Nelson, David" To: Avi Lior writes... > I don't understand why we need to discuss this > issue over and over again. Because we have not yet reached rough consensus? :-) -- 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, 11 Oct 2005 18:11:31 +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: Capabilities: Summary Date: Tue, 11 Oct 2005 14:11:48 -0400 Message-ID: Thread-Topic: Capabilities: Summary Thread-Index: AcW1byG9gKFdOQ8kSGC/cREBUtBkbgWEV3gwAIxk7dAAM/JGUA== From: "Avi Lior" To: "Nelson, David" , I don't think this is a valid question to ask. We should not be designing protocols based on assumptions such as the one you want us to make. Furthermore, sending a challenge to a node that supports challenges but does not support location is just wastefull. Having an advertizement in the access request does not add any new attributes (since the attribute for requesting location and advertizng location is the same) and does not requires any extra messages. =20 So forgive me but, the approach of advetizing takes the quess work out of the protocol and I don't understand why we need to discuss this issue over and over again. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, October 10, 2005 11:52 AM > To: radiusext@ops.ietf.org > Subject: RE: Capabilities: Summary >=20 > Hannes Tschofenig writes... >=20 > > a) problems seem to appear if the nas does not support the=20 > challenge. > > then the challenge will be treated as a reject. >=20 > Yes. However, we know that the RADIUS EAP method requires=20 > support in the NAS for challenges. Are there any deployment=20 > scenarios of interest for GEOPRIV that expect to use the=20 > RADIUS PAP or CHAP methods? If not, this may well be a moot point. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=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: Mon, 10 Oct 2005 18:49:03 +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: Capabilities: Summary Date: Mon, 10 Oct 2005 14:48:56 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325D3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcXNyiAOugH48VZJTqCWodhwBxkdWwAAFFhg From: "Nelson, David" To: Bernard Aboba writes... =20 > In any case, the issue only arises with NASes that don't support GEOPRIV, > since presumably ones that do will support Challenges. In the case of > legacy devices that support neither GEOPRIV nor Challenges, the issue is > moot, because treating the Challenge as an Access-Reject is the desired > result. I think that Avi's point is that the desired result is *not* Access-Reject in the particular scenario he describes: a roaming consortium which contains none legacy, non-GEOPRIV NASes. The home provider would *like* to use GEOPRIV information to authorize its roaming customers, but doesn't want to risk annoying the customer by denying any form of access when they happen to be roaming via a non-home ISP that has legacy NASes. Or at least I think that's the scenario. -- 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, 10 Oct 2005 18:41:08 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: Capabilities: Summary Date: Mon, 10 Oct 2005 11:40:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > > a) problems seem to appear if the nas does not support the challenge. > > then the challenge will be treated as a reject. > >Yes. However, we know that the RADIUS EAP method requires support in >the NAS for challenges. Are there any deployment scenarios of interest >for GEOPRIV that expect to use the RADIUS PAP or CHAP methods? If not, >this may well be a moot point. PAP implementations may well support challenges, since the User-Password attribute has been used with token cards. In any case, the issue only arises with NASes that don't support GEOPRIV, since presumably ones that do will support Challenges. In the case of legacy devices that support neither GEOPRIV nor Challenges, the issue is moot, because treating the Challenge as an Access-Reject is the desired result. -- 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, 10 Oct 2005 15:53:49 +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: Capabilities: Summary Date: Mon, 10 Oct 2005 11:52:22 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325D2@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities: Summary Thread-Index: AcW1byG9gKFdOQ8kSGC/cREBUtBkbgWEV3gwAIxk7dA= From: "Nelson, David" To: Hannes Tschofenig writes... > a) problems seem to appear if the nas does not support the challenge. > then the challenge will be treated as a reject. Yes. However, we know that the RADIUS EAP method requires support in the NAS for challenges. Are there any deployment scenarios of interest for GEOPRIV that expect to use the RADIUS PAP or CHAP methods? If not, this may well be a moot point. -- 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, 09 Oct 2005 20:21:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Capabilities: Summary Date: Sun, 9 Oct 2005 22:19:17 +0200 Message-ID: Thread-Topic: Capabilities: Summary Thread-Index: AcW1byG9gKFdOQ8kSGC/cREBUtBkbgWEV3gw From: "Tschofenig, Hannes" To: Cc: "Bernard Aboba" , hi all, i would like to finalize the discussions about the capabilities in the draft-ietf-geopriv-radius-lo-04.txt document. in this draft we suggested an attribute that is sent in both directions (from nas -> aaa server and from aaa server -> nas). bernard suggested an alternative solution that basically avoided the attribute from the nas -> aaa server.=20 here is the summary of bernards proposal (provided by himself):=20 ------------ a. RADIUS Server REQUIRES location in Access-Request or=20 Accounting-Request: server sends an Access-Challenge with an attribute=20 that expresses what is required.=20 b. RADIUS server would like location information in the Accounting-Request=20 but does not require it: RADIUS server sends an Access-Accept with an=20 attribute that expresses what is desired.=20 c. RADIUS server REQUIRES location in Access-Request, but has not received=20 it after sending an Access-Challenge: RADIUS server=20 sends an Access-Reject with an Error-Cause attribute with value "Missing Location Information" ------------ avi raised a few other issues, namely: a) problems seem to appear if the nas does not support the challenge. then the challenge will be treated as a reject. =20 b) avi presented a use case that seems to require the usage of a capability attribute sent from the nas -> aaa server:=20 the provided service depends on the availability of location information in the access-request. the aaa server will not reject the request if location information is not provided but the authorization decision depends on whether location information is present at all and based on the specific location information itself. a default service will be provided if location is not available and more services will be enabled depending on the specific location information provided to the aaa server.=20 is my summary correct?=20 ciao hannes -- 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, 09 Oct 2005 00:42:03 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Conclusion of Pre-Work Item Review on Bandwidth Document Date: Sat, 08 Oct 2005 17:41:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Just to clarify the status of the Bandwidth Document deployment review. The reponses appear to indicate there is interest in standardization of Bandwidth-related attributes, particularly within the switch community (IEEE 802.1). However, the deployment review also concluded that this community would not deploy the document as it currently exists. Also, review from the IEEE 802.11 community indicates that legacy APs are not capable of carrying out Bandwidth Limitation as specified in the document, due to hardware limitations. This explains why the existing WFA-defined VSAs have not been deployed. However, newer APs that are capable of carrying out Bandwidth Limitation have adopted more sophisticated VSAs, and as a result, these newer APs would also not be likely to adopt the approach described in the existing document. Based on the responses, the authors of the document are urged to incorporate the comments from the switch and 802.11 AP communities in order to develop a document that is likely to be deployed and implemented. Once that revision has been completed, and deployment feedback indicates that the revision addresses industry/customer needs, the RADEXT WG will once again consider the document for adoption as a RADEXT WG work item. -- 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, 09 Oct 2005 00:28:07 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Issue 139: Nonce Attribute Date: Sat, 08 Oct 2005 17:27:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Issue 139: Nonce Attribute Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: October 10, 2005 Reference: Document: RFC3576bis-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: It has been pointed out that the replay protection mechanisms recommended in RFC 3576 may be difficult to deploy. For example, the Event-Timestamp attribute requires time synchronization between the RADIUS server and NAS. In roaming situations this would require all networks between the RADIUS server and NAS to be running NTP, synchronized to the same clock. Similarly, IPsec with replay protection may not be deployable on all hops in the path. To provide more deployable replay protection it has been suggested that a Nonce attribute be introduced. This attribute would be sent by the DAC in a CoA/Disconnect-Request. If the DAS understands the attribute it would be copied into the CoA/Disconnect ACK/NAK (possibly along with another Nonce-attribute inserted by the DAS). The Nonce attribute could also be used to enhance replay protection in Accounting-Request packets. Since the receiver of the packet with a Nonce attribute doesn't need to understand it, this attribute is backward compatible with existing RFC 3576 implementations. -- 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, 07 Oct 2005 18:23:02 +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: Call for RADEXT submissions and agenda items for IETF-64 Date: Fri, 7 Oct 2005 14:21:27 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325CB@MAANDMBX2.ets.enterasys.com> Thread-Topic: Call for RADEXT submissions and agenda items for IETF-64 Thread-Index: AcXLa+8VtHRuUqFzRDGXPAyPSoueoA== From: "Nelson, David" To: Cc: , "Nelson, David" This is a general call for WG submissions and WG agenda items for the = RADEXT session at IETF-64 in Vancouver. Please reply to the chairs if you would like to make a presentation to = the RADEXT WG, including the subject mater, Internet-Draft URL, and = requested time allocation. Note that for IETF-64 we have on-line WG agendas, updatable by the WG = chairs, located on the IETF web site: = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 4 Regards, =A0 Dave Nelson -- 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, 06 Oct 2005 06:36:28 +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: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt Date: Thu, 6 Oct 2005 12:05:55 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F80E6E87@xmb-blr-416.apac.cisco.com> Thread-topic: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt Thread-index: AcXFhg1MnnHCoHeLRvmNFufD18jfNwEty7cg From: "Nagi Reddy Jonnala \(njonnala\)" To: "Bernard Aboba" , "Joseph Salowey \(jsalowey\)" Cc: > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, September 30, 2005 11:42 AM > To: Joseph Salowey (jsalowey) > Cc: radiusext@ops.ietf.org > Subject: RE: FW: I-D=20 > ACTION:draft-salowey-radext-delegated-prefix-00.txt >=20 > > [Joe] My understanding is that Framed-IPv6-Prefix causes a=20 > route to be=20 > > added in the NAS and I would expect that route to be advertised in a > > Router Advertisement messages. =20 >=20 > RFC 3162 Section 2.3 states about Framed-IPv6-Prefix: >=20 > " This Attribute indicates an IPv6 prefix (and=20 > corresponding route) > to be configured for the user. " >=20 > For Framed-IPv6-Route, RFC 3162, Section 2.5 states:=20 >=20 > " This Attribute provides routing information to be configured for > the user on the NAS. It is used in the Access-Accept packet and > can appear multiple times." >=20 > RFC 2865, Section 5.10 describes Framed-Routing: >=20 > " This Attribute indicates the routing method for the=20 > user, when the > user is a router to a network. It is only used in Access-Accept > packets." >=20 > Based on this, I think Framed-IPv6-Prefix causes a route to=20 > be added on the NAS and advertised to the user via Router=20 > Advertisement, but not via routing packets (e.g. RIPv2)=20 > unless indicated in Framed-Routing.=20 My understanding is that the user can get an IP address locally=20 on the NAS or can get one from Radius server via=20 Framed-IP-Address(for IPv4)or Framed-IPv6-Prefix(for IPv6) AVPs. Now the question is, who determines whether the route should be advertised or not. IMO, it is the local policy on the NAS. For instance, a user's machine can be a web server and=20 it should be reachable from the upstream network side. -- 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, 04 Oct 2005 14:52:48 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Cc: aboba@internaut.com Bcc: Subject: Issue: RFC 2486bis Typos Date: Tue, 04 Oct 2005 07:52:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Section 2.3: Change: "In some situations NAIs are are used together with a separate" To: "In some situations NAIs are used together with a separate" Section 2.4 Change: " The realm part internationalization is based on International Domain Name (IDN) [RFC3490]. To: "Internationalization of the realm part is based on 'Internationalizing Domain Names in Applications (IDNA) [RFC3490]." Change: "Similarly, we expect domain name comparisons, matching, resolution, and AAA routing to be performed on the ASCII versions of the international domain names. " To: "Similarly, we expect domain name comparisons, matching, resolution, and AAA routing to be performed on the ASCII versions of the internationalized domain names. " Section 2.8 Change: " alice@xn--tmonesimerkki-bfbb.example.net \(user\)@example.net The last example uses an IDN converted into an ASCII representation." To: " \(user\)@example.net alice@xn--tmonesimerkki-bfbb.example.net The last example uses an IDN converted to an ASCII representation." -- 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, 04 Oct 2005 05:52:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C8A7.C3B0D80D" Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 MIBS Date: Mon, 3 Oct 2005 22:49:32 -0700 Message-ID: Thread-Topic: Issue: Counters for Session Contexts not found in RFC3576 MIBS Thread-Index: AcXF0c5bHnacbzoBRdC/xjWeC0TwwwC1ZYiG From: "Murtaza Chiba \(mchiba\)" To: "Bernard Aboba" , "Nagi Reddy Jonnala \(njonnala\)" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C8A7.C3B0D80D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, basically we want a table of Error counters? Or do we want = something just for "Unknown Session Identifier"? Plus we need an = object to count NAKs for Diameter RAR. Murtaza -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Fri 30-Sep-05 8:15 To: Nagi Reddy Jonnala (njonnala) Cc: Murtaza Chiba (mchiba); stefaan.de_cnodder@alcatel.be; = radiusext@ops.ietf.org Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 = MIBS =20 I think I was going to go on to talk about Error Messages. Some of them = might be useful to count.=20 On Fri, 30 Sep 2005, Nagi Reddy Jonnala (njonnala) wrote: > =20 > > > Alternative, is to maintain a counter for requests that are=20 > > for Diameter RAR capabilities. > >=20 > > I do think it may make sense to count "Authorization Only" CoA and=20 > > Disconnect-Requests. In terms of the=20 >=20 > Did Bernard miss anything in the last line? I don't think we agreed = for > any "Authorize-only" Dyn auth requests. Could you guys conclude this > conversation as well? >=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 ------_=_NextPart_001_01C5C8A7.C3B0D80D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issue: Counters for Session Contexts not found in RFC3576 = MIBS

So, basically we want a table of Error counters?  = Or do we want something just for "Unknown Session = Identifier"?   Plus we need an object to count NAKs for = Diameter RAR.

Murtaza


-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Fri 30-Sep-05 8:15
To: Nagi Reddy Jonnala (njonnala)
Cc: Murtaza Chiba (mchiba); stefaan.de_cnodder@alcatel.be; = radiusext@ops.ietf.org
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 = MIBS

I think I was going to go on to talk about Error Messages.  Some of = them
might be useful to count.

On Fri, 30 Sep 2005, Nagi Reddy Jonnala (njonnala) wrote:

> 
> > > Alternative, is to maintain a counter for requests that = are
> > for Diameter RAR capabilities.
> >
> > I do think it may make sense to count "Authorization = Only" CoA and
> > Disconnect-Requests.  In terms of the
>
>  Did Bernard miss anything in the last line? I don't think we = agreed for
> any "Authorize-only" Dyn auth requests. Could you guys = conclude this
> conversation as well?
>
> --
> 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/<= /A>>
>

------_=_NextPart_001_01C5C8A7.C3B0D80D-- -- 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: