Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 27 Apr 2007 22:26:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for allocation of Tunnel-Type value (fwd) Date: Fri, 27 Apr 2007 15:25:37 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503DE510E@xmb-sjc-215.amer.cisco.com> Thread-Topic: Request for allocation of Tunnel-Type value (fwd) Thread-Index: AceJAEziuHtJ+Cx1Q8CPIsu0aT3xpQAGqaTw From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=308; t=1177712742; x=1178576742; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Request=20for=20allocation=20of=20Tunnel-Type=20value =20(fwd) |Sender:=20; bh=Vn0q+ncTINKHWNf5ZwPKl/2NjZjnfsX6f/trWIG7bbU=; b=s0R9luC6EQBTbN2wa1m0Rgt7+dsSw1tTFibS4uaYC9dSusb2mVjzCQVsZCe770HzKJsRAehG if9INBblqkrHJ9rfuujE4hsx6XIT/o2DxxjdzEiVTfmcvi4QWHgtS9W/awy5W/Wp7ZPLhrAG8A dr+0vF9folbz1nKyt573vNRVk=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Bernard Aboba allegedly scribbled on Friday, April 27, 2007 12:15 PM: > Anyway, it looks like the right answer is that Tunnel-Type and > Tunnel-Medium-Type are allocated as specified in RFC 2868, not 3575.=20 Yup. >=20 > Glen Zorn said: >> I stand corrected. -- to 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, 27 Apr 2007 19:15:16 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com Cc: radiusext@ops.ietf.org, iana-prot-param-comment@icann.org Bcc: Subject: RE: Request for allocation of Tunnel-Type value (fwd) Date: Fri, 27 Apr 2007 12:14:32 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Anyway, it looks like the right answer is that Tunnel-Type and Tunnel-Medium-Type are allocated as specified in RFC 2868, not 3575. Glen Zorn said: >I stand corrected. -- to 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, 27 Apr 2007 17:05:36 +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: Request for allocation of Tunnel-Type value (fwd) Date: Fri, 27 Apr 2007 10:04:51 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503DE4E8C@xmb-sjc-215.amer.cisco.com> Thread-Topic: Request for allocation of Tunnel-Type value (fwd) Thread-Index: AceI24hmUX4lt6eAS9ioofK20tE52QAEpXJA From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1599; t=1177693493; x=1178557493; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Request=20for=20allocation=20of=20Tunnel-Type=20value =20(fwd) |Sender:=20; bh=+BScX53yIrJHlMTOa2gZm1G3xqjze0QHAZa7PcPGuzA=; b=oYxAD03PL1ZfLWuB0dKNleaWPbpIjOAr/wnwZFc/ib69HI83RtV945qWehGrvVQxUCwgkYxA fI7lS7f2krB72HXrXZ7NwNiPdLRMTGvQeQfQKUA306Irm4R5hG1y/jEb; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Bernard Aboba allegedly scribbled on Friday, April 27, 2007 7:51 AM: >> As I recall, the intent was to require both the publication of an RFC >> and expert review (preferably by a relevant WG). "Expert Review" as >> defined in BCP 26 requires neither of these; RFC 3575 seems to imply >> that the former is required in the case of "Expert Review", but not >> the latter. >=20 > Here is what RFC 3575 Section 2.1 says: I stand corrected. >=20 > For registration requests where a Designated Expert should be > consulted, the responsible IESG area director should appoint the > Designated Expert. The intention is that any allocation will be > accompanied by a published RFC. However, the Designated Expert can > approve allocations once it seems clear that an RFC will be > published, allowing for the allocation of values prior to the > document being approved for publication as an RFC. The Designated > Expert will post a request to the AAA WG mailing list (or a > successor designated by the Area Director) for comment and review, > including an Internet-Draft. Before a period of 30 days has > passed, the Designated Expert will either approve or deny the > registration request, publish a notice of the decision to the AAA > WG mailing list or its successor, and inform IANA of its decision. > A denial notice must be justified by an explanation and, in the > cases where it is possible, concrete suggestions on how the > request can be modified so as to become acceptable. -- to 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, 27 Apr 2007 14:51:52 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com Cc: radiusext@ops.ietf.org, iana-prot-param-comment@icann.org Bcc: Subject: RE: Request for allocation of Tunnel-Type value (fwd) Date: Fri, 27 Apr 2007 07:51:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >As I recall, the intent was to require both the publication of an RFC >and expert review (preferably by a relevant WG). "Expert Review" as >defined in BCP 26 requires neither of these; RFC 3575 seems to imply >that the former is required in the case of "Expert Review", but not the >latter. Here is what RFC 3575 Section 2.1 says: For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. However, the Designated Expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC. The Designated Expert will post a request to the AAA WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, publish a notice of the decision to the AAA WG mailing list or its successor, and inform IANA of its decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable. -- to 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, 26 Apr 2007 23:40:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for allocation of Tunnel-Type value (fwd) Date: Thu, 26 Apr 2007 16:40:30 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503DE4C22@xmb-sjc-215.amer.cisco.com> Thread-Topic: Request for allocation of Tunnel-Type value (fwd) Thread-Index: AceIVND9Y9ec+FNNRQWnUju/Z4NHGgABikKg From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1082; t=1177630832; x=1178494832; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Request=20for=20allocation=20of=20Tunnel-Type=20value =20(fwd) |Sender:=20; bh=2Yzp5QegC7gGG5cm+/1IMFWcoMitDdapu8Hw3tpecjA=; b=FHF96EPAlHlR4fdpz+HseAt4TM6P93oHU5SVSghHy0FW7rIZwhTfKmHKj2Mf7lnbIPLp+56u DMJCSGPC3ZMApVksImQxFKcQ+A55X0okZtmRN01wWpBYVdWGruztRA9Q; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Bernard Aboba <> allegedly scribbled on Thursday, April 26, 2007 3:46 PM: > A question has arisen as to the appropriate IANA allocaiton policy > for new values of the Tunnel-Type and Tunnel-Medium-Type attributes.=20 >=20 > RFC 3575 states that all RADIUS attribute values are assigned by > Designated Expert, with the exception of Service-Type. However this > document only indicates that it updates RFC 2865, not RFC 2868, which > indicates allocation by IETF consensus. =20 >=20 > At first glance, this looks like an oversight. =20 Maybe, but nevertheless we can change either RFC or leave them both alone. I prefer the latter. > Is there a reason why > assignment of a new Tunnel-Type value should require IETF consensus > rather than Designated Expert? =20 As I recall, the intent was to require both the publication of an RFC and expert review (preferably by a relevant WG). "Expert Review" as defined in BCP 26 requires neither of these; RFC 3575 seems to imply that the former is required in the case of "Expert Review", but not the latter. -- to 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, 26 Apr 2007 22:46:40 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for allocation of Tunnel-Type value (fwd) Date: Thu, 26 Apr 2007 15:46:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A question has arisen as to the appropriate IANA allocaiton policy for new values of the Tunnel-Type and Tunnel-Medium-Type attributes. RFC 3575 states that all RADIUS attribute values are assigned by Designated Expert, with the exception of Service-Type. However this document only indicates that it updates RFC 2865, not RFC 2868, which indicates allocation by IETF consensus. At first glance, this looks like an oversight. Is there a reason why assignment of a new Tunnel-Type value should require IETF consensus rather than Designated Expert? -------------------------------------------------------------------------------- From: Amanda Baber via RT [mailto:iana-prot-param-comment@icann.org] Sent: Thu 4/26/2007 2:15 PM Cc: Bernard Aboba; bernard_aboba@hotmail.com Subject: [IANA #75548] General Request for Assignments (RADIUS Attribute 64, Tunnel-Type) Dear Bernard, Can you advise IANA on this request for a new value for RADIUS attribute 64 (Tunnel-Type)? Section 6.1 of RFC 2868 states, "Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16]." (Section 6.2 describes the same procedure for the remaining Tunnel-Medium-Type Attribute Values.) Section 2.1 of RFC 3575 appears to indicate that all attribute values are assigned by Designated Expert, except for those values associated with the Service-Type attribute. However, RFC 2868 does not appear to have been updated or obsoleted. RFC 3575 also states, "The intention is that any allocation will be accompanied by a published RFC. However, the Designated Expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC." Is the value he's requesting assigned by IETF Consensus, or by the process described in RFC 3575? If the latter, how should we advise the requester to proceed with this application? Thanks, Amanda Baber IANA -- to 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, 20 Apr 2007 02:42:47 +0000 Message-ID: <4626955E0003EAC9@n034.sc1.he.tucows.com> (added by postmaster@bouncemessage.net) Date: Thu, 19 Apr 2007 22:39:55 -0400 To: radiusext@ops.ietf.org From: David Mitton Subject: RE: new Service-Type Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I attempted to reply to this message last week, but my provider's webmail failed me twice and then lost the draft copy. Sigh.... On 4/10/2007 07:19 AM, David B. Nelson wrote: >Alan DeKok writes ... ... >IANA allocations for RADIUS are controlled by RFC 3575, which reads, in >part, as follows: ... > > The benefit with the method suggested in RFC 2882 is that > > you do not need IANA approval for the allocation. > >I personally consider vendor-specific enumerations, as described in RFC 2882 >to be a very bad practice. Please recall that RFC 2882 describes RADIUS >practices encountered in implementations, but does not necessisarily >recommend these practices. Various versions of the RADIUS Design Guidelines >draft have included text recommending against using VSEs, in favor of >standard IANA allocations. > >RFC 2882 says, in part: > > This technique has not seen any acceptance by the > working group or other vendors, however, the vendor did accomplish > the goal of not conflicting with working group additions or other > vendor values. > >In my opinion, which is based in part on discussions with the author of RFC >2882, that document lists certain practices which ought not to be >encouraged, in the interests of interoperability, but rather which vendors >have resorted to in order to bypass the normal IETF processes. RFC 2882 was written in the NASREQ WG to provide information as to why RADIUS as it was, needed more work. The re-reading the abstract I see it says it well: This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. The document itself, is often called by me, as a "Worst Practices" document. It is not an example of what to do, but to open peoples eyes to the types of things people were trying to do, and the problems they create. >In any event, new values of Service-Type, VSE or otherwise, do require IANA >allocation and do require IETF consensus. I will also point out that RFC 2882 was written before RFC 3575 was published. And I'm sure some of the portions Dave N. quotes were probably tweaked to prevent some of the issues I documented in 2882. W.r.t. VSEs, Since I created them, I am sympathetic to the rationale. While they do work, they create the interoperabilty problems Dave points out later in this thread. I encountered at least one RADIUS server that couldn't deal with the attribute values because they'd used only a byte internally for the nominal 4 byte integer. At the time, the code points I needed were additional Service-Types and Acct-Status-Types. Ultimately that product made the VSE code points an option that could be turned off. In general I would not recommend this type of design, but at the time, the politics of the IETF made it seem impossible to get anything RADIUS related even discussed. Some things have changed.... Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Apr 2007 00:35:35 +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 draft-zorn-radius-keywrap-12.txt Date: Thu, 19 Apr 2007 17:35:03 -0700 Message-ID: Thread-Topic: comments on draft-zorn-radius-keywrap-12.txt Thread-Index: AceC4JdWiOvQ8m+jRPucnRNoDQpaCgAAbkFw From: "Joseph Salowey \(jsalowey\)" To: "Bernard Aboba" , , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3101; t=1177029319; x=1177893319; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20comments=20on=20draft-zorn-radius-keywrap-12.txt |Sender:=20; bh=p8hC4R6RPZTB4P8uvs961T8Pt1ldXhFVLVAwg/iVzOo=; b=sYXnfMIrNJPLRAQw2szPa26PpI0LM6o7ZGb2jKpRvETxEdF164p+q6NBpdI6TUW5O5nZG6+w /Gs2O7dXmMipn/G+JYOt7dwL1niFKamf8hmIEjG5zLVrFpGPcSr8jbj/fdMJ7xeTIL407aRfa8 m6sLg+S9xWDC4jnirY2q8Hj/M=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, April 19, 2007 5:12 PM > To: dharkins@lounge.org; radiusext@ops.ietf.org > Subject: RE: comments on draft-zorn-radius-keywrap-12.txt >=20 > >[Joe] I disagree here. The KEK ID is an opaque octet string to=20 > >identify the key that is being used to encrypt the key. =20 > This document=20 > >does not specify a way to establish a key and the KEK ID is there to=20 > >facilitate different forms of key management. >=20 > In the existing implementations, what forms of key management=20 > are used to establish the KEK ID? > Is there a specification for the key management mechanisms? >=20 [Joe] Currently it is done by manual keying, which is less than ideal. > >In particular the attributes are > >designed not to require additional state on the RADIUS server so the=20 > >use of a KEK ID allows a new key to be brought into use. =20 > The KEK ID is=20 > >necessary unless a particular key management scheme is=20 > specified that=20 > >does not require it. >=20 > RADIUS as it exists today does not require a KEK ID because=20 > it impliictly assumes that there is only one key used between=20 > a RADIUS client and server at a time and that this key is=20 > identified by the client and server IP=20 > addresses. At IETF 68, Key Rollover was given as the=20 > primary reason why=20 > more than one key might be valid at a given time, so that=20 > some other key identifier might be needed. Assuming that=20 > credible ciphers (e.g. AES) are used, why should key rollover=20 > represent a problem? >=20 [Joe] yes, the primary reason to have a key ID is so you can change keys. Credible ciphers are not the problem. People may wish to change keys for administrative reasons (change of personnel etc.). In addition if an automated key management is performed "out-of-band" then you may need to identify a specific key from several generated keys. Regardless of whether it is cryptographically necessary or not a key lifetime is often defined for management purposes, when the life time expires the key needs to be replaced.=20 > >The KM ID serves to identify they key that is being=20 > transported. This=20 > >definition of this is specified by the application for which=20 > the key is=20 > >to be used. The draft should specify that for a the EAP-MSK=20 > >application this field is not used since there already is an=20 > attribute=20 > >defined to hold the EAP-MSK ID. >=20 > So you are saying that this specification is designed to=20 > enable future RADIUS key managment applications, rather than=20 > the existing ones? >=20 [Joe] No, the specification supports existing RADIUS key management applications as well as enables future one. =20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Apr 2007 00:12:29 +0000 Message-ID: From: "Bernard Aboba" To: dharkins@lounge.org, radiusext@ops.ietf.org Bcc: Subject: RE: comments on draft-zorn-radius-keywrap-12.txt Date: Thu, 19 Apr 2007 17:11:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[Joe] I disagree here. The KEK ID is an opaque octet string to identify >the key that is being used to encrypt the key. This document does not >specify a way to establish a key and the KEK ID is there to facilitate >different forms of key management. In the existing implementations, what forms of key management are used to establish the KEK ID? Is there a specification for the key management mechanisms? >In particular the attributes are >designed not to require additional state on the RADIUS server so the use >of a KEK ID allows a new key to be brought into use. The KEK ID is >necessary unless a particular key management scheme is specified that >does not require it. RADIUS as it exists today does not require a KEK ID because it impliictly assumes that there is only one key used between a RADIUS client and server at a time and that this key is identified by the client and server IP addresses. At IETF 68, Key Rollover was given as the primary reason why more than one key might be valid at a given time, so that some other key identifier might be needed. Assuming that credible ciphers (e.g. AES) are used, why should key rollover represent a problem? >The KM ID serves to identify they key that is being transported. This >definition of this is specified by the application for which the key is >to be used. The draft should specify that for a the EAP-MSK application >this field is >not used since there already is an attribute defined to hold the EAP-MSK >ID. So you are saying that this specification is designed to enable future RADIUS key managment applications, rather than the existing ones? -- to 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 Apr 2007 21:45:45 +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: Request for RADIUS crypto-agility solutions Date: Thu, 19 Apr 2007 14:45:04 -0700 Message-ID: Thread-Topic: Request for RADIUS crypto-agility solutions Thread-Index: Acd8Ov9mnSt9AQeTQrqF5RcBNRzy3QGgEKyg From: "Joseph Salowey \(jsalowey\)" To: "Alan DeKok" , "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1557; t=1177019105; x=1177883105; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20Request=20for=20RADIUS=20crypto-agility=20solutions |Sender:=20; bh=SlZX3QovYLTrrZCbk/qhbpkyzYnff2hQOahop5ehKKw=; b=WOSIFuNpfdIyHIAWyGCKnSm389JbBrroQWjDj3AKJ22mj8eK0WlhUzpnCSJNb6wIQBEHjIhH aehah8UruJHmivCgx/JR/O4VYJa6gyoEgpnapLwzGDAwVhNY9Sssj3CS; Authentication-Results: sj-dkim-5; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); I propose an attribute based crypto agility solution based on the following documents: http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.txt and http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt One of the goals of this approach is to reduce the impact on current RADIUS implementations by using attributes similar to existing attributes and not requiring "session state" between the RADIUS client and server. I believe this will be less impact on RADIUS implementations than the DTLS approach. Joe=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Wednesday, April 11, 2007 6:10 AM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: Re: Request for RADIUS crypto-agility solutions >=20 > Bernard Aboba wrote: > > This is a formal request for submission of documents solving the=20 > > RADIUS crypto-agility problem. Proposers should send an=20 > email to the RADEXT WG > > list providing a pointer to their proposal by April 21,=20 > 2007. Once the > > proposals have been submitted, we will initiate WG review. >=20 > I propose RADIUS + DTLS, as presented at IETF 68: >=20 > http://tools.ietf.org/id/draft-dekok-radext-dtls-00.txt >=20 > Alan DeKok. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Apr 2007 17:35:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-zorn-radius-keywrap-12.txt Date: Wed, 18 Apr 2007 10:34:37 -0700 Message-ID: Thread-Topic: comments on draft-zorn-radius-keywrap-12.txt Thread-Index: Acc+h8T3vcTG+DK/TwaOIlszkqLPkRDV2yZg From: "Joseph Salowey \(jsalowey\)" To: "Dan Harkins" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7227; t=1176917686; x=1177781686; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20comments=20on=20draft-zorn-radius-keywrap-12.txt |Sender:=20; bh=7Zb7vv0gsDrBBy4xmN1/UjFVy4vhMJZfSvXUIRhwZgE=; b=kLPzGAzRkDSBGEo4mxoVzOq+LdNhI0XB7tPT3ozGwVpIld1JLAzS+rcjNFerxj1nwDxullB3 O0P8a/MnJ6E5gUNhKZM06lHJGJLFbC12DiKE3ttZv6VBnODJQ/OH+/tz; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Hi Dan, Comments inline. > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dan Harkins > Sent: Monday, January 22, 2007 4:45 PM > To: radiusext@ops.ietf.org > Subject: comments on draft-zorn-radius-keywrap-12.txt >=20 >=20 > Hi, >=20 > I recently read draft-zorn-radius-keywrap-12.txt and have a few=20 > comments. I hope they can be addressed before this draft is advanced=20 > to RFC. >=20 > general: > * there is a real lack of requirements in this draft. Most things > are MAY and it looks like a compliant implementation could do > almost nothing, which seems odd for an RFC. Furthermore > interoperability will be extremely difficult since little=20 > behavior > MUST be followed. Ironically. one of the rare MUSTs in the draft > really should be a SHOULD. [Joe] There are interoperable implementations of this specification between different vendors, however the specification could probably be improved for clarity.=20 =20 > section 3.1: > * the Key ID, lifetime, IV and Key material fields MAY be omitted > but then the length of the keying material attribute would not > be >=3D 24 as defined later on when the layout of the attribute = is > defined. I suggest changing the length to be >=3D 8 and specify=20 > that > if any of these attributes are omitted then they MUST all be=20 > omitted > otherwise someone could legitimately omit one field and include > another and it would be impossible to parse the attribute on=20 > receipt. [Joe] I agree.=20 > * "if the client requires the use of the Keying-Material=20 > Attribute" > but it's not present then it "MAY ignore the message"?=20 > This should > be MUST or else "require" doesn't mean what I believe most=20 > people > think it means. >=20 [Joe] This seems reasonable to me.=20 > * KEK ID, KM ID are both unspecified. They are supposed to=20 > identify > the key but how? If the Frobnitz corporation defines the ID to=20 > be > sha("the KEK ID") and the Fubar corporation defines it as the > string "this is your KEK ID!" (both 20 bytes) then how do they > interoperate? 20 bytes? Why won't 4 do? Or even 2? Does this=20 > have > something to do with hashing to produce an ID? It's not=20 > specified. >=20 > Having unspecified things and then say "Further specification of > the > content of this field is outside the scope of this document"=20 > means > that specification in its entirety is outside the scope of this > document. That being the case then why is this even part of an=20 > IETF > document? These fields should be removed before the document is > advanced. >=20 > The KEK ID and KM ID, being entirely unspecified, are gigantic > subliminal channels. I really don't think that's appropriate. >=20 [Joe] I disagree here. The KEK ID is an opaque octet string to identify the key that is being used to encrypt the key. This document does not specify a way to establish a key and the KEK ID is there to facilitate different forms of key management. In particular the attributes are designed not to require additional state on the RADIUS server so the use of a KEK ID allows a new key to be brought into use. The KEK ID is necessary unless a particular key management scheme is specified that does not require it. =20 The KM ID serves to identify they key that is being transported. This definition of this is specified by the application for which the key is to be used. Incorporating this identity in the attribute reduces the need to have separate attributes for key ID which would be difficult to disambiguate if there are multiple attributes keys in the packet. The draft should specify that for a the EAP-MSK application this field is not used since there already is an attribute defined to hold the EAP-MSK ID. =20 > * if the Enc Type field is 0 then "the IV field MUST be as=20 > specified > in RFC3394". Is it supposed to be the "default IV"? If so then=20 > why > even bother sending it in the attribute? It would be painful to > make the attribute variable length-- i.e. if Enc Type field is 0 > then there is no IV field-- so why not change this MUST to a=20 > SHOULD? > Also, there may be legitimate reasons to use a different IV than > the > default one listed in RFC3394 (which is why that RFC allows it). >=20 [Joe] Apparently there are many different opinions on whether they IV MUST be the default specified in RFC 3394. Originally we meant it to be variable with the default suggested, however during expert review it was strongly suggested by an expert that it MUST be the default IV. =20 > section 3.3: > * MAC Key ID, same comments apply here as with KEK ID and KM ID=20 > above. > [Joe] Same comment as the KEK ID above. =20 > section 5: > * If two new keys are being defined then there is no point in=20 > having 3 > ID fields to identify them. They are implicitly identified here. > One > key is for key wrapping and the other key is used for integrity > checking. Again, there is no need for a KEK ID, KM ID, or MAC=20 > Key ID. >=20 [Joe] there are 3 keys the key used for MAC, the key used for key encryption and the key being encrypted. All are currently identified as they are different keys. As for the KEK and MAC keys it is possible for them to be derived from the same key or key exchange. If a key management mechanism is decided upon perhaps one of these fields may be deprecated. However, the freedom to be able to have these keys vary can facilitate different deployment models that are not possible with RADIUS today. =20 > * I think these two new keys MUST be cryptographically independent > of > the RADIUS shared secret (not SHOULD). The RADIUS shared secret > already has a defined use and it's not as a key deriving key.=20 > There > is no valid reason in any particular circumstance to ignore this > particular item (to paraphrase RFC2119). >=20 [Joe] We had some discussion of this among the authors. In general we all agreed that these keys SHOULD be independent of the RADIUS shared secret. We stopped short of mandating this because several felt that these new attributes provided a significant advantage over the current RADIUS mechanisms even if the current shared secret is used to facilitate deployment. Ideally we would be able to specify a key management mechanism that would allow for automated key exchange. =20 > I think it's great to have an RFC3394-style way to send keys from a=20 > RADIUS server to a RADIUS client but this seems to go way beyond that=20 > simple task. And there isn't any real apparent justification for those > excesses. KEK ID, KM ID, MAC Key ID... please just get rid of them. If > someone wants to pass VSAs then they should just pass VSAs. >=20 > thanks, >=20 > Dan. >=20 >=20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Apr 2007 18:32:38 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Proxy State and RFC 3576bis Date: Mon, 16 Apr 2007 11:31:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Good point. RFC 3576 implementers -- can you weigh in? >From: Alan DeKok >To: Bernard Aboba >CC: radiusext@ops.ietf.org >Subject: Re: Proxy State and RFC 3576bis >Date: Fri, 13 Apr 2007 03:06:18 +0200 > >Bernard Aboba wrote: > > [Alan DeKok] Yes. > > > > [BA] This suggests that paragraphs 3 and 4 in the text below are not > > correct. Any suggestions on how we can fix it? > > Before I do that, it would appear that my recommendation here is >opposite to what RFC 3576 says. Are we OK with changing the >recommendation in -bis? > > That is, do current implementations behave as per RFC 3576? If so, I >would prefer to maintain inter-operability. The text can then be left >as-is. > > If not, then the implementations do not use Proxy-State, and I would >prefer to replace the paragraphs with other text explaining why >Proxy-State is not used. The text in RFC 3576 permits implementations >to receive Proxy-State, but to not forward it. Maybe the >implementations have chosen that method. > > My preference is to have one recommended method of operation, rather >than 2-3. > > I'd like to get clarity on those questions before submitting suggested >text. > > 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: Mon, 16 Apr 2007 13:01:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: Publication of RADIUS Prepaid Document Date: Mon, 16 Apr 2007 15:00:05 +0200 Message-ID: <113091BD57179D4491C19DA7E10CD696D16283@mx1.office> Thread-Topic: Publication of RADIUS Prepaid Document Thread-Index: AceAJuZUKJy5A+mpQJ+O/YS8/836UwAACrXQ From: "Andreas Pashalidis" To: Dear all, No objections from my side.=20 (apologies for this late reply). Kind Regards, Andreas Pashalidis NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 Original Message: From: Bernard Aboba Sent: Wed 3/21/2007 6:26 AM To: radiusext@ops.ietf.org Subject: Publication of RADIUS Prepaid Document At IETF 68, it was suggested that the RADIUS Prepaid document be = published as an Informational RFC documenting existing usage (presumably = based on=20 RADIUS VSAs). This would enable us to unblock the document, since=20 conformance to the Guidelines document (still in progress) would no = longer be required. Are there any objections to this approach? -- to 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 Apr 2007 01:08:06 +0000 Message-ID: <461ED78A.4000003@nitros9.org> Date: Fri, 13 Apr 2007 03:06:18 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Proxy State and RFC 3576bis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > [Alan DeKok] Yes. > > [BA] This suggests that paragraphs 3 and 4 in the text below are not > correct. Any suggestions on how we can fix it? Before I do that, it would appear that my recommendation here is opposite to what RFC 3576 says. Are we OK with changing the recommendation in -bis? That is, do current implementations behave as per RFC 3576? If so, I would prefer to maintain inter-operability. The text can then be left as-is. If not, then the implementations do not use Proxy-State, and I would prefer to replace the paragraphs with other text explaining why Proxy-State is not used. The text in RFC 3576 permits implementations to receive Proxy-State, but to not forward it. Maybe the implementations have chosen that method. My preference is to have one recommended method of operation, rather than 2-3. I'd like to get clarity on those questions before submitting suggested text. 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, 12 Apr 2007 19:14:04 +0000 Message-ID: <461E8491.6060406@nitros9.org> Date: Thu, 12 Apr 2007 21:12:17 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Proxies and retransmissions? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Proxy retransmission is definitely a bad idea, since it violates the > principle of "Conservation of Packts", and thus could lead to congestion > problems. I don't have personal knowledge of proxy implementations that > retransmit, but then again I wouldn't be surprised if such > implementations existed. I've just been reviewing a proposal for a standardized RADIUS fail-over and retransmit. It involves N stages of proxies, each with primary & secondary. On NAS retransmit, each proxy is supposed to send packets to both the primary and secondary. The document states that there's obviously an exponential explosion in the number of packets, but for small N, it's claimed to be OK. I don't agree. 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, 12 Apr 2007 15:57:25 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org, radiusext@ops.ietf.org Bcc: Subject: RE: Proxies and retransmissions? Date: Thu, 12 Apr 2007 08:56:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > I think it's best to say intermediate nodes SHOULD NOT retransmit of >their own accord. They should do so only when they receive a retransmit >from the NAS. > > Is this an issue we need to address? How do current implementations >deal with retransmits? Proxy retransmission is definitely a bad idea, since it violates the principle of "Conservation of Packts", and thus could lead to congestion problems. I don't have personal knowledge of proxy implementations that retransmit, but then again I wouldn't be surprised if such implementations existed. -- to 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 Apr 2007 15:49:36 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Proxy State and RFC 3576bis Date: Thu, 12 Apr 2007 08:49:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Bernard Aboba wrote: >One of the deployment blockers with RFC 3576 is the need to modify >proxies to handle routing of RFC 3576 packets. While proxies typically >keep tables for dowstream forwarding, they typically do not keep tables >Given this, I am wondering how RADIUS proxies should handle Proxy-State >for RFC 3576 packets: > >a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as >suggested in the current text (and as would be done for an Access-Request)? [Alan DeKok] No. >b. Or can the RADIUS server include a Proxy-State attribute previously >obtained from an Access-Request used in the original authentication >within the Disconnect/CoA-Request to assist the proxy in routing the >request back to the NAS? In this case, wouldn't the RADIUS proxy >*remove* Proxy-State attributes from the Disconnect/CoA-Request?? [Alan DeKok] Yes. [BA] This suggests that paragraphs 3 and 4 in the text below are not correct. Any suggestions on how we can fix it? --------------- If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy or NAS MUST include those Proxy-State Attributes in its response to the server. A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet. The forwarding proxy or NAS MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous proxies. The forwarding proxy MUST NOT modify any other Proxy-State Attributes that were in the packet; it may choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The forwarding proxy MUST NOT change the order of any attributes of the same type, including Proxy-State. Other Attributes can be placed before, after or even between the Proxy-State Attributes. When the proxy receives a response to a CoA-Request or Disconnect- Request, it MUST remove its own Proxy-State (the last Proxy- State in the packet) before forwarding the response. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. -- to 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 Apr 2007 14:57:06 +0000 Message-ID: <461E4869.9080400@nitros9.org> Date: Thu, 12 Apr 2007 16:55:37 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Avi Lior wrote: > [Avi] Sorry i must be missing something. Can you explain what you mean > by non-qualified attribute names or qualified attribute name. Qualified attribute name: SDO-Attribute-Foo Unqualified attribute name: Attribute-Foo > [Avi] Sorry Alan but i don't get it. We never work with attribute names > themselves we work with Vendor Specific Dictionaries so all attributes > are always relative to a dictionary. So there is no confusion. The qualified attribute names are an attempt to enforce naming relative to a dictionary. Let's take RFC 4679 as an example. It defines Agent-Circuit-Id, among other attributes. As a vendor, Redback also defines Agent-Circuit-Id. If we simply refer to Agent-Circuit-Id, that name is ambiguous. We could say "RFC 4679 Agent-Circuit-Id", and "Redback VSA Agent-Circuit-Id". Or, we could say "ADSL-Agent-Circuit-Id", and "Redback-Agent-Circuit-Id". I prefer the second method. > [Avi] If you are thinking of suggesting that SDO prefix their attributes > with the SDOs name. That could be a good idea. Its a little too late. > And would require that we create a registry for SDO prefixes. But I am > not sure that this really helps. It may make it easier for humans to read. The 3GPP && 3GPP2 forums have already done this. We can request that SDOs do this for future work. > [Avi] The conflict is in the human brain but not in the protocol. Right? And in the implementation that has to parse "Agent-Circuit-Id", and try to guess which SDO or vendor it applies to. Ambiguity does not result in interoperable implementations. > [Avi] I am not opposed to it but I dont think its as big a problem as > you make it out to be. It's been a problem for me, and for the people I have to support. > [Avi] X_DNS_NAME and Y_DNS_NAME is equally confusing. And we already > of namespaces. If someone gave me a policy if IF X == 1.2.3.4 I would > ask which Vendor Dictionary are you using for X. Why do that when you can just refer to the fully qualified name? > By the way that is a > human readable policy not an actual policy. That policy would translate > X to something like (26,2234,45). The administrator may be typing in the name, rather than selecting it from a drop-down menu. With a drop down menu, that qualification can happen automatically, because the context for the name is available. If the name is entered as a test string, additional qualification is needed to resolve ambiguity. And humans need to be able to discuss policy, too. We're not going to talk about (26,2234,45) on this list. (Or at least, I can't be bothered to remember those numbers). We can talk about Agent-Circuit-Id, though. > [Avi] Why do you think SDOs are stupid? They change the > meaning/definition of an attribute like smart people at the IETF do. > For example, adding a new enumeration to an enumerated type. Or when a > bug is found. Or the semantics of an attribute can change as well while > still maintianing backwards compatibility. The semantics of an attribute can be clarified without changing its meaning. If the meaning changes, then I don't understand how the "same" attribute can be used simultaneously with two different meanings. Maybe I'm the one that's stupid, but I just don't see how it can work. 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, 12 Apr 2007 14:33:53 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D0F.A50F527A" Subject: RE: Guidelines Document Discussion Date: Thu, 12 Apr 2007 10:34:15 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "Bernard Aboba" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D0F.A50F527A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183 -----Original Message----- From: Alan DeKok [mailto:aland@nitros9.org] Sent: Thu 4/12/2007 4:01 AM To: Avi Lior Cc: Bernard Aboba; radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion =20 Avi Lior wrote: > i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK. > [Avi] When I said name space I mean an implicit name-space. I don't > think that vendors and operators be required to call their attribute > SDO-A-Foobar. The vendor id creates a name-space and that is > sufficient. I strongly disagree. Vendors or SDOs who use non-qualified attribute names have caused interoperability problems in the past, and will continue to do so in the future. [Avi] Sorry i must be missing something. Can you explain what you mean = by non-qualified attribute names or qualified attribute name. > The actual naming of the attribute is for human > readability. And for policies. If the policy says "Do X if DNS-Server is set to 1.2.3.4", what does that mean when two SDO's define the same name? SDO namespaces allow clear policies to be created. Non-SDO namespaces allow policies to be created that cannot be meaningfully interpreted. [Avi] Sorry Alan but i don't get it. We never work with attribute names = themselves we work with Vendor Specific Dictionaries so all attributes = are always relative to a dictionary. So there is no confusion. [Avi] If you are thinking of suggesting that SDO prefix their attributes = with the SDOs name. That could be a good idea. Its a little too late. = And would require that we create a registry for SDO prefixes. But I am = not sure that this really helps. It may make it easier for humans to = read. > [Avi] it's a fact of life that two SDOs can and probably will define > attribute that have the same name. They are operating autonomously. Then the RADIUS guidelines document needs to say that the attribute names should be prefixed with the SDO name, to obtain an SDO-specific namespace. They can then operate autonomously without the possibility of conflict. [Avi] The conflict is in the human brain but not in the protocol. Right? [Avi] This is not a RADIUS only problem by the way. It is an IETF = problem since VSA are defined by many protocols. [Avi] I am not opposed to it but I dont think its as big a problem as = you make it out to be. > When working in one SDO I am not checking the attributes of another = SDOs > or other vendors. Its not practical. I don't know about all the SDOs > or all the vendors. Lets get real here. Yes. Which is why prefixes create independent name spaces, and do not require coordination. Allowing SDO's to create names *without* prefixes has all of the problems you highlight, and all of the problems I highlight. Why not avoid both problems by using namespaces? [Avi] X_DNS_NAME and Y_DNS_NAME is equally confusing. And we already = of namespaces. If someone gave me a policy if IF X =3D=3D 1.2.3.4 I = would ask which Vendor Dictionary are you using for X. By the way that = is a human readable policy not an actual policy. That policy would = translate X to something like (26,2234,45). =20 Even if we had a prefix, I still would not rely on that prefix when = writting the policy down. I still would use X plus dictionary name. Or = I would say X as defined by some reference so I know the context of the = attribute. > Attributes change their meaning? That's bad practice. >=20 > [Avi] Meaning or semantics. Well that is just the way the cookie > crumbles sometimes. It is precisely dogma like that that make some = SDOs > nervous about sharing. That's an interesting approach. SDO's change the meaning of attributes so that existing implementations and deployments are non-compliant with the new meanings. Existing implementations and deployments are also non-interoperable with new deployments that understand the new meaning. And it makes the SDO's nervous to have this pointed out? Curious. Or maybe I misunderstood exactly how the SDO's change the meaning of attributes, while maintaining backwards compatibility and interoperability. [Avi] Why do you think SDOs are stupid? They change the = meaning/definition of an attribute like smart people at the IETF do. = For example, adding a new enumeration to an enumerated type. Or when a = bug is found. Or the semantics of an attribute can change as well while = still maintianing backwards compatibility. Alan DeKok. ------_=_NextPart_001_01C77D0F.A50F527A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Guidelines Document Discussion

Avi Lior
Office: +1 613 591-9104 x 6417
Cell  : +1 613 796-4183



-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org]
Sent: Thu 4/12/2007 4:01 AM
To: Avi Lior
Cc: Bernard Aboba; radiusext@ops.ietf.org
Subject: Re: Guidelines Document Discussion

Avi Lior wrote:
>   i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server = are OK.
> [Avi] When I said name space I mean an implicit name-space.  I = don't
> think that vendors and operators be required to call their = attribute
> SDO-A-Foobar.  The vendor id creates a name-space and that = is
> sufficient.

  I strongly disagree.  Vendors or SDOs who use non-qualified = attribute
names have caused interoperability problems in the past, and will
continue to do so in the future.

[Avi] Sorry i must be missing something.  Can you explain what you = mean by non-qualified attribute names or qualified attribute name.


>  The actual naming of the attribute is for human
> readability.

  And for policies.  If the policy says "Do X if = DNS-Server is set to
1.2.3.4", what does that mean when two SDO's define the same = name?

  SDO namespaces allow clear policies to be created.  Non-SDO = namespaces
allow policies to be created that cannot be meaningfully = interpreted.


[Avi] Sorry Alan but i don't get it.  We never work with attribute = names themselves we work with Vendor Specific Dictionaries so all = attributes are always relative to a dictionary.  So there is no = confusion.

[Avi] If you are thinking of suggesting that SDO prefix their attributes = with the SDOs name.  That could be a good idea.  Its a little = too late. And would require that we create a registry for SDO = prefixes.  But I am not sure that this really helps.  It may = make it easier for humans to read.



> [Avi] it's a fact of life that two SDOs can and probably will = define
> attribute that have the same name.  They are operating = autonomously.

  Then the RADIUS guidelines document needs to say that the = attribute
names should be prefixed with the SDO name, to obtain an = SDO-specific
namespace.  They can then operate autonomously without the = possibility
of conflict.

[Avi] The conflict is in the human brain but not in the protocol. = Right?

[Avi] This is not a RADIUS only problem by the way.  It is an IETF = problem since VSA are defined by many protocols.

[Avi] I am not opposed to it but I dont think its as big a problem as = you make it out to be.

> When working in one SDO I am not checking the attributes of another = SDOs
> or other vendors.  Its not practical.  I don't know about = all the SDOs
> or all the vendors.  Lets get real here.

  Yes.  Which is why prefixes create independent name spaces, = and do not
require coordination.  Allowing SDO's to create names *without* = prefixes
has all of the problems you highlight, and all of the problems I
highlight.  Why not avoid both problems by using namespaces?

[Avi]  X_DNS_NAME and Y_DNS_NAME is equally confusing.  And we = already of namespaces.  If someone gave me a policy if IF X =3D=3D = 1.2.3.4 I would ask which Vendor Dictionary are you using for X.  = By the way that is a human readable policy not an actual policy.  = That policy would translate X to something like (26,2234,45). 

Even if we had a prefix, I still would not rely on that prefix when = writting the policy down.  I still would use X plus dictionary = name.  Or I would say X as defined by some reference so I know the = context of the attribute.





>   Attributes change their meaning?  That's bad = practice.
>
> [Avi] Meaning or semantics. Well that is just the way the = cookie
> crumbles sometimes.  It is precisely dogma like that that make = some SDOs
> nervous about sharing.

  That's an interesting approach.  SDO's change the meaning = of
attributes so that existing implementations and deployments are
non-compliant with the new meanings.  Existing implementations = and
deployments are also non-interoperable with new deployments that
understand the new meaning.  And it makes the SDO's nervous to have = this
pointed out?

  Curious.  Or maybe I misunderstood exactly how the SDO's = change the
meaning of attributes, while maintaining backwards compatibility and
interoperability.

[Avi] Why do you think SDOs are stupid?  They change the = meaning/definition of an attribute like smart people at the IETF = do.  For example, adding a new enumeration to an enumerated type. = Or when a bug is found.  Or the semantics of an attribute can = change as well while still maintianing backwards compatibility.

  Alan DeKok.

------_=_NextPart_001_01C77D0F.A50F527A-- -- to 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 Apr 2007 14:04:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D0B.8B67F15F" Subject: RE: Guidelines Document Discussion Date: Thu, 12 Apr 2007 10:02:11 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D0B.8B67F15F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >[Avi] Given the IETF is a common denominator across SDOs, a way forward >perhaps is to encourage SDOs to publish their dictionaries as >INFORMATIONAL RFCs. And perhaps to register their Dictionaries in = IANA. I agree that this would be a good thing. If it were done, do you think = that=20 SDOs would be more willing to reuse attributes from other SDOs? [Avi] At least they will know about them. That would be a start. But = there is still the control thing. [Avi] Here is a question for you. Do you think the IETF would use the = VSAs defined by an SDO? MS-MPPE... is such an example I guess. ------_=_NextPart_001_01C77D0B.8B67F15F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Guidelines Document Discussion

>[Avi] Given the IETF is a common denominator = across SDOs, a way forward
>perhaps is to encourage SDOs to publish their dictionaries as
>INFORMATIONAL RFCs.  And perhaps to register their Dictionaries = in IANA.

I agree that this would be a good thing.  If it were done, do you = think that
SDOs would be more willing to reuse attributes from other SDOs?

[Avi] At least they will know about them.  That would be a start. = But there is still the control thing.

[Avi] Here is a question for you.  Do you think the IETF would use = the VSAs defined by an SDO?  MS-MPPE... is such an example I = guess.

------_=_NextPart_001_01C77D0B.8B67F15F-- -- to 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 Apr 2007 13:53:39 +0000 Message-ID: <461E3987.8030106@nitros9.org> Date: Thu, 12 Apr 2007 15:52:07 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: radext mailing list Subject: Proxies and retransmissions? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I noticed recently that retransmissions by intermediate nodes wasn't covered in the Issues & Fixes draft. I'm not proposing that we add more text to it, but the issue is one that's come up recently in SDO's. This topic was discussed earlier: http://www1.tools.ietf.org/wg/radext/minutes?item=minutes58.html ... - some implementations retransmitting at intermediate [proxy] nodes - recommendations: no retransmission from [proxy] intermediate nodes (but track retransmission) ... I think it's best to say intermediate nodes SHOULD NOT retransmit of their own accord. They should do so only when they receive a retransmit from the NAS. Is this an issue we need to address? How do current implementations deal with retransmits? 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, 12 Apr 2007 08:02:40 +0000 Message-ID: <461DE76E.1060202@nitros9.org> Date: Thu, 12 Apr 2007 10:01:50 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Avi Lior wrote: > i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK. > [Avi] When I said name space I mean an implicit name-space. I don't > think that vendors and operators be required to call their attribute > SDO-A-Foobar. The vendor id creates a name-space and that is > sufficient. I strongly disagree. Vendors or SDOs who use non-qualified attribute names have caused interoperability problems in the past, and will continue to do so in the future. > The actual naming of the attribute is for human > readability. And for policies. If the policy says "Do X if DNS-Server is set to 1.2.3.4", what does that mean when two SDO's define the same name? SDO namespaces allow clear policies to be created. Non-SDO namespaces allow policies to be created that cannot be meaningfully interpreted. > [Avi] it's a fact of life that two SDOs can and probably will define > attribute that have the same name. They are operating autonomously. Then the RADIUS guidelines document needs to say that the attribute names should be prefixed with the SDO name, to obtain an SDO-specific namespace. They can then operate autonomously without the possibility of conflict. > When working in one SDO I am not checking the attributes of another SDOs > or other vendors. Its not practical. I don't know about all the SDOs > or all the vendors. Lets get real here. Yes. Which is why prefixes create independent name spaces, and do not require coordination. Allowing SDO's to create names *without* prefixes has all of the problems you highlight, and all of the problems I highlight. Why not avoid both problems by using namespaces? > Attributes change their meaning? That's bad practice. > > [Avi] Meaning or semantics. Well that is just the way the cookie > crumbles sometimes. It is precisely dogma like that that make some SDOs > nervous about sharing. That's an interesting approach. SDO's change the meaning of attributes so that existing implementations and deployments are non-compliant with the new meanings. Existing implementations and deployments are also non-interoperable with new deployments that understand the new meaning. And it makes the SDO's nervous to have this pointed out? Curious. Or maybe I misunderstood exactly how the SDO's change the meaning of attributes, while maintaining backwards compatibility and interoperability. 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, 12 Apr 2007 07:48:55 +0000 Message-ID: <461DE425.8080704@nitros9.org> Date: Thu, 12 Apr 2007 09:47:49 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Proxy State and RFC 3576bis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > One of the deployment blockers with RFC 3576 is the need to modify > proxies to handle routing of RFC 3576 packets. While proxies typically > keep tables for dowstream forwarding, they typically do not keep tables > for upstream forwarding. Rather, they typically rely on the Proxy-State > attribute to enable forwarding of an Access-Response back to the > originating NAS. I've been working with sites recently to deploy RFC 3576 solutions. We've found out that the simplest way to perform upstream forwarding is to keep session state in DB's for all intermediate nodes. i.e. We ignore Proxy-State. When there is a failover relationship between two servers for downstream forwarding, DBN replication is used to ensure that both share the same information for upstream forwarding. That is, the packets may traverse different paths going downstream and upstream. However, since servers in a failover relationship are "identical", they should behave identically for up/downstream forwarding. > Given this, I am wondering how RADIUS proxies should handle Proxy-State > for RFC 3576 packets: > > a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as > suggested in the current text (and as would be done for an Access-Request)? No. > b. Or can the RADIUS server include a Proxy-State attribute previously > obtained from an Access-Request used in the original authentication > within the Disconnect/CoA-Request to assist the proxy in routing the > request back to the NAS? In this case, wouldn't the RADIUS proxy > *remove* Proxy-State attributes from the Disconnect/CoA-Request?? Yes. However, Proxy-State is almost entirely useless. For downstream forwarding, we can't key off of the Proxy-State in replies to find the corresponding request, because some implementations historically mangled Proxy-State, in defiance of the RFC requirements. Therefore, it's best for the server to keep internal tables for downstream forwarding, and use those tables to match replies to requests. Proxy-State is added for RFC compliance, but is otherwise ignored. The contents are never examined to match replies to requests. For RFC 3576 behavior, once sessions are kept in a DB, Proxy-State is also useless. Since Proxy-State isn't signed or authenticated, and since it can be mangled by intermediate nodes, it can't be used by an intermediate node as the basis for any decision. If we ignore deployment issues, a solution to the upstream routing problem would be add a new attribute. This attribute would be added on downstream proxying by intermediate nodes, just like Proxy-State. But it would be signed and authenticated at each hop. Its contents would be sufficient information for the upstream path to make a forwarding decision, independent of any other data. Intermediate nodes therefore become stateless, and servers in a failover relationship do not have to contact each other to maintain information about upstream paths for sessions. This means that all of the proxying servers would have to support this attribute, and that the final home server would have to store N copies of the attribute per session, one for each intermediate hop. It would also allow intermediate nodes to catch routing loops, as they could potentially examine all copies of the new attribute for "their" copy. Since all proxies have to be updated from base RFC 2865 functionality to support RFC 3576 upstream routing, this proposal might just work. 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, 12 Apr 2007 00:39:34 +0000 Date: Wed, 11 Apr 2007 17:39:18 -0700 Message-Id: <200704120039.l3C0dIpE028976@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4818 on RADIUS Delegated-IPv6-Prefix Attribute From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4818 Title: RADIUS Delegated-IPv6-Prefix Attribute Author: J. Salowey, R. Droms Status: Standards Track Date: April 2007 Mailbox: jsalowey@cisco.com, rdroms@cisco.com Pages: 7 Characters: 12993 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-delegated-prefix-05.txt URL: http://www.rfc-editor.org/rfc/rfc4818.txt This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to 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 Apr 2007 00:38:55 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proxy State and RFC 3576bis Date: Wed, 11 Apr 2007 17:38:40 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed One of the deployment blockers with RFC 3576 is the need to modify proxies to handle routing of RFC 3576 packets. While proxies typically keep tables for dowstream forwarding, they typically do not keep tables for upstream forwarding. Rather, they typically rely on the Proxy-State attribute to enable forwarding of an Access-Response back to the originating NAS. Given this, I am wondering how RADIUS proxies should handle Proxy-State for RFC 3576 packets: a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as suggested in the current text (and as would be done for an Access-Request)? b. Or can the RADIUS server include a Proxy-State attribute previously obtained from an Access-Request used in the original authentication within the Disconnect/CoA-Request to assist the proxy in routing the request back to the NAS? In this case, wouldn't the RADIUS proxy *remove* Proxy-State attributes from the Disconnect/CoA-Request?? FYI, here is the current text on Proxy-State in -04: If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy or NAS MUST include those Proxy-State Attributes in its response to the server. A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet. The forwarding proxy or NAS MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous proxies. The forwarding proxy MUST NOT modify any other Proxy-State Attributes that were in the packet; it may choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. If a Proxy-State Attribute is added to a packet when forwarding the packet, the Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The forwarding proxy MUST NOT change the order of any attributes of the same type, including Proxy-State. Other Attributes can be placed before, after or even between the Proxy-State Attributes. When the proxy receives a response to a CoA-Request or Disconnect- Request, it MUST remove its own Proxy-State (the last Proxy- State in the packet) before forwarding the response. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. -- to 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 Apr 2007 00:26:40 +0000 Message-ID: From: "Bernard Aboba" To: avi@bridgewatersystems.com, aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Guidelines Document Discussion Date: Wed, 11 Apr 2007 17:25:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[Avi] Given the IETF is a common denominator across SDOs, a way forward >perhaps is to encourage SDOs to publish their dictionaries as >INFORMATIONAL RFCs. And perhaps to register their Dictionaries in IANA. I agree that this would be a good thing. If it were done, do you think that SDOs would be more willing to reuse attributes from other SDOs? -- to 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 Apr 2007 19:51:11 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-04.txt Message-Id: Date: Wed, 11 Apr 2007 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Author(s) : M. Chiba, et al. Filename : draft-ietf-radext-rfc3576bis-04.txt Pages : 34 Date : 2007-4-11 This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-rfc3576bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-rfc3576bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-11110833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-rfc3576bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-rfc3576bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-11110833.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to 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 Apr 2007 16:30:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines Document Discussion Date: Wed, 11 Apr 2007 12:31:05 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" Cc: "Bernard Aboba" , Alan see inline,=20 Avi Lior wrote: > [Avi] The name space for a VSA is defined -- it the SDOs (or vendors=20 > namespace). I don't know what else you would do. ... > [Avi] The reality is that one SDO may define DNS-Server because it=20 > does not know that another attribute by that name is already defined. > There is no global repository for looking up what other SDO have done. Which appears to contract your previous statement. i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK. [Avi] When I said name space I mean an implicit name-space. I don't think that vendors and operators be required to call their attribute SDO-A-Foobar. The vendor id creates a name-space and that is sufficient. The actual naming of the attribute is for human readability. Having said that, it would be nice if a vendor did want their attribute to be widely used that they did somehow decorated the name with the vendor designation as Microsoft did (I assume that the MSS of the MSS-MPPE... Attribute is for Microsoft).=20 Both SDO's defining "DNS-Server" without qualification is not OK. [Avi] it's a fact of life that two SDOs can and probably will define attribute that have the same name. They are operating autonomously. When working in one SDO I am not checking the attributes of another SDOs or other vendors. Its not practical. I don't know about all the SDOs or all the vendors. Lets get real here. [Avi] As to the qualification part, I am sure when an SDO defines DNS-Server they do provide both the definition for the attribute and the semantics for its use. > [Avi] There is apprehension and that relates to change control. If I=20 > use an attribute x from VendorA, then I need assurances that if that=20 > attribute is going to change or that I would be consulted or be=20 > notified when such a change occurs. Attributes change their meaning? That's bad practice. [Avi] Meaning or semantics. Well that is just the way the cookie crumbles sometimes. It is precisely dogma like that that make some SDOs nervous about sharing. > [Avi] Given the IETF is a common denominator across SDOs, a way=20 > forward perhaps is to encourage SDOs to publish their dictionaries as=20 > INFORMATIONAL RFCs. And perhaps to register their Dictionaries in IANA. I agree. 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 Apr 2007 16:14:15 +0000 Message-ID: <461D0915.3070904@nitros9.org> Date: Wed, 11 Apr 2007 18:13:09 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Avi Lior wrote: > [Avi] The name space for a VSA is defined -- it the SDOs (or vendors > namespace). I don't know what else you would do. ... > [Avi] The reality is that one SDO may define DNS-Server because it does > not know that another attribute by that name is already defined. There > is no global repository for looking up what other SDO have done. Which appears to contract your previous statement. i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK. Both SDO's defining "DNS-Server" without qualification is not OK. > [Avi] There is apprehension and that relates to change control. If I > use an attribute x from VendorA, then I need assurances that if that > attribute is going to change or that I would be consulted or be notified > when such a change occurs. Attributes change their meaning? That's bad practice. > [Avi] Given the IETF is a common denominator across SDOs, a way forward > perhaps is to encourage SDOs to publish their dictionaries as > INFORMATIONAL RFCs. And perhaps to register their Dictionaries in IANA. I agree. 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 Apr 2007 16:02:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines Document Discussion Date: Wed, 11 Apr 2007 12:02:47 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , Cc: Hi, Please see inline....=20 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, April 11, 2007 11:39 AM To: aland@nitros9.org; Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion > If the name space is SDO-specific. "SDO-Attribute-Foo". I don't=20 >see why the IETF would not honor such name spaces. [Avi] The name space for a VSA is defined -- it the SDOs (or vendors namespace). I don't know what else you would do. > > Having SDOs define attributes *without* a specific name-space leads=20 >to problems. Common terms are... common. Is "DNS-Server" a good=20 >attribute name for multiple SDO's to define? Probably not. This makes sense to me; it probably should be part of design guidelines. [Avi] The reality is that one SDO may define DNS-Server because it does not know that another attribute by that name is already defined. There is no global repository for looking up what other SDO have done. >Interoperability where we don't have to write or maintain a RADIUS=20 >server implementation for every SDO. VSA's and name spaces are useful=20 >here, because they mean that one RADIUS server deployment can=20 >interoperate with multiple SDO's simultaneously. Right. That is a good goal, I think. There is no good reason why one SDO shouldn't be able to reuse VSAs from another SDO,=20 [Avi] There is apprehension and that relates to change control. If I use an attribute x from VendorA, then I need assurances that if that attribute is going to change or that I would be consulted or be notified when such a change occurs. [Avi] A great example of a widely used VSA is the Microsoft MS-MPPE-SEND-KEY etc. because it was published as an RFC. How many other SDOs publish their attributes as RFCs.=20 =20 or why configuring a RADIUS server to send a VSA should be any more complex than configuring the same server to send an attribute from the Standards space. We need to make it easier to incorporate VSAs into standard RADIUS implementations. [Avi] Given the IETF is a common denominator across SDOs, a way forward perhaps is to encourage SDOs to publish their dictionaries as INFORMATIONAL RFCs. And perhaps to register their Dictionaries in IANA. -- to 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 Apr 2007 15:44:13 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: avi@bridgewatersystems.com, radiusext@ops.ietf.org Bcc: Subject: Re: Guidelines Document Discussion Date: Wed, 11 Apr 2007 08:43:54 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > > Right. Assuming that the SDOs utilize similar attribute formats, and > > the specifications are published, this should work. In particular, I > > would like to eliminate the need for SDOs to utilize RADIUS standard > > attributes just in order to have their specification widely > > disseminated. In the long term the IETF should strive to assist SDOs in > > defining their own RADIUS attributes. > > That is a very good idea. It would enhance interoperability, and >reduce problems. There is no inherent reason why SDO-defined RADIUS attributes are any less "legitimate" than ones defined by the IETF. I am puzzled by documents such as the RADIUS MIPv4 specification, which claim that the solution to interoperability issues between SDO-defined VSAs is to define attributes in the IETF standards space. You cannot solve an interoperability problem by creating *yet another* way to do something, particularly if the new way has to be significantly different from the existing VSA attributes, due to differences in the data models. In such a case, it seems better to me to start from a single deployed set of VSA attributes, enhancing them with additional VSAs or standards space attributes as necessary. -- to 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 Apr 2007 15:39:40 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org, avi@bridgewatersystems.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Guidelines Document Discussion Date: Wed, 11 Apr 2007 08:38:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > If the name space is SDO-specific. "SDO-Attribute-Foo". I don't see >why the IETF would not honor such name spaces. > > Having SDOs define attributes *without* a specific name-space leads to >problems. Common terms are... common. Is "DNS-Server" a good attribute >name for multiple SDO's to define? Probably not. This makes sense to me; it probably should be part of design guidelines. >Interoperability where we don't have to write or maintain a RADIUS >server implementation for every SDO. VSA's and name spaces are useful >here, because they mean that one RADIUS server deployment can >interoperate with multiple SDO's simultaneously. Right. That is a good goal, I think. There is no good reason why one SDO shouldn't be able to reuse VSAs from another SDO, or why configuring a RADIUS server to send a VSA should be any more complex than configuring the same server to send an attribute from the Standards space. We need to make it easier to incorporate VSAs into standard RADIUS implementations. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Apr 2007 13:26:48 +0000 Message-ID: <461CE1E3.4020900@nitros9.org> Date: Wed, 11 Apr 2007 15:25:55 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avi Lior CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Avi Lior wrote: > I don't think we could standerdize a VSA encoding. But at least we can > make a recommendation on how an VSA could be encoded. I would offer the > WiMAX encoding as a good example. It aligns with the RADIUS attribute > extension encoding at least in the header. And for the payload it allows > a structured types -- like 3GPP2. Sounds good to me. > - 1 or 2 byte VSA's for "efficiency" where "integer" type would do > [Avi]You mean prohibit the use of 1 or 2 byte TLVs where an integer > would do? If yes I disagree. RADIUS packets are getting smaller and > smaller these days? If I have an enumeration (of TRUE or FALSE) using a > 32-bit value is wasteful in view of the size limitation of both > attributes and packet size. I don't see it as necessary. I won't object if other people think it's necessary, though. > - SDO-specific interpretations of existing RADIUS commands, attributes, > or values for "integer" attributes. > [Avi] Not sure I understand the "...values for integer" part. e.g. 'Service-Type = Foo' doesn't mean "Foo", it means something else. Not that Service-Type is the problem... the problem is people saying "Foo doesn't really apply, but it's the closest of the existing standards to what we want, so we'll just use it." > - SDO's publishing standards that use existing standardized attribute > names for SDO-specific attributes, or which use confusingly similar > names > > [Avi] A good idea for readability. But not a show stopper. Is the IETF > willing to also honor SDOs name spaces? Probably not. If the name space is SDO-specific. "SDO-Attribute-Foo". I don't see why the IETF would not honor such name spaces. Having SDOs define attributes *without* a specific name-space leads to problems. Common terms are... common. Is "DNS-Server" a good attribute name for multiple SDO's to define? Probably not. > SDO's and vendors should be reminded that the goal of VSA's is to > obtain interoperability. > > [Avi] interoperability within the SDO or with others? I think within > the SDO primarily. To achieve interoperability between SDOs, and SDO is > free to use another SDOs attributes. It would be helpful for us RADIUS > vendors if the encoding was the same though. Interoperability where we don't have to write or maintain a RADIUS server implementation for every SDO. VSA's and name spaces are useful here, because they mean that one RADIUS server deployment can interoperate with multiple SDO's simultaneously. 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 Apr 2007 13:16:01 +0000 Message-ID: <461CDF64.5060503@nitros9.org> Date: Wed, 11 Apr 2007 15:15:16 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: avi@bridgewatersystems.com, radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Avi wrote: >> If I have an enumeration (of TRUE or FALSE) using a >> 32-bit value is wasteful in view of the size limitation of both >> attributes and packet size. > > Are you saying that the VSA space should allow one octet or two octet > data types? I don't see why. While it may be useful, a quick perusal of the dictionaries shows few existing definitions of one or two-byte data types. > We could certainly recommend the use of unique name spaces for VSAs > (e.g. SDO-Name) so as to avoid confusion. By all means, yes. Since only attribute spaces were deemed to be vendor-specific, vendors have used non-unique name spaces for VSA's, making inter-operation with multiple vendors more difficult. >> [Avi] interoperability within the SDO or with others? I think within >> the SDO primarily. To achieve interoperability between SDOs, and SDO is >> free to use another SDOs attributes. It would be helpful for us RADIUS >> vendors if the encoding was the same though. > > Right. Assuming that the SDOs utilize similar attribute formats, and > the specifications are published, this should work. In particular, I > would like to eliminate the need for SDOs to utilize RADIUS standard > attributes just in order to have their specification widely > disseminated. In the long term the IETF should strive to assist SDOs in > defining their own RADIUS attributes. That is a very good idea. It would enhance interoperability, and reduce problems. 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 Apr 2007 13:11:59 +0000 Message-ID: <461CDE43.5040104@nitros9.org> Date: Wed, 11 Apr 2007 15:10:27 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for RADIUS crypto-agility solutions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > This is a formal request for submission of documents solving the RADIUS > crypto-agility problem. Proposers should send an email to the RADEXT WG > list providing a pointer to their proposal by April 21, 2007. Once the > proposals have been submitted, we will initiate WG review. I propose RADIUS + DTLS, as presented at IETF 68: http://tools.ietf.org/id/draft-dekok-radext-dtls-00.txt 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, 10 Apr 2007 21:16:21 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: Issue 130: Diameter Compatibility (traffic-rule-draft) Date: Tue, 10 Apr 2007 14:16:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Propose resolution to be the current Diameter Considerations section in >draft -02. This uses the same approach as RFC4675. Looks good. -- to 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, 10 Apr 2007 21:15:29 +0000 Message-ID: From: "Bernard Aboba" To: mauricio.sanchez@hp.com, radiusext@ops.ietf.org Bcc: Subject: RE: Issue 111: Accounting (traffic-rule-draft) Date: Tue, 10 Apr 2007 14:14:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >In light that the treatment of accounting behavior would be best treated >elsewhere, such as in 3576bis, I would suggest that we omit any discussion >of accounting behavior in this draft. This means that sections 1.4 would >be >modified and section A.3 would be eliminated to remove accounting >references. > >Does this seem like a reasonable path? Yes. -- to 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, 10 Apr 2007 19:54:06 +0000 DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=amvZOXQky3Jc4AQBWzKjpdLAgXA/I2wQJDyLZKSqDof3cfvbGdQhAGTb1KYoyj4XdpUT+JsScG89okV1amLZJKY659RE6eki/g6Y6TcojCvNhrEzEgMT6CC4Xm+Ke52TtvGkhtt8mCdc0DbkDoabulC+tO8GRP+lSOUpRIEZ31Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=VVKVSFlYwVjJuvcc6OJpEgflvWM9ojnMA8SlGqZlb1plFxcFWNpjji2rK18AdVCnBhH3zk+A3b5b2iC+6c8PACTfqsEZka7VQsrSHW8PAKbzdYKlfnBwX/VRqV+W+yKp3P8cO7vSGZ6BGhjEvFl8GSyrKDVNVq4e9XeNMspHaZo= Message-ID: <461BE998.9030102@lipetsk.ru> Date: Tue, 10 Apr 2007 23:46:32 +0400 From: Victor Gamov User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: new Service-Type Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK, let me explain my point of view. As this I-D propose new Service-Type values it's means that IETF Consensus required. It's a real fact. As to the question about only one implementation using this values so I propose this attributes because I really hope that it may be useful in environment where video services (like video-call or video-on-demand) are deployed. As recommended by http://www.ietf.org/ietf/1id-guidelines.html, chair of the WG must grant permissions to IETF to publish I-D. But I think that the utility of this new values need to be discussed by RADext WG firstly. If this values will be found helpful -- WG can recommend it for using in suitable situations and publish this I-D to get IETF Consensus. If not -- WG can discard it. If its needed to have more examples where this values may be used I will try to give it. -- CU, Victor Gamov -- to 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, 10 Apr 2007 19:50:44 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-fixes-03.txt Message-Id: Date: Tue, 10 Apr 2007 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Common RADIUS Implementation Issues and Suggested Fixes Author(s) : D. Nelson, A. DeKok Filename : draft-ietf-radext-fixes-03.txt Pages : 23 Date : 2007-4-10 This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-fixes-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-fixes-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-10142157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-fixes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-fixes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-10142157.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to 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, 10 Apr 2007 14:57:16 +0000 Message-ID: <3009218.1176217012006.JavaMail.?@fh1038.dia.cp.net> Date: Tue, 10 Apr 2007 14:56:52 +0000 (UTC) From: "david@mitton.com" Reply-To: "david@mitton.com" To: Subject: RE: RFC 2882 and new Service-Type MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit Let be re-iterate some of Dave's comments.... The purpose of RFC 2882 was to indicate the nature and scope of "extentions" to RADIUS that were seen in practice. I have often called it by a name that is not part of IETF nomenclature, a "Worst Practices" document. The goal of the document was to bring some of these issues to light, so that hopefully they would be addressed by the AAA movement at the time. The politics of the situation at the time didn't seem to think there was much to be done in the area. I was trying to illustrate the reality of the situation. One prominent vendor objected vocally to his products being described there. Also note that it preceeds RFC 3575, and some of the sections quoted below have probably been tweaked in response to it. That said, being the author of the VSE concept, I still think it has merit. But it does suffer the arguments given here and later in this thread. If it were baked into the protocol somehow, then it would benefit from the standard. As an ad-hoc extention, VSEs can and will cause interoperability problems. I ran into at least one RADIUS server that couldn't handle them at all because they exceeded the bit width of the variable they had carefully optimized to carry the known values. While this is an example of a short sighted implementation, I think a standard should be very clear on what and where values can be extended. And since the WG has not accepted the VSE scheme, I would not recommend it's use in a product today. David Mitton. ----Original Message---- From: d.b.nelson@comcast.net Date: Apr 10, 2007 7:19 To: "Alan DeKok", "Victor Gamov" Cc: Subj: RE: new Service-Type Alan DeKok writes ... > IANA performs the allocations itself. You can request > that IANA allocate numbers for those Service-Type values. > But you cannot control which numbers IANA allocates. IANA allocations for RADIUS are controlled by RFC 3575, which reads, in part, as follows: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Allocation of new Service-Type values requires IETF Consensus. > If there is only one application that uses these two > Service-Types, my suggestion would be to allocate a vendor- > specific enumeration. See RFC 2882, Section 2.2.1 for how this > is done. > > The benefit with the method suggested in RFC 2882 is that > you do not need IANA approval for the allocation. I personally consider vendor-specific enumerations, as described in RFC 2882 to be a very bad practice. Please recall that RFC 2882 describes RADIUS practices encountered in implementations, but does not necessisarily recommend these practices. Various versions of the RADIUS Design Guidelines draft have included text recommending against using VSEs, in favor of standard IANA allocations. RFC 2882 says, in part: This technique has not seen any acceptance by the working group or other vendors, however, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values. In my opinion, which is based in part on discussions with the author of RFC 2882, that document lists certain practices which ought not to be encouraged, in the interests of interoperability, but rather which vendors have resorted to in order to bypass the normal IETF processes. In any event, new values of Service-Type, VSE or otherwise, do require IANA allocation and do require IETF consensus. Regards, Dave Nelson -- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Apr 2007 14:46:47 +0000 Message-ID: <9960120.1176216365220.JavaMail.?@fh1038.dia.cp.net> Date: Tue, 10 Apr 2007 14:46:05 +0000 (UTC) From: "david@mitton.com" Reply-To: "david@mitton.com" To: radiusext@ops.ietf.org Subject: RE: RFC 2882 and new Service-Type MIME-Version: 1.0 Content-Type: text/plain;charset="UTF-8" Content-Transfer-Encoding: 7bit Let be re-iterate some of Dave's comments.... The purpose of RFC 2882 was to indicate the nature and scope of "extentions" to RADIUS that were seen in practice. I have often called it by a name that is not part of IETF nomenclature, a "Worst Practices" document. The goal of the document was to bring some of these issues to light, so that hopefully they would be addressed by the AAA movement at the time. The politics of the situation at the time didn't seem to think there was much to be done in the area. I was trying to illustrate the reality of the situation. One prominent vendor objected vocally to his products being described there. Also note that it preceeds RFC 3575, and some of the sections quoted below have probably been tweaked in response to it. That said, being the author of the VSE concept, I still think it has merit. But it does suffer the arguments given here and later in this thread. If it were baked into the protocol somehow, then it would benefit from the standard. As an ad-hoc extention, VSEs can and will cause interoperability problems. I ran into at least one RADIUS server that couldn't handle them at all because they exceeded the bit width of the variable they had carefully optimized to carry the known values. While this is an example of a short sighted implementation, I think a standard should be very clear on what and where values can be extended. And since the WG has not accepted the VSE scheme, I would not recommend it's use in a product today. David Mitton. ----Original Message---- From: d.b.nelson@comcast.net Date: Apr 10, 2007 7:19 To: "Alan DeKok", "Victor Gamov" Cc: Subj: RE: new Service-Type Alan DeKok writes ... > IANA performs the allocations itself. You can request > that IANA allocate numbers for those Service-Type values. > But you cannot control which numbers IANA allocates. IANA allocations for RADIUS are controlled by RFC 3575, which reads, in part, as follows: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Allocation of new Service-Type values requires IETF Consensus. > If there is only one application that uses these two > Service-Types, my suggestion would be to allocate a vendor- > specific enumeration. See RFC 2882, Section 2.2.1 for how this > is done. > > The benefit with the method suggested in RFC 2882 is that > you do not need IANA approval for the allocation. I personally consider vendor-specific enumerations, as described in RFC 2882 to be a very bad practice. Please recall that RFC 2882 describes RADIUS practices encountered in implementations, but does not necessisarily recommend these practices. Various versions of the RADIUS Design Guidelines draft have included text recommending against using VSEs, in favor of standard IANA allocations. RFC 2882 says, in part: This technique has not seen any acceptance by the working group or other vendors, however, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values. In my opinion, which is based in part on discussions with the author of RFC 2882, that document lists certain practices which ought not to be encouraged, in the interests of interoperability, but rather which vendors have resorted to in order to bypass the normal IETF processes. In any event, new values of Service-Type, VSE or otherwise, do require IANA allocation and do require IETF consensus. Regards, Dave Nelson -- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Apr 2007 13:25:35 +0000 Message-ID: <461B8FF0.6020504@nitros9.org> Date: Tue, 10 Apr 2007 15:24:00 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "David B. Nelson" CC: 'Victor Gamov' , radiusext@ops.ietf.org Subject: Re: new Service-Type Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > One of the properties of a standard protocol is that the code-points are > controlled and universally understood. If you want to have a private > version of the foo-bar protocol, then it doesn't matter what code-points you > use in your implementation, as they will not be encountered by > standards-compliant implementations. In that case, however, you need not > engage the IETF at all. The reason for standards is for plug-'n-play > interoperability. No argument there. >> The alternative is to perform allocations for every little >> variation of every little application, which will not scale. > > That depends, I suppose, on whether you think of RADIUS as a standardized, > interoperable protocol or simply a convenient a transport for proprietary, > boutique applications. Realistically, all protocols are used in both scenarios. In some cases, it's simpler, cheaper, and easier to deploy localized non-standard and non-interoperable solutions... especially where those solutions are intended to never inter-operate with other deployments. The question for this document is whether or not it falls into the first set, or the second. If there is only one application that needs these values, I see no point in standardizing them. If there is only one implementation, it is, by definition, non-interopable with anything else, Non-interoperable implementations have no requirements for inter-operability. The vendor can use VSE's, or poach on the IANA space. It's up to him. And since his implementation is already non-interoperable, it won't affect anyone else. And doesn't the IETF process generally require two inter-operable implementations? If there is no second implementation that will support this functionality, why can we not push off the discussion until there is an inter-operable RADIUS client? 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, 10 Apr 2007 12:18:19 +0000 From: "David B. Nelson" To: "'Alan DeKok'" Cc: "'Victor Gamov'" , Subject: RE: new Service-Type Date: Tue, 10 Apr 2007 08:16:13 -0400 Message-ID: <001c01c77b6a$0875b4b0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acd7ZcrwZjfHZm6pTCqvxrtP+x6E7AAAq8aA Alan DeKok writes... > If there is not a strong demand for RADIUS allocations, > then the deployments using the new numbers are few and far > between. In that case, it matters little to the rest of the > world which numbers are used. One of the properties of a standard protocol is that the code-points are controlled and universally understood. If you want to have a private version of the foo-bar protocol, then it doesn't matter what code-points you use in your implementation, as they will not be encountered by standards-compliant implementations. In that case, however, you need not engage the IETF at all. The reason for standards is for plug-'n-play interoperability. If there is a chance that your "walled garden" will ever open up and interact with the rest of the world, however, non-assigned code-points are a very bad practice, indeed. The fact that VSEs poach on high-valued regions of the code-point space, that IANA is never likely to reach, does make them "work". It does nothing to promote interoperability, however. > In that case, I would recommend VSE's. I, on the other hand, would never recommend VSEs. In my opinion VSEs for Service-Type violate the RADIUS IANA Considerations RFC. > The alternative is to perform allocations for every little > variation of every little application, which will not scale. That depends, I suppose, on whether you think of RADIUS as a standardized, interoperable protocol or simply a convenient a transport for proprietary, boutique applications. -- to 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, 10 Apr 2007 11:53:24 +0000 Message-ID: <461B7A8E.8080602@nitros9.org> Date: Tue, 10 Apr 2007 13:52:46 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: PROTO writeup for Issues & Fixes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Find enclosed the proposed PROTO writeup for Issues & Fixes, which will > submitted for IESG review once -03 hits the archive. Comment welcome. I have just submitted -03. > The document splits normative and informative references. > There are no normative references to IDs. There is a normative reference to [PREFIX]. tools.ietf.org says it's in state AUTH48. There appear to be about 8-10 requests before it in the RFC editors queue. 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, 10 Apr 2007 11:46:23 +0000 Message-ID: <461B78C8.3070704@nitros9.org> Date: Tue, 10 Apr 2007 13:45:12 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "David B. Nelson" CC: 'Victor Gamov' , radiusext@ops.ietf.org Subject: Re: new Service-Type Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > IANA allocations for RADIUS are controlled by RFC 3575, which reads, in > part, as follows: ... > Allocation of new Service-Type values requires IETF Consensus. Hmm... OK. > I personally consider vendor-specific enumerations, as described in RFC 2882 > to be a very bad practice. Please recall that RFC 2882 describes RADIUS > practices encountered in implementations, but does not necessisarily > recommend these practices. Various versions of the RADIUS Design Guidelines > draft have included text recommending against using VSEs, in favor of > standard IANA allocations. I understand. However, VSE's are known to work. > In my opinion, which is based in part on discussions with the author of RFC > 2882, that document lists certain practices which ought not to be > encouraged, in the interests of interoperability, but rather which vendors > have resorted to in order to bypass the normal IETF processes. > > In any event, new values of Service-Type, VSE or otherwise, do require IANA > allocation and do require IETF consensus. If there is a strong demand for RADIUS allocations, then I agree that the allocations should be made, and documented. If there is not a strong demand for RADIUS allocations, then the deployments using the new numbers are few and far between. In that case, it matters little to the rest of the world which numbers are used. In that case, I would recommend VSE's. The alternative is to perform allocations for every little variation of every little application, which will not scale. So... is there a strong demand for the allocations requested by the original document? 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, 10 Apr 2007 11:21:41 +0000 From: "David B. Nelson" To: "'Alan DeKok'" , "'Victor Gamov'" Cc: Subject: RE: new Service-Type Date: Tue, 10 Apr 2007 07:19:21 -0400 Message-ID: <001001c77b62$17bef330$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acd7Wz5AcqByWPZdTXuXhFMLU0oTwwABL+Ug Alan DeKok writes ... > IANA performs the allocations itself. You can request > that IANA allocate numbers for those Service-Type values. > But you cannot control which numbers IANA allocates. IANA allocations for RADIUS are controlled by RFC 3575, which reads, in part, as follows: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Allocation of new Service-Type values requires IETF Consensus. > If there is only one application that uses these two > Service-Types, my suggestion would be to allocate a vendor- > specific enumeration. See RFC 2882, Section 2.2.1 for how this > is done. > > The benefit with the method suggested in RFC 2882 is that > you do not need IANA approval for the allocation. I personally consider vendor-specific enumerations, as described in RFC 2882 to be a very bad practice. Please recall that RFC 2882 describes RADIUS practices encountered in implementations, but does not necessisarily recommend these practices. Various versions of the RADIUS Design Guidelines draft have included text recommending against using VSEs, in favor of standard IANA allocations. RFC 2882 says, in part: This technique has not seen any acceptance by the working group or other vendors, however, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values. In my opinion, which is based in part on discussions with the author of RFC 2882, that document lists certain practices which ought not to be encouraged, in the interests of interoperability, but rather which vendors have resorted to in order to bypass the normal IETF processes. In any event, new values of Service-Type, VSE or otherwise, do require IANA allocation and do require IETF consensus. Regards, Dave Nelson -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Apr 2007 10:27:01 +0000 Message-ID: <461B6635.7000701@nitros9.org> Date: Tue, 10 Apr 2007 12:25:57 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Victor Gamov CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: new Service-Type Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Victor Gamov wrote: > Some times ago I ask about propose new Service-Type values to carry > information about video services. Now I have I-D which propose such > values. This document placed at > http://so.comsat.ru/IST/draft-vit-radext-videoservicetype-00.txt > > Please tell me what else must I do to approve this values by IANA? IANA performs the allocations itself. You can request that IANA allocate numbers for those Service-Type values. But you cannot control which numbers IANA allocates. If there is only one application that uses these two Service-Types, my suggestion would be to allocate a vendor-specific enumeration. See RFC 2882, Section 2.2.1 for how this is done. The benefit with the method suggested in RFC 2882 is that you do not need IANA approval for the allocation. 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, 10 Apr 2007 08:25:06 +0000 DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=PKrDUBEIpYbMHAOsQF/t4K5XnmjNeKVV+1+uQSoZMiAJ7VkQOvfACpFGoUWFfiKgO0/UKZS+6AAA+LbxMQH+4w2OfS0UW2OWC89oSW2o6FsQ8UXr/J3gUzDWqFt5kQNjFkEoOjiIwnmXQbIp6rU78PtWmJpT3BFRfse++aRLIL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=soJTkvNEZOrKtL6G1e6RpnhsAMoqxzSN1w7R0b9bv3M2lEkWqRv7Z6Fxke4Hwfzp97YdpeqZP5wtCUm4AXGeQWF4GFnO8zQCz66dU0e5VPGWNEyb7KbbCJ4Us1s1mY7TN9saHCX/A89VGC8EtI0e9d2zK25DTIm4nA0fMHrDoM8= Message-ID: <461B498E.1020308@lipetsk.ru> Date: Tue, 10 Apr 2007 12:23:42 +0400 From: Victor Gamov User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: new Service-Type Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Bernard! Some times ago I ask about propose new Service-Type values to carry information about video services. Now I have I-D which propose such values. This document placed at http://so.comsat.ru/IST/draft-vit-radext-videoservicetype-00.txt Please tell me what else must I do to approve this values by IANA? Thanks! -- CU, Victor Gamov -- to 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, 09 Apr 2007 19:07:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines Document Discussion Date: Mon, 9 Apr 2007 15:06:56 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , Cc: =20 -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, April 09, 2007 2:55 PM To: Avi Lior; aland@nitros9.org Cc: radiusext@ops.ietf.org Subject: RE: Guidelines Document Discussion >[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO=20 >will always need to create their own VSAs. We are starting to see=20 >convergences in the Wireless/Wireline networks and it would be nice if=20 >SDOs attributes would interoperate or at least it should be easy to=20 >translate between SDOs. This seems like it might be an achievable goal. The RFC 2865 recommended VSA format has caused some problems because of its limitations (8-bit type space) and lack of treatment as opaque octets (the Diameter/RADIUS=20 translation problem in RFC 4005). If we address the limitations, and make=20 it clear that following the recommendation is not required and cannot be assumed by implementations, then this can work. [avi] Good. >If I have an enumeration (of TRUE or FALSE) using a 32-bit value is=20 >wasteful in view of the size limitation of both attributes and packet=20 >size. Are you saying that the VSA space should allow one octet or two octet data types? [Avi] Why not? Certainly in structured types this is very useful. In the past when working in SDO space I had lots of questions as to why are we using a 32-bit value for an enumeration of true or false. -- to 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, 09 Apr 2007 18:55:05 +0000 Message-ID: From: "Bernard Aboba" To: avi@bridgewatersystems.com, aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Guidelines Document Discussion Date: Mon, 09 Apr 2007 11:54:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO >will always need to create their own VSAs. We are starting to see >convergences in the Wireless/Wireline networks and it would be nice if >SDOs attributes would interoperate or at least it should be easy to >translate between SDOs. This seems like it might be an achievable goal. The RFC 2865 recommended VSA format has caused some problems because of its limitations (8-bit type space) and lack of treatment as opaque octets (the Diameter/RADIUS translation problem in RFC 4005). If we address the limitations, and make it clear that following the recommendation is not required and cannot be assumed by implementations, then this can work. >If I have an enumeration (of TRUE or FALSE) using a >32-bit value is wasteful in view of the size limitation of both >attributes and packet size. Are you saying that the VSA space should allow one octet or two octet data types? >[Avi] A good idea for readability. But not a show stopper. Is the IETF >willing to also honor SDOs name spaces? Probably not. We could certainly recommend the use of unique name spaces for VSAs (e.g. SDO-Name) so as to avoid confusion. >[Avi] interoperability within the SDO or with others? I think within >the SDO primarily. To achieve interoperability between SDOs, and SDO is >free to use another SDOs attributes. It would be helpful for us RADIUS >vendors if the encoding was the same though. Right. Assuming that the SDOs utilize similar attribute formats, and the specifications are published, this should work. In particular, I would like to eliminate the need for SDOs to utilize RADIUS standard attributes just in order to have their specification widely disseminated. In the long term the IETF should strive to assist SDOs in defining their own RADIUS attributes. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 09 Apr 2007 18:40:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Guidelines Document Discussion Date: Mon, 9 Apr 2007 14:39:44 -0400 Message-ID: From: "Avi Lior" To: "Alan DeKok" , "Bernard Aboba" Cc: Bernard and Alan, =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Sunday, April 08, 2007 10:35 AM To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Bernard Aboba wrote: > One of the things that struck me about the current document is that it > assumes that the differences in data model between the IETF Standard=20 > space and the VSA space represent a long term problem which needs to=20 > be resolved. I think the problem does need to be resolved in a standards body. I've had any number of off-line discussions trying to get people to fix their implementations (less code usually means it is more inter-operable). It's difficult to convince people that they're doing anything problematic if they can point to RFC 2865, and say "the VSA space is a free-for-all". [Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO will always need to create their own VSAs. We are starting to see convergences in the Wireless/Wireline networks and it would be nice if SDOs attributes would interoperate or at least it should be easy to translate between SDOs. =20 I don't think we could standerdize a VSA encoding. But at least we can make a recommendation on how an VSA could be encoded. I would offer the WiMAX encoding as a good example. It aligns with the RADIUS attribute extension encoding at least in the header. And for the payload it allows a structured types -- like 3GPP2. > Even if there were to be some convergence of the standard and VSA data > models, it strikes me that this convergence might only be temporary,=20 > since a vendor or SDO using the VSA space can define their own=20 > attribute format as well as attributes. As many have already done. [Avi] I think that SDOs will always create their own attributes. But as to the attribute format, I don't think an SDO would invent something if there was already a good example to follow. > It strikes me that RADIUS VSA usage may face a similar evolution, and=20 > that such a parth, if successfully traveled, should not be cause for > dismay. As we have discovered, there may be circumstances in which a > particular RADIUS attribute set may be easier to define within a VSA=20 > space than within the standards space. Rather than trying to fit a=20 > square peg into a round hole by modifying the document to work with=20 > the existing RADIUS standard data model, it is simpler to retain use of VSAs. I concur. [Avi] I agree. > If we were writing an equivalent paragraph to the VSA allocation=20 > description found in RFC 2865 Section 6.2 today, I think we might=20 > include more instances in which allocation of VSAs is desirable. For > example: >=20 > * Where interoperability is useful but usage is confined to a specific > access mechanism or SDO specification; > * Where allocation of a large number of attributes is required (>5?) > * Where data types are required that fall outside of the usage defined > in the Guidelines document; And where SDOs wish to exert change control over the specification. > We might also include circumstances in which VSA usage would be=20 > strongly > discouraged: >=20 > * Where the VSAs represent a change to the RADIUS protocol. This=20 > would include definition of new commands or operational modes. We should also encourage good practices, and discourage bad ones: - near-random numbering of VSA's per packet - VSA's containing ASCII string data, rather than TLV's - 1 or 2 byte VSA's for "efficiency" where "integer" type would do [Avi]You mean prohibit the use of 1 or 2 byte TLVs where an integer would do? If yes I disagree. RADIUS packets are getting smaller and smaller these days? If I have an enumeration (of TRUE or FALSE) using a 32-bit value is wasteful in view of the size limitation of both attributes and packet size. - defining attributes in the IANA managed space, rather than using VSA's [Avi] When feasible. - SDO-specific interpretations of existing RADIUS commands, attributes, or values for "integer" attributes. [Avi] Not sure I understand the "...values for integer" part. - SDO's publishing standards that use existing standardized attribute names for SDO-specific attributes, or which use confusingly similar names [Avi] A good idea for readability. But not a show stopper. Is the IETF willing to also honor SDOs name spaces? Probably not. SDO's and vendors should be reminded that the goal of VSA's is to obtain interoperability. [Avi] interoperability within the SDO or with others? I think within the SDO primarily. To achieve interoperability between SDOs, and SDO is free to use another SDOs attributes. It would be helpful for us RADIUS vendors if the encoding was the same though. > I would suggest that the Guidelines document needs to tackle this and=20 > other issues arising from the usage of VSAs. Yes. [Avi] I agree as well. 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: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 08 Apr 2007 14:36:39 +0000 Message-ID: <4618FDA1.2080202@nitros9.org> Date: Sun, 08 Apr 2007 16:35:13 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Guidelines Document Discussion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > One of the things that struck me about the current document is that it > assumes that the differences in data model between the IETF Standard > space and the VSA space represent a long term problem which needs to be > resolved. I think the problem does need to be resolved in a standards body. I've had any number of off-line discussions trying to get people to fix their implementations (less code usually means it is more inter-operable). It's difficult to convince people that they're doing anything problematic if they can point to RFC 2865, and say "the VSA space is a free-for-all". > Even if there were to be some convergence of the standard and VSA data > models, it strikes me that this convergence might only be temporary, > since a vendor or SDO using the VSA space can define their own attribute > format as well as attributes. As many have already done. > As a result, it strikes me that the Guidelines document probably needs > to accept that the RADIUS standard and VSA data models are currently > different and are likely to remain so. The document also needs to > recognize the reality of today's VSA usage in other ways. Yes. ... > While this paragraph has been used to argue that SDO usage of VSAs has > gone beyond the original intent of RFC 2865, on comparing this paragraph > with those in Section 5.26, I am not sure. Since this paragraph comes > from the IANA considerations section, it is really talking about the > circumstances in which vendors (which would include SDOs) should be > encouraged to use VSAs rather than requesting an allocation from the > standards space. Yes. That should be made very clear. > It strikes me that RADIUS VSA usage may face a similar evolution, and > that such a parth, if successfully traveled, should not be cause for > dismay. As we have discovered, there may be circumstances in which a > particular RADIUS attribute set may be easier to define within a VSA > space than within the standards space. Rather than trying to fit a > square peg into a round hole by modifying the document to work with the > existing RADIUS standard data model, it is simpler to retain use of VSAs. I concur. > If we were writing an equivalent paragraph to the VSA allocation > description found in RFC 2865 Section 6.2 today, I think we might > include more instances in which allocation of VSAs is desirable. For > example: > > * Where interoperability is useful but usage is confined to a specific > access mechanism or SDO specification; > * Where allocation of a large number of attributes is required (>5?) > * Where data types are required that fall outside of the usage defined > in the Guidelines document; And where SDOs wish to exert change control over the specification. > We might also include circumstances in which VSA usage would be strongly > discouraged: > > * Where the VSAs represent a change to the RADIUS protocol. This would > include definition of new commands or operational modes. We should also encourage good practices, and discourage bad ones: - near-random numbering of VSA's per packet - VSA's containing ASCII string data, rather than TLV's - 1 or 2 byte VSA's for "efficiency" where "integer" type would do - defining attributes in the IANA managed space, rather than using VSA's - SDO-specific interpretations of existing RADIUS commands, attributes, or values for "integer" attributes. - SDO's publishing standards that use existing standardized attribute names for SDO-specific attributes, or which use confusingly similar names SDO's and vendors should be reminded that the goal of VSA's is to obtain interoperability. > I would suggest that the Guidelines document needs to tackle this and > other issues arising from the usage of VSAs. Yes. 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: Sun, 08 Apr 2007 00:18:38 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: PROTO writeup for Issues & Fixes Date: Sat, 07 Apr 2007 17:18:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Find enclosed the proposed PROTO writeup for Issues & Fixes, which will submitted for IESG review once -03 hits the archive. Comment welcome. ------------------------------------------------------------------------ Title: Common RADIUS Implementation Issues and Suggested Fixes I-D: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt Status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd: Bernard Aboba I have personally reviewed the document. (1.b) Has the document had adequate review from both key WG members and key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. This document has been through a WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Document review has focused on the RADEXT WG since the document is about RADIUS protocol issues and fixes. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. At various points, 8 people have posted review comments or made contributions relating to the document. The issues raised and the resolutions are available for inspection at http://www.drizzle.com/~aboba/RADEXT/ (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. An output of the run on this revision of the ID by the online nits checker: TBD, pending -03 submission to address IDNits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document splits normative and informative references. There are no normative references to IDs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? This document has no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document does not contain sections written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: - Technical Summary This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. - Working Group Summary This document originally included issues and fixes relating to RFC 3576, but it was decided that handling that in a separate document (RFC 3576bis) would be more appropriate. During the development of this document, a number of issues required extended discussion, most recently text relating to handling of duplicate detection within RADIUS. - Document Quality This document describes issues that have been raised as a result of the widespread deployment of RADIUS for authentication, authorization and accounting. - Personnel Bernard Aboba is the document shepherd. The responsible Area Director is Dan Romascanu. No IANA expert is needed. -- to 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, 07 Apr 2007 23:21:38 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Guidelines Document Discussion Date: Sat, 07 Apr 2007 16:20:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed After IETF 68, I spent some time reading the current guidelines document and thinking about how we should proceed to revise it. One of the things that struck me about the current document is that it assumes that the differences in data model between the IETF Standard space and the VSA space represent a long term problem which needs to be resolved. Part of the reasoning is that without converging the data models, it may be difficult for RADIUS attributes specified using VSAs to be standardized without requiring changes to the standard data model. At IETF 66, we had a discussion about this, and there was considerable resistance to the notion of extending the RADIUS data model to sync up better with the VSA data model. Even if there were to be some convergence of the standard and VSA data models, it strikes me that this convergence might only be temporary, since a vendor or SDO using the VSA space can define their own attribute format as well as attributes. As a result, it strikes me that the Guidelines document probably needs to accept that the RADIUS standard and VSA data models are currently different and are likely to remain so. The document also needs to recognize the reality of today's VSA usage in other ways. RFC 2865 Section 5.26 characterizes VSAs as follows: This Attribute is available to allow vendors to support their own extended Attributes not suitable for general usage. It MUST not affect the operation of the RADIUS protocol. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode. These two paragraphs, which occur within the core of the RADIUS specification [RFC2865] hold up quite well even today. The characterization of VSAs as "not suitable for general usage" is consistent with specifications created by SDOs for specific uses. An example is RFC 4679 created by the DSL Forum. It would also fit VSAs defined by IEEE 802 that are specific to the IEEE 802 family of protocols, such as those defined in RFC 4675. The point made in the second sentence is that VSAs are just attirbutes and do not affect the RADIUS protocol itself; this would preclude SDOs from creating their own RADIUS dialects. Note that this section does not talk about interoperability. That discussion occurs in RFC 2865, Section 6.2: Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. While this paragraph has been used to argue that SDO usage of VSAs has gone beyond the original intent of RFC 2865, on comparing this paragraph with those in Section 5.26, I am not sure. Since this paragraph comes from the IANA considerations section, it is really talking about the circumstances in which vendors (which would include SDOs) should be encouraged to use VSAs rather than requesting an allocation from the standards space. However, this is not the only situation in which use of VSAs would make sense; the "not for general use" description from Section 5.26 is more comprehensive. If we are to adjust to the idea that the standards data model and the VSA data model will not necessarily converge, I think we will also need to adjust to a potentially larger role for VSAs, as well as thinking about the long-term relationship between the IETF and SDOs which utilize the RADIUS protocol. Within the SNMP community, the need for an efficient and scalable approach to non-IETF MIB development has been evident for quite a while. As described in RFC 4663, it is most efficient for MIBs to be developed within the standards organizations developing the protocols that require management, since handling MIB work in a separate standards body results in additional travel and coordination costs which are difficult to justify. To help ensure quality, the IETF can provide assistance in the form of Guidelines documents and reviews provided by a Doctor team, and of course the IETF continues to assert change control over the SNMP protocol. It strikes me that RADIUS VSA usage may face a similar evolution, and that such a parth, if successfully traveled, should not be cause for dismay. As we have discovered, there may be circumstances in which a particular RADIUS attribute set may be easier to define within a VSA space than within the standards space. Rather than trying to fit a square peg into a round hole by modifying the document to work with the existing RADIUS standard data model, it is simpler to retain use of VSAs. If we were writing an equivalent paragraph to the VSA allocation description found in RFC 2865 Section 6.2 today, I think we might include more instances in which allocation of VSAs is desirable. For example: * Where interoperability is useful but usage is confined to a specific access mechanism or SDO specification; * Where allocation of a large number of attributes is required (>5?) * Where data types are required that fall outside of the usage defined in the Guidelines document; We might also include circumstances in which VSA usage would be strongly discouraged: * Where the VSAs represent a change to the RADIUS protocol. This would include definition of new commands or operational modes. I would suggest that the Guidelines document needs to tackle this and other issues arising from the usage of VSAs. -- to 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, 07 Apr 2007 06:04:56 +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: Publication of RADIUS Prepaid Document Date: Fri, 6 Apr 2007 23:03:54 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503BE14A9@xmb-sjc-215.amer.cisco.com> Thread-Topic: Publication of RADIUS Prepaid Document Thread-Index: Acd32ApV4phajIrjQ+ioTVEm/UQi5wBAlnAA From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=268; t=1175925839; x=1176789839; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Publication=20of=20RADIUS=20Prepaid=20Document |Sender:=20; bh=up5qvf6d5hYmmHnJddRuJxF4znXAhhmhiCU9zQosj2E=; b=JK3p8y2H4yNTgqm4Ta7cB3sd5CDbp2gyZxlCnY/rZydHa/Bsv5G0RpmnoiRlAaaYjx75crmf wcaUOSXnaN435AOY8CKOKHHprsM1u9zQRuClVd3+MwaiaHQp5XEcxl5F; Authentication-Results: sj-dkim-5; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); Bernard Aboba allegedly scribbled on Thursday, April 05, 2007 4:13 PM: >> OK w/me. Any idea _what_ VSA set? >=20 > WiMAX or 3GPP2 VSAs? Cool - I think they are (at least close to) identical, so that sounds pretty useful. -- to 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 Apr 2007 23:14:19 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Publication of RADIUS Prepaid Document Date: Thu, 05 Apr 2007 16:13:29 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >OK w/me. Any idea _what_ VSA set? WiMAX or 3GPP2 VSAs? -- to 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 Apr 2007 15:12:52 +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: Publication of RADIUS Prepaid Document Date: Thu, 5 Apr 2007 08:12:39 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262503BE0D34@xmb-sjc-215.amer.cisco.com> Thread-Topic: Publication of RADIUS Prepaid Document Thread-Index: Acdro3bQbvEiXgsLRf6SnDlCbLXdJQL8UUPw From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=497; t=1175785965; x=1176649965; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20Publication=20of=20RADIUS=20Prepaid=20Document |Sender:=20; bh=uM0PCbfu27MekAZPsBhNhiMtZBRo8yCMM8MVH2wV6cs=; b=fLg6fQ71Sdl0WufEPPS7oQrdqh53DEioNeAfLC7kaRNObDvz/qeyR4mXUMRb/ofvYji6CaVB lhajmioGNSgxRjUiZC6mXe4N8ZWodbOROZDf9Bb2jXH3vYtL8/tXN+db; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Bernard Aboba <> allegedly scribbled on Wednesday, March 21, 2007 3:27 AM: > At IETF 68, it was suggested that the RADIUS Prepaid document be > published as an Informational RFC documenting existing usage > (presumably based on RADIUS VSAs). This would enable us to unblock > the document, since =20 > conformance to the Guidelines document (still in progress) would no > longer be required.=20 >=20 > Are there any objections to this approach? OK w/me. Any idea _what_ VSA set? -- to 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 Apr 2007 15:10:23 +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: Publication of RADIUS Prepaid Document Date: Thu, 5 Apr 2007 10:41:11 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9DD4@exchtewks2.starentnetworks.com> Thread-Topic: Publication of RADIUS Prepaid Document thread-index: Acdro75H5idBMa9NQOiihiiOluCAOQL7JgsQ From: "Chowdhury, Kuntal" To: "Bernard Aboba" , I support publishing this document as an informational RFC. -Kuntal > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Bernard Aboba > Sent: Wednesday, March 21, 2007 5:27 AM > To: radiusext@ops.ietf.org > Subject: Publication of RADIUS Prepaid Document >=20 > At IETF 68, it was suggested that the RADIUS Prepaid document be published > as an Informational RFC documenting existing usage (presumably based on > RADIUS VSAs). This would enable us to unblock the document, since > conformance to the Guidelines document (still in progress) would no longer > be required. >=20 > Are there any objections to this approach? >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 05 Apr 2007 09:50:44 +0000 Message-ID: <4614C643.8030605@nitros9.org> Date: Thu, 05 Apr 2007 11:49:55 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-radext-fixes-02.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: .. > ** Missing expiration date. The document expiration date should appear on > the first and last page. Added 'Expires:' header. > ** The document seems to lack separate sections for Informative/Normative > References. All references will be assumed normative when checking for > downward references. Removed a trailing '.' from normative/informative section names. A -03 will be issued shortly. 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 Apr 2007 06:09:16 +0000 Message-ID: <4614923F.80609@nitros9.org> Date: Thu, 05 Apr 2007 08:07:59 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-radext-fixes-02.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > IDNITs gives some errors on this document: Hmm.. I'm not sure why the -01 was OK, and this one isn't. > ** Missing expiration date. The document expiration date should appear on > the first and last page. It's on the first, apparently not on the last. Is this a new requirement? > ** The document seems to lack separate sections for Informative/Normative > References. All references will be assumed normative when checking for > downward references. 5.1 has Normative && 5.2 has Informative references. I think idnits is looking for very specific text. > -- Missing reference section? I think this is because idnits is looking for very specific text for the section names. We can update those, andn run idnits again. I think the only substantive error is the lack of an expiration date on the last page. A -03 will be issued shortly. 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, 04 Apr 2007 23:47:14 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: PROTO Writeup: RFC 4590bis Date: Wed, 04 Apr 2007 16:46:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Since no additional issues have been raised, we are preparing to send RFC 4590bis off to the IESG for publication as a Proposed Standard. Here is the PROTO writeup: ------------------------------------------------------------------------ Title: RADIUS Extension for Digest Authentication I-D: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.txt Status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd: Bernard Aboba I have personally reviewed the document. (1.b) Has the document had adequate review from both key WG members and key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes. This document has been through a WG last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? This document includes some fixes to RFC 4590, which was discovered to contain IANA errors after publication. These problems were fixed along with a few other errata. So this document has already received extensive review in the relatively recent past. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid consensus behind this document, as there was behind RFC 4590. The issues raised and the resolutions are available for inspection at http://www.drizzle.com/~aboba/RADEXT/ (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. An output of the run on this revision of the ID by the online nits checker: idnits 2.04.05 tmp/draft-ietf-radext-rfc4590bis-01.txt: tmp/draft-ietf-radext-rfc4590bis-01.txt(1132): Found possible IPv4 address '3.2.2.2' in position 64; this doesn't match RFC3330's suggested 192.0.2.0/24 address range. [BA] 3.2.2.2 is a section header, not an address. Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- ** There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. [BA] They are not example addresses. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 1008 '0-1 0 0 1 0 24 State [4]...' -- Looks like a reference, but probably isn't: '1' on line 1028 '0 0-1 0 0 0 121 Digest-HA1 [1][2]...' -- Looks like a reference, but probably isn't: '2' on line 1028 '0 0-1 0 0 0 121 Digest-HA1 [1][2]...' -- Looks like a reference, but probably isn't: '3' on line 1018 '0-1 0 0 0-1 0-1 111 Digest-Algorithm [3]...' == Missing Reference: 'Note 1' is mentioned on line 1039, but not defined '[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth...' -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 1' == Missing Reference: 'Note 2' is mentioned on line 1042, but not defined '[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1...' -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 2' == Missing Reference: 'Note 3' is mentioned on line 1045, but not defined '[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed....' -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 3' == Missing Reference: 'Note 4' is mentioned on line 1047, but not defined '[Note 4] An Access-Challenge MUST contain a State attribute, whic...' -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 4' ** Downref: Normative reference to an Informational RFC: RFC 3579 -- Obsolete informational reference (is this intentional?): RFC 2069 (Obsoleted by RFC 2617) [BA] This is intentional. Summary: 3 errors (**), 4 warnings (==), 9 comments (--). (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document splits normative and informative references. There are no normative references to IDs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? I have verified that the IANA consideration exists and is consistent with the body of the document. The inconsistency in RFC 4590 was the reason why this document needed to be produced. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document does not contain sections written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: - Technical Summary This document defines an extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. - Working Group Summary Working Group discussion largely centered on whether the issues identified in RFC 4590 could be fixed via an errata or whether a new RFC was required. Due to conflicts between the RFC 4590 text and the parameters allocated by IANA, it was decided that a new RFC would be needed, so as to avoid potential interoperability problems. - Document Quality This document is needed to address a problem in the IANA allocations for Digest Authentication as well as several errata that were found after the publication of RFC 4590. At this point, we believe that RFC 4590bis addresses all issues raised since the publication of RFC 4590. - Personnel Bernard Aboba is the document shepherd. The responsible Area Director is Dan Romascanu. No IANA expert is needed. -- to 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, 04 Apr 2007 21:43:49 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: I-D ACTION:draft-ietf-radext-fixes-02.txt Date: Wed, 04 Apr 2007 14:43:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed IDNITs gives some errors on this document: idnits 2.04.05 tmp/draft-ietf-radext-fixes-02.txt: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 924 looks like a reference '[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate...' -- Missing reference section? 'RFC2865' on line 903 looks like a reference '[RFC2865]...' -- Missing reference section? 'RFC3579' on line 970 looks like a reference 'The alternate algorithm to [RFC3579] Section 2.6.1 that is descri...' -- Missing reference section? 'RFC4669' on line 956 looks like a reference '[RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RF...' -- Missing reference section? 'RFC2866' on line 907 looks like a reference '[RFC2866]...' -- Missing reference section? 'RFC2869' on line 910 looks like a reference '[RFC2869]...' -- Missing reference section? 'RFC2618' on line 933 looks like a reference '[RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB",...' -- Missing reference section? 'RFC4668' on line 953 looks like a reference '[RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RF...' -- Missing reference section? '1' on line 627 looks like a reference '[1] New RADIUS specifications and implementations MUST NOT use Acce...' -- Missing reference section? '2' on line 630 looks like a reference '[2] Access-Reject MUST mean denial of access to the requested servi...' -- Missing reference section? '3' on line 634 looks like a reference '[3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge...' -- Missing reference section? 'Note 2' on line 651 looks like a reference '[Note 2] As per RFC 3579, the use of the Password-Retry in EAP...' -- Missing reference section? 'RFC2462' on line 927 looks like a reference '[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address...' -- Missing reference section? 'RFC3927' on line 947 looks like a reference '[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configura...' -- Missing reference section? 'RFC3162' on line 936 looks like a reference '[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC...' -- Missing reference section? 'RFC3580' on line 939 looks like a reference '[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,...' -- Missing reference section? 'RFC3748' on line 943 looks like a reference '[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H....' -- Missing reference section? 'RFC4282' on line 950 looks like a reference '[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Netw...' -- Missing reference section? 'PREFIX' on line 961 looks like a reference 'The references to [PREFIX] should be replaced with a reference to...' -- Missing reference section? 'RFC2607' on line 930 looks like a reference '[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy...' Summary: 2 errors (**), 0 warnings (==), 20 comments (--). -- to 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, 04 Apr 2007 19:50:44 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-fixes-02.txt Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Common RADIUS Implementation Issues and Suggested Fixes Author(s) : D. Nelson, A. DeKok Filename : draft-ietf-radext-fixes-02.txt Pages : 23 Date : 2007-4-4 This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-fixes-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-fixes-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4140917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-fixes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-fixes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4140917.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to 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, 04 Apr 2007 14:04:36 +0000 Message-ID: <4613B04A.5000604@teliasonera.com> Date: Wed, 04 Apr 2007 17:03:54 +0300 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Sanchez, Mauricio (ProCurve)" CC: Jouni Korhonen , radiusext@ops.ietf.org Subject: Re: Filter-rules-01 & Issue 192 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Now also CC:ing the RADEXT. Jouni Korhonen kirjoitti: > Hi, > > There are of course corner cases where the last rule-delim alone would > go into the a new attribute.. then the savings would be more ;-) > > I'm OK with your earlier ABNF proposal as it now allows multiple rules > per attribute. So, consider issue 192 closed from my side. > > Anyway, in the ABNF you proposed earlier the role of 'rule-delim' is > actually something like 'end-of-rule' mark. It would be nice if you > could reflect this in the ABNF. > > > Cheers, > Jouni > > > > Sanchez, Mauricio (ProCurve) kirjoitti: >> Jouni recommended... >> >> >>> -----Original Message----- >>> From: jouni.korhonen@teliasonera.com >>> [JiK] Yes. Is there a particular reason to add a trailing rule-delim if >>> there is only a single rule? If not maybe the example below would work: >>> >>> rule-list = rule >>> rule-list =/ rule-list rule-delim rule >>> rule = "v1" " " (flush-rule / permit-all-rule >>> / l2-filter-rule / l2-tunnel-rule >>> / ip-filter-rule / ip-tunnel-rule >>> / http-filter-rule / http-redir-rule) >> >> Yes, your syntax saves one whole octet :), but is the complexity merited? >> Can we just go with my proposal? It would keep the general rule syntax >> consistent. >> 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, 04 Apr 2007 13:10:43 +0000 Message-ID: <4613A3A1.2090700@piuha.net> Date: Wed, 04 Apr 2007 16:09:53 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Sanchez, Mauricio (ProCurve)" CC: radiusext@ops.ietf.org Subject: Re: Issue 164: Review (traffic-rule-draft) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I have reviewed the new draft revision for the relevant parts and I'm happy with it. Thanks for the making the changes. You can close the issue. Jari Sanchez, Mauricio (ProCurve) kirjoitti: > > I believe draft -02 contains resolutions to all Jari’s comments in > issue 164. Need confirmation from Jari. > > Cheers, > > MS > > -------------------------------------------- > > Mauricio Sanchez, CISSP > > Network Security Architect > > ProCurve Networking Business > > Hewlett Packard > > 8000 Foothills Boulevard, ms 5557 > > Roseville CA, 95747-5557 > > 916.785.1910 Tel > > 916.785.1815 Fax > > mauricio.sanchez@hp.com > > -------------------------------------------- > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: