Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 24 May 2005 17:56:03 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Issue 63: Request-ID Supplementation Cc: radiusext@ops.ietf.org Date: Tue, 24 May 2005 13:53:39 -0400 Message-Id: <20050524175339.C774C16D00@mail.nitros9.org> Bernard Aboba wrote: > The RADIUS Request-ID shouldn't affect this algorithm. However, once the > Request-ID wraps you've got potentially more serious problems since the > key stream used in encrypting "hidden" RADIUS attributes should be > considered compromised. I agree. And as you noted in your RADIUS security presentation, this attack is not possible if the Message-Authenticator attribute is required. This says to me that if we can't deprecate PAP, we should at least mandate the use of Message-Authenticator. 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: Tue, 24 May 2005 04:47:54 +0000 Date: Mon, 23 May 2005 21:46:45 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: Issue 63: Request-ID Supplementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Not in FreeRADIUS. Our implementation does not track EAP > identifiers by NAS-IP-Address or other attribute sent by the NAS. > Instead, it uses the EAP identifier, source IP address, and the State > attribute. Since the State attribute is under the control of the > RADIUS server, this means that the "uniqueness" of each session is > under the control of the server, and not the NAS. > > Since proxies may play games with NAS-IP-Address (e.g. translating > private IP's to their own), depending on any attribute under control > of the NAS may result in deployment problems. I think this meets the requirements of RFC 3579. The goal was for a RADIUS server to be able to distinguish between EAP sessions regardless of which NAS they came from. > A rough description of the algorithm used is as follows: > > if (EAP start, or EAP identity) { > allocate unique State Attribute > insert into "active" queue, with key (EAP identifier, State, source IP) > } else { > look up active session in queue, with above key > } > > The algorithm appears to work in deployment, including home servers > which receive EAP sessions via intermediate RADIUS proxies. > > > Is it sufficient to address the Request-ID number space > > "wrap-around" issue? > > For RADIUS Request ID's? I'm unclear. The RADIUS Request-ID shouldn't affect this algorithm. However, once the Request-ID wraps you've got potentially more serious problems since the key stream used in encrypting "hidden" RADIUS attributes should be considered compromised. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 21 May 2005 02:32:36 +0000 Date: Fri, 20 May 2005 19:31:42 -0700 (PDT) From: Bernard Aboba To: iesg@ietf.org cc: "Nelson, David" , ietf-secretary@ietf.org, radiusext@ops.ietf.org Subject: Consideration of draft-ietf-radext-chargeable-user-id-05.txt as a Proposed Standard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The RADEXT WG has completed its review of the "Chargeable User Identity" specification (draft-ietf-radext-chargeable-user-id-05.txt) and recommends to the IESG that it be considered as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt The issues discussed during development of the document are available here: http://www.drizzle.com/~aboba/RADEXT/ The -05 version of the document resolves all open issues. The CUI document describes a RADIUS attribute that enables a local operator to obtain assurance that it has obtained a chargeable user identity, even in cases where user privacy has been invoked, preventing the local operator from learning the user identity. While initial discussions of the document envisaged usage in a wide variety of scenarios, eventually the WG converged on only a single usage scenario, which usage of the CUI attribute was requested by the NAS device. This enables resolution of issues relating to backward compatibility. Since the WG converged on the usage scenario, the document has not been controversial. An appeal is not expected. -- 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, 19 May 2005 22:13:42 +0000 Message-ID: <428D0F73.2050805@alcatel.be> Date: Fri, 20 May 2005 00:13:07 +0200 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: draft-ietf-radext-dynauth-xxx-mib-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi, The new drafts on the dynauth MIBs are available at http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-00.txt and http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-00.txt Only a few changes compared to the previous versions: 1) The syntax of radiusDynAuthServerClientPortNumber changed from Integer32 to InetPortNumber to line up with the other Radius MIB drafts 2) Some extra clarrification in the description of radiusDynAuthServDisconUserSessRemoved and radiusDynAuthServCoAUserSessChanged on what a dynauth server has to do if it does not know how many user sessions are impacted by a request (e.g., in case of a proxy). 3) some typos corrected. All comments would be very welcome! Thanks, Stefaan -- 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, 19 May 2005 17:30:59 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Issue 63: Request-ID Supplementation Cc: radiusext@ops.ietf.org Date: Thu, 19 May 2005 13:28:27 -0400 Message-Id: <20050519172827.7E0F9170A2@mail.nitros9.org> A long time ago, Bernard Aboba wrote: > [ request Id supplementation ] > > This practice applies to other types of RADIUS requests, other than those > involving EAP. > > It is commonly a problem on high port density devices. > Is this practice clearly defined? Yes. > Is it commonly implemented? Not in FreeRADIUS. Our implementation does not track EAP identifiers by NAS-IP-Address or other attribute sent by the NAS. Instead, it uses the EAP identifier, source IP address, and the State attribute. Since the State attribute is under the control of the RADIUS server, this means that the "uniqueness" of each session is under the control of the server, and not the NAS. Since proxies may play games with NAS-IP-Address (e.g. translating private IP's to their own), depending on any attribute under control of the NAS may result in deployment problems. A rough description of the algorithm used is as follows: if (EAP start, or EAP identity) { allocate unique State Attribute insert into "active" queue, with key (EAP identifier, State, source IP) } else { look up active session in queue, with above key } The algorithm appears to work in deployment, including home servers which receive EAP sessions via intermediate RADIUS proxies. > Is it sufficient to address the Request-ID number space > "wrap-around" issue? For RADIUS Request ID's? I'm unclear. 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, 19 May 2005 03:42:32 +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: RE: REMINDER: Final Review of CUI-05 Date: Thu, 19 May 2005 06:42:10 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D40B6B4@esebe100.NOE.Nokia.com> Thread-Topic: REMINDER: Final Review of CUI-05 Thread-Index: AcVcJI/ES+LOkpuRQNusv7orzuOBWQAACBrg From: To: , Cc: Hi, > > I just realized that the first page needs to be updated with the = latest > > statement on intellectual property > > rights (IPR). Should I go ahead and submit an updated version (-06) = or > > wait till May 20th? > > Thanks, > > Farid >=20 > Actually, I don't think you need to do anything until you need to = submit > an -06 for some other reason (e.g. IETF last call comment, etc.). Agreed. 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: Thu, 19 May 2005 03:39:25 +0000 Date: Wed, 18 May 2005 20:38:40 -0700 (PDT) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org Subject: RE: REMINDER: Final Review of CUI-05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I just realized that the first page needs to be updated with the latest > statement on intellectual property > rights (IPR). Should I go ahead and submit an updated version (-06) or > wait till May 20th? > Thanks, > Farid Actually, I don't think you need to do anything until you need to submit an -06 for some other reason (e.g. IETF last call comment, etc.). -- 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, 19 May 2005 01:47:59 +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: REMINDER: Final Review of CUI-05 Date: Wed, 18 May 2005 18:47:24 -0700 Message-ID: Thread-Topic: REMINDER: Final Review of CUI-05 Thread-Index: AcVcBjKQQP5/7xjzRNmkiDihxcv+TAADcVqQ From: "Adrangi, Farid" To: "Bernard Aboba" Cc: I just realized that the first page needs to be updated with the latest statement on intellectual property rights (IPR). Should I go ahead and submit an updated version (-06) or wait till May 20th? Thanks, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, May 18, 2005 5:02 PM > To: radiusext@ops.ietf.org > Subject: REMINDER: Final Review of CUI-05 >=20 >=20 > WG Last Call has completed on the Chargeable User Identity=20 > document, and a > new version (CUI-05) has been submitted that the author has indicated > closes all the open issues (82 & 83). >=20 > The revised document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeab le-user-id-05.txt The RADEXT Issues list is available here: http://www.drizzle.com/~aboba/RADEXT/ If you have filed an open issue against the document, or if you have an opinion about the resolution of Issues 82 or 83, or if you have any other last minute comments about this document, please post your Issue to the RADEXT WG mailing list ASAP. Assuming we do not hear anything by May 20, 2005 we will forward the document on to the IESG for consideration as a proposed standard. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 May 2005 00:03:28 +0000 Date: Wed, 18 May 2005 17:02:16 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: Final Review of CUI-05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII WG Last Call has completed on the Chargeable User Identity document, and a new version (CUI-05) has been submitted that the author has indicated closes all the open issues (82 & 83). The revised document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt The RADEXT Issues list is available here: http://www.drizzle.com/~aboba/RADEXT/ If you have filed an open issue against the document, or if you have an opinion about the resolution of Issues 82 or 83, or if you have any other last minute comments about this document, please post your Issue to the RADEXT WG mailing list ASAP. Assuming we do not hear anything by May 20, 2005 we will forward the document on to the IESG for consideration as a proposed standard. -- 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, 13 May 2005 22:02:09 +0000 From: "Alan DeKok" To: "Sanchez, Mauricio (PNB Roseville)" Subject: Proposed Resolution to Issue 25: Issues with IEEE 802 Extensions Draft Cc: radiusext@ops.ietf.org Date: Fri, 13 May 2005 17:59:14 -0400 Message-Id: <20050513215914.2AFBA16DD6@mail.nitros9.org> Once the proposed text included below is added to the draft, and my one-sentence comment added[1], I agree that the issues is resolved. Alan DeKok. [1] See the last line of this message. "Sanchez, Mauricio (PNB Roseville)" wrote: > > > 2.1. Egress-VLANID > > > > The text following this doesn't define the attribute > > format, or where the VLANID goes. ASCII art would be appreciated. > > Propose following text: > > "The Integer field is four octets in length. The format of the Integer > field consists of two parts, the first consuming high-order octet and > the second consuming the remaining three lower-order octets. The > high-order octet field indicates if the VLANID is allowed for tagged or > untagged packets. The second part is the 12-bit 802.1Q VLAN VID value > that has been padded out to consume the remaining three lower-order > octets. A sample encoding follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tag Option | Pad (12-bit) | VLANID (12-bit) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Values for the Tag Option part include: > 1 = Tagged > 2 = Untagged > > Padding bits SHOULD be 0 (zero). > > VLANID is the 12-bit 802.1Q-2003 VID value. " > > > > > Section 1.2 talks about possibly using the "extended attribute" > > format, and says that the following lengths are calculated > > using the short form. If so, for consistency, ASCII art of > > the attributes showing the short form would be good, even if > > there isn't consensus that it's the proper format to use. > > > All usage of extended attributes have been completely removed from > draft. > > > > > Also, the data types are "Integer32" and "UInt32". Are > > these RADIUS types, or new types? It should be clarified as > > to where these types come from. > > All non-traditional datatypes have been removed and replaced with a > traditional RFC2865 datatypes. > > > > > >2.3. VLAN-Name > > > > > > Description > > ... > > > The VLAN-Name attribute contains two parts; the first > > part is the > > > VLAN name, the second part indicates if frames on the VLAN for > > > this port are to be represented in tagged or untagged format. > > > > I suggest arranging the attribute so that the "tagged/untagged" > > information is at the same offset in the attribute as the > > Egress-VLANID attribute. Putting the value after > > variable-length "String" data makes it harder to parse. > > Putting the value in a different place than in the > > Egress-VLANID attribute creates more "special-case" > > considerations in the code. > > Suggestion taken. Propose following format: > > "The first octet of this string indicates whether the frames on the VLAN > are tagged 0x01 or Untagged 0x02. The remaining octets represent the > VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a). UTF-8 > encoded 10646 characters are recommended, but a robust implementation > SHOULD support the field as undistinguished octets." > > > > > > > 2.4. User-Priority-Table > > ... > > > Data-Type > > > > > > UInt64 > > > > Q: Is this the first proposed 64-bit integer data type in RADIUS? > > Would have been, but as mentioned above, all usage of non-traditional > RADIUS datatypes have been removed. Therefore, 64-bit integer no longer > proposed. > > > > > >2.12. Origin-Realm > > > > Add missing text: This attribute is defined as an Extended > > RADIUS attribute. > > This attribute has been removed from draft. > > > > > > 3.1. Accounting-EAP-Auth-Method > > ... > > >Value > > > > > > The Value field is eight octets. In case of expanded types > > > defined in [RFC3748] Section 5.7, the least significant 32 bits > > > contain the Vendor-Type field, and the next 24 bits contain the > > > Vendor-Id field. > > > > Leaving 8 bits of... what? > > > > Again, ASCII art, even using the proposed format from > > Appendix A would help clarify the attribute. > > Propose following clarifying text: > > "The Value field is eight octets. In case of expanded types > defined in [RFC3748] Section 5.7, the least significant 32 bits > contain the Vendor-Type field, and the next 24 bits contain the > Vendor-Id field.: And 8 bits reserved bits, which SHOULD be zero. -- 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, 12 May 2005 09:19:50 +0000 Message-ID: <42831F89.70006@piuha.net> Date: Thu, 12 May 2005 12:19:05 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: "Sanchez, Mauricio (PNB Roseville)" CC: radiusext@ops.ietf.org Subject: Re: Issue 56: Capabilities Attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree that cutting functionality is a good way to achieve a deadline. Are there any remaining issues wrt. the security properties of unknown support for filters etc? --Jari Sanchez, Mauricio (PNB Roseville) wrote: >Bernard pointed out... > > > > >>Issue 56: Capabilities Attribute >>Submitter name: Bernard Aboba >>Submitter email address: aboba@internaut.com Date first >>submitted: January 28, 2005 >>Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html >>Document: CUI, IEEE 802 >>Comment type: T >>Priority: S >>Section: Various >>Rationale/Explanation of issue: >>Farid mentioned in his last message that we might want to >>move ahead on defining a general Capabilities attribute. >>Here is a strawman proposal: >> >> >> ><...strawman proposal removed for brevity...> > > >> String2 >> >> The String2 field is one or more octets. The actual >>format of the >> information is site or application specific as described in >> [RFC2865] Section 5.26. >>[Glen Zorn] >>Why only client & request? >>[Bernard Aboba] >>The usage scenario I had in mind was a NAS announcing to a >>server that it supported various attributes. This could be >>useful, for debugging purposes (oops, I forgot to upgrade >>that NAS!), or backward compatibility (server won't send a >>new attribute to a NAS that doesn't support it). >> >>Can you describe how a server could use a Capabilities attribute? >>Proposed Resolution: Discuss >> >> > >The question of a capability attribute is one that puts the timeliness >for completion of the ieee802 draft in jeopardy. The design team has >decided to punt in the short-term and not have a direct dependence on a >capability attribute. Proposed text follows: > >"2.1. Capability Advertisement > >RADIUS does not currently define a method by which a NAS can advertise >its capabilities and in many instances, it would be desirable for the >home network to know what capabilities are supported by the NAS to >ensure proper operational behavior. The attributes defined in this >document are intended to be used to enforce policy by the NAS. If a NAS >does not recognize these attributes it will most likely ignore them and >the desired policy will not be enforced. A method for the NAS >advertising the capability to support these attributes would help the >AAA server understand if the intended policies can be enforced. >Inasmuch, we expect this lack of generalized capability advertisement to >be rectified and when available, should minimally be used in conjunction >with the NAS-Filter-Rule(TBD) attribute. " > > >MS > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 May 2005 00:27:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 58: End-to-End Capabilities Date: Wed, 11 May 2005 17:27:04 -0700 Message-ID: Thread-Topic: Issue 58: End-to-End Capabilities Thread-Index: AcVWiQ3z4TdtXz49S8+Sf8IFsZ42MgAABiKQ From: "Sanchez, Mauricio (PNB Roseville)" To: Jari chimed in... =20 > Issue 58: End-to-End Capabilities > Submitter name: Jari Arkko > Submitter email address: jari.arkko@piuha.net Date first=20 > submitted: January 20, 2005 > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00062.html > Document: CUI, IEEE 802 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > I agree that we need a capabilities function. But I would=20 > like to see a relatively coarse granularity facility, rather=20 > than something that sends data about individual attributes.=20 > For instance, I liked the list that someone made up about=20 > prepaid, filtering capability, redirection, etc. The right=20 > granularity to me appears to roughly one RFC. I say roughly=20 > because I do want to prepare for the possibility that, say,=20 > prepaid has a small number of different profiles*. > And yes, there can be capabilities that don't map nicely to=20 > new attributes. > There seems to be a few different kinds of capabilities=20 > negotiation, by the way. In Diameter, for instance, we have=20 > hop-by-hop negotiation. The primary purpose of this scheme is=20 > to ensure to provide information for routing purposes. > But another type of negotiation is something that occurs=20 > end-to-end with a specific home system, and this is what we=20 > attempt to address in the various proposals right now. The=20 > primary purpose of this is to ensure whether we can send an=20 > attribute or command or expect a behavior relating to this=20 > specific user's session. > =20 > The difference between the two approaches is that even if you=20 > know next-hop wise that FOO is supported, you don't know if=20 > FOO is supported for the particular user's session at a=20 > particular home domain. Note that the end-to-end negotiation=20 > is typically limited to the capabilities of the server that=20 > you currently talk to; it may well be that even if FOO=20 > doesn't exist on the authentication server it might exist on=20 > the accounting server at the same domain. This part is harder=20 > to solve, so I presume we are not going to require it. > Anyway, here's my strawman approach to capabilities > negotiation: > 1. End-to-end Capability Attribute > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Capabilities string ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Type > TBD for end-to-end capability attribute. > Length > The length. > Capabilities string > This field contains a variable length bit string. Each > bit position, if set to 1, indicates full compliance > with the respective feature specification. > An initial allocation of bits for different features > is listed below: > Bit 0 (NASREQ) Support for basic authentication and > authorization service [RFC 2865, I-D.NASREQ]. > Mandatory in RADIUS. > Bit 1 (MOBILE IPv4) Support for Mobile IPv4 [I-D.MIPv4]. > Bit 2 (PREPAID) Support for prepaid services [I-D.Prepaid-R, > I-D.Prepaid-D]. > Bit 3 (ACCOUNTING) Support for accounting [RFC 2866, RFC 3855]. > Bit 4 (FILTER-RULE) Support for generalized filters (mandatory > in Diameter nodes and optional for RADIUS > nodes). > Bit 5 (REDIRECT) Support for user-session redirection > feature (I-D.redirect). > Bit 6 (CUI) Support for the CUI functionality (I-D.CUI). > Bit 7 (LOCATION) Support for the location attributes (I-D.LOC). > Bit 128 (CX) Support for the 3GPP CX application. > Bit 129 (Sh) Support for the 3GPP Sh application. > Bit 130 (Rf/Ro) Support for the 3GPP Rf/Ro application. > 2. Diameter Compatibility > This attribute functions in an equivalent manner in both > RADIUS and Diameter. In Diameter, the base protocol layer > may fill in the attribute values automatically based on its > knowledge of applications running on top of it. > Note that a single bit has been allocated for a feature > if it is expected that it is supported in the same manner > in RADIUS and Diameter and that translation rules exist. > In this situation the peer does not care whether Diameter > or RADIUS is used on the other side. Otherwise, separate > bits have been allocated. > 3. IANA Considerations > IANA should create a new name space, Capabilities Bit. > The initial values in this name space include those > listed in Section 1. New values in the 0-128 range can > be allocated through IETF Consensus. Other values (upto > 2023 i.e. 253 bytes times 8 bits) can be allocated > on a First-Come First Served basis with Specification > Required. > --Jari As with issue 57, the question of a capability attribute is one that puts the timeliness for completion of the ieee802 draft in jeopardy. The design team has decided to punt in the short-term and not have a direct dependence on a capability attribute. Proposed text follows: "2.1. Capability Advertisement RADIUS does not currently define a method by which a NAS can advertise its capabilities and in many instances, it would be desirable for the home network to know what capabilities are supported by the NAS to ensure proper operational behavior. The attributes defined in this document are intended to be used to enforce policy by the NAS. If a NAS does not recognize these attributes it will most likely ignore them and the desired policy will not be enforced. A method for the NAS advertising the capability to support these attributes would help the AAA server understand if the intended policies can be enforced. Inasmuch, we expect this lack of generalized capability advertisement to be rectified and when available, should minimally be used in conjunction with the NAS-Filter-Rule(TBD) attribute. " MS -- 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, 12 May 2005 00:24:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 56: Capabilities Attribute Date: Wed, 11 May 2005 17:23:47 -0700 Message-ID: Thread-Topic: Issue 56: Capabilities Attribute Thread-Index: AcVWiCEM+ZusM3GhSiqkHvBYHDjO+gAACAdQ From: "Sanchez, Mauricio (PNB Roseville)" To: Bernard pointed out... > Issue 56: Capabilities Attribute > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com Date first=20 > submitted: January 28, 2005 > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00034.html > Document: CUI, IEEE 802 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > Farid mentioned in his last message that we might want to=20 > move ahead on defining a general Capabilities attribute. =20 > Here is a strawman proposal: >=20 <...strawman proposal removed for brevity...> > String2 >=20 > The String2 field is one or more octets. The actual=20 > format of the > information is site or application specific as described in > [RFC2865] Section 5.26. > [Glen Zorn] > Why only client & request? > [Bernard Aboba] > The usage scenario I had in mind was a NAS announcing to a=20 > server that it supported various attributes. This could be=20 > useful, for debugging purposes (oops, I forgot to upgrade=20 > that NAS!), or backward compatibility (server won't send a=20 > new attribute to a NAS that doesn't support it). >=20 > Can you describe how a server could use a Capabilities attribute? > Proposed Resolution: Discuss The question of a capability attribute is one that puts the timeliness for completion of the ieee802 draft in jeopardy. The design team has decided to punt in the short-term and not have a direct dependence on a capability attribute. Proposed text follows: "2.1. Capability Advertisement RADIUS does not currently define a method by which a NAS can advertise its capabilities and in many instances, it would be desirable for the home network to know what capabilities are supported by the NAS to ensure proper operational behavior. The attributes defined in this document are intended to be used to enforce policy by the NAS. If a NAS does not recognize these attributes it will most likely ignore them and the desired policy will not be enforced. A method for the NAS advertising the capability to support these attributes would help the AAA server understand if the intended policies can be enforced. Inasmuch, we expect this lack of generalized capability advertisement to be rectified and when available, should minimally be used in conjunction with the NAS-Filter-Rule(TBD) attribute. " MS -- 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, 12 May 2005 00:11: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: Issue 25: Issues with IEEE 802 Extensions Draft Date: Wed, 11 May 2005 17:09:52 -0700 Message-ID: Thread-Topic: Issue 25: Issues with IEEE 802 Extensions Draft Thread-Index: AcVWhU3vofDbOyqIQTGxhXlozO2l9AAAAyoA From: "Sanchez, Mauricio (PNB Roseville)" To: Alan wrote a very long time ago... =20 > -----Original Message----- > * Subject: Re: New version of IEEE 802 Attributes Draft Available=20 > * From: "Alan DeKok" >=20 > * Date: Sun, 07 Nov 2004 20:03:11 -0500=20 > http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee > 802-02.txt > > 2.1. Egress-VLANID >=20 > The text following this doesn't define the attribute=20 > format, or where the VLANID goes. ASCII art would be appreciated. Propose following text: "The Integer field is four octets in length. The format of the Integer field consists of two parts, the first consuming high-order octet and the second consuming the remaining three lower-order octets. The high-order octet field indicates if the VLANID is allowed for tagged or untagged packets. The second part is the 12-bit 802.1Q VLAN VID value that has been padded out to consume the remaining three lower-order octets. A sample encoding follows:=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag Option | Pad (12-bit) | VLANID (12-bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Values for the Tag Option part include: 1 =3D Tagged 2 =3D Untagged =09 Padding bits SHOULD be 0 (zero). VLANID is the 12-bit 802.1Q-2003 VID value. " >=20 > Section 1.2 talks about possibly using the "extended attribute" > format, and says that the following lengths are calculated=20 > using the short form. If so, for consistency, ASCII art of=20 > the attributes showing the short form would be good, even if=20 > there isn't consensus that it's the proper format to use. All usage of extended attributes have been completely removed from draft.=20 >=20 > Also, the data types are "Integer32" and "UInt32". Are=20 > these RADIUS types, or new types? It should be clarified as=20 > to where these types come from. All non-traditional datatypes have been removed and replaced with a traditional RFC2865 datatypes. >=20 > >2.3. VLAN-Name > > > > Description > ... > > The VLAN-Name attribute contains two parts; the first=20 > part is the > > VLAN name, the second part indicates if frames on the VLAN for > > this port are to be represented in tagged or untagged format. >=20 > I suggest arranging the attribute so that the "tagged/untagged" > information is at the same offset in the attribute as the=20 > Egress-VLANID attribute. Putting the value after=20 > variable-length "String" data makes it harder to parse. =20 > Putting the value in a different place than in the=20 > Egress-VLANID attribute creates more "special-case"=20 > considerations in the code. Suggestion taken. Propose following format: "The first octet of this string indicates whether the frames on the VLAN are tagged 0x01 or Untagged 0x02. The remaining octets represent the VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a). UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets." >=20 > > 2.4. User-Priority-Table > ... > > Data-Type > > > > UInt64 >=20 > Q: Is this the first proposed 64-bit integer data type in RADIUS? Would have been, but as mentioned above, all usage of non-traditional RADIUS datatypes have been removed. Therefore, 64-bit integer no longer proposed. =20 >=20 > >2.12. Origin-Realm >=20 > Add missing text: This attribute is defined as an Extended=20 > RADIUS attribute. This attribute has been removed from draft.=20 >=20 > > 3.1. Accounting-EAP-Auth-Method > ... > >Value > > > > The Value field is eight octets. In case of expanded types > > defined in [RFC3748] Section 5.7, the least significant 32 bits > > contain the Vendor-Type field, and the next 24 bits contain the > > Vendor-Id field. >=20 > Leaving 8 bits of... what? >=20 > Again, ASCII art, even using the proposed format from=20 > Appendix A would help clarify the attribute. Propose following clarifying text: "The Value field is eight octets. In case of expanded types defined in [RFC3748] Section 5.7, the least significant 32 bits contain the Vendor-Type field, and the next 24 bits contain the Vendor-Id field.: MS -- 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, 11 May 2005 22:27:42 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Cc: Subject: RFC 2866 nit Message-Id: <20050511222528.20A00170FD@mail.nitros9.org> Date: Wed, 11 May 2005 18:25:28 -0400 (EDT) I don't think this is serious enough to warrant an ISSUE, but I just noticed that RFC 2866 describes Acct-Session-Id as "text" in the ASCII art, and as "string" in the description following. RFC 2865 uses either "text" and "text", or "string" and "string". 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, 11 May 2005 22:15:50 +0000 From: "Alan DeKok" To: Jari Arkko Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Cc: radiusext@ops.ietf.org Date: Wed, 11 May 2005 18:13:16 -0400 Message-Id: <20050511221316.CA58716DD6@mail.nitros9.org> Jari Arkko wrote: > > Years of deployment without complaints is a strong indicator that a > >problem doesn't exist. Let's let sleeping dogs lie. > > > Ok. But I'd still like to understand this better. Or I really > need to, because we need to decide whether to > (a) strip i18n out of the bis draft altogether > (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware- > name-slot scheme > (c) change to utf-8 altogether I would say (b). > Also, before you answer the above lets try to get some > understanding on whether "no complaints" means > (i) no one is using i18n dns names yet. i have some sense > that this might be the case, as at least here in Finland > I think they allowed the new types of allocations > very recently. Mosrly. i18n domain names have historically been rare. > (ii) existing support (just let utf-8 through) is working > well Definitely. > (iii) solutions from a single vendor work well, but > not a lot of interop has been attempted with this > particular case I would say that interoperability hasn't been *reported* on. But the deployments of RADIUS are so varied that I would be surprised if interoperability isn't already being tested in live situations. I haven't heard of i18n problems with interoperability. My guess, therefore, is that such problems are rare. 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, 11 May 2005 19:56: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: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Date: Wed, 11 May 2005 15:56:34 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103232C@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Thread-Index: AcVWRdTHph+uBAhrQiSRUpnxYAgptAAGvctw From: "Nelson, David" To: > Question: How does this work for NASes that support both IPv4 and IPv6? > Which objects would such devices use? Here's some additional advice on this question, from David Harrington, MIB Doctor. Below is a portion of Dave's reply to my informal query, of today, on how to handle the details of this issue. This does not constitute formal MIB Doctor review. I think you would also need to specify that an implementation MUST NOT have different addresses in radiusAuthServerAddress [old object] and radiusAuthServerInetAddress [new object]. It would probably be acceptable to have an IPv6-formatted IPv4 address in the InetAddress and the IPv4 format of the same address in the IPAddress object. Note from RFC3291: "A single host system may be configured with multiple addresses (IPv4 or IPv6), and possibly with multiple DNS names. Thus it is possible for a single host system to be accessible by multiple InetAddressType/InetAddress pairs. If this could be an implementation or usage issue, the DESCRIPTION clause of the relevant objects must fully describe which address is reported in a given InetAddressType/InetAddress pair." So it is possible that there is an IPv6 InetAddress, and radiusAuthServerAddress COULD be used to store the IPv4 address of the same server; I feel uneasy about doing this, because it would tend to prolong the use of the deprecated radiusAuthServerAddress object, and would have forward-compatibility issues for applications that only supported the InetAddress objects, and only supported IPv4 communications; it could not retrieve the IPv4 address of the server. I would prefer to see one row for the IPv6 InetAddress, and another row for the IPv4 InetAddress. In any case, the MIB module (when separated from the surrounding text) should be clear on how this should be handled. So, I guess we need to clarify the issues around multi-version IP stacks on RADIUS servers (and clients) and include that guidance in the relevant DESCRIPTION clauses of the MIB modules. I would interpret this advice to suggest that a dual-stack RADIUS server would need to have (at least) two row entries in the client's table of servers, such that the IPv4 address was never confused with the IPv6 address. Bernard has already indicated that robust client implementations might not want to fail over from the IPv6 address of one server host to the IPv4 address of the same host. Dave H. also recommends: Write a compliance clause that calls for use of the new object, not the old. Deal with backwards compatibility by deprecating the old compliance clause and add a new compliance clause that includes the new address objects and does not include the deprecated object. Implementations can always support both compliance clauses if they choose. If there are no objections, I will proceed to revise the drafts based on the collected MIB Doctor suggestions. -- 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, 11 May 2005 19:37:59 +0000 Message-ID: <42825F01.5070006@piuha.net> Date: Wed, 11 May 2005 22:37:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>I concur with the sentiment, but I wonder if the text in the NAIbis >>draft, that purports to add internationalization support, has already >>awakened that particular canine? :-) >> >> > >Based on the responses, sending NAIs in UTF-8 within the >EAP-Response/Identity will not awaken the canine. > > But I'm still concerned that we are not doing any of the normalization and mapping stuff that seems to be necessary in order to get comparisons right. I agree that it should not be done by proxies. But it should be done at the time you enter the stuff to the db, or type the NAI to the client machine. But it seemed like implementations are not doing that either. >>From what we've heard it sounds like RADIUS proxy implementations handle >the User-Name attribute as opaque octets, and that may be all we should >assume. > >Avi's Issue 75 (leave the NAI in UTF-8) seems to be compatible with that >perspective. > > I suppose the other alternative, assuming the realms are idn-unaware name slots could also be argued to be compatible with that. Except in the ! case but there we are not treating the attribute as opaque octets anyway. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 19:37:53 +0000 Message-ID: <42825EFE.3010507@piuha.net> Date: Wed, 11 May 2005 22:37:34 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Alan DeKok CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Alan, > Years of deployment without complaints is a strong indicator that a >problem doesn't exist. Let's let sleeping dogs lie. > > Ok. But I'd still like to understand this better. Or I really need to, because we need to decide whether to (a) strip i18n out of the bis draft altogether (b) keep current utf-8 + plain-old-dns-name-but-as-idnunaware- name-slot scheme (c) change to utf-8 altogether In some sense all of these approaches can be argued to be doing as little as possible. Which one do you want? Also, before you answer the above lets try to get some understanding on whether "no complaints" means (i) no one is using i18n dns names yet. i have some sense that this might be the case, as at least here in Finland I think they allowed the new types of allocations very recently. (ii) existing support (just let utf-8 through) is working well (iii) solutions from a single vendor work well, but not a lot of interop has been attempted with this particular case --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 18:41:44 +0000 Date: Wed, 11 May 2005 11:41:30 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Update on the IEEE 802 extensions document? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Could the authors please post proposed resolutions (or at least updates) on the open issues? I'd like to get this document cleaned up and accepted as a WG work item by the end of this month. -- 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, 11 May 2005 18:33:59 +0000 Date: Wed, 11 May 2005 11:33:21 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I concur with the sentiment, but I wonder if the text in the NAIbis > draft, that purports to add internationalization support, has already > awakened that particular canine? :-) Based on the responses, sending NAIs in UTF-8 within the EAP-Response/Identity will not awaken the canine. >From what we've heard it sounds like RADIUS proxy implementations handle the User-Name attribute as opaque octets, and that may be all we should assume. Avi's Issue 75 (leave the NAI in UTF-8) seems to be compatible with that perspective. -- 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, 11 May 2005 18:21:40 +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: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Date: Wed, 11 May 2005 14:21:24 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032329@MAANDMBX2.ets.enterasys.com> Thread-Topic: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Thread-Index: AcVWUmAlnzrSn4RuRY6ufB1Gf7LJ+gAA2c3g From: "Nelson, David" To: Alan DeKok writes... > Let's let sleeping dogs lie. I concur with the sentiment, but I wonder if the text in the NAIbis draft, that purports to add internationalization support, has already awakened that particular canine? :-) -- 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, 11 May 2005 18:13:56 +0000 Date: Wed, 11 May 2005 11:13:47 -0700 (PDT) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: Issue: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Assigned Issue 91. Are there any objections to these changes? Otherwise, I propose that this Issue be accepted. On Wed, 11 May 2005, Beck01, Wolfgang wrote: > typos in section 'RADIUS server behaviour' > > Submitter name: Wolfgang Beck > Submitter email address: beckw@t-systems.com > Date first submitted: 11 May 2005 > Document: draft-ietf-radext-digest-auth-02.txt > Comment type: E > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > missing verb in > 'The RADIUS server Digest-Realm, Message-Authenticator (see > [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and > MAY add Digest-Domain, Digest-Opaque attributes to the Access- > Challenge message.' > > and > > 'A RADIUS MUST check if the RADIUS client is authorized to serve users > of the realm mentioned in the Digest-Realm attribute.' > > Requested change: > 'The RADIUS server MUST add Digest-Realm, Message-Authenticator (see > [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and > MAY add Digest-Domain, Digest-Opaque attributes to the Access- > Challenge message.' > > 'A RADIUS server MUST check if the RADIUS client is authorized to > serve users of the realm mentioned in the Digest-Realm attribute.' > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 18:09:02 +0000 Date: Wed, 11 May 2005 11:08:49 -0700 (PDT) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 7: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If there are no objections, I propose we accept this resolution. On Wed, 11 May 2005, Beck01, Wolfgang wrote: > 2. Detailed Description > > 2.1 RADIUS Client Behavior > > [..] > To do the latter, it sends an Access-Request containing a Digest-Method > and a Digest-URI attribute but without a Digest-Nonce attribute. > It adds a Message-Authenticator (see [RFC3579]) attribute to the > Access-Request message. The RADIUS server chooses a nonce and responds > with an Access-Challenge containing a Digest-Nonce attribute. > [..] > > 2.2 RADIUS Server Behavior > > If the RADIUS server receives an Access-Request message with a > Digest-Method and a Digest-URI attribute but without a Digest-Nonce > attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce > attribute and sends it in an Access-Challenge message to the RADIUS > client. The RADIUS server MUST add Digest-Realm, Message-Authenticator > (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and > MAY add Digest-Domain, Digest-Opaque attributes to the Access- > Challenge message. > [..] > RADIUS servers issuing nonces MAY construct a Digest-Nextnonce > attribute and add it to the Access-Accept message. This is useful to > limit the lifetime of a nonce and to save a round-trip in future > requests (see nextnonce discussion in [RFC2617], section 3.2.3). The > RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) > and sends the Access-Accept message to the RADIUS client. > > > 4. Table of Attributes > > The following table provides a guide to which attributes may be found > in which kinds of packets, and in what quantity. > > +-------------------------+-----+-----+--------+--------+-----------+ > | Attribute | # | Req | Accept | Reject | Challenge | > +-------------------------+-----+-----+--------+--------+-----------+ > | User-Name | TBD | 1 | 0 | 0 | 0 | > | Message-Authenticator | TBD | 1 | 1 | 1 | 1 | > > [..] > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 18:04:45 +0000 Date: Wed, 11 May 2005 11:04:32 -0700 (PDT) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 77: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This looks ok to me. On Wed, 11 May 2005, Beck01, Wolfgang wrote: > 3.14 Digest-Opaque attribute > > Description > This attribute holds the opaque parameter that is passed to the > HTTP-style client. The HTTP-style client will pass this value > back to the server (ie the RADIUS client) without modification. > This attribute is only used when the RADIUS server chooses > nonces and MUST only be used in Access-Request and Access- > Challenge messages. > > [..] > +-------------------------+-----+-----+--------+--------+-----------+ > | Attribute | # | Req | Accept | Reject | Challenge | > +-------------------------+-----+-----+--------+--------+-----------+ > [..] > | Digest-Auth-Param | TBD | 0+ | 0+ | 0 | 0+ | > [..] > > > > Wolfgang Beck > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 17:53:11 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Cc: radiusext@ops.ietf.org Date: Wed, 11 May 2005 13:50:55 -0400 Message-Id: <20050511175055.0ED0E16DD6@mail.nitros9.org> Bernard Aboba wrote: > Right. Is this something we should try to fix, or just leave alone? My opinion would be to leave it alone. > I don't recall hearing complaints about Microsoft IAS either. Years of deployment without complaints is a strong indicator that a problem doesn't exist. Let's let sleeping dogs lie. 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, 11 May 2005 17:31:46 +0000 Date: Wed, 11 May 2005 10:31:39 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Which is difficult, especially since the locale information isn't > sent in the RADIUS packet. Without that, I'm not sure how to use > stringprep properly to get better string comparisons. Right. Is this something we should try to fix, or just leave alone? > As an implementor, my inclination is to avoid the whole issue as it > relates to software, and push it back to the users and administrators. > > That is, get them to type in the strings (names, realms, etc.) as > opaque tokens which have to be entered in one "normal" form. I guess this makes sense. The user has to know how the administrator set up their account if they hope to be able to authenticate successfully. This includes understanding exactly how the NAI was internationalized. > Precedent exists for this request, in the Windows warning messages > about "you must have capslock off...", which tells the user that what > *they* think of as equivalent strings are not, and the strings must > always be entered as exactly the same set of characters. > > I don't recall hearing that this was an issue for FreeRADIUS, and > it's used in many, many internationalized configurations. I don't recall hearing complaints about Microsoft IAS either. -- 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, 11 May 2005 17:30: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: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Date: Wed, 11 May 2005 13:29:19 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032328@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Thread-Index: AcVWToZiAOR7urUQSEuBYLnwpWK/WQAACxug From: "Nelson, David" To: "Bernard Aboba" Cc: > Sounds like yet another problem for "Issues and Fixes". And perhaps an update to RFC 3162, "RADIUS and IPv6"? -- 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, 11 May 2005 17:26:21 +0000 Date: Wed, 11 May 2005 10:26:07 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A potential conflict would appear to exist if RADIUS servers are > configured on a NAS with a mixture of IPv4 and IPv6 addresses. Do we > have a notion of a single RADIUS server that could be addressed by > either IPv4 or IPv6? If the NAS has a dual-mode stack, with both IPv4 > and IPv6 addresses, RADIUS servers would see these as separate NASes, > based on the shared secret lookup. Is that right? Certainly there will be two different shared secret entries, one with the IPv6 address/shared secret and another with the IPv4 address/shared secret. Hopefully the RADIUS client will be a bit more intelligent in not doing things like failing over from the IPv4 address to the IPv6 address when the RADIUS server doesn't answer. However, this does bring up another issue, which is how the RADIUS server identifies the NAS if it is more than one hop away. NASes can have more than one IPv6 address and this makes it possible for a NAS to put a linkscope address in the NAS-IPv6-Address field. If the proxy is on the same link as the RADIUS client, the RADIUS server could receive a packet with a NAS-IPv6-Address as a linklocal address. The same issue can occur with IPv4 Link Local, and of course a NAS can have more than one IPv4 and IPv6 address. One potential suggestion might be to use the NAS-Identifier attribute in such a situation so as to avoid having to configure the RADIUS server with all potential NAS addresses. > I agree that the WG needs to consider all the semantics and operational > issues of IPv6 support, and document that somewhere, even if the MIB > isn't the best place. Sounds like yet another problem for "Issues and Fixes". -- 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, 11 May 2005 17:22:49 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Date: Wed, 11 May 2005 13:20:27 -0400 Message-Id: <20050511172027.1FD0516DD6@mail.nitros9.org> Jari Arkko wrote: > It looks like implementations may actually be capable of > accepting non-ASCII input. However, there does not appear > to be any specific support for character set aware comparisons, > normalization, etc. Which is difficult, especially since the locale information isn't sent in the RADIUS packet. Without that, I'm not sure how to use stringprep properly to get better string comparisons. > What does this imply? I'm not quite sure... and the input > is too small to make any definite conclusions. But it could > be that alternative #1 for NAIbis issue resolution is preferrable, > given that it better ensures correctness of lookups and > comparisons. Comments? As an implementor, my inclination is to avoid the whole issue as it relates to software, and push it back to the users and administrators. That is, get them to type in the strings (names, realms, etc.) as opaque tokens which have to be entered in one "normal" form. Precedent exists for this request, in the Windows warning messages about "you must have capslock off...", which tells the user that what *they* think of as equivalent strings are not, and the strings must always be entered as exactly the same set of characters. I don't recall hearing that this was an issue for FreeRADIUS, and it's used in many, many internationalized configurations. 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, 11 May 2005 17:19:27 +0000 Date: Wed, 11 May 2005 10:19:20 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Attempting to summarize: (I hope you Bernard posted all the > responses you got privately, I've only seen two.) I will look through my email but I don't think I got any private responses. I think we have three responses. > It looks like implementations may actually be capable of > accepting non-ASCII input. However, there does not appear > to be any specific support for character set aware comparisons, > normalization, etc. Yes. UTF-8 can be sent in the NAI, but the RADIUS proxies are doing exact string matches against the realm table. This makes me wonder if we don't need to provide guidance on what the proxies *should* do. > What does this imply? I'm not quite sure... I think it implies that proxy implementations may have problems with internationalization. > and the input > is too small to make any definite conclusions. But it could > be that alternative #1 for NAIbis issue resolution is preferrable, > given that it better ensures correctness of lookups and > comparisons. Comments? Given the feedback we have received, it would appear to me that implementations are doing good to be correctly processing UTF-8, let alone IDNA. -- 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, 11 May 2005 17:15:05 +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: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Date: Wed, 11 May 2005 13:14:54 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032327@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Thread-Index: AcVWRdTHph+uBAhrQiSRUpnxYAgptAABUqXA From: "Nelson, David" To: Bernard Aboba writes... > Question: How does this work for NASes that support both IPv4 and IPv6? > Which objects would such devices use? This begs the operational question of how RADIUS clients might support IPv4/IPv6 co-existence. I suppose that this issue might extend beyond the scope of the MIB itself. A potential conflict would appear to exist if RADIUS servers are configured on a NAS with a mixture of IPv4 and IPv6 addresses. Do we have a notion of a single RADIUS server that could be addressed by either IPv4 or IPv6? If the NAS has a dual-mode stack, with both IPv4 and IPv6 addresses, RADIUS servers would see these as separate NASES, based on the shared secret lookup. Is that right? I agree that the WG needs to consider all the semantics and operational issues of IPv6 support, and document that somewhere, even if the MIB isn't the best place. -- 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, 11 May 2005 17:07:16 +0000 Date: Wed, 11 May 2005 10:06:59 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 25 Apr 2005, Bernard Aboba wrote: > RFC 2486bis specifies how the NAI is internationalized. In the > development of this document, some questions have arisen about the > behavior of existing EAP peers and RADIUS proxies. In order to understand > how existing implementations function, we need implementers to volunteer > the answer to several questions: > > 1. How is internationalization supported on your EAP peer implementation? > Does your EAP peer implementation support formating of the realm > portion in IDN, or does it enable entering of UTF-8, or perhaps just plain > ASCII? For use with PPP, only ASCII is supported. In EAP over IEEE 802, UTF-8 is supported. IDN is not supported (e.g. the realm part is not translated to IDN or checked for compatibility with it). > 2. How is internationalization supported on your RADIUS proxy > implementation?. > > How does your implementation support internationalization within the realm > table? Are realm table entries stored in IDN, UTF-8, or something else? They are stored in UTF-8. > How are comparisons done between the realm in the NAI and the realm stored > in the realm table? Stringprep is not used in comparing the NAI realm to the realm in the realm table, just an ordinary match. -- 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, 11 May 2005 16:24:32 +0000 Date: Wed, 11 May 2005 09:23:53 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: Re: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Question: How does this work for NASes that support both IPv4 and IPv6? Which objects would such devices use? On Wed, 11 May 2005, Nelson, David wrote: > Since the discussion of this issue has subsided, with no WG members > dissenting from the MIB Doctor's recommendations, I propose to > incorporate those recommendations into the next revision of the drafts. > > In summary, the drafts will contain the tables from RFCs 2618-2621 with > the IPv4-only format address objects changed from "current" to > "deprecated". New tables will be added (in parallel) with IPv4/IPv6 > format address objects. To promote backwards compatibility, the > compliance statements will require both old and new tables to be > instantiated when IPv4 addresses are in use, and only the new tables > when IPv4 addresses are not in use (i.e. IPv6 only). > > The new RFCs, when issued, will either Update or Obsolete RFCs > 2618-2621, as appropriate. > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 15:07: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: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Date: Wed, 11 May 2005 11:07:05 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032322@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposed Resolution to Issue 87 (RADIUS MIB Updates) Thread-Index: AcVWOxfQ+wDUTR0UQx+YFaik2nDjNA== From: "Nelson, David" To: Since the discussion of this issue has subsided, with no WG members dissenting from the MIB Doctor's recommendations, I propose to incorporate those recommendations into the next revision of the drafts. In summary, the drafts will contain the tables from RFCs 2618-2621 with the IPv4-only format address objects changed from "current" to "deprecated". New tables will be added (in parallel) with IPv4/IPv6 format address objects. To promote backwards compatibility, the compliance statements will require both old and new tables to be instantiated when IPv4 addresses are in use, and only the new tables when IPv4 addresses are not in use (i.e. IPv6 only). The new RFCs, when issued, will either Update or Obsolete RFCs 2618-2621, as appropriate. -- 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, 11 May 2005 13:36:43 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEC5@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Proposed Resolution to Issue 79: Date: Wed, 11 May 2005 15:14:40 +0200 MIME-Version: 1.0 Content-Type: text/plain 2.2 RADIUS Server Behavior [..] A RADIUS MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server silently discards the Access-Request message. Other actions taken by the RADIUS server are out of scope of this document. However, the RADIUS server should notify the operator and may take additional action such as discarding all future requests from this client, until some management action tells it to do so again. 7. Security Considerations [..] The RADIUS server MUST check the Digest-Realm attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised. Wolfgang Beck -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- 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, 11 May 2005 13:36:12 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEC4@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Proposed Resolution to Issue 78: Date: Wed, 11 May 2005 15:13:49 +0200 MIME-Version: 1.0 Content-Type: text/plain 1.3 Overview [..] RADIUS clients and servers can support one, or both nonce generation modes. If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. The nonce generation mode is a configurable parameter The operator MUST make sure that the RADIUS client software uses the correct nonce generation mode when accessing a specific RADIUS server. RADIUS clients implementing both modes MUST offer respective configuration options. [For new formatting, see to draft-ietf-radext-digest-auth-02.txt] 3.1 Digest-Response attribute Description If this attribute is present in an Access-Request message, the RADIUS server MUST view the Access-Request as a Digest one. [..] Length >= 3 Text When using HTTP digest, the text field is 32 octets long and contains hexadecimal representation of 16 octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without quotes. [..] 3.10 Digest-Entity-Body-Hash attribute Description When using the qop level 'auth-int', a hash of the HTTP-style message body's contents is required for digest calculation. Instead of sending the complete body of the message, only its hash value is sent. This hash value can be used directly in the digest calculation. The clarifications described in section 22.4 of [RFC2617] about the hash of empty entity bodies apply to the Digest-Entity- Body-Hash attribute. This attribute MUST only be sent in Access-Request packets. Type [IANA: use 111 if possible] for Digest-Entity-Body-Hash Length >=3 Text The attribute holds the hexadecimal representation of H(entity- body). This hash is required by certain authentication mechanisms, such as HTTP Digest with quality of protection set to "auth-int". RADIUS clients MUST use this attribute to transport the hash of the entity body when HTTP Digest is the authentication mechanism and the RADIUS server requires to verify the integrity of the entity body (e.g., qop parameter set to "auth-int"). Extensions to this document may define support for authentication mechanisms other than HTTP Digest. wb: extension would be indicated by Digest-Algorithm or Digest-Qop, of course. Migration Path to Diameter: still left in -02, as there is no diameter-sip-app draft describing the functionality yet. Wolfgang Beck -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- 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, 11 May 2005 13:32:56 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEC2@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Issue: Date: Wed, 11 May 2005 15:10:49 +0200 MIME-Version: 1.0 Content-Type: text/plain typos in section 'RADIUS server behaviour' Submitter name: Wolfgang Beck Submitter email address: beckw@t-systems.com Date first submitted: 11 May 2005 Document: draft-ietf-radext-digest-auth-02.txt Comment type: E Priority: S Section: 2.2 Rationale/Explanation of issue: missing verb in 'The RADIUS server Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access- Challenge message.' and 'A RADIUS MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute.' Requested change: 'The RADIUS server MUST add Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access- Challenge message.' 'A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute.' -- 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, 11 May 2005 13:32:45 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEC1@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Proposed Resolution to Issue 7: Date: Wed, 11 May 2005 15:09:54 +0200 MIME-Version: 1.0 Content-Type: text/plain 2. Detailed Description 2.1 RADIUS Client Behavior [..] To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. It adds a Message-Authenticator (see [RFC3579]) attribute to the Access-Request message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. [..] 2.2 RADIUS Server Behavior If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge message to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message-Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access- Challenge message. [..] RADIUS servers issuing nonces MAY construct a Digest-Nextnonce attribute and add it to the Access-Accept message. This is useful to limit the lifetime of a nonce and to save a round-trip in future requests (see nextnonce discussion in [RFC2617], section 3.2.3). The RADIUS server adds a Message-Authenticator attribute (see [RFC3579]) and sends the Access-Accept message to the RADIUS client. 4. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. +-------------------------+-----+-----+--------+--------+-----------+ | Attribute | # | Req | Accept | Reject | Challenge | +-------------------------+-----+-----+--------+--------+-----------+ | User-Name | TBD | 1 | 0 | 0 | 0 | | Message-Authenticator | TBD | 1 | 1 | 1 | 1 | [..] Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- 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, 11 May 2005 13:30:26 +0000 Message-ID: <428208F3.2060206@piuha.net> Date: Wed, 11 May 2005 16:30:27 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attempting to summarize: (I hope you Bernard posted all the responses you got privately, I've only seen two.) It looks like implementations may actually be capable of accepting non-ASCII input. However, there does not appear to be any specific support for character set aware comparisons, normalization, etc. What does this imply? I'm not quite sure... and the input is too small to make any definite conclusions. But it could be that alternative #1 for NAIbis issue resolution is preferrable, given that it better ensures correctness of lookups and comparisons. Comments? --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 13:23:16 +0000 Message-ID: <42820742.8030302@piuha.net> Date: Wed, 11 May 2005 16:23:14 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >RFC 2486bis specifies how the NAI is internationalized. In the >development of this document, some questions have arisen about the >behavior of existing EAP peers and RADIUS proxies. In order to understand >how existing implementations function, we need implementers to volunteer >the answer to several questions: > >1. How is internationalization supported on your EAP peer implementation? > >Does your EAP peer implementation support formating of the realm >portion in IDN, or does it enable entering of UTF-8, or perhaps just plain >ASCII? > Note that many protocols work with IDNs as "IDN unaware domain name slots". That is, an IDN may look like a regular ASCII DNS name. The only question is if an implementation actually can take a UTF-8 string also, directly. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 May 2005 13:13:21 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEC3@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Proposed Resolution to Issue 77: Date: Wed, 11 May 2005 15:12:39 +0200 MIME-Version: 1.0 Content-Type: text/plain 3.14 Digest-Opaque attribute Description This attribute holds the opaque parameter that is passed to the HTTP-style client. The HTTP-style client will pass this value back to the server (ie the RADIUS client) without modification. This attribute is only used when the RADIUS server chooses nonces and MUST only be used in Access-Request and Access- Challenge messages. [..] +-------------------------+-----+-----+--------+--------+-----------+ | Attribute | # | Req | Accept | Reject | Challenge | +-------------------------+-----+-----+--------+--------+-----------+ [..] | Digest-Auth-Param | TBD | 0+ | 0+ | 0 | 0+ | [..] Wolfgang Beck -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- 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, 11 May 2005 05:20:48 +0000 Date: Tue, 10 May 2005 22:20:12 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue tracking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The RADIUS Issues web page is located here: http://www.drizzle.com/~aboba/RADEXT/ The Issues list describes the process by which Issues are submitted and tracked in the RADEXT WG. I've been working on updating the Issues list and have run into a number of problems with the way people are posting to the list, which has made it difficult to figure out the status of issues on current documents. To get this figured out, I'd like to request help from WG participants so that the process can work more smoothly. Here is a summary of the process: Issue Submission Any Working Group (WG) participant can at any time submit an Issue relating to any draft that is a WG work item, or in pre-work item review. All Issues should be posted to the WG mailing list (radiusext@ops.ietf.org) in the format described on the Issues list, with Issue: in the subject line. In trying to update the Issues list, it appears that Issues were submitted without an Issue: in the subject line, and as a result, these Issues are not being tracked. Also, it is not clear to me that all postings with Issue: in the subject line correspond to new issues, rather than proposed resolutions of old issues. Please use the Issue: subject line without an Issue number *only* when submitting a new issue. If the posting is a proposed resolution to an existing issue, please refer to the issue by the Issue #. If you have submitted an Issue that hasn't ended up on the Issue list or if you have found a new Issue being incorrectly created, please contact me so that I can get it fixed. Issue Resolution In order to resolve an Issue, the editor needs to post a resolution to the Issue to the mailing list. The resolution posting should include the following Subject line: "Proposed Resolution to Issue X:" in the subject line, where X is the Issue #. The resolution posting should include the text of the proposed resolution in its entirety, not just a summary. Note that editors can proposed a resolution to an Issue, but resolution requires a response from the original poster of the Issue, to confirm that the resolution is ok with them. If you have posted an Issue for which the editor has proposed a resolution, please respond to that posting with your opinion on whether the proposed resolution is satisfactory or not. If not, please proposed alternative text so as to move the discussion along. Documents in WG Last Call The above process is particularly important for documents in WG last call. Before a document can be sent to the IESG for consideration, we need to confirm that all open issues are closed, but unless the above process is followed, we will be unable to do that. So as to avoid unnecessary delays, please help us in accurately tracking Issue status so that we can complete documents in a timely way. -- 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, 11 May 2005 03:05:22 +0000 Date: Tue, 10 May 2005 20:05:08 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Final Review of CUI-05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII WG Last Call has completed on the Chargeable User Identity document, and a new version (CUI-05) has been submitted that the author has indicated closes all the open issues (82 & 83). The revised document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-05.txt The RADEXT Issues list is available here: http://www.drizzle.com/~aboba/RADEXT/ If you have filed an open issue against the document, or if you have an opinion about the resolution of Issues 82 or 83, or if you have any other last minute comments about this document, please post your Issue to the RADEXT WG mailing list ASAP. Assuming we do not hear anything by May 20, 2005 we will forward the document on to the IESG for consideration as a proposed standard. -- 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, 11 May 2005 02:36:34 +0000 Date: Tue, 10 May 2005 19:35:39 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Acceptance as WG work items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A clarification on the status of several documents. Based on the response to the following posting: http://ops.ietf.org/lists/radiusext/2005/msg00270.html there appears to be sufficient interest to adopt the RADIUS MIB revisions, RFC 3576 MNIBs and RADIUS Extensions for IEEE 802 as RADEXT WG work items. These documents can now be submitted with draft-ietf-radext-* titles (with the new boilerplate, please) once the pre-work item review issues have been addressed. ----------------------------------------------------------------------- As discussed at today's meeting, we are looking to gauge WG interest in making the following documents WG work items: RADIUS MIB Revision http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt RFC 3576 MIBs http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-03.txt http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-03.txt RADIUS Extensions for IEEE 802 http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-03.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: Thu, 05 May 2005 17:18:58 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Comments on RADIUS MIB documents - MIB Doctor Review Date: Thu, 05 May 2005 13:16:19 -0400 Message-Id: <20050505171619.89E0316DD6@mail.nitros9.org> "Nelson, David" wrote: > My personal assumption was that implementers of IPv4-only products > didn't want to see the existing MIBs obsoleted or deprecated, > because someone (a customer or a marketing manager) might request > the successor MIBs to be implemented in the next release. The real > reason might be something altogether different, of course. Laziness? Open source products are notorious for ignoring customer requests, and implementing only the "fun" things. :) > In any event, we have expert review comments on the proposed MIBs that > indicate that this novel augmentation approach is undesirable. The > suggestion is to update all of the MIBs, deprecating the tables in RFC > 2618-2621. Products will still have to implement them, though, in order to be backwards compatible with the people who haven't updated. > I'm asking that the WG members proactively respond, indicating > acceptance of the MIB Doctors recommendations, or rejection of the > recommendations together with a rationale for doing so. Once we have > determined consensus on this, then I will be able to issue the next > draft version. I'd like to keep this task on schedule. I accept the MIB Doctors recommendations. Having new MIBs is better than trying to augment the old ones. 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, 05 May 2005 17:07:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on RADIUS MIB documents - MIB Doctor Review Date: Thu, 5 May 2005 13:06:43 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103231A@MAANDMBX2.ets.enterasys.com> Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYgAJN8wlAAAmIwsAAAgIWQ From: "Nelson, David" To: "Romascanu, Dan \(Dan\)" , > > OK, so no one's interested in discussing this. :-( >=20 > taking offense - I did comment on this actually :-) Yes, I know. I'd had considered your response as "unofficial" MIB Doctor commentary (note that I wrote MIB Doctors [plural]). Sorry to be unclear or to cause offense. I was seeking response from our "silent majority". -- 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, 05 May 2005 17:01:47 +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: RE: Comments on RADIUS MIB documents - MIB Doctor Review Date: Thu, 5 May 2005 19:59:14 +0300 Message-ID: Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYgAJN8wlAAAmIwsA== From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , > OK, so no one's interested in discussing this. :-( taking offense - I did comment on this actually :-) > I'm asking that the WG members proactively respond, indicating > acceptance of the MIB Doctors recommendations, or rejection of the > recommendations together with a rationale for doing so. Once we have > determined consensus on this, then I will be able to issue the next > draft version. I'd like to keep this task on schedule. Better prepare a strong argument to reject the MIB Doctor = recommendations. It's not that the WG does not have this option, but = both the MIB Doctor reviewer and the Area Director came with clear = arguments IMO that demonstrated that the path that was taken by the WG = creates an interoperability problem between existing implementations of = the previous set of RFCs and 2618-2621.=20 I am in favor of following the recommendations.=20 Regards, Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David > Sent: 05 May, 2005 6:52 PM > To: radiusext@ops.ietf.org > Subject: RE: Comments on RADIUS MIB documents - MIB Doctor Review >=20 >=20 > > I am forwarding some RADIUS MIB comments to the WG list, with the > > author's permission. > >=20 > > I'd like to solicit the WG's opinion on structuring of IPv6 address > > support in the RADIUS MIBs, based on the attached comments. >=20 > OK, so no one's interested in discussing this. :-( >=20 > The WG chose, during a couple of IETF meetings, to pursue the slightly > novel approach of augmenting the existing MIB tables with a set of > IPV4/IPv6 address types, and leaving RFC 2618-2621 untouched, and > un-deprecated. There was not much explicit discussion on=20 > *why* this was > the WG's preference. My personal assumption was that implementers of > IPv4-only products didn't want to see the existing MIBs obsoleted or > deprecated, because someone (a customer or a marketing manager) might > request the successor MIBs to be implemented in the next release. The > real reason might be something altogether different, of course. >=20 > In any event, we have expert review comments on the proposed MIBs that > indicate that this novel augmentation approach is undesirable. The > suggestion is to update all of the MIBs, deprecating the tables in RFC > 2618-2621. >=20 > I'm asking that the WG members proactively respond, indicating > acceptance of the MIB Doctors recommendations, or rejection of the > recommendations together with a rationale for doing so. Once we have > determined consensus on this, then I will be able to issue the next > draft version. I'd like to keep this task on schedule. >=20 > Thanks! >=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, 05 May 2005 15:53: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: Comments on RADIUS MIB documents - MIB Doctor Review Date: Thu, 5 May 2005 11:52:26 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032319@MAANDMBX2.ets.enterasys.com> Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYgAJN8wlA= From: "Nelson, David" To: > I am forwarding some RADIUS MIB comments to the WG list, with the > author's permission. >=20 > I'd like to solicit the WG's opinion on structuring of IPv6 address > support in the RADIUS MIBs, based on the attached comments. OK, so no one's interested in discussing this. :-( The WG chose, during a couple of IETF meetings, to pursue the slightly novel approach of augmenting the existing MIB tables with a set of IPV4/IPv6 address types, and leaving RFC 2618-2621 untouched, and un-deprecated. There was not much explicit discussion on *why* this was the WG's preference. My personal assumption was that implementers of IPv4-only products didn't want to see the existing MIBs obsoleted or deprecated, because someone (a customer or a marketing manager) might request the successor MIBs to be implemented in the next release. The real reason might be something altogether different, of course. In any event, we have expert review comments on the proposed MIBs that indicate that this novel augmentation approach is undesirable. The suggestion is to update all of the MIBs, deprecating the tables in RFC 2618-2621. I'm asking that the WG members proactively respond, indicating acceptance of the MIB Doctors recommendations, or rejection of the recommendations together with a rationale for doing so. Once we have determined consensus on this, then I will be able to issue the next draft version. I'd like to keep this task on schedule. Thanks! -- 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, 03 May 2005 14:45:17 +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: RE: Comments on RADIUS MIB documents - MIB Doctor Review Date: Tue, 3 May 2005 17:42:47 +0300 Message-ID: Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYgACwubWA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , I believe that we need to redefine the tables in the new MIB modules in = any case. - if backwards compatibility with existing management applications is = required this can be achieved only by defining new tables, as = demonstrated by Bert - if backwards compatibility is not required, why bother AUGMENT-ing? = The AUGMENTS would not work because there can be no one-to-one = relationship with the rows pointing to ipv6 objects.=20 IMHO the 'clean way' is to deprecate 2618 to 2621, replace the address = objects with the new TCs, and place all under new root OIDs.=20 Are there many IPv4 only implementations out there that would need to be = replaced in deployment? Regards, Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David > Sent: 02 May, 2005 8:24 PM > To: radiusext@ops.ietf.org > Subject: Comments on RADIUS MIB documents - MIB Doctor Review >=20 >=20 > I am forwarding some RADIUS MIB comments to the WG list, with the > author's permission. >=20 > I'd like to solicit the WG's opinion on structuring of IPv6 address > support in the RADIUS MIBs, based on the attached comments. >=20 > ------------------------ Comment 1 ------------------------- >=20 > > http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt > > http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt > > http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt > > http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt >=20 > Unfortunately, I do not have the time to be able to commit to doing > a full MIB Doctor review. However I did have a brief look at the > documents and I have a serious concern about the approach. >=20 > Specifically, each document contains a MIB module that AUGMENTS a > conceptual row entry in an existing table. The augmenting row > contains IP-version-neutral columns that are intended to replace > some IPv4-specific columns in the augmented row. There is a > statement in the narrative part of the documents that those > IPv4-specific columns are deprecated -- see Sections 4, 5, and 6 of > the drafts -- but documents do not contain a revised version of the > original MIB module with the status value of the IPv4-specific > objects changed from 'current' to 'deprecated'. >=20 > There are two things that bother me about this approach. >=20 > First, it is customary when the status of an object in an IETF MIB > module is changed for that MIB module to be reissued with an updated > definition of that object. The above-mentioned drafts would leave > it up to the user of the MIB module to perform that update. I don't > think that is wise. Note that if new revisions of the existing MIB > modules are published, there is little reason not to put the new > objects into the existing tables, rather than making augmenting rows > in new modules. >=20 > Second, and more seriously, there is no discussion of what happens > when an agent that implements the new/updated MIB module interacts > with a management application that is built expect the old > definitions. It is not actually clear to me how to avoid breaking > such applications except by definining an entirely new table (as was > done in draft-ietf-ipv6-rfc2096-update-07.txt, to give one example), > and stipulating in the compliance statements for the new/updated MIB > module that the existing IPv4-specific tables are to be populated > when the address type is IPv4. >=20 > If it has already not done so, I would suggest that the RADEXT WG > should explicitly discuss whether or not they want to preserve > backard compatibility with management applications that implement > RFCs 2618 through 2621, since that has a big impact on the design of > the MIB module. >=20 > Regards, >=20 > Mike Heard >=20 > ----------------------- Comment 2 ------------------------------ >=20 > > The specific approach was taken at the request of the WG members. =20 > > Folks wanted to specifically avoid obsoleting the existing=20 > RFCs. I'd=20 > > like to get some WG comment on your concerns with that approach. >=20 > That sounds fair. One way to do that -- which I hinted at in=20 > my earlier > e-mail -- would be to make new tables to parallel the old, but using > InetAddressType/InetAddress pairs in place of IpAddress (as you did in > the augmentation tables). The compliance statements for the new MIB > module could then require that both the old table and new table be > instantiated when the address type is IPv4, but not otherwise. The > downside, obviously, is that there are a lot of extra objects; it is > more efficient for the agent to implement only one set of tables. The > upside is that management apps that used to work before continue to > work, although they are limited to just the IPv4-related entries, and > the old specs don't have to be revised. >=20 > //cmh >=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: Mon, 02 May 2005 17:24:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments on RADIUS MIB documents - MIB Doctor Review Date: Mon, 2 May 2005 13:23:55 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103230D@MAANDMBX2.ets.enterasys.com> Thread-Topic: Comments on RADIUS MIB documents - MIB Doctor Review Thread-Index: AcVOxX0bPVyT41DrT7ynBJfBc3gmLQAdWDYg From: "Nelson, David" To: I am forwarding some RADIUS MIB comments to the WG list, with the author's permission. I'd like to solicit the WG's opinion on structuring of IPv6 address support in the RADIUS MIBs, based on the attached comments. ------------------------ Comment 1 ------------------------- > http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-00.txt > http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-00.txt > http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-00.txt > http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-00.txt Unfortunately, I do not have the time to be able to commit to doing a full MIB Doctor review. However I did have a brief look at the documents and I have a serious concern about the approach. Specifically, each document contains a MIB module that AUGMENTS a conceptual row entry in an existing table. The augmenting row contains IP-version-neutral columns that are intended to replace some IPv4-specific columns in the augmented row. There is a statement in the narrative part of the documents that those IPv4-specific columns are deprecated -- see Sections 4, 5, and 6 of the drafts -- but documents do not contain a revised version of the original MIB module with the status value of the IPv4-specific objects changed from 'current' to 'deprecated'. There are two things that bother me about this approach. First, it is customary when the status of an object in an IETF MIB module is changed for that MIB module to be reissued with an updated definition of that object. The above-mentioned drafts would leave it up to the user of the MIB module to perform that update. I don't think that is wise. Note that if new revisions of the existing MIB modules are published, there is little reason not to put the new objects into the existing tables, rather than making augmenting rows in new modules. Second, and more seriously, there is no discussion of what happens when an agent that implements the new/updated MIB module interacts with a management application that is built expect the old definitions. It is not actually clear to me how to avoid breaking such applications except by definining an entirely new table (as was done in draft-ietf-ipv6-rfc2096-update-07.txt, to give one example), and stipulating in the compliance statements for the new/updated MIB module that the existing IPv4-specific tables are to be populated when the address type is IPv4. If it has already not done so, I would suggest that the RADEXT WG should explicitly discuss whether or not they want to preserve backard compatibility with management applications that implement RFCs 2618 through 2621, since that has a big impact on the design of the MIB module. Regards, Mike Heard ----------------------- Comment 2 ------------------------------ > The specific approach was taken at the request of the WG members. =20 > Folks wanted to specifically avoid obsoleting the existing RFCs. I'd=20 > like to get some WG comment on your concerns with that approach. That sounds fair. One way to do that -- which I hinted at in my earlier e-mail -- would be to make new tables to parallel the old, but using InetAddressType/InetAddress pairs in place of IpAddress (as you did in the augmentation tables). The compliance statements for the new MIB module could then require that both the old table and new table be instantiated when the address type is IPv4, but not otherwise. The downside, obviously, is that there are a lot of extra objects; it is more efficient for the agent to implement only one set of tables. The upside is that management apps that used to work before continue to work, although they are limited to just the IPv4-related entries, and the old specs don't have to be revised. //cmh -- 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, 02 May 2005 06:27: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: CUI version -05 Date: Sun, 1 May 2005 23:26:28 -0700 Message-ID: Thread-Topic: CUI version -05 Thread-Index: AcVO39+Kd1M7S18pTEi8BnEfiBBseg== From: "Adrangi, Farid" To: Cc: "Bernard Aboba" , "Nelson, David" , "Greg Weber" Hi all, I have submitted version -05 of the CUI draft that addresses issues 82 and 83. The draft does not yet appear in I-D, but you can view the draft here: http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i d-05.txt The suggested editorial in issue 82 (submitted by Greg Weber) was done in -05 draft. And the issue 83 (submitted by Bernard) was addressed as below: Text in -04 " If a home RADIUS server that supports the CUI attribute receives an Access-Request packet containing a CUI (set to nul or otherwise), it MUST include the CUI attribute in the Access-Accept packet. Otherwise, if the Access-Request packet does not contain a CUI, the home RADIUS server MUST NOT include the CUI attribute in the Access-Accept packet. " =20 Rewrite it to=20 =20 " If a home RADIUS server that supports the CUI attribute receives an Access-Request packet containing a CUI (set to nul or otherwise), it MUST include the CUI attribute in the Access-Accept packet. Otherwise, if the Access-Request packet does not contain a CUI, the home RADIUS server SHOULD NOT include the CUI attribute in the Access-Accept packet. The Access-Request may be sent either in the initial authentication or durig re-authentication. " Text in -04 " A RADIUS client requesting the CUI attribute in an Access-Accept packet MUST include within the Access-Request=20 packet a CUI attribute with a single NUL character (referred to as a nul CUI). " =20 Rewrite it to: " A RADIUS client requesting the CUI attribute in an Access-Accept packet MUST include within the Access-Request packet a CUI attribute. For the initial authentication, the CUI attribute will include a single NUL character (referred to as a nul CUI). And, during re-authentication, the CUI attribute will include a previously received=20 CUI value (referred to as a non-nul CUI value) in the Access-Accept.=20 Upon receiving a non-nul CUI value in an Access-Request the home RADIUS server MAY verify that the value of CUI matches the CUI from the previous Access-Accept. If the verification fails, then the RADIUS server SHOULD respond with an Access-Reject message.=20 " And finally, added the following text to the end of section 2.1: " A NAS that requested the CUI during reauthentication by including the CUI in the Access-Request, will receive the CUI in the Access-Accept. The NAS MUST include the value of that CUI in all Accounting 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: