Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 19:43:05 +0000 From: "David B. Nelson" To: Subject: RE: Revisions to RFC 4005 Date: Fri, 31 Aug 2007 15:42:46 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000601c7ec07$1aceb8b0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrsQ1nmTDuePFgQ7mwlslXtyWQUgAGXmewAAlmCuAAAGOkMAACCAlgAAJXtgA= Glen Zorn writes... > Right, so what I'm suggesting is that whatever Diameter-related > issues there might be w/the extended attributes should be addressed > in the extended attributes document... Yes. > ...while another small document ... should address the general > problem w/VSA translation... That sounds reasonable. That work might be undertaken in the DIME WG as an update to RFC 4005, for example. Or not. :-) -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2007 18:28:56 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Revisions to RFC 4005 Date: Fri, 31 Aug 2007 11:13:14 -0700 Message-ID: <001701c7ebfa$997ff640$cc7fe2c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrsQ1nmTDuePFgQ7mwlslXtyWQUgAGXmewAAlmCuAAAGOkMAACCAlg Content-Language: en-us > Just for the sake of findability (don't think that that's actually > a word, but hopefully you know what I mean), I would think that > that kind of update would be better addressed in a document that > had "Diameter" in the title. Well, this is a cross-protocol issue, but I agree that the preferable vehicle would be an rfc4005bis (update or revision) document. I've previously sent an e-mail to the DIME WG chairs (and copied this list) to see if there is any document in that WG which could take on this issue. I've not seen any reply. OTOH, when RADEXT is extending RADIUS we have a pro-active obligation to address Diameter interoperability in our documents [gwz] [gwz] Right, so what I'm suggesting is that whatever Diameter-related issues there might be w/the extended attributes should be addressed in the extended attributes document, while another small document (_not_ an entire rewrite of RFC 4005 unless there are other problems) should address the general problem w/VSA translation (though as you know I believe that the best approach is no translation at all, esp. given the impossibility of translating Diameter AVPs to RADIUS attributes in the general case). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 17:21:53 +0000 From: "David B. Nelson" To: Subject: RE: Revisions to RFC 4005 Date: Fri, 31 Aug 2007 13:15:03 -0400 Organization: Elbrys Networks, Inc. Message-ID: <006d01c7ebf2$77fde750$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfrsQ1nmTDuePFgQ7mwlslXtyWQUgAGXmewAAlmCuAAAGOkMA== Glen Zorn writes... > Just for the sake of findability (don't think that that's actually > a word, but hopefully you know what I mean), I would think that > that kind of update would be better addressed in a document that > had "Diameter" in the title. Well, this is a cross-protocol issue, but I agree that the preferable vehicle would be an rfc4005bis (update or revision) document. I've previously sent an e-mail to the DIME WG chairs (and copied this list) to see if there is any document in that WG which could take on this issue. I've not seen any reply. OTOH, when RADEXT is extending RADIUS we have a pro-active obligation to address Diameter interoperability in our documents. -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2007 17:01:35 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Subject: RE: Revisions to RFC 4005 Date: Fri, 31 Aug 2007 10:00:58 -0700 Message-ID: <000d01c7ebf0$81da8a50$858f9ef0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrsQ1nmTDuePFgQ7mwlslXtyWQUgAGXmewAAlmCuA= Content-Language: en-us Alan DeKok writes... > However it is done, it looks like we have to update 4005 to > obtain Diameter compatibility for the extended attributes. That part of the problem will need to be addressed by the extended attributes draft, because our charter requires a Diameter compatibility section in any of our work products, to address interoperability with Diameter. It's not so clear that we need to address the issue of "legacy" (RADIUS Classic) VSAs in Diameter at the same time, or at least in the same document. Of course, if one mechanism serves both purposes, so much the better. [gwz] [gwz] Just for the sake of findability (don't think that that's actually a word, but hopefully you know what I mean), I wiuld think that that kind of update would be better addressed in a document that had "Diameter" in the title. -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2007 16:58:24 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'Bernard Aboba'" , , Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Fri, 31 Aug 2007 09:57:21 -0700 Message-ID: <000c01c7ebf0$005fdf70$011f9e50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrsFNwEVU+XedBTeKPcA4K0Ox7iQAPyvDg Content-Language: en-us Glen Zorn wrote: > Maybe. What do you have in mind? I don't think so, because standard > Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any > variety have a Vendor code of 0. That would be backwards compatible, and wouldn't require changes to existing implementations. > We may have a problem translating the new > RADIUS "grouped attributes" to Diameter, though, because don't Diameter > grouped AVPs have a fixed syntax? Yes. We could say that the extended attributes are encapsulated in a Diameter attribute 26 as-is... except that attribute 26 isn't allowed in Diameter packets. However it is done, it looks like we have to update 4005 to obtain Diameter compatibility for the extended attributes. [gwz] [gwz] I really think that that is going a bit overboard. Is there some reason that these things could not be handled (at worst) in a document updating 4005 instead of obsoleting it? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 12:35:06 +0000 From: "David B. Nelson" To: Subject: RE: Revisions to RFC 4005 Date: Fri, 31 Aug 2007 08:35:01 -0400 Message-ID: <026301c7ebcb$5c783a20$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrsQ1nmTDuePFgQ7mwlslXtyWQUgAGXmew Alan DeKok writes... > However it is done, it looks like we have to update 4005 to > obtain Diameter compatibility for the extended attributes. That part of the problem will need to be addressed by the extended attributes draft, because our charter requires a Diameter compatibility section in any of our work products, to address interoperability with Diameter. It's not so clear that we need to address the issue of "legacy" (RADIUS Classic) VSAs in Diameter at the same time, or at least in the same document. Of course, if one mechanism serves both purposes, so much the better. -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2007 12:19:57 +0000 Message-ID: <46D8073C.2090603@deployingradius.com> Date: Fri, 31 Aug 2007 14:19:08 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Lars Eggert CC: IESG IESG , 'radext mailing list' Subject: Re: DISCUSS: draft-ietf-radext-fixes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars Eggert wrote: >> If a duplicate response is received by the client, it is no different >> than an *unsolicited* response. Neither one matches a pending request, >> so the responses are discarded. > > Ah - that makes total sense now. I'll leave it up to you to decide if > you'd like to stick this explanation into the draft. We can add a sentence or two to clarify that: ...later responses MUST be silently discarded, as they do not match a pending request. That is, later responses are treated exactly the same as unsolicited responses, and are silently discarded. > Thanks for pointing me at that - it had slipped my mind that you had > explained this already. As above, I think sticking a bit of the > explanation from your email into the document would be good, but this is > up to you. "After about 30 seconds, most RADIUS clients and end users will have given up on the authentication request. Therefore, there is little value in having a larger cache timeout." I'll make the changes. Unless anyone else has comments, I'll submit a revised version next week. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 09:22:08 +0000 Message-ID: <46D7DD95.8020905@nitros9.org> Date: Fri, 31 Aug 2007 11:21:25 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org, d.b.nelson@comcast.net Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > Maybe. What do you have in mind? I don't think so, because standard > Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any > variety have a Vendor code of 0. That would be backwards compatible, and wouldn't require changes to existing implementations. > We may have a problem translating the new > RADIUS "grouped attributes" to Diameter, though, because don't Diameter > grouped AVPs have a fixed syntax? Yes. We could say that the extended attributes are encapsulated in a Diameter attribute 26 as-is... except that attribute 26 isn't allowed in Diameter packets. However it is done, it looks like we have to update 4005 to obtain Diameter compatibility for the extended attributes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 08:12:27 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , , Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Fri, 31 Aug 2007 01:08:46 -0700 Message-ID: <004701c7eba6$27ec13f0$77c43bd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrjkNH19YyIVeYQNmKC6jccyyOwQAFlFiQ Content-Language: en-us >9.6.2. Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP > > The Diameter AVP will consist of the following fields: > > Diameter Flags: V=1, M=0, P=0 > Diameter Vendor code = RADIUS VSA Vendor code > Diameter AVP code = RADIUS VSA Vendor type code > Diameter AVP length = length of AVP (header + data) > Diameter Data = RADIUS VSA vendor data Won't using a RADIUS VSA Vendor code of 0 result in a conflict between the RADIUS "extended" attributes and already allocated Diameter AVPs? [gwz] Maybe. What do you have in mind? I don't think so, because standard Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any variety have a Vendor code of 0. We may have a problem translating the new RADIUS "grouped attributes" to Diameter, though, because don't Diameter grouped AVPs have a fixed syntax? The RADIUS groupings could be created in an ad hoc fashion, though...in addition, 4005 says that "Nested Multiple vendor data fields MUST be expanded into multiple Diameter AVPs.". I'm not really sure that that really works even with current v-s subattributes, since it seems to assume that there is no important relation between the subattributes that could be lost by breaking them apart. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 08:12:20 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'David B. Nelson'" Cc: Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Fri, 31 Aug 2007 00:56:15 -0700 Message-ID: <004601c7eba4$683c61a0$38b524e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqNvFAhq0sLWK0RZ+0YgprCNFXQQBVpMgw Content-Language: en-us David B. Nelson wrote: > The RADIUS Design Guidelines document is targeted to be a BCP, and to > describe current usages and recommend attribute design practices based on > RADIUS as it is defined today. That's the WG's consensus. As such, it's > probably the wrong vehicle to use for introducing new usages, such as > suggesting Diameter AVPs with type 26. Current uses already involve getting RADIUS VSA's in non-RFC formats into Diameter packets. Whether we like to admit it or not, the practice already seems to be following David Mitton's draft: [gwz] Why do you think that? http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt So it is a BCP. Sort of. [gwz] Except that the (grossly misnamed) Best Current Practice documents turn out to be neither current nor practices (and rather rarely best ;-). In fact, they are statements of what the IETF (or IESG, IAB, whatever) _wishes_ the current practices would be, whether those wishes have any relation to reality or not. > If RFC 2005 needs to be updated, I think that ought to be done in a separate > document, either in RADEXT or in DIME. That's more work. Do we have an editor for that document, or someone willing to shepherd it? Is the WG against the idea of having suggested practices updating holes in previous specs? 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: Fri, 31 Aug 2007 05:43:11 +0000 Message-ID: <46D7A333.1070400@deployingradius.com> Date: Fri, 31 Aug 2007 07:12:19 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Glen Zorn CC: 'Bernard Aboba' , radiusext@ops.ietf.org, d.b.nelson@comcast.net Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > It seems as if all we'd really have to do in the extended attributes draft > is to specify that the'M' bit has to be set in the Diameter AVP. Also: - map extended attributes somewhere into the Diameter space - i.e. allocate 256 Diameter attributes for RADIUS translation - note that Diameter attributes of LONGER than 253 characters are allowed for those attributes - D<->R gateways MUST use a new method to map both attributes and lengths for extended attributes. All of that means updating the suggested mapping in RFC 4005, for both normal (now extended) RADIUS attributes, and for normal (now extended) VSA's. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Aug 2007 05:13:43 +0000 Message-ID: From: "Bernard Aboba" To: glenzorn@comcast.net Cc: radiusext@ops.ietf.org, aland@deployingradius.com, d.b.nelson@comcast.net Bcc: Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Thu, 30 Aug 2007 22:12:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >9.6.2. Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP > > The Diameter AVP will consist of the following fields: > > Diameter Flags: V=1, M=0, P=0 > Diameter Vendor code = RADIUS VSA Vendor code > Diameter AVP code = RADIUS VSA Vendor type code > Diameter AVP length = length of AVP (header + data) > Diameter Data = RADIUS VSA vendor data Won't using a RADIUS VSA Vendor code of 0 result in a conflict between the RADIUS "extended" attributes and already allocated Diameter AVPs? -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2007 04:55:06 +0000 Message-ID: <46D79ED9.1010301@deployingradius.com> Date: Fri, 31 Aug 2007 06:53:45 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Bernard Aboba CC: glenzorn@comcast.net, d.b.nelson@comcast.net, radiusext@ops.ietf.org Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Because the extended attribute draft uses Attribute 26, but with a > vendor code of 0, which currently isn't supported by RFC 4005? Also, the suggested format for RADIUS VSA's mirrors normal RADIUS attributes. With an extended attribute format, SDO's will say "Me, too", and use the same format for their attributes. Those attributes then have to be translated to Diameter. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 30 Aug 2007 23:47:49 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: , , Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Thu, 30 Aug 2007 16:46:34 -0700 Message-ID: <003f01c7eb60$02cd5f70$08681e50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfrSOGxqEMgizpuR9WxUML0yg6vigAFZJQw Content-Language: en-us >Since the "extended attributes" document will need to deal with VSA formats >(and Diameter translation of same), > >[gwz] I'm not sure why? Because the extended attribute draft uses Attribute 26, but with a vendor code of 0, which currently isn't supported by RFC 4005? [gwz] Wel, it's true that 4005 doesn't explicitly support a vendor code of zero, but I don't think that it explicitly _doesn't_ support it, either. Here's the section on translating RADIUS VSAs to Diameter: 9.6.2. Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP The Diameter AVP will consist of the following fields: Diameter Flags: V=1, M=0, P=0 Diameter Vendor code = RADIUS VSA Vendor code Diameter AVP code = RADIUS VSA Vendor type code Diameter AVP length = length of AVP (header + data) Diameter Data = RADIUS VSA vendor data Note that the VSAs are considered optional by RADIUS rules, and this specification does not set the Mandatory flag. If an implementor desires a VSA be made mandatory because it represents a required service policy, the RADIUS gateway should have a process to set the bit on the Diameter side. If the RADIUS receiving code knows of vendor specific field interpretations for the specific vendor, it may employ them to parse an extended AVP code or data length. Otherwise the recommended standard fields will be used. Nested Multiple vendor data fields MUST be expanded into multiple Diameter AVPs. [gwz] It seems as if all we'd really have to do in the extended attributes draft is to specify that the'M' bit has to be set in the Diameter AVP. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2007 21:01:54 +0000 Message-ID: From: "Bernard Aboba" To: glenzorn@comcast.net, aland@deployingradius.com, d.b.nelson@comcast.net Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Thu, 30 Aug 2007 14:01:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Since the "extended attributes" document will need to deal with VSA formats >(and Diameter translation of same), > >[gwz] I'm not sure why? Because the extended attribute draft uses Attribute 26, but with a vendor code of 0, which currently isn't supported by RFC 4005? -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2007 17:39:32 +0000 From: "David B. Nelson" To: Subject: RE: Revisions to RFC 4005 Date: Thu, 30 Aug 2007 13:32:40 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001301c7eb2b$c40bfeb0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfqXMQGKb25a6LSSdufOvV7IIcBxQAyfuZwAADSQaA= Glen Zorn writes... > > Since the "extended attributes" document will need to deal with > > VSA formats (and Diameter translation of same),... > > I'm not sure why? I agree that the issue of transparency of VSAs in RADIUS and Diameter is not strictly related to Extended RADIUS Attributes. Ideally, this would be addressed in an rfc4005bis draft. One does not exist, however. So, the question is what's the next best fit? -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2007 16:58:54 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , , Cc: Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Thu, 30 Aug 2007 09:57:49 -0700 Message-ID: <000c01c7eb26$e611f690$b235e3b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqXMQGKb25a6LSSdufOvV7IIcBxQAyfuZw Content-Language: en-us > Current uses already involve getting RADIUS VSA's in non-RFC formats >into Diameter packets. Whether we like to admit it or not, the practice >already seems to be following David Mitton's draft: > >http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt Since the "extended attributes" document will need to deal with VSA formats (and Diameter translation of same), [gwz] [gwz] I'm not sure why? >perhaps this can be tackled there? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2007 07:46:23 +0000 Message-ID: <46D66661.5020009@deployingradius.com> Date: Thu, 30 Aug 2007 08:40:33 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Bernard Aboba CC: d.b.nelson@comcast.net, radiusext@ops.ietf.org Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Since the "extended attributes" document will need to deal with VSA > formats (and Diameter translation of same), perhaps this can be tackled > there? That would be good. It *should* be addressed somewhere, and soon. 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, 30 Aug 2007 07:30:17 +0000 Message-ID: <46D66AB6.4040801@nitros9.org> Date: Thu, 30 Aug 2007 08:59:02 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Lars Eggert CC: IESG IESG , 'radext mailing list' Subject: Re: DISCUSS: draft-ietf-radext-fixes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars Eggert wrote: > [ timers ] > -06 specifies such a mechanism, which was the important part of my > concern. A minor remaining nit is that the "within the limits of > [RFC2865] Section 2.4" part should be removed, because that section in > RFC2865 does not actually discuss any such limits. OK. >>> 2.2.2. Duplicate detection and orderly delivery. ... > If clients need not perform duplicate detection, how are they supposed > to silently discard later responses? No duplicate detection = no state > about packets received in the past, right? Yes. RADIUS is a request / response protocol. The client sends a request, and looks for a matching response. Once it has a matching response, it effectively forgets about the request. If a duplicate response is received by the client, it is no different than an *unsolicited* response. Neither one matches a pending request, so the responses are discarded. >> Section 2.2.2., paragraph 8: >>> Each cache entry SHOULD be purged after a period of time. This time >>> SHOULD be no less than 5 seconds, and no more than 30 seconds. >> >> DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower >> bound will prevent late duplicates from remaining undetected. > > This has remained unchanged in -06 AFAICT. As does my response: :) http://ops.ietf.org/lists/radiusext/2007/msg00449.html In short, MSL doesn't matter to a server, as it doesn't see round trip times. It sees a request, and responds to that request. 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, 30 Aug 2007 03:08:13 +0000 From: "David B. Nelson" To: Subject: FW: DISCUSS: draft-ietf-radext-fixes Date: Wed, 29 Aug 2007 23:07:48 -0400 Message-ID: <019f01c7eab2$f2143f80$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqqmVn2eC9wDbOSxCzu33lgY6AagACHWZA Forwarding to the list... > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, August 29, 2007 10:06 PM > To: draft-ietf-radext-fixes@tools.ietf.org > Cc: IESG IESG; radext-chairs@tools.ietf.org > Subject: Re: DISCUSS: draft-ietf-radext-fixes > > Hi, > > I checked the -06 update against my original DISCUSS, and except for > the few remaining issues detailed below, all my concerns have been > addressed - thank you! > > On 2007-7-2, at 20:48, ext Lars Eggert wrote: > > Section 2.2.1., paragraph 7: > >> [b] Congestive backoff. While it is not necessary for RADIUS client > >> implementations to implement complex retransmission algorithms, > >> implementations SHOULD support congestive backoff within the > >> limits > >> suggested by [RFC2865] Section 2.4. > ... > > DISCUSS: RFC2865 Section 2.4 does not suggests any timer management > > scheme or timer limits, and I couldn't find this anywhere else in > > RFC2865, either. Consequently, this document needs to specify the > > desired mechanism. See RFC2988 for an example of such a mechanism. > > -06 specifies such a mechanism, which was the important part of my > concern. A minor remaining nit is that the "within the limits of > [RFC2865] Section 2.4" part should be removed, because that section > in RFC2865 does not actually discuss any such limits. > > > Section 2.2.2., paragraph 0: > >> 2.2.2. Duplicate detection and orderly delivery. > > > > DISCUSS: This section is all about duplicate detection at the server > > due to client retransmissions. But any UDP packet can be > > duplicated in > > the network. This section should hence also discuss detection of > > duplicate responses at the client. > > This section has significantly changed in -06. My one remaining > concern is with the new text that says: > > RADIUS clients do not have to perform duplicate detection. When a > client sends a request, it processes the first response that has a > valid Response Authenticator as defined in [RFC2865] Section 3. Any > later responses MUST be silently discarded. > > If clients need not perform duplicate detection, how are they > supposed to silently discard later responses? No duplicate detection > = no state about packets received in the past, right? > > > Section 2.2.2., paragraph 8: > >> Each cache entry SHOULD be purged after a period of time. This > >> time > >> SHOULD be no less than 5 seconds, and no more than 30 seconds. > > > > DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower > > bound will prevent late duplicates from remaining undetected. > > This has remained unchanged in -06 AFAICT. > > Lars -- to unsubscribe send a message to radiusext-request@ops.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, 29 Aug 2007 22:26:33 +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-06.txt Message-Id: Date: Wed, 29 Aug 2007 16:15: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 Remote Authentication Dial In User Service (RADIUS) Author(s) : D. Nelson, A. DeKok Filename : draft-ietf-radext-fixes-06.txt Pages : 28 Date : 2007-8-29 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-06.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-06.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-06.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-8-29151435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-fixes-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-fixes-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-29151435.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, 29 Aug 2007 17:11:19 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: "'David B. Nelson'" , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Wed, 29 Aug 2007 09:55:41 -0700 Message-ID: <001801c7ea5d$6fc8b0b0$4f5a1210$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqAsRyi+Yr8lkUQVqsnHiyzk1qSQAWihew Content-Language: en-us Glen Zorn wrote: > [gwz] It is -- the problem with "subattributes" as described in RFC 2865 is > that they must fit in a single VSA. With this draft, we open up the > possibility (with the "continuation" bit) of having really huge attributes > containing subattributes that themselves are larger than a single VSA. It > seems like we either need to restrict the usage of subattributes or decide > on one or the other. The *extended* attributes can be larger than 256 octets, due to the continuation flag. Inside of the extended attributes, any sub-attributes do not have a continuation flag, and their "length" field is still 8 bits. So they can be a few octets longer than an RFC 2865 VSA. [gwz] [gwz] Good point. So the two constructs are almost (but not quite the same)... (David) > I see an advantage in directly supporting sub-attributes, in terms of a > cleaner data model, however, I also see that diverging from the Diameter > model of grouped AVPs may lead to greater difficulty in translation and > coexistence. I'll submit the edited "guidelines" document today. It suggests that RFC 4005 be updated, and allow Diameter attributes of type 26, which will transport the contents of RADIUS attributes of type 26. Since most Diameter servers also talk RADIUS, any translation difficulties (mostly) go away. [gwz] [gwz] If you're going to do that, you might just as well just stick the whole RADIUS message in an AVP (as I've suggested before) & be done w/it: no translation, period. The server implements attribute 26 parsing once, and then it's done. 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, 29 Aug 2007 16:43:08 +0000 Message-ID: From: "Bernard Aboba" To: aland@deployingradius.com, d.b.nelson@comcast.net Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Wed, 29 Aug 2007 09:42:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > Current uses already involve getting RADIUS VSA's in non-RFC formats >into Diameter packets. Whether we like to admit it or not, the practice >already seems to be following David Mitton's draft: > >http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt Since the "extended attributes" document will need to deal with VSA formats (and Diameter translation of same), perhaps this can be tackled there? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 29 Aug 2007 13:37:40 +0000 From: "David B. Nelson" To: "'Hannes Tschofenig'" , "'Dave Frascone'" Cc: Subject: Update to RFC 4005? Date: Wed, 29 Aug 2007 09:22:33 -0400 Message-ID: <000401c7ea3f$a91bf750$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqP6hAsrKFesCbRRCJAdCSHfdGnQ== Hi Hannes and Dave, If you're following the RADEXT WG mailing list, you may have noticed that we are trying to figure out what to do about VSAs, in terms of our RADIUS Attributes Design Guidelines document. It has been suggested that Diameter allow the direct importation of RADIUS attribute 26 (VSA) in order to rationalize the treatment of VSAs between RADIUS and Diameter. There is an expired draft that describes this issue, and recommended ways to address it. http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt Alan DeKok suggested including this type of recommendation in the RADIUS Attributes Design Guidelines draft, targeted to become a BCP. I'm not so sure that a BCP can "Update" a Proposed Standard (e.g. RFC 4005). Does the DIME WG have any documents in process that might pick up and address this issue? 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: Wed, 29 Aug 2007 12:58:56 +0000 From: "David B. Nelson" To: Subject: RE: Revisions to RFC 4005 Date: Wed, 29 Aug 2007 08:58:40 -0400 Message-ID: <000301c7ea3c$531d3970$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqNfsVsLRVQCN6QDq3ZPoG8PspwgABYNwg Alan DeKok writes... > That's more work. Do we have an editor for that document, or > someone willing to shepherd it? I don't know. We should probably talk to the DIME WG chairs to see if this could be wrapped into a revision document they are already working on. > Is the WG against the idea of having suggested practices updating > holes in previous specs? It might also meet resistance at the IESG, as a proposed BCP document attempting to Update a Proposed Standard document, regardless of what the RADEXT WG feels. Generally speaking this is not permissible. That's why we needed to make the Issues and Fixes draft a Standards Track document. -- to unsubscribe send a message to radiusext-request@ops.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, 29 Aug 2007 12:13:34 +0000 Message-ID: <46D562B1.70904@deployingradius.com> Date: Wed, 29 Aug 2007 14:12:33 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > The RADIUS Design Guidelines document is targeted to be a BCP, and to > describe current usages and recommend attribute design practices based on > RADIUS as it is defined today. That's the WG's consensus. As such, it's > probably the wrong vehicle to use for introducing new usages, such as > suggesting Diameter AVPs with type 26. Current uses already involve getting RADIUS VSA's in non-RFC formats into Diameter packets. Whether we like to admit it or not, the practice already seems to be following David Mitton's draft: http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt So it is a BCP. Sort of. > If RFC 2005 needs to be updated, I think that ought to be done in a separate > document, either in RADEXT or in DIME. That's more work. Do we have an editor for that document, or someone willing to shepherd it? Is the WG against the idea of having suggested practices updating holes in previous specs? 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, 29 Aug 2007 11:14:19 +0000 From: "David B. Nelson" To: Subject: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Wed, 29 Aug 2007 07:13:49 -0400 Message-ID: <033301c7ea2d$ace22c40$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfqA+RW/SD7yL0WQLa6X5piNIACjwAKOBQw Alan DeKok writes... > I'll submit the edited "guidelines" document today. It suggests that > RFC 4005 be updated, and allow Diameter attributes of type 26, which > will transport the contents of RADIUS attributes of type 26. The RADIUS Design Guidelines document is targeted to be a BCP, and to describe current usages and recommend attribute design practices based on RADIUS as it is defined today. That's the WG's consensus. As such, it's probably the wrong vehicle to use for introducing new usages, such as suggesting Diameter AVPs with type 26. If RFC 2005 needs to be updated, I think that ought to be done in a separate document, either in RADEXT or in DIME. -- to unsubscribe send a message to radiusext-request@ops.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, 29 Aug 2007 06:07:34 +0000 Message-ID: <46D50CCC.6030501@deployingradius.com> Date: Wed, 29 Aug 2007 08:06:04 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Glen Zorn CC: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > [gwz] It is -- the problem with "subattributes" as described in RFC 2865 is > that they must fit in a single VSA. With this draft, we open up the > possibility (with the "continuation" bit) of having really huge attributes > containing subattributes that themselves are larger than a single VSA. It > seems like we either need to restrict the usage of subattributes or decide > on one or the other. The *extended* attributes can be larger than 256 octets, due to the continuation flag. Inside of the extended attributes, any sub-attributes do not have a continuation flag, and their "length" field is still 8 bits. So they can be a few octets longer than an RFC 2865 VSA. (David) > I see an advantage in directly supporting sub-attributes, in terms of a > cleaner data model, however, I also see that diverging from the Diameter > model of grouped AVPs may lead to greater difficulty in translation and > coexistence. I'll submit the edited "guidelines" document today. It suggests that RFC 4005 be updated, and allow Diameter attributes of type 26, which will transport the contents of RADIUS attributes of type 26. Since most Diameter servers also talk RADIUS, any translation difficulties (mostly) go away. The server implements attribute 26 parsing once, and then it's done. 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, 28 Aug 2007 22:36:42 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Subject: RE: Extended attributes support for structured data (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Tue, 28 Aug 2007 13:24:34 -0700 Message-ID: <003901c7e9b1$7311fb70$5935f250$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9gACVyX5AACTLrcAABLHsQAAIqARA= Content-Language: en-us -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson Sent: Tuesday, August 28, 2007 12:24 PM To: radiusext@ops.ietf.org Subject: Extended attributes support for structured data (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Glen Zorn writes... > Actually, it does (as illustrated in the examples), it's just not > very explicit about it. Right. I certainly missed it. > ...the problem with "subattributes" as described in RFC 2865 is > that they must fit in a single VSA. With this draft, we open up > the possibility (with the "continuation" bit) of having really huge > attributes containing subattributes that themselves are larger than > a single VSA. It seems like we either need to restrict the usage > of subattributes or decide on one or the other. One or the other what? Could you please elaborate? [gwz] Sorry, either really big attributes w/really big subattributes or grouped attributes. They seem to both serve the same purpose. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Aug 2007 19:23:40 +0000 From: "David B. Nelson" To: Subject: Extended attributes support for structured data (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt) Date: Tue, 28 Aug 2007 15:23:36 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004601c7e9a8$ee569e20$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9gACVyX5AACTLrcAABLHsQ Glen Zorn writes... > Actually, it does (as illustrated in the examples), it's just not > very explicit about it. Right. I certainly missed it. > ...the problem with "subattributes" as described in RFC 2865 is > that they must fit in a single VSA. With this draft, we open up > the possibility (with the "continuation" bit) of having really huge > attributes containing subattributes that themselves are larger than > a single VSA. It seems like we either need to restrict the usage > of subattributes or decide on one or the other. One or the other what? Could you please elaborate? -- to unsubscribe send a message to radiusext-request@ops.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, 28 Aug 2007 18:54:21 +0000 From: "Glen Zorn" To: "'David B. Nelson'" , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Tue, 28 Aug 2007 11:53:14 -0700 Message-ID: <003301c7e9a4$b0e38e80$12aaab80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9gACVyX5AACTLrcA== Content-Language: en-us ... As currently being discussed in this thread, the draft does not permit the encoding of sub-attributes within an Extended RADIUS attribute format. [gwz] Actually, it does (as illustrated in the examples), it's just not very explicit about it. RFC 2865 permits this practice for VSAs with a non-zero Vendor-ID, i.e. non-IETF "vendors". RFC 2865, Section 5.26 reads, in part: Multiple subattributes MAY be encoded within a single Vendor- Specific attribute, although they do not have to be. Should we include similar language in this draft, perhaps with a prohibition on nested sub-attribute for the sake of simplicity, in this document? I thought that the presentation on this draft at IETF-69 indicated that this capability would be available. [gwz] [gwz] It is -- the problem with "subattributes" as described in RFC 2865 is that they must fit in a single VSA. With this draft, we open up the possibility (with the "continuation" bit) of having really huge attributes containing subattributes that themselves are larger than a single VSA. It seems like we either need to restrict the usage of subattributes or decide on one or the other. As long the recommended structure of sub-attributes is standardized and limited, so as to limit the variations of format that servers would be expected to cope with, I think this would be a good feature, in support of structured, multi-part attributes. I understand that the tagging feature can also support structured data, in an indirect fashion, but its design is optimized to support related groups of individual attributes (grouped AVPs). That's the way Diameter addresses the issue of structured data. I see an advantage in directly supporting sub-attributes, in terms of a cleaner data model, however, I also see that diverging from the Diameter model of grouped AVPs may lead to greater difficulty in translation and coexistence. Discussion? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Aug 2007 15:30:07 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Tue, 28 Aug 2007 11:29:50 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003801c7e988$46084680$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9gACa4IRA= Further comments on the draft: Section 2. Although according to the specification the allocation of RADIUS attribute type codes has been controlled by IANA, this has not been the case in reality. In the real world, certain vendors have grabbed attribute type codes that they shouldn't have. The result is that many RADIUS deployments have had to work around these attribute collisions. Therefore, each time a new attribute type is introduced it raises the possibility that something will break. The proposed scheme must be impervious to this artifact. I suggest deleting this paragraph. It duplicates some content of RFC 3575 and adds nothing to the purpose of this document, going forward. Section 7. This solution requires that the IETF be allocated Vendor-Type of zero to the IETF. RFC 2865, Section 5.26 says, in part: Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the "Assigned Numbers" RFC [6]. Taken together, these sections of text might be interpreted to mean that the IETF is assigning a Private Enterprise Code of 0 to itself. The PEN Registry at the following URL: http://www.iana.org/assignments/enterprise-numbers indicates: 0 Reserved Internet Assigned Numbers Authority iana&iana.org that 0 is reserved for IANA. Is that the same as reserved for IETF use? Should we add clarifying text to indicate that the Vendor-Id of 0 is not strictly a PEN? It also requires that IANA be set up to manage the RADIUS Extended Attributes. This means that there would be a new section in the existing RADIUS Registry dealing with IETF VSA Extended-Type field. The allocation rules for extended RADIUS attributes align with the rules for allocation of the standard RADIUS attributes. Does this mean to reference RFC 3575? -- to unsubscribe send a message to radiusext-request@ops.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, 28 Aug 2007 14:49:55 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Tue, 28 Aug 2007 10:49:42 -0400 Organization: Elbrys Networks, Inc. Message-ID: <003101c7e982$aaf9daf0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9gACVyX5A= Specific comments on the draft: Abstract: In order for the Remote Authentication Dial In User Service protocol to continue to support new applications, the RADIUS attribute space must be extended beyond the current limit of 255 possible attribute types. This document defines a mechanism to extend the base RADIUS attribute types while maintaining backwards compatibility as well as compatibility with Diameter. If this document is to address grouped attributes (AVPs) and structured (complex or multi-part) attributes, we should so indicate in the abstract. That description should be included in the Introduction section, as well. Section 2. A need to group RADIUS attributes together has become more prevalent in current work. Therefore, the proposed scheme NUST provide a mechanism to group attributes. s/NUST/MUST/ Section 4. Up-to-date values of the RADIUS Extended-Type field are specified in the most recent "Assigned Numbers" IANA [RFC3575] . Values XXXX-YYYY are reserved. Actually, RFC 3575 does not contain the RADIUS Registry, that is located at the following URL: http://www.iana.org/assignments/radius-types. RFC 3575 documents some RFC-defined and some legacy "bootlegged" assignments, and defines a process for IANA assignment going forward from its date of publication. It is not the registry. The draft text should clarify the distinction. As currently being discussed in this thread, the draft does not permit the encoding of sub-attributes within an Extended RADIUS attribute format. RFC 2865 permits this practice for VSAs with a non-zero Vendor-ID, i.e. non-IETF "vendors". RFC 2865, Section 5.26 reads, in part: Multiple subattributes MAY be encoded within a single Vendor- Specific attribute, although they do not have to be. Should we include similar language in this draft, perhaps with a prohibition on nested sub-attribute for the sake of simplicity, in this document? I thought that the presentation on this draft at IETF-69 indicated that this capability would be available. As long the recommended structure of sub-attributes is standardized and limited, so as to limit the variations of format that servers would be expected to cope with, I think this would be a good feature, in support of structured, multi-part attributes. I understand that the tagging feature can also support structured data, in an indirect fashion, but its design is optimized to support related groups of individual attributes (grouped AVPs). That's the way Diameter addresses the issue of structured data. I see an advantage in directly supporting sub-attributes, in terms of a cleaner data model, however, I also see that diverging from the Diameter model of grouped AVPs may lead to greater difficulty in translation and coexistence. Discussion? -- to unsubscribe send a message to radiusext-request@ops.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, 28 Aug 2007 11:50:51 +0000 Message-ID: <46D40BDF.7080004@deployingradius.com> Date: Tue, 28 Aug 2007 13:49:51 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Glen Zorn CC: 'Alan DeKok' , "'David B. Nelson'" , 'radext mailing list' Subject: Re: Extensibility of draft-ietf-radext-filter-rules Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > However, the filter rules document could quickly use many attributes, > exhausting the standard attribute space. > [gwz] > [gwz] I'm a bit confused by this statement: the attribute extension draft > basically doubles the size of the existing > "standard attribute space. Are you saying that the filter rules would take > up that whole extension? No, but it defines a lot of attributes that can be interpreted ONLY in a grouped context. It's just easier to define a filter rule attribute, and pack it with sub-attributes that the filter rules need. It means that the filter rules are also easily extensible. > Given the utility of sub-attributes, and the fact that most vendors > have implemented them already, or will implement them for WiMAX, I'm > inclined to add them to the extended attributes draft. > [gwz] What changes would you make? If the current draft doesn't have sub-attributes, just used 8-bit sub-TLV's, and creating a "tlv" type would be sufficient. 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, 28 Aug 2007 06:43:48 +0000 Message-ID: <46D3C3E1.3030802@deployingradius.com> Date: Tue, 28 Aug 2007 08:42:41 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Bernard Aboba CC: glenzorn@comcast.net, dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Subject: Re: Consideration of consideration of requirements for consideration Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > So far, only three people have responded to this topic, and two of them > are the chairs. Are we sure we even have a quorum to talk about quorum > requirements ?:) Whatever we're talking about, I support the consensus. 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, 27 Aug 2007 22:01:32 +0000 From: "David B. Nelson" To: "'Hannes Tschofenig'" Cc: "'radext mailing list'" Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 18:01:35 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001501c7e8f5$d5d97ba0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfot4dNdLBSYEuDQieGj2BhBThaWQAPZFbQ Hannes Tschofenig writes... > Right. There is, however, a timing issue involved with the work and > I am not sure when the corresponding work in RADIUS gets done. Do > you have an estimate? Well, we've moved forward today to having accepted the draft as a WG document and the editor has indicated that a revised -00 draft will be posted sometime this week. It would be nice to think that we could be ready for a WGLC within a few weeks, unless we get bogged down in comment resolution from the initial formal review. In an optimistic scenario, one might envision completion of WGLC prior to IETF-70. :-) -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 21:35:07 +0000 Message-ID: From: "Bernard Aboba" To: glenzorn@comcast.net, aland@nitros9.org, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 14:34:50 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > I didn't see a call on the list to make the extended attributes document >a WG item. Here is a link to the call: http://ops.ietf.org/lists/radiusext/2007/msg00477.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 21:19:20 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'David B. Nelson'" Cc: "'radext mailing list'" Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 09:41:36 -0700 Message-ID: <001a01c7e8c9$22db33d0$68919b70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfotUD2hHYjQtOsSzaBHsy8+J0iEwAE5obg Content-Language: en-us ..[gwz] . > BTW, I think we have completed the consensus call on that document, but I > don't remember if I saw the official result announced. I didn't see a call on the list to make the extended attributes document a WG item. [gwz] [gwz] That happened some time ago -- in fact, I think you even responded positively ;-) [gwz] There wasn't any objections at IETF 69, though. 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: Mon, 27 Aug 2007 21:16:23 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: "'Bernard Aboba'" , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 13:40:15 -0700 Message-ID: <003101c7e8ea$796bfce0$6c43f6a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo5mZQIJM42oYbTXKaUXxOVi1aswAAOkcgAABNIGAAAHuFsA== Content-Language: en-us -----Original Message----- From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] Sent: Monday, August 27, 2007 1:28 PM To: 'Glen Zorn' Cc: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Glen Zorn writes... > [gwz] OK, so I'll finish cleaning up the examples in the draft & > submit the new "draft-ietf-radext" version this week. Please use file name draft-ietf-radext-extended-attributes-00.txt. [gwz] ACK Thanks! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 21:13:26 +0000 From: "Glen Zorn" To: "'Peter Nixon'" , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 13:38:02 -0700 Message-ID: <002a01c7e8ea$2a350ea0$7e9f2be0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo57CFyN6AtYbfSb2Hd3R+rOtswQAAWg9g Content-Language: en-us [gwz] ... FWIW I also think that RADSEC should be a WG item also but I am aware that some people are vehemently against that for reasons that are less apparent... [gwz] Since I am one of those people, let me try to further clarify my reasons for opposition. Very simply, RADSEC is not RADIUS & this is the RADIUS Extensions WG. RADSEC changes virtually everything in RADIUS except the format of the packets & attributes. This must be considered a new protocol, IMHO. If the RADSEC folks want to have a BOF & try to convince the IETF that we should work on standardizing this arguably good idea (at least in the context of server<->server communication, I'm not convinced about client<->server) I wouldn't oppose that at all, since that's the way we deal with new protocols around here, AFAIK. ... -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 20:27:38 +0000 From: "David B. Nelson" To: "'Glen Zorn'" Cc: "'Bernard Aboba'" , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 16:27:48 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000801c7e8e8$bb9920e0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo5mZQIJM42oYbTXKaUXxOVi1aswAAOkcgAABNIGA= Glen Zorn writes... > [gwz] OK, so I'll finish cleaning up the examples in the draft & > submit the new "draft-ietf-radext" version this week. Please use file name draft-ietf-radext-extended-attributes-00.txt. Thanks! -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 20:24:55 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 16:24:57 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000701c7e8e8$55c1f620$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo5k8R00rbOFClRhirD88U6F5WNAAAWLHg Bernard Aboba writes... > The call for adoption of a WG work item is separate from the final > consensus determination. Agreed. > In the call for adoption, the goal is to determine if there are > enough people interested and whether there is consensus for adoption. Yup. > In determining this, both the opinions voiced on the mailing list > and at IETF 69 need to be taken into account. Right. > Given that no dissenting opinions have been voiced and given the > size of both audiences put together, I think that the adoption > requirements have been met. Good deal. Will the authors of this draft please prepare a revision with the file name draft-ietf-radext-extended-attributes-00.txt? We will then begin formal review, leading to WGLC. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 20:19:54 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" , , Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 13:19:33 -0700 Message-ID: <002001c7e8e7$955d5640$c01802c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo5mZQIJM42oYbTXKaUXxOVi1aswAAOkcg Content-Language: en-us >Please recall, however, that as a rough rule of thumb the IESG likes to see >a document thoroughly reviewed and commented upon by six or more >individuals >during WGLC, before it can be sent to the IESG as "publication requested". >That's why we ask for that level of interest before adopting a draft as a >WG >work item. The call for adoption of a WG work item is separate from the final consensus determination. In the call for adoption, the goal is to determine if there are enough people interested and whether there is consensus for adoption. In determining this, both the opinions voiced on the mailing list and at IETF 69 need to be taken into account. Given that no dissenting opinions have been voiced and given the size of both audiences put together, I think that the adoption requirements have been met. [gwz] [gwz] OK, so I'll finish cleaning up the examples in the draft & submit the new "draft-ietf-radext" version this week. [gwz] ... -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 20:18:26 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 16:18:30 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000601c7e8e7$6f88e380$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfo5Sk3tg1cEMWQTQGIQ38SAFLz3AAAg/aw Bernard Aboba writes... > Note that this was a request from a *former* member of the IESG. Yeah, but I saw something similar from Jari Arkko more recently. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 20:16:37 +0000 From: Peter Nixon To: radiusext@ops.ietf.org Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 23:16:12 +0300 User-Agent: KMail/1.9.6 (enterprise 20070731.694771) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708272316.13049.listuser@peternixon.net> On Mon 27 Aug 2007, you wrote: > [gwz] ... > > (b) "Is the level of affirmative response sufficient for this draft to > become a WG work item?" > [gwz] > [gwz] Discounting the recent explosion of people (seldom, if ever, heard > from before) pushing radsec, I suspect that there aren't many more than 4 > people active on this list (even including authors & chairs ;-). There are many of us who also lurk on the list and prefer to leave the arguing up to others :-) I think this draft should be accepted as a WG item. FWIW I also think that RADSEC should be a WG item also but I am aware that some people are vehemently against that for reasons that are less apparent... Regards -- Peter Nixon http://peternixon.net/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 20:08:14 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Bcc: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 13:07:56 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Please recall, however, that as a rough rule of thumb the IESG likes to see >a document thoroughly reviewed and commented upon by six or more >individuals >during WGLC, before it can be sent to the IESG as "publication requested". >That's why we ask for that level of interest before adopting a draft as a >WG >work item. The call for adoption of a WG work item is separate from the final consensus determination. In the call for adoption, the goal is to determine if there are enough people interested and whether there is consensus for adoption. In determining this, both the opinions voiced on the mailing list and at IETF 69 need to be taken into account. Given that no dissenting opinions have been voiced and given the size of both audiences put together, I think that the adoption requirements have been met. In the final consensus determination, there is a need to make sure that the document has been thoroughly reviewed, both within the WG and externally (if necessary). As a result, that process is somewhat different. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 20:01:51 +0000 Message-ID: From: "Bernard Aboba" To: glenzorn@comcast.net, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Consideration of consideration of requirements for consideration Date: Mon, 27 Aug 2007 13:01:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[gwz] Discounting the recent explosion of people (seldom, if ever, heard >from before) pushing radsec, I suspect that there aren't many more than 4 >people active on this list (even including authors & chairs ;-). So far, only three people have responded to this topic, and two of them are the chairs. Are we sure we even have a quorum to talk about quorum requirements ?:) -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 19:59:24 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Bcc: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 12:59:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Please recall, however, that as a rough rule of thumb the IESG likes to see >a document thoroughly reviewed and commented upon by six or more >individuals >during WGLC, before it can be sent to the IESG as "publication requested". >That's why we ask for that level of interest before adopting a draft as a >WG >work item. Note that this was a request from a *former* member of the IESG. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 19:53:46 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 15:53:35 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000501c7e8e3$f3f86130$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Ace9tOzrK/K07uGHRIeggMd0wdfJ2grIgqIgAAJA/GAAAKhbIA== Glen Zorn writes... > ... I suspect that there aren't many more than 4 people active on > this list (even including authors & chairs ;-). Winking smiley-face duly noted. Please recall, however, that as a rough rule of thumb the IESG likes to see a document thoroughly reviewed and commented upon by six or more individuals during WGLC, before it can be sent to the IESG as "publication requested". That's why we ask for that level of interest before adopting a draft as a WG work item. Do we have any additional "takers" for this draft? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 19:30:50 +0000 From: "Glen Zorn" To: "'David B. Nelson'" Cc: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 12:30:16 -0700 Message-ID: <001c01c7e8e0$b2c2aed0$18480c70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Ace9tOzrK/K07uGHRIeggMd0wdfJ2grIgqIgAAJA/GA= Content-Language: en-us [gwz] ... (b) "Is the level of affirmative response sufficient for this draft to become a WG work item?" [gwz] [gwz] Discounting the recent explosion of people (seldom, if ever, heard from before) pushing radsec, I suspect that there aren't many more than 4 people active on this list (even including authors & chairs ;-). [gwz] ... -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 18:32:10 +0000 From: "David B. Nelson" To: Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt Date: Mon, 27 Aug 2007 14:31:39 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000001c7e8d8$81bb3c60$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: Ace9tOzrK/K07uGHRIeggMd0wdfJ2grIgqIg Bernard Aboba writes... > Please reply to this message indicating whether you believe the > document should be adopted as a RADEXT WG work item. =A0 > This Request for Review will last until July 22, 2007. In reviewing the archives, I see that six WG members, including two who = are authors of the draft, indicated that it ought to be come a WG work item. FWIW, I think so too. No WG members objected. Discounting chairs and authors, four WG members responded affirmatively. The consensus of the room at IETF-69 was in favor of adopting this = document as s WG work item. The deadline for review passed about a month ago. This leads me to ask: (a) "Are there any other responses pro or con?" (b) "Is the level of affirmative response sufficient for this draft to become a WG work item?" (c) "If not, are there any other suggestions as to how the RADEXT WG = should fulfill this charter deliverable?" -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 17:14:47 +0000 From: "Glen Zorn" To: "'Alan DeKok'" , "'David B. Nelson'" Cc: "'radext mailing list'" Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 09:38:11 -0700 Message-ID: <001901c7e8c8$a897c390$f9c74ab0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acfos4reMKTLiWEcSoyPbpMu8CzTsQAFHtWw Content-Language: en-us David B. Nelson wrote: > Maybe. Keep in mind that the Extended RADIUS attribute work is introducing > a method of accommodating grouped attributes (AVPs) in RADIUS. That's nice, but doesn't solve the next problem. The filter rules document really describes transporting IP addresses and ports via... text strings. The guidelines document says this is not recommended. However, the filter rules document could quickly use many attributes, exhausting the standard attribute space. [gwz] [gwz] I'm a bit confused by this statement: the attribute extension draft basically doubles the size of the existing "standard attribute space. Are you saying that the filter rules would take up that whole extension? Is it time to allow sub-attributes? I will not that the guidelines document also has them as not recommended. But 3GPP is using them, as is WiMAX. And WiMAX is using the extended attributes proposal... with the WiMAX vendor identifier. Given the utility of sub-attributes, and the fact that most vendors have implemented them already, or will implement them for WiMAX, I'm inclined to add them to the extended attributes draft. [gwz] What changes would you make? That would permit the filter rules document to define sub-attributes using the normal RADIUS data types, and encapsulate them in a "filter rules" AVP. Given the choice between implementing sub-attributes and parsing text strings, I strongly prefer sub-attributes. 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, 27 Aug 2007 14:37:11 +0000 Message-ID: <46D2E142.4040007@gmx.net> Date: Mon, 27 Aug 2007 16:35:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "David B. Nelson" CC: 'radext mailing list' Subject: Re: Extensibility of draft-ietf-radext-filter-rules Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, David B. Nelson wrote: > Hannes Tschofenig writes... > > >> I have sent a few mails regarding the extensibility of >> draft-ietf-radext-filter-rules >> >> I have never received a response on how it should look like. >> > > This is an open issue against that document and we need to resolve it here > on the list. Will the authors please comment? > > >> As I indicated in a previous mail we have guessed one approach in >> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt. >> It uses grouped AVPs and is therefore not great for RADIUS. >> > > Maybe. Keep in mind that the Extended RADIUS attribute work is introducing > a method of accommodating grouped attributes (AVPs) in RADIUS. > > Right. There is, however, a timing issue involved with the work and I am not sure when the corresponding work in RADIUS gets done. Do you have an estimate? Ciao Hannes > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 14:26:40 +0000 From: "David B. Nelson" To: Subject: RE: Draft Update: draft-ietf-geopriv-radius-lo-16.txt Date: Mon, 27 Aug 2007 10:25:35 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004f01c7e8b6$222fac30$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfoByNrU9XwAUgmR3qege2VOJ7jaQArlfUw Bernard Aboba writes... > -16 of the RADIUS Location Document has been submitted. This is likely to > be the last revision. So if there are any issues, please speak up NOW. I think that this document is as good as it's going to get, given that the RADEXT WG has only recently come to a tentative consensus on the format of an extended RADIUS attribute that would support complex (i.e. multi-part) attributes via the use of sub-attributes. That document is not yet available as a RADEXT WG work item draft (coming soon?). I think that the GEOPRIV draft could have been a much cleaner design if it has used sub-attributes, from the forthcoming RADIUS Extended Attributes draft, but the timing of this wasn't auspicious. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 14:16:43 +0000 Message-ID: <46D2DC5E.2060706@nitros9.org> Date: Mon, 27 Aug 2007 16:14:54 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "David B. Nelson" CC: 'radext mailing list' Subject: Re: Extensibility of draft-ietf-radext-filter-rules Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >> Is it time to allow sub-attributes? > > That's exactly what the proposed Extended Attributes work provides. One > level of nesting for sub-attributes. I thought I had seen it at one point, but that doesn't stand out in a quick check of the current draft. >> I will not that the guidelines document also has them as not >> recommended. > > For RADIUS "Classic", that's correct. The guidelines document should probably say it's OK for RADEXT to do it. :) .. > BTW, I think we have completed the consensus call on that document, but I > don't remember if I saw the official result announced. I didn't see a call on the list to make the extended attributes document a WG item. There wasn't any objections at IETF 69, though. 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, 27 Aug 2007 14:08:14 +0000 From: "David B. Nelson" To: "'radext mailing list'" Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 10:07:03 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004e01c7e8b3$8b3bca90$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfosnK6sFbV8cUAT5C15CSAnQ3WrAAAHcNw Alan DeKok writes... > However, the filter rules document could quickly use many attributes, > exhausting the standard attribute space. That's would not be the intent. Read on. > Is it time to allow sub-attributes? That's exactly what the proposed Extended Attributes work provides. One level of nesting for sub-attributes. > I will not that the guidelines document also has them as not > recommended. For RADIUS "Classic", that's correct. > That would permit the filter rules document to define sub-attributes > using the normal RADIUS data types, and encapsulate them in a "filter > rules" AVP. Given the choice between implementing sub-attributes and > parsing text strings, I strongly prefer sub-attributes. That's how the filter rules draft would be designed using the extended attributes draft. BTW, I think we have completed the consensus call on that document, but I don't remember if I saw the official result announced. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 14:00:45 +0000 Message-ID: <46D2D8A7.2090509@nitros9.org> Date: Mon, 27 Aug 2007 15:59:03 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "David B. Nelson" CC: 'radext mailing list' Subject: Re: Extensibility of draft-ietf-radext-filter-rules Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Maybe. Keep in mind that the Extended RADIUS attribute work is introducing > a method of accommodating grouped attributes (AVPs) in RADIUS. That's nice, but doesn't solve the next problem. The filter rules document really describes transporting IP addresses and ports via... text strings. The guidelines document says this is not recommended. However, the filter rules document could quickly use many attributes, exhausting the standard attribute space. Is it time to allow sub-attributes? I will not that the guidelines document also has them as not recommended. But 3GPP is using them, as is WiMAX. And WiMAX is using the extended attributes proposal... with the WiMAX vendor identifier. Given the utility of sub-attributes, and the fact that most vendors have implemented them already, or will implement them for WiMAX, I'm inclined to add them to the extended attributes draft. That would permit the filter rules document to define sub-attributes using the normal RADIUS data types, and encapsulate them in a "filter rules" AVP. Given the choice between implementing sub-attributes and parsing text strings, I strongly prefer sub-attributes. 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, 27 Aug 2007 13:56:33 +0000 Message-ID: <46D2D77E.60003@nitros9.org> Date: Mon, 27 Aug 2007 15:54:06 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Issues & Fixes document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > I think that's right. Would you like to reprise the final proposed > resolution text, i.e. the changes to the current draft? I think I've lost > track... The I-D tools page will show the "diff" graphically, but here it is from local version control. It's a bit long, so it might be an awkward read as-is. Alan DeKok. ----- @@ -152,30 +152,102 @@ Some RADIUS client implementations do no Some RADIUS client implementations do not properly use the State attribute in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user -on the same NAS and port). - -Where an EAP-Message attribute is included in an Access-Challenge or -Access-Accept attribute, RADIUS servers SHOULD also include a State -attribute. See Section 2.1.3 on Request ID supplementation for -additional benefits to using the State attribute in this fashion. - +on the same NAS and port). Where an EAP-Message attribute is included +in an Access-Challenge or Access-Accept attribute, RADIUS servers +SHOULD also include a State attribute. See Section 2.1.2 on Request +ID supplementation for additional benefits to using the State +attribute in this fashion. + +As defined in [RFC2865] Table 5.44, Access-Request packets may contain +a State attribute. The table does not qualify this statement, while +the text in Section 5.24 quoted above adds other requirements not +specified in that table. + +We extend the requirements of [RFC2865] to say that Access-Requests +which are part of an ongoing Access-Request / Access-Challenge +authentication process SHOULD contain a State attribute. It is the +responsibility of the server to send a State attribute in an +Access-Challenge packet, if that server needs a State attribute in a +subsequent Access-Request to tie multiple Access-Requests togther into +one authentication session. As defined in [RFC2865] Section 5.24, the +State MUST be sent unmodified from the client to the server in the new +Access-Request reply to that challenge, if any. + +While most server implementations require the presence of a State +attribute in an Access-Challenge packet, some challenge-response +systems can distinguish the initial request from the response to the +challenge without using a State attribute to track an authentication +session. The Access-Challenge and subsequent Access-Request packets +for those systems do not need to contain a State attribute. + +Other authentication mechanisms need to tie a sequence of +Access-Request / Access-Challenge packets together into one ongoing +authentication session. Servers implementing those authentication +mechanisms SHOULD include a State attribute in Access-Challenge +packets. + +In general, if the authentication process involves one or more +Access-Request / Access-Challenge sequences, the State attribute +SHOULD be sent by the server in the Access-Challenge packets. Using +the State attribute to create a multi-packet session is the simplest +method available in RADIUS today. While other methods of creating +multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1), +those methods are NOT RECOMMENDED. + +The only permissible values for a State attribute are values provided +in an Access-Accept, Access-Challenge, CoA-Request or +Disconnect-Request packet. A RADIUS client MUST use only those values +for the State attribute that it has previously received from a server. An Access-Request sent as a result of a new or restarted -authentication run MUST NOT include the State attribute, even if the +authentication run MUST NOT include the State attribute, even if a State attribute has previously been received in an Access-Challenge for the same user and port. -Since a State attribute is always initially provided by the server in -an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request, -a RADIUS client MUST NOT insert a State attribute that it has not -previously received from the server. - -As defined in [RFC 2865] Table 5.44, Access-Request packets MAY -contain a State attribute. We extend that definition here, to say -that Access-Request packets that contain an authentication attribute -or a Service-Type attribute with the value Call Check (10) MAY contain -a State attribute. Access-Request packets not matching the above -description MUST contain a State attribute. - +In contrast, Access-Requests which are intended to perform +authorization checks MUST contain a State attribute in order to tie +the authorization check to a previous authentication session. This +last requirement often means that an Access-Accept needs to contain a +State attribute, which is then used in a later Access-Request that +performs authorization checks. + +Access-Request packets that contain a Service-Type attribute with +value Authorize Only (17) MUST contain a State attribute. +Access-Request packets that contain a Service-Type attribute with +value Call Check (10) SHOULD NOT contain a State attribute. Any other +Access-Request packet that performs authorization checks MUST contain +a State attribute. + +The standard use case for Call-Check is pre-screening authentication +based solely on the end-point identifier information, such as phone +number or MAC address in Calling-Station-ID and optionally +Called-Station-ID. In that use case there is no source of the State +attribute in the NAS. Other, non-standard, uses of Call-Check may +require or permit the use of a State Attribute, but are beyond the +scope of this document. + +Implementing Call Check functionality via requests where the User-Name +and User-Password contain the same information (e.g. MAC address) is +NOT RECOMMENDED. This practice gives an attacker both the clear-text +and cipher-text of the User-Password field, which permits many +additional attacks on the security of the RADIUS protocol. For +example, if the Request Authenticator does not satisfy the [RFC2865] +requirements on global and temporal uniqueness, the practice described +above may lead to the compromise of the User-Password attribute in +other Access-Requests for unrelated users. Access to the cipher-text +also greatly simplifies offline dictionary attacks, potentially +exposing the shared secret, and compromising the entire RADIUS +protocol. + +Any Access-Request packet that performs authorization checks, +including Call Check, MUST contain a Message-Authenticator attribute. +Any response to an Access-Request performing an authorization check +MUST NOT contain confidential information about any user (such as +Tunnel-Password), unless that Access-Request contains a State +attribute. The use of State here permits the authorization check to +be tied to an earlier user authentication. In that case, the server +MAY respond to the NAS with confidential information about that user. +The server MUST NOT respond to that authorization check with +confidential information about any other user. .in -0.3i .NH 3 .R @@ -275,13 +347,20 @@ implementations to implement complex ret implementations to implement complex retransmission algorithms, implementations SHOULD support congestive backoff within the limits suggested by [RFC2865] Section 2.4. - +.PP +.in +0.3i RADIUS retransmission timers are based on the model used in DHCPv6 [RFC3315]. Variables used here are also borrowed from this specification. RADIUS is a request/response-based protocol. The message exchange terminates when the requester successfully receives the answer or the message exchange is considered to have failed -according to the retransmission mechanism described below. +according to the RECOMMENDED retransmission mechanism described below. +Other retransmission mechanisms are possible, so long as they satisfy +the requirements on jitter and congestive backoff. + +The following algorithms apply to any client that originates RADIUS +packets, including but not limited to Access-Request, +Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576]. The retransmission behavior is controlled and described by the following variables: @@ -341,6 +420,13 @@ message. If MRC is non-zero, the messag message. If MRC is non-zero, the message exchange fails when the either the sender has transmitted the message MRC times, or when MRD seconds have elapsed since the client first transmitted the message. + +For Accounting-Request packets, the default values for MRC, MRD, and +MRT SHOULD be zero. These settings will enable a RADIUS client to +continue sending accounting requests to a RADIUS server until the +request is acknowledged. If any of MRC, MRD, or MRT are non-zero, +then the accounting information could potentially be discarded without +being recorded. .in -0.3i .NH 3 .R @@ -732,24 +818,27 @@ 5.26 states: .fi It is possible for either a standard attribute or VSA to represent a -request for an unavailable service. However, where the Type or -Vendor-ID is unknown, a RADIUS client will not know whether the -attribute defines a service or not. - -In general, it is best for RADIUS clients to err on the side of +request for an unavailable service. However, where the Type, +Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know +whether the attribute defines a service or not. + +In general, it is best for a RADIUS clients to err on the side of caution. On receiving an Access-Accept including an attribute of -unknown Type, a RADIUS client SHOULD assume that it is a potential -service definition, and treat it as an Access-Reject. Unknown VSAs -SHOULD be ignored by RADIUS clients. - -As there may be interoperability issues with the above suggestion, -client implementations SHOULD make the suggested behavior -configurable. A configuration flag such as "treat unknown attributes -as reject" can be exposed to the system administrator. If the flag is +known Type for an unimplemented service, a RADIUS client MUST treat it +as an Access-Reject, as directed in [RFC2865] Section 1.1. On +receiving an Access-Accept including an attribute of unknown Type, a +RADIUS client SHOULD assume that it is a potential service definition, +and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by +RADIUS clients. + +In order to avoid introducing changes in default behavior, existing +implementations that do not obey this recommendation should make the +behavior configurable, with the legacy behavior being enabled by +default. A configuration flag such as "treat unknown attributes as +reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown -attributes in Access-Accepts are be silently ignored. The default -value for the flag SHOULD be set to true. +attributes in Access-Accepts are be silently ignored. On receiving a packet including an attribute of unknown type, RADIUS authentication server implementations SHOULD ignore such attributes. @@ -1163,7 +1252,8 @@ forged by an attacker. Cache entries ca forged by an attacker. Cache entries can then be forcibly expired, negating the utility of the cache. This attack can be mitigated by following the suggestions in [RFC3579] Section 4, or by requiring the -presence of Message-Authenticator, as described in Section 2.2.2. +presence of Message-Authenticator, as described in Sections 2.1.1 and +2.2.2. Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in a wide variety of @@ -1211,6 +1301,10 @@ Droms, R., Bound, J., Volz, B., Lemon, T Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. +.IP [RFC3576] +Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, +"Dynamic Authorization Extensions to Remote Authentication +Dial In User Service (RADIUS)", RFC 3576, July 2003. .IP [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 13:31:10 +0000 From: "David B. Nelson" To: "'radext mailing list'" Subject: RE: Extensibility of draft-ietf-radext-filter-rules Date: Mon, 27 Aug 2007 09:29:46 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004b01c7e8ae$561c5780$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfoFXiu56twu+FGRVyzRWXtdmD64gAmF5Sw Hannes Tschofenig writes... > I have sent a few mails regarding the extensibility of > draft-ietf-radext-filter-rules > > I have never received a response on how it should look like. This is an open issue against that document and we need to resolve it here on the list. Will the authors please comment? > As I indicated in a previous mail we have guessed one approach in > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt. > It uses grouped AVPs and is therefore not great for RADIUS. Maybe. Keep in mind that the Extended RADIUS attribute work is introducing a method of accommodating grouped attributes (AVPs) in RADIUS. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Aug 2007 13:27:11 +0000 From: "David B. Nelson" To: Subject: RE: Issues & Fixes document Date: Mon, 27 Aug 2007 09:25:43 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004a01c7e8ad$c52ff830$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfoqUK6mQnLCVohQzi2IvaljQtX/gABDM0g Alan DeKok writes... > Not hearing any more updates, I think we can submit the latest version > of the document. I think that's right. Would you like to reprise the final proposed resolution text, i.e. the changes to the current draft? I think I've lost track... -- to unsubscribe send a message to radiusext-request@ops.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, 27 Aug 2007 12:49:39 +0000 Message-ID: <46D2C7CB.20205@nitros9.org> Date: Mon, 27 Aug 2007 14:47:07 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issues & Fixes document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not hearing any more updates, I think we can submit the latest version of the 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: Sun, 26 Aug 2007 19:13:08 +0000 Message-ID: <46D1D09D.1060004@gmx.net> Date: Sun, 26 Aug 2007 21:12:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 'radext mailing list' Subject: Extensibility of draft-ietf-radext-filter-rules Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have sent a few mails regarding the extensibility of draft-ietf-radext-filter-rules I have never received a response on how it should look like. As I indicated in a previous mail we have guessed one approach in http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt. It uses grouped AVPs and is therefore not great for RADIUS. I would appreciate guidance. Ciao Hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 26 Aug 2007 17:29:12 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Draft Update: draft-ietf-geopriv-radius-lo-16.txt Date: Sun, 26 Aug 2007 10:28:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed -16 of the RADIUS Location Document has been submitted. This is likely to be the last revision. So if there are any issues, please speak up NOW. >From: Hannes Tschofenig >To: Internet-Drafts Administrator >Subject: Draft Update: draft-ietf-geopriv-radius-lo-16.txt >Date: Sun, 26 Aug 2007 10:00:02 +0200 > >Dear Editor, > >we would like to submit an update of an GEOPRIV working group item. Please >find the updated draft here: >http://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv-radius-lo-16.txt > >Ciao >Hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Aug 2007 20:05:53 +0000 From: "David B. Nelson" To: Cc: Subject: Formal review of draft-ietf-radext-management-authorization-00.txt Date: Fri, 24 Aug 2007 08:37:57 -0400 Message-ID: <01ee01c7e64b$99dfdfb0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfmS5lEoHppAUSiRZa+o4BWqf47Aw== Now that the draft "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" has been accepted as a RADEXT WG work item, and has been published in the Internet Drafts repository at http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-00.txt, please formally review the document to determine if it is ready for WGLC. Please send comments to this list using the format described in the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/. This review period will last until September 14, 2007. At that time issues raised on the list will be resolved. Once all issues are addressed we will start WGLC on the document. This notice is being copied to the ISMS WG list, as this document is a normative dependency for the "RADIUS Usage for SNMP Transport Models" draft being worked on in the ISMS WG. A summary of changes from draft-nelson-radius-management-authorization-05.txt is listed below, and includes resolution of all comments received during the pre-WG work item review: "SNMP View Based Access Control Method (VACM)" --> "SNMP View Based Access Control Model (VACM)" Spelling corrections. "UTF-8 encoded 10646 [RFC2279]" --> "UTF-8 encoded 10646 [RFC3629]" Addition to IANA Considerations Section: "Assignment of additional values for attributes defined in this document are to be processed as described in [RFC3575]." Break References Section into Normative and Informative. -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2007 15:11:52 +0000 From: "David B. Nelson" To: Subject: Request for formal review of draft-ietf-radext-management-authorization-00.txt Date: Fri, 24 Aug 2007 11:11:11 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00b401c7e661$019e3470$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfmYQFdzr81K53NSKOqvs3X9EedcA== (The first attempt is stuck somewhere, so I'm resending this message.) Now that the draft "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" has been accepted as a RADEXT WG work item, and has been published in the Internet Drafts repository at http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati on-00.txt, please formally review the document to determine if it is ready for WGLC. Please send comments to this list using the format described in the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/. This review period will last until September 14, 2007. At that time issues raised on the list will be resolved. Once all issues are addressed we will start WGLC on the document. This notice is being copied to the ISMS WG list, as this document is a normative dependency for the "RADIUS Usage for SNMP Transport Models" draft being worked on in the ISMS WG. A summary of changes from draft-nelson-radius-management-authorization-05.txt is listed below, and includes resolution of all comments received during the pre-WG work item review: "SNMP View Based Access Control Method (VACM)" --> "SNMP View Based Access Control Model (VACM)" Spelling corrections. "UTF-8 encoded 10646 [RFC2279]" --> "UTF-8 encoded 10646 [RFC3629]" Addition to IANA Considerations Section: "Assignment of additional values for attributes defined in this document are to be processed as described in [RFC3575]." Break References Section into Normative and Informative. -- to unsubscribe send a message to radiusext-request@ops.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, 23 Aug 2007 21:15:20 +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-management-authorization-00.txt Message-Id: Date: Thu, 23 Aug 2007 17:15:01 -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 : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-00.txt Pages : 15 Date : 2007-8-23 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, and for more granular levels of access rights and management privileges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-00.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-management-authorization-00.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-management-authorization-00.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-8-23160918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-management-authorization-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-23160918.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: Thu, 23 Aug 2007 20:18:25 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair Subject: Protocol Action: 'RADIUS Extension for Digest Authentication' to Proposed Standard Message-Id: Date: Thu, 23 Aug 2007 16:17:36 -0400 The IESG has approved the following document: - 'RADIUS Extension for Digest Authentication ' as a Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-02.txt 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. Protocol 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. This document is believed to address all issues raised since the publication of RFC 4590. The document was reviewed by Dan Romascanu on behalf of the IESG. Note to RFC Editor RFC Editor, Please replace Appendix A with the text below: This is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C). The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is omitted for brevity. The SIP messages are not shown completely. The password of user '12345678' is 'secret'. The shared secret between RADIUS client and server is 'secret'. To ease testing, only the last byte of the RADIUS authenticator changes between requests. In a real implementation, this would be a serious flaw. A->B INVITE sip:97226491335@example.com SIP/2.0 From: To: B->A SIP/2.0 100 Trying B->C Code = Access-Request (1) Packet identifier = 0x7c (124) Length = 97 Authenticator = F5E55840E324AA49D216D9DBD069807C NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B C->B Code = Access-challenge (11) Packet identifier = 0x7c (124) Length = 72 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3 B->A SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="example.com" ,nonce="3bada1a0",qop=auth,algorithm=MD5 Content-Length: 0 A->B ACK sip:97226491335@example.com SIP/2.0 A->B INVITE sip:97226491335@example.com SIP/2.0 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" ,realm="example.com" ,response="7679b84a560835846ec553174dbabb69" ,uri="sip:97226491335@example.com",username="12345678" ,qop=auth,algorithm=MD5 ,cnonce="56593a80,nc="00000001" From: To: B->C Code = Access-Request (1) Packet identifier = 0x7d (125) Length = 221 Authenticator = F5E55840E324AA49D216D9DBD069807D NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = 3bada1a0 Digest-Nonce-Count = 00000001 Digest-Response = 7679b84a560835846ec553174dbabb69 Digest-Username = 12345678 SIP-AOR = sip:12345678@example.com Message-Authenticator = BD037498E8385878A46ECF4D5F8D2B48 C->B Code = Access-Accept (2) Packet identifier = 0x7d (125) Length = 72 Authenticator = 36E1201AD4377664E720184CE7B3D8C6 Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64 B->A SIP/2.0 180 Ringing B->A SIP/2.0 200 OK A->B ACK sip:97226491335@example.com SIP/2.0 A second example shows the traffic between a web browser (A), web server (B), and a RADIUS server (C). A->B GET /index.html HTTP/1.1 B->C Code = Access-Request (1) Packet identifier = 0x7e (126) Length = 68 Authenticator = F5E55840E324AA49D216D9DBD069807E NAS-IP-Address = 192.0.2.38 NAS-Port = 5 Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992 C->B Code = Access-challenge (11) Packet identifier = 0x7e (126) Length = 72 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A B->A HTTP/1.1 401 Authentication Required WWW-Authenticate: Digest realm="example.com", nonce="a3086ac8",qop=auth,algorithm=MD5 Content-Length: 0 A->B GET /index.html HTTP/1.1 Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8" ,nc="00000001",cnonce="56593a78" ,realm="example.com" ,response="ba623217b5ec024d30c4aaef9d8494de" ,uri="/index.html",username="12345678" B->C Code = Access-Request (1) Packet identifier = 0x7f (127) Length = 176 Authenticator = F5E55840E324AA49D216D9DBD069807F NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = GET Digest-URI = /index.html Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = a3086ac8 Digest-Nonce-Count = 00000001 Digest-Response = ba623217b5ec024d30c4aaef9d8494de Digest-Username = 12345678 Message-Authenticator = C360BFCEDFFBCE893469E802013DA5AA C->B Code = Access-Accept (2) Packet identifier = 0x7f (127) Length = 72 Authenticator = F1ECAC22D3C88E0260B287FA35595F80 Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c Message-Authenticator = 956312EC57AF51ABC4F6965270F34982 B->A HTTP/1.1 200 OK ... ... -- to unsubscribe send a message to radiusext-request@ops.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, 23 Aug 2007 08:54:42 +0000 Message-ID: <46CD4B26.8030201@deployingradius.com> Date: Thu, 23 Aug 2007 10:53:58 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Glen Zorn CC: Bernard Aboba , dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: >> ... >> Yes. RFC 2865 mentions only User-Password and CHAP-Password, and >> refers to other "authentication information". We could extend the list >> to include currently known authentication attributes. But I think it's >> better to give directions for future efforts. > > Speaking of which, shouldn't this be in the design guidelines, > rather than issues & fixes? Perhaps. It's in the context of "clarifying how to use state", which belongs in issues & fixes, because many people got it wrong. How to use State in the future is just another sentence here. The text can be re-iterated, and expanded in the "guidelines" 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: Wed, 22 Aug 2007 18:32:13 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ipawM4PqKzSAcEq5VZbSxszL63aSd3eJ/jUX9y7jCaZC9lPMv6nxytmbOPseiloPnG6W6Sgl4A7qsPtbRnEk4Ng59bGYpUIO9Dx/MFf7lVZ7uyA07T4M1RFKjMtgPoqn0Vm+lwsaj8HNNBBDHVdQpswAr/67F96lYL5RFqx85Uw=; Date: Wed, 22 Aug 2007 11:31:38 -0700 (PDT) From: Glen Zorn Subject: Re: Request for Review: "Issues and Fixes" changes To: Alan DeKok , Bernard Aboba Cc: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1493323623-1187807498=:84117" Content-Transfer-Encoding: 8bit Message-ID: <438110.84117.qm@web45601.mail.sp1.yahoo.com> --0-1493323623-1187807498=:84117 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit ... Yes. RFC 2865 mentions only User-Password and CHAP-Password, and refers to other "authentication information". We could extend the list to include currently known authentication attributes. But I think it's better to give directions for future efforts. Speaking of which, shouldn't this be in the design guidelines, rather than issues & fixes? --------------------------------- Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-1493323623-1187807498=:84117 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
...
Yes. RFC 2865 mentions only User-Password and CHAP-Password, and
refers to other "authentication information". We could extend the list
to include currently known authentication attributes. But I think it's
better to give directions for future efforts.
 
Speaking of which, shouldn't this be in the design guidelines, rather than issues & fixes?

Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. --0-1493323623-1187807498=:84117-- -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 16:01:56 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WyEQuSW0RLEq6J7pjjjz8G1BoiDHQZbrCd31ufV5xzeARP2epWxz+wQwX8Pe4OX17q2qhsjgh0yRZAWo1rqBvnpdZ+cwDB6jkQFo2B7u7a1cX+sdR7W/2TY8I/TgZW4eWRMFFjQ1waBxjqC1s8QE0SC5lmVo+xBwLwY/LBaYujA=; Date: Wed, 22 Aug 2007 09:01:46 -0700 (PDT) From: Glen Zorn Subject: Re: Reminder: automated key management is often required for new protocols To: Alan DeKok , Bernard Aboba Cc: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1767419651-1187798506=:99339" Content-Transfer-Encoding: 8bit Message-ID: <532755.99339.qm@web45609.mail.sp1.yahoo.com> --0-1767419651-1187798506=:99339 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Alan DeKok wrote: Bernard Aboba wrote: > I think you mean "distribution of long-term credentials" here. In > (D)TLS the session keys are are fresh for each session (via the use of > client.random and server.random). Sure. RFC 4107 calls them "long term session keys", but they're long term credentials in the context of RADIUS. gwz> What 4107 _really calls them is "long-term keys" (see section 2, paragraph gwz> 2) but whatever... ... --------------------------------- Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. --0-1767419651-1187798506=:99339 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Alan DeKok <aland@deployingradius.com> wrote:
Bernard Aboba wrote:
> I think you mean "distribution of long-term credentials" here. In
> (D)TLS the session keys are are fresh for each session (via the use of
> client.random and server.random).

Sure. RFC 4107 calls them "long term session keys", but they're long
term credentials in the context of RADIUS.
 
gwz> What 4107 _really calls them is "long-term keys" (see section 2, paragraph
gwz> 2) but whatever...

...

Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. --0-1767419651-1187798506=:99339-- -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 15:55:44 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wXw/mYQ8inIqw1xG7KPSDnx6g8AzMEnhsExZwO/DRCDklSANn1NCb8dxm9EuRCNdIuMa/4C8uKXSgcRNN0JMraSa9blsAWPbAq0hb8ijGd+9qxr3/52Bs2JNI9+cRmHltFVHN86MVPWjhWQ91YwWKFjRzyZfspwLgTl2Efy5mq4=; Date: Wed, 22 Aug 2007 08:55:32 -0700 (PDT) From: Glen Zorn Subject: Re: Reminder: automated key management is often required for new protocols To: Alan DeKok , "David B. Nelson" Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-787850332-1187798132=:96479" Content-Transfer-Encoding: 8bit Message-ID: <429951.96479.qm@web45609.mail.sp1.yahoo.com> --0-787850332-1187798132=:96479 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Alan DeKok wrote: ... Section 2.2: The manual key management for long-term session keys meets the last criteria in this section: The scale of each deployment is very limited. Ideally, each long-term key in DTLS is shared only between one server and one client. Each client-server pair shares a unique key, and those keys are (ideally) not re-used across multiple client-server pairs. There aren't many deployments that are smaller scale than two parties. gwz> I don't think that by "deployment" they mean how many parties share a key gwz> ;-); more like how many NASs to a server (which can be in the thousands). ... --------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. --0-787850332-1187798132=:96479 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Alan DeKok <aland@nitros9.org> wrote:
...

Section 2.2: The manual key management for long-term session keys
meets the last criteria in this section:

The scale of each deployment is very limited.

Ideally, each long-term key in DTLS is shared only between one server
and one client. Each client-server pair shares a unique key, and those
keys are (ideally) not re-used across multiple client-server pairs.
There aren't many deployments that are smaller scale than two parties.
 
gwz> I don't think that by "deployment" they mean how many parties share a key
gwz> ;-); more like how many NASs to a server (which can be in the thousands).

...

Building a website is a piece of cake.
Yahoo! Small Business gives you all the tools to get online. --0-787850332-1187798132=:96479-- -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 15:41:34 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=HxrfultqvmGGVqZVCsq1yRvdgJ3Oo6CesTMTwCNUgkV5JDMDPf89pjQRCISOQXSOg77wJrVHapAKJshci2O/gNxqYF14Ud/133UVN7iVme/0LosOFsbHfnaSwoCKP2ugSXBqWUelZt0eKG6mr77nvEAe9n+WUEIWkPWGS8J9vTs=; Date: Wed, 22 Aug 2007 08:40:53 -0700 (PDT) From: Glen Zorn Subject: Re: Request for Review: "Issues and Fixes" changes To: Bernard Aboba , aland@deployingradius.com, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1512281982-1187797253=:90920" Content-Transfer-Encoding: 8bit Message-ID: <253146.90920.qm@web45609.mail.sp1.yahoo.com> --0-1512281982-1187797253=:90920 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bernard Aboba wrote: >To clarify: some SERVER implementations need State for particular >authentication methods. Others do not. > >The only interoperability requirement is on the client. If it sees a >State in an Access-Challenge, it echoes that back in the next >Access-Request. There is no interoperability requirement on the server. >If it needs State, it implements code looking for State. gwz> And sending a State attribute in the first place. >If it doesn't >need state, it doesn't implement code looking for State. gwz> Nor send a State attribute in the first place. I think the issue goes beyond interoperability (although that is certainly something worth clarifying). For example, if an Access-Request contains neither an authentication attribute or State attribute, there are security implications. Some RADIUS attributes (such as Tunnel-Password) reveal confidential information about a user, and so they require some evidence of user authentication. gwz> Well, maybe; but when used w/L2TP (the only real-world usage of the Tunnel- gwz> Password attribute of which I'm aware) it normally contains a password for gwz> the NAS/LAC to use to authenticate itself to the LNS & so has nothing to do gwz> with any human user. The RFC 2868 attributes are often used in replies to gwz> Access-Requests with Service-Type = Call Check, BTW. > There's no reason for server to send State if they don't need it. For the reasons above, I don't believe that is what RFC 2865 intended. gwz> I don't quite get your logic here. 2865 seems pretty clear and unambiguous gwz> (for once ;-) on this topic: usage of the State attribute is always optional on gwz> the server side & server driven and it is always mandatory on the client side -- gwz> if it receives one it must return it unchanged in the next Access-Request (if gwz> any). ... > The recommendation is that new authentication methods SHOULD use State >for multiple Access-Request / Access-Challenge sequences. Since >existing methods *don't* use State all of the time for such sequences, >it's impolite to require that new methods MUST use it. gwz> I agree. RFC 2865 has a MUST relating to inclusion of authentication attributes or State within an Access-Request. It would seem that this ignored some cases (such as Call-Check) in which State either is optional or realistically can't be included at all. gwz> I believe that common practice is to include a User-Password attribute in call gwz> checks, possibly containing a canned "password". This practice has the gwz> nice side-effect of providing (weak) authentication of the NAS as well -- gwz> something that was otherwise impossible pre-2869. ... --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search. --0-1512281982-1187797253=:90920 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Bernard Aboba <bernard_aboba@hotmail.com> wrote:
>To clarify: some SERVER implementations need State for particular
>authentication methods. Others do not.
>
>The only interoperability requirement is on the client. If it sees a
>State in an Access-Challenge, it echoes that back in the next
>Access-Request. There is no interoperability requirement on the server.
>If it needs State, it implements code looking for State.
 
gwz> And sending a State attribute in the first place.
 
>If it doesn't
>need state, it doesn't implement code looking for State.
gwz> Nor send a State attribute in the first place.

I think the issue goes beyond interoperability (although that is certainly
something worth clarifying).

For example, if an Access-Request contains neither an authentication
attribute or State attribute, there are security implications.

Some RADIUS attributes (such as Tunnel-Password) reveal confidential
information about a user, and so they require some evidence of user
authentication.
 
gwz> Well, maybe; but when used w/L2TP (the only real-world usage of the Tunnel-
gwz> Password attribute of which I'm aware) it normally contains a password for
gwz> the NAS/LAC to use to authenticate itself to the LNS & so has nothing to do
gwz> with any human user.  The RFC 2868 attributes are often used in replies to
gwz> Access-Requests with Service-Type = Call Check, BTW.
 
> There's no reason for server to send State if they don't need it.

For the reasons above, I don't believe that is what RFC 2865 intended.
 
gwz> I don't quite get your logic here.  2865 seems pretty clear and unambiguous
gwz> (for once ;-) on this topic: usage of the State attribute is always optional on
gwz> the server side & server driven and it is always mandatory on the client side --
gwz> if it receives one it must return it unchanged in the next Access-Request (if
gwz> any). 
...

> The recommendation is that new authentication methods SHOULD use State
>for multiple Access-Request / Access-Challenge sequences. Since
>existing methods *don't* use State all of the time for such sequences,
>it's impolite to require that new methods MUST use it.
gwz> I agree.

RFC 2865 has a MUST relating to inclusion of authentication attributes or
State within an Access-Request. It would seem that this ignored some cases
(such as Call-Check) in which State either is optional or realistically
can't be included at all.
 
gwz> I believe that common practice is to include a User-Password attribute in call
gwz> checks, possibly containing a canned "password".  This practice has the
gwz> nice side-effect of providing (weak) authentication of the NAS as well --
gwz> something that was otherwise impossible pre-2869.
...

Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search. --0-1512281982-1187797253=:90920-- -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 09:59:47 +0000 Message-ID: <46CC08E9.6040407@deployingradius.com> Date: Wed, 22 Aug 2007 11:59:05 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes -- Call-Check. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: ... >> "The standard use case for Call-Check is pre-screening >> authentication based solely on the phone number information in > > s/phone number information/end-point identifier information, such as phone > number or MAC address,/ Looks good to me. > This generalizes the content of the Call*-Station-ID to more closely match > current practice. 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, 22 Aug 2007 09:47:18 +0000 Message-ID: <46CC05E6.7040201@deployingradius.com> Date: Wed, 22 Aug 2007 11:46:14 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> ... >> Any Access-Request packet that performs authorization checks, >> including Call Check, MUST contain a Message-Authenticator attribute. > > I'm not sure what it means to say "performs authorization checks". Do > you mean that the Access-Request doesn't contain an authentication > attribute (and therefore that State is required)? While we do require > "Authorize Only" Access-Requests to include a Message-Authenticator > attribute, I'm not sure this is the only case. Yes. The suggested text discusses Authorize Only specifically, but leaves open the issue of what other authorization checks could be. I'd prefer to avoid discussion of "authentication attributes". I think it just causes confusion. > I don't know that the RADIUS server can necessarily determine what > attributes constitute "confidential information". The local administrator configuring the policy can do that. > So I think we need > to try to simplify things somewhat. Was there an issue with the RFC > 2865 prescription (either include an authentication attribute or State)? Yes. RFC 2865 mentions only User-Password and CHAP-Password, and refers to other "authentication information". We could extend the list to include currently known authentication attributes. But I think it's better to give directions for future efforts. The alternative is to issue a later document that patches the list of authentication attributes. >> The Call-Check situation is one where the authentication is being done >> on the call, via the Called / Calling Station Id. So in this situation, >> the Called / Calling Station id attributes are the authentication >> attributes. > > That seems like a reasonable explanation of the RFC 2865 MUST. I'd > suggest that we include this explanation in the text to clarify the > meaning of "authentication attribute" in RFC 2865. RFC 2865 uses "authentication information", which seems vague, but useful. >> ... This practice should be discouraged, because it results in >> giving an attacker both the clear-text and cipher-text for User-Password. > > Which in turn can lead to compromise of the User-Password attribute if > the Request Authenticator is every repeated with the same shared secret > (e.g. global and temporal uniqueness required as per RFC 2865). This > also would be something worth including in the text. OK. ... For example, if the Request Authenticator does not satisfy the [RFC2865] requirements on global and temporal uniqueness, the practice described above may lead to the compromise of the User-Password attribute in other Access-Requests for unrelated users. Access to the cipher-text also greatly simplifies offline dictionary attacks, potentially exposing the shared secret, and compromising the entire RADIUS protocol. ... >> The server doesn't need to use State for EAP. It doesn't need to use >> State for *some* challenge-response systems using User-Password. It >> doesn't need to use State for Call-Check... which doesn't leave many >> areas where it is needed. > > Yup. RFC 2865 only REQUIRES State where "authentication attributes" are > not present at all. So if we can clarify what "authentication > attributes" mean, then we'll know when State is required. State is not required for authentication. State is required for authorization checks. I'm open to suggestions for more detailed text. > As for other cases, I think it may depend on the attributes included in > the Access-Accept. However, in the interest of simplicity, it is > probably not reasonable for the RADIUS server to keep track of all the > situations in which a State attribute might be needed. I don't think it needs to keep track. I think that particular authentication mechanisms may mandate the use of State. For authorization, if the Access-Request doesn't contain a State, the server won't be able to tie it to a previous authentication, and therefore won't be able to return Access-Accept. >> I can't recommend when State MUST be used elsewhere, because I can't >> think of other situations where it's needed. The text already makes it >> a MUST for Authorization-Only, and MUST for other authorization checks. > > Can we define what "authorization checks" means? Is this just > Service-Type = Call Check or Authorize-Only? Service-Type = Call Check is really (pre)-authentication. Authorize-Only is an authorization check, and is described as such in the document, The additional vague wording on "authorization checks" is there to catch future uses, and to avoid repeating past mistakes. 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, 22 Aug 2007 06:54:46 +0000 Message-ID: From: "Bernard Aboba" To: aland@deployingradius.com Cc: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: "Issues and Fixes" changes Date: Tue, 21 Aug 2007 23:54:14 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > Some of which can be dealt with by mandating Message-Authenticator. >Once the NAS is authenticated, there are fewer security issues with >allowing it to perform authorization checks. There are two somewhat distinct issues. One is the authenticity of the Access-Request; that is addressed by adding Message-Authenticator. The other is whether the NAS is authorized to obtain the user's authorizations. That requires the NAS to demonstrate that it is acting on behalf of a live user via the inclusion of either an authentication attribute or State. >RFC 3576 is silent on this issue, because it defines Authorize Only in >the context of CoA / Disconnect messages, and not for Access-Requests. Right. > Maybe something like this: > >... >Any Access-Request packet that performs authorization checks, >including Call Check, MUST contain a Message-Authenticator attribute. I'm not sure what it means to say "performs authorization checks". Do you mean that the Access-Request doesn't contain an authentication attribute (and therefore that State is required)? While we do require "Authorize Only" Access-Requests to include a Message-Authenticator attribute, I'm not sure this is the only case. >Any response to an Access-Request performing an authorization check >MUST NOT contain confidential information about any user (such as >Tunnel-Password), unless that Access-Request contains a State >attribute. I don't know that the RADIUS server can necessarily determine what attributes constitute "confidential information". So I think we need to try to simplify things somewhat. Was there an issue with the RFC 2865 prescription (either include an authentication attribute or State)? > The Call-Check situation is one where the authentication is being done >on the call, via the Called / Calling Station Id. So in this situation, >the Called / Calling Station id attributes are the authentication >attributes. That seems like a reasonable explanation of the RFC 2865 MUST. I'd suggest that we include this explanation in the text to clarify the meaning of "authentication attribute" in RFC 2865. > However, most systems implementing this kind of check (e.g. MAC >address checking) do so by setting the User-Name and User-Password to >the MAC address. This is done because it's easier to just add a MAC >address as a user/password, rather than implementing a Call-Check >policy. This practice should be discouraged, because it results in >giving an attacker both the clear-text and cipher-text for User-Password. Which in turn can lead to compromise of the User-Password attribute if the Request Authenticator is every repeated with the same shared secret (e.g. global and temporal uniqueness required as per RFC 2865). This also would be something worth including in the text. > The server doesn't need to use State for EAP. It doesn't need to use >State for *some* challenge-response systems using User-Password. It >doesn't need to use State for Call-Check... which doesn't leave many >areas where it is needed. Yup. RFC 2865 only REQUIRES State where "authentication attributes" are not present at all. So if we can clarify what "authentication attributes" mean, then we'll know when State is required. > The most common use of State seems to be in *addition* to the >authentication attributes. e.g. EAP, or challenge-response methods that >leverage User-Password. Yes. > A less common use of State is for authorization checks, in order to >tie the authorization checks to a previous authentication session. (And >how does the server know that the NAS will need State for use in a later >authorization check? Should the server ALWAYS send State back?) In a CoA-Request with "Authorize Only" the DAC expects that an Access-Request will result. Now this presumes that the DAC can obtain a State Attribute that the RADIUS server will understand. Otherwise, the RADIUS server won't be able to make sense of the State Attribute provided by the DAC. As for other cases, I think it may depend on the attributes included in the Access-Accept. However, in the interest of simplicity, it is probably not reasonable for the RADIUS server to keep track of all the situations in which a State attribute might be needed. > I can't recommend when State MUST be used elsewhere, because I can't >think of other situations where it's needed. The text already makes it >a MUST for Authorization-Only, and MUST for other authorization checks. Can we define what "authorization checks" means? Is this just Service-Type = Call Check or Authorize-Only? -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 06:32:11 +0000 Message-ID: <46CBD84B.4000709@deployingradius.com> Date: Wed, 22 Aug 2007 08:31:39 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > For example, if an Access-Request contains neither an authentication > attribute or State attribute, there are security implications. Some of which can be dealt with by mandating Message-Authenticator. Once the NAS is authenticated, there are fewer security issues with allowing it to perform authorization checks. I would also add that since authorization checks do not include authentication attributes, they MUST include a Message-Authenticator. RFC 3576 is silent on this issue, because it defines Authorize Only in the context of CoA / Disconnect messages, and not for Access-Requests. Maybe something like this: ... Any Access-Request packet that performs authorization checks, including Call Check, MUST contain a Message-Authenticator attribute. Any response to an Access-Request performing an authorization check MUST NOT contain confidential information about any user (such as Tunnel-Password), unless that Access-Request contains a State attribute. The use of State here permits the authorization check to be tied to an earlier user authentication. In that case, the server MAY respond to the NAS with confidential information about that user. The server MUST NOT respond to that authorization check with confidential information about any other user. ... > Some RADIUS attributes (such as Tunnel-Password) reveal confidential > information about a user, and so they require some evidence of user > authentication. Therefore if there is no authentication attribute > present, then the server needs some evidence that the request is linked > to a previous user authentication, so that the server is authorized to > answer the request. That evidence is provided by the State Attribute. Yes. See above. > RFC 2865 has a MUST relating to inclusion of authentication attributes > or State within an Access-Request. It would seem that this ignored some > cases (such as Call-Check) in which State either is optional or > realistically can't be included at all. The Call-Check situation is one where the authentication is being done on the call, via the Called / Calling Station Id. So in this situation, the Called / Calling Station id attributes are the authentication attributes. However, most systems implementing this kind of check (e.g. MAC address checking) do so by setting the User-Name and User-Password to the MAC address. This is done because it's easier to just add a MAC address as a user/password, rather than implementing a Call-Check policy. This practice should be discouraged, because it results in giving an attacker both the clear-text and cipher-text for User-Password. > Given this situation, I don't > believe that a SHOULD would provide the required clarification. Instead, > it would be better to clarify the cases in which State is a MUST and > the cases in which it is optional. The server doesn't need to use State for EAP. It doesn't need to use State for *some* challenge-response systems using User-Password. It doesn't need to use State for Call-Check... which doesn't leave many areas where it is needed. The most common use of State seems to be in *addition* to the authentication attributes. e.g. EAP, or challenge-response methods that leverage User-Password. A less common use of State is for authorization checks, in order to tie the authorization checks to a previous authentication session. (And how does the server know that the NAS will need State for use in a later authorization check? Should the server ALWAYS send State back?) I can't recommend when State MUST be used elsewhere, because I can't think of other situations where it's needed. The text already makes it a MUST for Authorization-Only, and MUST for other authorization checks. Everything else is a SHOULD. This is what the text says today. Are there additional suggestions for "... MUST use State" ? 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, 22 Aug 2007 05:51:35 +0000 Message-ID: <46CBCECB.8090306@deployingradius.com> Date: Wed, 22 Aug 2007 07:51:07 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I think you mean "distribution of long-term credentials" here. In > (D)TLS the session keys are are fresh for each session (via the use of > client.random and server.random). Sure. RFC 4107 calls them "long term session keys", but they're long term credentials in the context of RADIUS. > Even if TLS-PSK is used and the PSKs are re-used across client-server > pairs (e.g. RADIUS shared secret practices are replicated in TLS-PSK), > the session keys would still be likely to be temporally and globally > unique, due to the (D)TLS freshness functionality. Yes. > It might help to articulate the threat model a bit. Are we worried about > an offline dictionary attack on the PSK or its precursor, or are we > worried about temporal or global uniqueness of the TLS master secret? An offline dictionary attack on the PSK or its precursor. The simplest way to avoid that is to suggest the use of certificates. 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, 22 Aug 2007 05:35:48 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Reminder: automated key management is often required for new protocols Date: Tue, 21 Aug 2007 22:35:17 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > DTLS requires manual key management to distribute long-term session >keys. These can be shared secrets for TLS-PSK methods, or certificates >for other TLS methods. I think you mean "distribution of long-term credentials" here. In (D)TLS the session keys are are fresh for each session (via the use of client.random and server.random). > Section 2.2: The manual key management for long-term session keys >meets the last criteria in this section: I think you mean "long-term credentials"; (D)TLS session keys are not long-term, they are refreshed on session resume. > Ideally, each long-term key in DTLS is shared only between one server >and one client. Each client-server pair shares a unique key, and those >keys are (ideally) not re-used across multiple client-server pairs. >There aren't many deployments that are smaller scale than two parties. Even if TLS-PSK is used and the PSKs are re-used across client-server pairs (e.g. RADIUS shared secret practices are replicated in TLS-PSK), the session keys would still be likely to be temporally and globally unique, due to the (D)TLS freshness functionality. > We could say that for PSK methods, the PSK that is used in TLS MUST be >the output of the shared secret amplification, and not the original text >as entered by the administrator. This method would be a step to >addressing the requirements of [RFC4107] Section 2.3. At the minimum, >it would increase the attack cost by a fixed factor of (say) 1,000,000. It might help to articulate the threat model a bit. Are we worried about an offline dictionary attack on the PSK or its precursor, or are we worried about temporal or global uniqueness of the TLS master secret? -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 05:23:23 +0000 Message-ID: <46CBC82B.7090604@nitros9.org> Date: Wed, 22 Aug 2007 07:22:51 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >>> If you have not already taken a look at RFC 4107 in the context of >>> your working group, please do so. > > So, all of the RADEXT WG members participating in the discussion of our > Crypto-Agility work item now have some homework to do: read RFC 4107 and > report back on how it applies to the proposed solutions we are considering. DTLS requires manual key management to distribute long-term session keys. These can be shared secrets for TLS-PSK methods, or certificates for other TLS methods. Section 2.1: As noted at the bottom of page 2 of RFC 4107, TLS provides automated key management. Therefore the requirements of Section 2.1 are satisfied by DTLS. Section 2.2: The manual key management for long-term session keys meets the last criteria in this section: The scale of each deployment is very limited. Ideally, each long-term key in DTLS is shared only between one server and one client. Each client-server pair shares a unique key, and those keys are (ideally) not re-used across multiple client-server pairs. There aren't many deployments that are smaller scale than two parties. Section 2.3: If certificates are used, the certificate generation scheme will have to satisfy these criteria. If shared secrets are used for TLS-PSK, it gets a little harder to meet these criteria. We could avoid the problem by pushing the requirements back onto the admistrator (i.e. You MUST use hard-to-guess shared secrets). But that's not particularly secure. Perhaps something like Paul Funk's proposal would help: http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt We could say that for PSK methods, the PSK that is used in TLS MUST be the output of the shared secret amplification, and not the original text as entered by the administrator. This method would be a step to addressing the requirements of [RFC4107] Section 2.3. At the minimum, it would increase the attack cost by a fixed factor of (say) 1,000,000. 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, 22 Aug 2007 05:00:43 +0000 Message-ID: From: "Bernard Aboba" To: aland@deployingradius.com, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: "Issues and Fixes" changes Date: Tue, 21 Aug 2007 22:00:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >To clarify: some SERVER implementations need State for particular >authentication methods. Others do not. > >The only interoperability requirement is on the client. If it sees a >State in an Access-Challenge, it echoes that back in the next >Access-Request. There is no interoperability requirement on the server. >If it needs State, it implements code looking for State. If it doesn't >need state, it doesn't implement code looking for State. I think the issue goes beyond interoperability (although that is certainly something worth clarifying). For example, if an Access-Request contains neither an authentication attribute or State attribute, there are security implications. Some RADIUS attributes (such as Tunnel-Password) reveal confidential information about a user, and so they require some evidence of user authentication. Therefore if there is no authentication attribute present, then the server needs some evidence that the request is linked to a previous user authentication, so that the server is authorized to answer the request. That evidence is provided by the State Attribute. So I don't think it is accurate to say that the server can dispense with the State Attribute without consequences. > There's no reason for server to send State if they don't need it. For the reasons above, I don't believe that is what RFC 2865 intended. > > Please refresh my memory regarding these discussions. Why would an EAP > > exchange in RADIUS not require the use of State? > > RFC 3579 doesn't recommend using it. Instead, it has a very >complicated system which is more fragile, but sometimes functionally >equivalent. Where an EAP-Message attribute is included in an Access-Request, the RFC 2865 requirement for an authentication attribute or State is fulfilled. So I would agree that the use of State is not required. > The recommendation is that new authentication methods SHOULD use State >for multiple Access-Request / Access-Challenge sequences. Since >existing methods *don't* use State all of the time for such sequences, >it's impolite to require that new methods MUST use it. RFC 2865 has a MUST relating to inclusion of authentication attributes or State within an Access-Request. It would seem that this ignored some cases (such as Call-Check) in which State either is optional or realistically can't be included at all. Given this situation, I don't believe that a SHOULD would provide the required clarification. Instead, it would be better to clarify the cases in which State is a MUST and the cases in which it is optional. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 05:00:35 +0000 Message-ID: <46CBC2C3.80008@deployingradius.com> Date: Wed, 22 Aug 2007 06:59:47 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: radiusext@ops.ietf.org CC: "David B. Nelson" Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Replying to myself with suggested text that may be clearer: ... As defined in [RFC2865] Table 5.44, Access-Request packets may contain a State attribute. The table does not qualify this statement, while the text in Section 5.24 quoted above adds other requirements not specified in that table. We extend the requirements of [RFC2865] to say that Access-Requests which are part of an ongoing Access-Request / Access-Challenge authentication process SHOULD contain a State attribute. It is the responsibility of the server to send a State attribute in an Access- Challenge packet, if that server needs a State attribute in a subsequent Access-Request to tie multiple Access-Requests together into one authentication session. As defined in [RFC2865] Section 5.24, the State MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any. While most server implementations require the presence of a State attribute in an Access-Challenge packet, some challenge-response systems can distinguish the initial request from the response to the challenge without using a State attribute to track an authentication session. The Access-Challenge and subsequent Access-Request packets for those systems do not need to contain a State attribute. Other authentication mechanisms need to tie a sequence of Access- Request / Access-Challenge packets together into one ongoing authentication session. Servers implementing those authentication mechanisms SHOULD include a State attribute in Access-Challenge packets. In general, if the authentication process involves one or more Access-Request / Access-Challenge sequences, the State attribute SHOULD be sent by the server in the Access-Challenge packets. Using the State attribute to create a multi-packet session is the simplest method available in RADIUS today. While other methods of creating multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1), those methods are NOT RECOMMENDED. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2007 04:34:30 +0000 Message-ID: <46CBBC96.6040107@deployingradius.com> Date: Wed, 22 Aug 2007 06:33:26 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >> ... Some need State, others do not. > > Here's the problem with that approach, it doesn't lead to interoperable > standards. To clarify: some SERVER implementations need State for particular authentication methods. Others do not. The only interoperability requirement is on the client. If it sees a State in an Access-Challenge, it echoes that back in the next Access-Request. There is no interoperability requirement on the server. If it needs State, it implements code looking for State. If it doesn't need state, it doesn't implement code looking for State. > The documents we produce are supposed to lead to independent, > interoperable implementations based on the document alone. I don't see how > that happens if we decide that the on-the-wire message content is > implementation-dependent. The server requirements for local policy and authentication are *always* implementation-dependent. Sometimes the implementation is the code, other times the local site policy. > If any compliant system relies on receiving a given attribute for > interoperability, then the standard needs to mandate that all > implementations send that attribute. There's no reason for server to send State if they don't need it. What interoperability requirements are you thinking about? >> I'd like to make it a MUST, but based on the discussions around >> EAP, I think it's only a SHOULD. > > Please refresh my memory regarding these discussions. Why would an EAP > exchange in RADIUS not require the use of State? RFC 3579 doesn't recommend using it. Instead, it has a very complicated system which is more fragile, but sometimes functionally equivalent. Even in EAP implementations that use State, the initial identity request from the server doesn't need a State. It probably *shouldn't* have one, because allocating one would involve tracking sessions for unknown, and un-named users. >> Some RADIUS client implementations do not properly use the State >> attribute in order to distinguish a restarted EAP authentication >> process from the continuation of an ongoing process (by the same user >> on the same NAS and port). Where an EAP-Message attribute is >> included in an Access-Challenge or Access-Accept attribute, RADIUS >> servers SHOULD also include a State attribute. > > Why is this not a MUST? See above. Also, Section 2.1.2 in the document describes the new method of using State, and makes it a SHOULD. >> We extend the requirements of [RFC2865] to say that Access-Requests >> which are part of an ongoing Access-Request / Access-Challenge >> authentication process SHOULD contain a State attribute. > > Why not MUST for the general case, with SHOULD or MAY for specific exception > cases? The only MUST is that an implementation MUST use State if there's no simpler way to track a "session". If multiple packet exchanges don't need "session" tracking (as above), then there's no need to use State. I have no real objection to making it a MUST, but doing so would involve requiring many implementations to add State that they don't need. > And how does an implementation that needs State tell that it is talking to > an implementation that doesn't? This seems like a real interoperability > problem. A SERVER implementation that needs state talks to a CLIENT implementation that MUST echo State from an Access-Challenge in any subsequent Access-Request. Server implementations don't talk to each other. :) >> Any other Access- >> Request packet that does not contain an authentication attribute as > > Uh... We just used the undefined term "authentication attribute". :-) I'll go nuke it. >> A server may send an EAP-Message "identity request", and not include >> State. For the rest of the EAP session, State may be required. > > May be required? When? Why? Under what circumstances? I don't think we > can leave it that open ended. RFC 3576 does. I believe that there are EAP server implementations that don't use State. >>> We should also advise authors of VSAs that they ought to take >>> note of this issue, and be explicit in their documents as to whether >>> or not a State attribute is required to pair up with any new >>> authentication attributes being defined. >> Is the suggested text above clear enough to cover this possibility? > > Not really. I didn't see any mention of VSAs. It's not about VSA's. It's about the authentication process. I would prefer to not discuss VSA's, or the particular authentication attributes (whatever they are). The recommendation is that new authentication methods SHOULD use State for multiple Access-Request / Access-Challenge sequences. Since existing methods *don't* use State all of the time for such sequences, it's impolite to require that new methods MUST use it. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Aug 2007 20:12:38 +0000 From: "David B. Nelson" To: Subject: RE: Reminder: automated key management is often required for new protocols Date: Tue, 21 Aug 2007 16:12:29 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00a701c7e42f$99cf1630$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfkLUQR9s/rX/ZkS86EKAeRkGn6qQAAfXNA > >If you have not already taken a look at RFC 4107 in the context of > >your working group, please do so. So, all of the RADEXT WG members participating in the discussion of our Crypto-Agility work item now have some homework to do: read RFC 4107 and report back on how it applies to the proposed solutions we are considering. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2007 19:51:49 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: FW: Reminder: automated key management is often required for newprotocols Date: Tue, 21 Aug 2007 12:51:13 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >From: Sam Hartman >To: wgchairs@ietf.org >Subject: Reminder: automated key management is often required for >newprotocols >Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT) > >I wanted to send out a brief reminder to working group chairs about >RFC 4107. This BCP, published in June of 2005, gives guidance on when >our protocols need to have an automated key management mechanism. > >By this point, you should expect to need to follow RFc 4107 for any >new protocols and should not be surprised when you are required to >update protocols to comply with RFC 4107 in order to significantly >increase their applicability. > >In many cases, this means you will need to have an automated mechanism >for doing key management for security mechanisms your protocol. This >does not mean you need to support PKIs or even public-key operations. > >If you have not already taken a look at RFc 4107 in the context of >your working group, please do so. If you have any questions Tim and I >would be happy to answer them. > >I'm writing because it looks like I will file a number of discuss >positions this week asking for significant additional security work to >be done on protocols before they can be published. I'd like to avoid >such late surprises for future work. > > >Sam Hartman >Security Area Director > -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2007 17:57:30 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Tue, 21 Aug 2007 13:57:00 -0400 Organization: Elbrys Networks, Inc. Message-ID: <009f01c7e41c$ac89d5c0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfkB/r6a4R9Lx/zQLi+0iyl+yU3kgAEbJKQ Alan DeKok writes... > The problem is that the MUST for State is really > implementation-dependent. i.e. challenge-response systems > leverage Access-Challenge and User-Password. Some need State, > others do not. Here's the problem with that approach, it doesn't lead to interoperable standards. The documents we produce are supposed to lead to independent, interoperable implementations based on the document alone. I don't see how that happens if we decide that the on-the-wire message content is implementation-dependent. Sure, implementers are free to innovate and go above and beyond the standard, or even to deviate from the standard if they don't want to claim strict compliance. What we cannot do, I think, is decide that the standard should leave the on-the-wire message format and content up to individual implementations. It needs to be fully specified -- standardized. > The MAY here means "if your system needs it, it is permitted to use > it. If your system doesn't need it, there's no harm in adding it." If any compliant system relies on receiving a given attribute for interoperability, then the standard needs to mandate that all implementations send that attribute. > I'd like to make it a MUST, but based on the discussions around > EAP, I think it's only a SHOULD. Please refresh my memory regarding these discussions. Why would an EAP exchange in RADIUS not require the use of State? > The other thing is that the whole use of State for authorization > checks is a horrible hack. Well, yeah, maybe. But it's a standardized hack, upon which many implementations rely. :-) It is what it is. > I've re-written the text, and as a bonus, it looks like we can drop > the references to specific authentication attributes: > > ... > Some RADIUS client implementations do not properly use the State > attribute in order to distinguish a restarted EAP authentication > process from the continuation of an ongoing process (by the same user > on the same NAS and port). Where an EAP-Message attribute is > included in an Access-Challenge or Access-Accept attribute, RADIUS > servers SHOULD also include a State attribute. Why is this not a MUST? > See Section 2.1.3 on > Request ID supplementation for additional benefits to using the State > attribute in this fashion. > > As defined in [RFC2865] Table 5.44, Access-Request packets may > contain a State attribute. The table does not qualify this > statement, while the text in Section 5.24 quoted above adds > additional requirements. > > We extend the requirements of [RFC2865] to say that Access-Requests > which are part of an ongoing Access-Request / Access-Challenge > authentication process SHOULD contain a State attribute. Why not MUST for the general case, with SHOULD or MAY for specific exception cases? > While most > implementations require the presence of a State attribute in an > Access-Challenge packet, some challenge-response systems can > distinguish the initial request from the response to the challenge > without using a State attribute to track an authentication session. > The Access-Challenge and subsequent Access-Request packets for those > systems do not need to contain a State attribute. And how does an implementation that needs State tell that it is talking to an implementation that doesn't? This seems like a real interoperability problem. > Other authentication systems require additional information outside > of the authentication mechanism in order to tie a sequence of Access- > Request / Access-Challenge packets to an ongoing authentication > session. Those systems SHOULD include a State attribute in Access- > Challenge packets. > > In general, if the authentication process involves one or more > Access-Request / Access-Challenge sequences, the State attribute > SHOULD be sent in the Access-Challenge packets. Again, why not MUST? Or at least MUST for the general case, with SHOULD or MAY for specific exception cases (that we fully describe). > The only permissible values for a State attribute are values provided > in an Access-Accept, Access-Challenge, CoA-Request or Disconnect- > Request packet. A RADIUS client MUST use only those values for the > State attribute that it has previously received from a server. An > Access-Request sent as a result of a new or restarted authentication > run MUST NOT include the State attribute, even if a State attribute > has previously been received in an Access-Challenge for the same user > and port. > > In contrast, Access-Requests which are intended to perform > authorization checks MUST contain a State attribute in order to tie > the authorization check to a previous authentication session. This > last requirement often means that an Access-Accept needs to contain a > State attribute, which is then used in a later Access-Request that > performs authorization checks. > > Access-Request packets that contain a Service-Type attribute with > value Authorize Only (17) MUST contain a State attribute. Access- > Request packets that contain a Service-Type attribute with value Call > Check (10) SHOULD NOT contain a State attribute. Any other Access- > Request packet that does not contain an authentication attribute as Uh... We just used the undefined term "authentication attribute". :-) > defined above MUST contain a State attribute. This list is not > exhaustive, and may be extended in future specifications. > I would prefer to focus on the process, rather than the attributes. Agreed. > A server may send an EAP-Message "identity request", and not include > State. For the rest of the EAP session, State may be required. May be required? When? Why? Under what circumstances? I don't think we can leave it that open ended. > > We should also advise authors of VSAs that they ought to take > > note of this issue, and be explicit in their documents as to whether > > or not a State attribute is required to pair up with any new > > authentication attributes being defined. > > Is the suggested text above clear enough to cover this possibility? Not really. I didn't see any mention 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: Tue, 21 Aug 2007 15:24:32 +0000 Message-ID: <46CB037C.6070201@deployingradius.com> Date: Tue, 21 Aug 2007 17:23:40 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Ah, so you are using MAY to indicate conditional MUST, rather than to > indicate an option (i.e. personal choice). That doesn't comport with RFC > 2119. I understand why the Table of Attributes has 0-1, but I'm concerned > about the use of MAY in the text, especially if we really mean a conditional > MUST. I think we need to break out the conditions in the text, applying > MUST and MAY as appropriate. The problem is that the MUST for State is really implementation-dependent. i.e. challenge-response systems leverage Access-Challenge and User-Password. Some need State, others do not. The MAY here means "if your system needs it, it is permitted to use it. If your system doesn't need it, there's no harm in adding it." I'd like to make it a MUST, but based on the discussions around EAP, I think it's only a SHOULD. The other thing is that the whole use of State for authorization checks is a horrible hack. Instead, there should be a session identifier returned by the RADIUS server to the NAS in an Access-Accept, and that session identifier should be used in all subsequent authorization checks, and Accounting-Requests. I've re-written the text, and as a bonus, it looks like we can drop the references to specific authentication attributes: ... Some RADIUS client implementations do not properly use the State attribute in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). Where an EAP-Message attribute is included in an Access-Challenge or Access-Accept attribute, RADIUS servers SHOULD also include a State attribute. See Section 2.1.3 on Request ID supplementation for additional benefits to using the State attribute in this fashion. As defined in [RFC2865] Table 5.44, Access-Request packets may contain a State attribute. The table does not qualify this statement, while the text in Section 5.24 quoted above adds additional requirements. We extend the requirements of [RFC2865] to say that Access-Requests which are part of an ongoing Access-Request / Access-Challenge authentication process SHOULD contain a State attribute. While most implementations require the presence of a State attribute in an Access-Challenge packet, some challenge-response systems can distinguish the initial request from the response to the challenge without using a State attribute to track an authentication session. The Access-Challenge and subsequent Access-Request packets for those systems do not need to contain a State attribute. Other authentication systems require additional information outside of the authentication mechanism in order to tie a sequence of Access- Request / Access-Challenge packets to an ongoing authenticaiton session. Those systems SHOULD include a State attribute in Access- Challenge packets. In general, if the authentication process involves one or more Access-Request / Access-Challenge sequences, the State attribute SHOULD be sent in the Access-Challenge packets. The only permissible values for a State attribute are values provided in an Access-Accept, Access-Challenge, CoA-Request or Disconnect- Request packet. A RADIUS client MUST use only those values for the State attribute that it has previously received from a server. An Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if a State attribute has previously been received in an Access-Challenge for the same user and port. In contrast, Access-Requests which are intended to perform authorization checks MUST contain a State attribute in order to tie the authorization check to a previous authentication session. This last requirement often means that an Access-Accept needs to contain a State attribute, which is then used in a later Access-Request that performs authorization checks. Access-Request packets that contain a Service-Type attribute with value Authorize Only (17) MUST contain a State attribute. Access- Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access- Request packet that does not contain an authentication attribute as defined above MUST contain a State attribute. This list is not exhaustive, and may be extended in future specifications. > I would recommend adding text to that effect, as an implementation note, to > clarify when the State attribute is and is not required in an > Access-Challenge and subsequent Access-Request. See text above. > Yes, adding wording as to what attributes require the inclusion of the State > attribute would be preferable. I would prefer to focus on the process, rather than the attributes. A server may send an EAP-Message "identity request", and not include State. For the rest of the EAP session, State may be required. > I think we need to mention them, and describe the type of attribute that > would qualify as authentication attribute in general terms. We should also > advise authors of VSAs that they ought to take note of this issue, and be > explicit in their documents as to whether or not a State attribute is > required to pair up with any new authentication attributes being defined. Is the suggested text above clear enough to cover this possibility? 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, 21 Aug 2007 13:36:40 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Tue, 21 Aug 2007 09:36:16 -0400 Message-ID: <018501c7e3f8$3fa96890$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcfjzWQRtWPCADTzS4WDfaYSox+X4QAJYaswAAEoQRA= David B. Nelson writes... Following up to my last post... > You might go on to say: > > "The standard use case for Call-Check is pre-screening > authentication based solely on the phone number information in s/phone number information/end-point identifier information, such as phone number or MAC address,/ > Calling-Station-ID and optionally Called-Station-ID. In that use > case there is no source of the State attribute in the NAS. Other, > non-standard, uses of Call-Check may require or permit the use of > a State Attribute, but are beyond the scope of this document." This generalizes the content of the Call*-Station-ID to more closely match current practice. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2007 13:10:52 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Tue, 21 Aug 2007 09:10:28 -0400 Message-ID: <018401c7e3f4$a58a5420$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcfjzWQRtWPCADTzS4WDfaYSox+X4QAJYasw Alan DeKok writes... > Maybe we want to change that to "... Call Check MAY NOT contain > a State attribute". This permits them to (magically) have one > if they so desire. It permits them to not have one in real-life > implementations. "MAY NOT" is not a keyword defined in RFC 2119. I would avoid using it. I think you want to say something like: "Access-Request messages containing a Service-Type attribute with a value of Call Check SHOULD NOT contain a State attribute." You might go on to say: "The standard use case for Call-Check is pre-screening authentication based solely on the phone number information in Calling-Station-ID and optionally Called-Station-ID. In that use case there is no source of the State attribute in the NAS. Other, non-standard, uses of Call-Check may require or permit the use of a State Attribute, but are beyond the scope of this document." > This permits them to (magically) have one if they so > desire. It permits them to not have one in real-life > implementations. The text I suggest here does the same. It just makes the usage conditions a bit more explicit, which I think is desirable. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2007 12:58:30 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Tue, 21 Aug 2007 08:57:43 -0400 Message-ID: <018301c7e3f2$dd6f5400$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcfjzNIJr7ylnQioRdCVVRJB0+Xa6QAIy+Og Alan DeKok writes... > >> We extend this definition to say that Access-Requests which > >> are part of an ongoing authentication process MAY contain a > >> State attribute. > > > > So, this sentence really confuses me. Maybe I'm taking it out > > of context, but my understanding is that an Access-Request that > > is part of an ongoing authentication process MUST contain a State > > Attribute. This has been the case since the State attribute was > > defined. Why are we changing it to MAY? > > We're not. RFC 2865, Table 5.44 says State is "0-1" in > Access-Request. Note 1 says that Access-Requests contain User- > Password, CHAP-Password, or State. Section 2 says that Access- > Challenges MAY contain State. Ah, so you are using MAY to indicate conditional MUST, rather than to indicate an option (i.e. personal choice). That doesn't comport with RFC 2119. I understand why the Table of Attributes has 0-1, but I'm concerned about the use of MAY in the text, especially if we really mean a conditional MUST. I think we need to break out the conditions in the text, applying MUST and MAY as appropriate. One of the nits that has always bothered me about RFC 2865 (and others that imitate its style) is relegating important, normative elements of the protocol definition to footnotes to the Table of Attributes. I think we can do better to aid readability by pulling those elements out into text descriptions, in the relevant sections where the concepts are discussed. > While most implementations require State in Access-Challenge, I have > seen some challenge-response systems that do not require it. Those > systems can distinguish the initial request from the response to the > challenge without using State to track a "session". I would recommend adding text to that effect, as an implementation note, to clarify when the State attribute is and is not required in an Access-Challenge and subsequent Access-Request. > >> Any Access-Request that does not contain an authentication > >> attribute MUST contain a State attribute. This list of > >> authorization parameters is not exhaustive, and may be extended > >> in future specifications. > > > > In the second sentence, did you mean "authentication" rather than > > "authorization"? > > Maybe. I think it's safer just to clean up the terminology. Yes, adding wording as to what attributes require the inclusion of the State attribute would be preferable. > What about vendor or SDO extensions? I think we need to mention them, and describe the type of attribute that would qualify as authentication attribute in general terms. We should also advise authors of VSAs that they ought to take note of this issue, and be explicit in their documents as to whether or not a State attribute is required to pair up with any new authentication attributes being defined. That advice might also go in the Design Guidelines draft, BTW. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2007 09:43:47 +0000 Message-ID: <46CAB399.1070307@deployingradius.com> Date: Tue, 21 Aug 2007 11:42:49 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: radiusext@ops.ietf.org CC: satou.hiroaki@lab.ntt.co.jp, ohta.hiroshi@lab.ntt.co.jp, christian.jacquenet@francetelecom.com, tsunemasa@gmail.com, haixiang@nortel.com Subject: Re: Request for review of "AAA Framework for Multicasting" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > A request for review has been received relating to the document "AAA > Framework for Multicasting" which is under development within the MBONED > WG. The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt One nit: The document formatting appears to be broken. e.g. Page 12 is mostly blank. This makes the document harder to read. I'm not sure why Section 2 defines the terms Accounting, Authentication, and Authorization. The document is already discussing AAA issues, so familiarity with the three A's should be assumed. Perhaps the intent was to give examples of how AAA would be used in this scenario? Section 4.1 is titled "Framework for multicast AAA". This may lead someone to conclude that the AAA protocol is being multicast. I don't think that's correct. The diagram in that section appears to confuse the AAA process with the later multicast data. My understanding is that the request/response for AAA is unicast, and the data that is being accessed is then sent via multicast. Perhaps a time-sequence diagram would be useful, to replace the diagram in Section 4.1. The text in 4.1 is also awkward. It contains a series of overlapping conditionals for setting behavior. The text should be expanded to describe specific scenarios in detail from start to finish, rather than discussing multiple scenarios simultaneously. Adding a time-sequence diagram for each scenario would be useful, too. Section 4.2 Multiple User IDs is confusing. In AAA, each user id is treated as a separate user. This document should avoid the term "user id", as it is easy to confuse with the term "user". Instead, maybe "access identifier" could be used. The definition could be added to Section 2.1. The relationships between the terms (1:N, M:N, etc.) should also be included in the definitions in Section 2.1. This lets the reader immediately know the relationships, independent of their use-cases. The later discussion of use cases can then become clearer. Also, the document sometimes refers to "user", and sometimes to "user id" in the same context. (e.g. Section 4.1, "the user requests content".) Later, the document clarifies that the user may have multiple user ID's. This is confusing, because the document first talks about users requesting content, and then switches to say no, it's not a user, it's a user id. Instead, all discussion of access requests in the document should be done using consistent terminology, such as "access identifier", rather than "user". In some cases, the user will map 1:1 with an access identifier. In others, it will be 1:N. ... The actual mapping rules for NSPs and CPs to map user IDs with the IDs in other provider domains is a matter for the providers. A solution should provide an API between the providers to flexibly support various mapping methods. ... API's should be avoided. Instead, the Chargeable-User-Identity (RFC 4372) should be used to map identifiers to users. This is simpler, scalable, and already deployed. Section 4.3: ... Standardization of the logs or messages to share content usage information is important to support a single NSP sharing accounting information with multiple CPs or a single CP receiving from multiple NSPs. ... The logs should not be standardized. Instead, the contents on the AAA messages should be standardized. ... This framework specifies an accounting API provided by the NSP and accessed by the CP to allow for sharing user- behavior and content-reception information between the NSP AAA and CP AAA. This accounting API should be configurable to allow the CP to request only the logging information it actually requires. ... Negotiation of the contents of accounting messages is not a normal part of AAA. This requirement may be unnecessary, OR it may be very difficult to implement in existing AAA systems. ... When logging information is shared through the accounting API, it is important that the CP be able to match the user as described in the database operated by the NSP to the user as described in the database operated by the CP. ... This is already part of existing AAA systems. I'm not sure it's necessary to re-iterate this requirement here. Overall, Section 4.3 appears to re-state many common AAA requirements for accounting. The document also spends a lot of time talking about "needs". Is the document a framework, a model, or a requirements document? Or is it all three? The document should separate the model from the requirements more explicitly. The model should be discussed first, and then the requirements listed second. ... 4.4 Access Control and CP selection by NSP When a NSP receives an access request from a user, it is necessary for the NSP to determine to which CP the request is to be directed. It is necessary for the NSP to ensure that it is not spoofed by an inappropriate CP or user. ... Doesn't AAA already do this? What are the concrete requirements added by this document? Or is this document just introducing AAA concepts to people more familiar with multicast issues? ... 4.5 API for Admission Control Information by NSP After authorizing a user request, the NSP may have further conditions for determining its admission control decision. MACCNT-REQ-draft defines requirements for providing the network capability to conduct admission control based on the network bandwidth usage status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves are out of the scope of this memo. ... These mechanisms are defined (or are in the process of being defined) in normal AAA. This document could refer to AAA specifications that meet its needs. ... However the NSP's AAA Server should be provided with an Admission control API that allows for interfacing so that additional conditions can be added to the admission control decision. ... I have no idea what this sentence means. "allows for interfacing" is extremely vague. Also, AAA protocols do not provide for much in the way of capability negotiation. The authors should double-check the requirements of this document against the functionality provided by an existing AAA protocol such as RADIUS. The requirements MAY be more than existing protocols can satisfy. In general, AAA clients provide a set of information to the AAA server in the access request, and the AAA server makes an accept/deny decision based on that information. AAA servers cannot negotiate for more information. This document should define what information is available to the participants. It should discuss what information SHOULD be made available by the AAA client to the AAA server, and what information MUST be made available. ... 4.6 Access Control and Distinguishing of Users by CP The user ID and authentication information are forwarded transparently by the NSP so that the CP can distinguish the user, as well as authenticate and authorize the request. ... Does this impose requirements on the behavior of the AAA systems? If so, what? ... 4.7 Caching of AAA results An NSP should be able to cache AAA results based upon an agreement between the NSP and a CP. The AAA cache would store information about permissions of a specific user to receive multicast data from specified channel(s) up to specified expiration date(s) and time(s). ... This is not a cache, and should not be referred to as a cache. Instead, the NSP obtains a policy from the AAA server for a particular session, and applies that policy to that session, for the duration of the session. The term "cache" should be deleted from the document entirely. Further: ... If such caching is implemented, ... The functionality described as a "cache" MUST be implemented. ... It should be possible for a CP to send unsolicited requests to the NSP to refresh or change the permissions for a user for specific channel(s). ... This is possible using existing AAA protocols. ... When a user is receiving multicast content and the permission is about to expire, the NSP may send a notification to the user client that his session is about to expire, and that he will need to re-connect. The user will have to reestablish a connection. ... In AAA terms, the user will have to re-authenticate, not re-connect. There is no AAA "connection" between the user and the NSP. I have no comments at this time on Section 5. Overall, the document is very rough, and could use substantial clarifications and editing. Recommendations: - use consistent terminology throughout the document - expand on the examples - clearly separate model and requirements - discuss model before requirements - clarify requirements - the authors need MUCH more familiarity with AAA systems - the requirements need to be validated against AAA functionality 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, 21 Aug 2007 08:28:06 +0000 Message-ID: <46CAA1FF.9050900@deployingradius.com> Date: Tue, 21 Aug 2007 10:27:43 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > I don't find the text with the words "authorization parameters" in RFC 2865. > Perhaps this is a misquote? Where did this text come from? I don't find it > in 2865 or Issues & Fixes -05. RFC 2865 seems to have it right. It was one of the suggested re-wordings I posted to the list. 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, 21 Aug 2007 08:27:31 +0000 Message-ID: <46CAA1D9.4040804@nitros9.org> Date: Tue, 21 Aug 2007 10:27:05 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes -- Call-Check. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Based on the discussion so far, acknowledging that Call-Check is > pre-authentication (not in the 802.11i key-caching sense, but in a > pre-screening sense, you don't have my credentials yet), I think that even > MAY is stretching the point. Can anyone describe a use case for Call-Check > in which the NAS would have a State attribute from an existing user session > or ongoing authentication sequence? Nope. Maybe we want to change that to "... Call Check MAY NOT contain a State attribute". This permits them to (magically) have one if they so desire. It permits them to not have one in real-life implementations. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Aug 2007 08:22:36 +0000 Message-ID: <46CAA096.4060206@nitros9.org> Date: Tue, 21 Aug 2007 10:21:42 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Alan DeKok writes... > >> The Call-Check MAY need to be tied to a previous authentication >> request. This can be done via the State attribute being sent in an >> Access-Accept, and used in a later Access-Request with Call Check. > > Can you suggest a specific use case where this may happen? My > understanding of the use of Call-Check is that it always precedes a formal > authentication. Hmm... yes. RFC 2865 has no requirements on Access-Requests with Call Check containing State, so I think that requirement can be removed from the document. >> We extend this definition to say that Access-Requests which are part >> of an ongoing authentication process MAY contain a State attribute. > > So, this sentence really confuses me. Maybe I'm taking it out of context, > but my understanding is that an Access-Request that is part of an ongoing > authentication process MUST contain a State Attribute. This has been the > case since the State attribute was defined. Why are we changing it to MAY? We're not. RFC 2865, Table 5.44 says State is "0-1" in Access-Request. Note 1 says that Access-Requests contain User-Password, CHAP-Password, or State. Section 2 says that Access-Challenges MAY contain State. While most implementations require State in Access-Challenge, I have seen some challenge-response systems that do not require it. Those systems can distinguish the initial request from the response to the challenge without using State to track a "session". >> Access-Request packets that contain a Service-Type attribute with >> value Call Check (10) or Authorize Only (17) MUST contain a State >> attribute. > > I would suggest MUST for Authorize-Only and MAY for Call-Check. OK. >> Any Access-Request that does not contain an authentication >> attribute MUST contain a State attribute. This list of >> authorization parameters is not exhaustive, and may be extended >> in future specifications. > > In the second sentence, did you mean "authentication" rather than > "authorization"? Maybe. I think it's safer just to clean up the terminology. > As I indicated in a separate message, I think we need to include a formal > definition (e.g. by list) of those attributes we consider to be > authentication attributes. What about vendor or SDO extensions? > We are debating whether unknown values of other attributes, or unknown > attribute types, ought to be treated similarly. The suggestion is that a > NAS MAY choose to treat them similarly, i.e. treat unknown attribute types, > or unknown values of known attribute types as an Access-Reject based on > locally configured policy, with the default being to silently ignore them, > for backwards compatibility. NASes MAY implement this local policy feature, > and it is RECOMMENDED for any new implementations or significant revisions. > We ought not to deprecate any existing implementations that don't have this > local policy feature, however. 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: Mon, 20 Aug 2007 21:00:14 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Mon, 20 Aug 2007 17:00:07 -0400 Organization: Elbrys Networks, Inc. Message-ID: <005801c7e36d$1725eb90$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjZvUAmq0FpXpQT4+wsrAudQIIKgABCJsQ Bernard Aboba writes... > > > Any Access-Request that does not contain an authentication > > > attribute MUST contain a State attribute. This list of > > > authorization parameters is not exhaustive, and may be > > > extended in future specifications. > > > >In the second sentence, did you mean "authentication" rather than > >"authorization"? > > This quote came from RFC 2865, so I'm not sure what it means. > That's for us to figure out, I guess :) RFC 2865, Section 4.1 reads, in part: An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password. Note that in this case the word is "authentication". I don't find the text with the words "authorization parameters" in RFC 2865. Perhaps this is a misquote? Where did this text come from? I don't find it in 2865 or Issues & Fixes -05. RFC 2865 seems to have it right. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:34:30 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Mon, 20 Aug 2007 16:34:15 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , , Bernard wrote: If it breaks existing deployments, I'd like to know where they got the State Attribute from :) [Avi] The RADIUS lords work in mysterious ways sometimes. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:30:18 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Mon, 20 Aug 2007 16:30:26 -0400 Organization: Elbrys Networks, Inc. Message-ID: <005001c7e368$f15434c0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjZ1AySUGjxo9uSsmpBwMg2390qwAAQJKQ Avi Lior writes... > > I would suggest MUST for Authorize-Only and MAY for Call-Check. > > [Avi] I agree with David. I am not buying even the MAY for Call- > Check. But I can live with it. Based on the discussion so far, acknowledging that Call-Check is pre-authentication (not in the 802.11i key-caching sense, but in a pre-screening sense, you don't have my credentials yet), I think that even MAY is stretching the point. Can anyone describe a use case for Call-Check in which the NAS would have a State attribute from an existing user session or ongoing authentication sequence? -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:26:47 +0000 Message-ID: From: "Bernard Aboba" To: avi@bridgewatersystems.com, dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Bcc: Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Mon, 20 Aug 2007 13:26:26 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >[Avi] I agree with David. Call-Check is Pre-authentication, there is no >prior user-session. Right. This seems like a mistake in RFC 2865. We probably should explicitly address this in the document. >[Avi] I think an Access-Request with Service-Type set to Call-Check MUST >NOT contain State. However, making that restriction may break existing >deployements -- Issues and Fixes should not break existing deployements. > >Snip.... If it breaks existing deployments, I'd like to know where they got the State Attribute from :) -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:23:54 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Mon, 20 Aug 2007 16:23:56 -0400 Organization: Elbrys Networks, Inc. Message-ID: <004c01c7e368$08b65720$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjZhyjimllGwGkQZGRZoQ1S8aIFgAAJFrg Bernard Aboba writes... > If I read RFC 2865 correctly, it would seem that an Access-Request > containing Service-Type="Call-Check" MUST contain a State attribute, > since this won't contain User-Password, CHAP-Password or any other > "authentication" attribute". Now, I'm not sure I understand where > the NAS is supposed to get the State Attribute from... Indeed. This brings to mind one of my favorite sayings regarding software: "How did this ever work?". My understanding of the use case for a Access-Request with a Service-Type of Call-Check is that the Calling-Station-ID (and possibly the Called-Station-ID) provides the identity of the remote user for the purpose of a pre-screening authentication, originally used to decide whether the NAS should accept the call set-up on an ISDN or DSL link, terminating in a modem pool. The idea was to avoid tying up a modem, if the user wasn't one of your authorized customers. In this use case there can be no valid source of the State attribute in the NAS. > ...but that does seem to be what RFC 2865 is saying. Well, I wonder... > > > Any Access-Request that does not contain an authentication > > > attribute MUST contain a State attribute. This list of > > > authorization parameters is not exhaustive, and may be extended > > > in future specifications. > > > >In the second sentence, did you mean "authentication" rather than > >"authorization"? > > This quote came from RFC 2865, so I'm not sure what it means. > That's for us to figure out, I guess :) I'll look at this again, in context, but taken out of context it does seem confusing. > That is already in RFC 2865, I believe. Yes, and we think it's correct! :-) > BTW, I believe that there may be some other hints on this in > RFC 2869. For example, in the ARAP section there is some discussion > of how NASes that don't support ARAP are supposed to behave. OK, we can look at that text for any possible guidance. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:16:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check. Date: Mon, 20 Aug 2007 16:18:20 -0400 Message-ID: From: "Avi Lior" To: "David B. Nelson" , [Avi] I agree with David. Call-Check is Pre-authentication, there is no prior user-session. =20 [Avi] I think an Access-Request with Service-Type set to Call-Check MUST NOT contain State. However, making that restriction may break existing deployements -- Issues and Fixes should not break existing deployements. Snip.... > Access-Request packets that contain a Service-Type attribute with > value Call Check (10) or Authorize Only (17) MUST contain a State > attribute. I would suggest MUST for Authorize-Only and MAY for Call-Check. [Avi] I agree with David. I am not buying even the MAY for Call-Check. But I can live with 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: Mon, 20 Aug 2007 20:16:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: review of "Issues and Fixes" Date: Mon, 20 Aug 2007 16:18:19 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" Cc: Well, I think issues and fixes should define the term authentication attribute. Authentication attributes contain the information required to authenticate the user. Examples are: User-Password, CHAP-Password, ARAP-Password and EAP-Message. Regarding Message-Authenticator -- based on your response, I don't think that Message-Authenticator is an authentication attribute because it does not contian information required to authenticate the user. Message-Authenticator purpose is to protect the packet. I think that "Other kinds of Authentication Information" must refer to other kinds of user authentication information. But if I am wrong, then this is another grey area that needs to be plugged up. -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, August 20, 2007 10:43 AM To: Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: review of "Issues and Fixes" > As defined in [RFC 2865] Table 5.44, Access-Request packets MAY > contain a State attribute. We extend that definition here, to say > that Access-Request packets that contain an authentication attribute > or a Service-Type attribute with the value Call Check (10) MAY > contain a State attribute. Access-Request packets not matching the > above description MUST contain a State attribute. > >The term authentication attribute is not defined. What is an=20 >authentication attribute? Is Message-Authenticator an authetication=20 >attribute? RFC 2865, Section 4.1 says: " An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password." RFC 2869 Section 2.2 says: " Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS." Based on this, User-Password, CHAP-Password, EAP-Message and ARAP-Password=20 should fall in the list of authentication attributes. Based on RFC 4590, a=20 Digest-Response Attribute also qualifies. Not sure whether Message-Authenticator falls into "other kinds of authentication information." -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 20:11:05 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@elbrysnetworks.com, radiusext@ops.ietf.org Bcc: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Mon, 20 Aug 2007 13:10:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I would suggest MUST for Authorize-Only and MAY for Call-Check. If I read RFC 2865 correctly, it would seem that an Access-Request containing Service-Type="Call-Check" MUST contain a State ttribute, since this won't contain User-Password, CHAP-Password or any other "authentication attribute". Now, I'm not sure I understand where the NAS is supposed to get the State Attribute from, but that does seem to be what RFC 2865 is saying. > > Any Access-Request that does not contain an authentication > > attribute MUST contain a State attribute. This list of > > authorization parameters is not exhaustive, and may be extended > > in future specifications. > >In the second sentence, did you mean "authentication" rather than >"authorization"? This quote came from RFC 2865, so I'm not sure what it means. That's for us to figure out, I guess :) >I think you meant "new service". I agree. > >We have previously agreed that unknown values of the Service-Type attribute >MUST be treated as an Access-Reject. That much is clear. That is already in RFC 2865, I believe. >We are debating whether unknown values of other attributes, or unknown >attribute types, ought to be treated similarly. The suggestion is that a >NAS MAY choose to treat them similarly, i.e. treat unknown attribute types, >or unknown values of known attribute types as an Access-Reject based on >locally configured policy, with the default being to silently ignore them, >for backwards compatibility. NASes MAY implement this local policy >feature, >and it is RECOMMENDED for any new implementations or significant revisions. >We ought not to deprecate any existing implementations that don't have this >local policy feature, however. BTW, I believe that there may be some other hints on this in RFC 2869. For example, in the ARAP section there is some discussion of how NASes that don't support ARAP are supposed to behave. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 16:08:27 +0000 Message-ID: <46C9BC5F.6020307@nitros9.org> Date: Mon, 20 Aug 2007 18:07:59 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: aland@nitros9.org, radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I think we 'd also need to include ARAP & Digest authentication, no? Yes. > Think this is "Call Check". I'm curious whether current > implementations of Call Check satisfy this or not. That was a typo, sorry. I don't know of implementations that do this... >> This also adds an informative reference to RFC 3576. > > The reference should probably be to [RFC3576bis]. OK... along with RFC4590bis for Digest-Response. 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, 20 Aug 2007 16:04:03 +0000 From: "David B. Nelson" To: Subject: RE: review of "Issues and Fixes" Date: Mon, 20 Aug 2007 12:04:00 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001d01c7e343$b8f7a5a0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjQzoTpWaB25BaQwmQNv2q7WkvMgAAD4gA Alan DeKok writes... > I would prefer to avoid creating or using a new term. The perhaps we should use the definition of the "term" instead, as an in-line macro expansion, as it were. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 16:00:29 +0000 Message-ID: <46C9BA8A.9070407@nitros9.org> Date: Mon, 20 Aug 2007 18:00:10 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: review of "Issues and Fixes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > If we are to user the term "authentication attribute" as words-of-art, then > I think we should include a definition, along the lines you have just > suggested. I would prefer to avoid creating or using a new term. 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, 20 Aug 2007 15:59:15 +0000 From: "David B. Nelson" To: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Mon, 20 Aug 2007 11:59:09 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001901c7e343$0b5e6c80$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjI5jIUAtzeuldTeSp8L+O5lWCHgAGvYwA Alan DeKok writes... > The Call-Check MAY need to be tied to a previous authentication > request. This can be done via the State attribute being sent in an > Access-Accept, and used in a later Access-Request with Call Check. Can you suggest a specific use case where this may happen? My understanding of the use of Call-Check is that it always precedes a formal authentication. > We extend this definition to say that Access-Requests which are part > of an ongoing authentication process MAY contain a State attribute. So, this sentence really confuses me. Maybe I'm taking it out of context, but my understanding is that an Access-Request that is part of an ongoing authentication process MUST contain a State Attribute. This has been the case since the State attribute was defined. Why are we changing it to MAY? > Access-Request packets that contain a Service-Type attribute with > value Call Check (10) or Authorize Only (17) MUST contain a State > attribute. I would suggest MUST for Authorize-Only and MAY for Call-Check. > Any Access-Request that does not contain an authentication > attribute MUST contain a State attribute. This list of > authorization parameters is not exhaustive, and may be extended > in future specifications. In the second sentence, did you mean "authentication" rather than "authorization"? As I indicated in a separate message, I think we need to include a formal definition (e.g. by list) of those attributes we consider to be authentication attributes. > I would simply say that the algorithms apply to any client originating > RADIUS packets, including Disconnect-Requests. This covers the Dynamic > Authorization Client, without adding a dependency on RFC 3576bis. > Suggested text: > > The following algorithms apply to any client that originates RADIUS > packets, including but not limited to Access-Request, > Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576]. > > This also adds an informative reference to RFC 3576. That seems reasonable. > Sure. It's RECOMMENDED. We can simply say "... the RECOMMENDED > retransmission algorithm below is..." > > [ MRD and MRC] > > This could have some unforeseen (and potentially adverse) impacts on > > RADIUS accounting. Today, some RADIUS accounting clients continue to > > retransmit for long periods of time, intentionally, in order to improve > > reliability. If there is an upper bound on the number of times a sender > > may retransmit an accounting message, then accounting messages could be > > lost in situations where today they would be delivered. So I think this > > needs to be changed. > > We can add a note: > > For Accounting-Request packets, the default values for MRC, MRD, > and MRT SHOULD be zero. These settings will enable a RADIUS client > to continue sending accounting requests to a RADIUS server until > the request is acknowledged. If any of MRC, MRD, or MRT are non- > zero, then the accounting information could potentially be > discarded without being recorded. That also seems reasonable. > > Section 2.5 > > > > The issue that this section is attempting to address is the > > seeming contradiction between [RFC2865] Section 1.1 which states: > ... > > and [RFC2865] Section 5 which states: > ... > > As I recall, the conclusion was that the advice of Section 1.1 > > applies to known attributes, so that if a NAS receives an attribute > > that is known and represents a service, but is not implemented, > > it is treated as an Access-Reject. Whereas if the attribute is not > > known, then it MAY be ignored. > > It's difficult to know if a new attribute defines a new server. I think you meant "new service". I agree. We have previously agreed that unknown values of the Service-Type attribute MUST be treated as an Access-Reject. That much is clear. We are debating whether unknown values of other attributes, or unknown attribute types, ought to be treated similarly. The suggestion is that a NAS MAY choose to treat them similarly, i.e. treat unknown attribute types, or unknown values of known attribute types as an Access-Reject based on locally configured policy, with the default being to silently ignore them, for backwards compatibility. NASes MAY implement this local policy feature, and it is RECOMMENDED for any new implementations or significant revisions. We ought not to deprecate any existing implementations that don't have this local policy feature, however. > > The question was then what the behavior is for a NAS encountering > > an unknown attribute. Given the MAY in Section 5, behavior can > > only be recommended, not mandated, because of backward > > compatibility. Agreed. > > [BA] My recommendation would be to add a clarification of the > > meaning of Section 1.1: > >... On receiving an Access-Accept including an attribute of > > known Type for an unimplemented service, a RADIUS client MUST > > treat it as an Access-Reject, as directed in [RFC2865] Section > > 1.1. > > It's difficult to know that an unknown type is for an > unimplemented service. But I think I know what you mean. We know that an unknown value of the Service-Type attribute is an unimplemented service, by definition. For unknown attribute types, or unknown value of known attribute types, the discussion above applies. > > I think what we are trying to say here is that existing > > implementations that ignore unknown attributes should probably > > not change to treating them as an Access-Reject by default, or > > else on upgrading the NAS, the users could see an unexpected > > change in behavior. Not by default, anyway. I think it is a good idea to add the capability of treating unknown attribute type codes or unknown values of known attributes as Access-Reject as an administrator manageable option. The default is to ignore them, for backwards compatibility and maximum interoperability with RADIUS extensions. The ability to treat these "unknown" attributes as Access-Reject for maximum security should be a non-default, administrator-selectable option. > > In order to avoid introducing changes in default behavior, > > existing implementations that do not obey this recommendation > > should make the behavior configurable, with the legacy behavior > > being enabled by default. A configuration flag such as "treat > > unknown attributes as reject" can be exposed to the system > > administrator. If the flag is set to true, then Access-Accepts > > containing unknown attributes are treated as Access-Rejects. If > > the flag is set to false, then unknown attributes in Access- > > Accepts are be silently ignored. Agreed. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 15:26:00 +0000 From: "David B. Nelson" To: Subject: RE: review of "Issues and Fixes" Date: Mon, 20 Aug 2007 11:25:18 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001201c7e33e$50a8b660$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AcfjOOyRVqx7vI81RnWyG1itOCSytgABO2HQ Bernard Aboba writes... > >The term authentication attribute is not defined. What is an > >authentication attribute? Is Message-Authenticator an > >authentication attribute? > Based on this, User-Password, CHAP-Password, EAP-Message and > ARAP-Password should fall in the list of authentication attributes. > Based on RFC 4590, a Digest-Response Attribute also qualifies. > Not sure whether Message-Authenticator falls into "other kinds of > authentication information." If we are to user the term "authentication attribute" as words-of-art, then I think we should include a definition, along the lines you have just suggested. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 14:43:19 +0000 Message-ID: From: "Bernard Aboba" To: avi@bridgewatersystems.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: review of "Issues and Fixes" Date: Mon, 20 Aug 2007 07:43:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > As defined in [RFC 2865] Table 5.44, Access-Request packets MAY > contain a State attribute. We extend that definition here, to say > that Access-Request packets that contain an authentication attribute > or a Service-Type attribute with the value Call Check (10) MAY > contain a State attribute. Access-Request packets not matching the > above description MUST contain a State attribute. > >The term authentication attribute is not defined. What is an >authentication attribute? Is Message-Authenticator an authetication >attribute? RFC 2865, Section 4.1 says: " An Access-Request MUST contain either a User-Password or a CHAP- Password or a State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password." RFC 2869 Section 2.2 says: " Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS." Based on this, User-Password, CHAP-Password, EAP-Message and ARAP-Password should fall in the list of authentication attributes. Based on RFC 4590, a Digest-Response Attribute also qualifies. Not sure whether Message-Authenticator falls into "other kinds of authentication information." -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 14:22:35 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Request for Review: "Issues and Fixes" changes Date: Mon, 20 Aug 2007 07:22:02 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > For example, an Access-Request containing one of the authentication > attributes User-Password or CHAP-Password MAY contain a State > attribute. Other attributes intended to carry authentication > information include EAP-Message, though this list is not exhaustive, > and may be extended in future specifications. I think we 'd also need to include ARAP & Digest authentication, no? > Access-Request packets that contain a Service-Type attribute with > value Call Chack (10) or Authorize Only (17) MUST contain a State > attribute. Any Access-Request that does not contain an > authentication attribute MUST contain a State attribute. This list > of authorization parameters is not exhaustive, and may be extended in > future specifications. Think this is "Call Check". I'm curious whether current implementations of Call Check satisfy this or not. > The following algorithms apply to any client that originates RADIUS > packets, including but not limited to Access-Request, > Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576]. > > This also adds an informative reference to RFC 3576. The reference should probably be to [RFC3576bis]. > We can add a note: > > For Accounting-Request packets, the default values for MRC, MRD, > and MRT SHOULD be zero. These settings will enable a RADIUS client > to continue sending accounting requests to a RADIUS server until > the request is acknowledged. If any of MRC, MRD, or MRT are non- > zero, then the accounting information could potentially be > discarded without being recorded. This is better, thanks. >It's difficult to know that an unknown type is for an unimplemented >service. But I think I know what you mean. Actually, I meant a known type; for an unknown type, I agree. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Aug 2007 12:08:51 +0000 Message-ID: <46C9843B.6000208@nitros9.org> Date: Mon, 20 Aug 2007 14:08:27 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Request for Review: "Issues and Fixes" changes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Does it make sense to include a State attribute in an Access-Request with > a Service-Type attribute with value Call Check (10)? Typically in these > cases there is no state to encode. The Call-Check MAY need to be tied to a previous authentication request. This can be done via the State attribute being sent in an Access-Accept, and used in a later Access-Request with Call Check. Suggested text: ... As defined in [RFC2865] Table 5.44, Access-Request packets MAY contain a State attribute. The table does not qualify this statement, while the text in Section 5.24 says This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request. We extend this definition to say that Access-Requests which are part of an ongoing authentication process MAY contain a State attribute. Access-Requests which are intended to perform authorization checks MUST contain a State attribute. This last requirement often means that an Access-Accept will contain a State attribute, so that a later authorization check may use that State to tie the authorization check to a previous authentication request. For example, an Access-Request containing one of the authentication attributes User-Password or CHAP-Password MAY contain a State attribute. Other attributes intended to carry authentication information include EAP-Message, though this list is not exhaustive, and may be extended in future specifications. Access-Request packets that contain a Service-Type attribute with value Call Chack (10) or Authorize Only (17) MUST contain a State attribute. Any Access-Request that does not contain an authentication attribute MUST contain a State attribute. This list of authorization parameters is not exhaustive, and may be extended in future specifications. ... > Section 2.2.1 > > I think this section needs to note that the suggested algorithms apply > not only to a RADIUS client, but also to a Dynamic Authorization Client, > defined in RFC 3576bis. Either that, or the algorithm text needs to be > transplanted into RFC 3576bis. I would simply say that the algorithms apply to any client originating RADIUS packets, including Disconnect-Requests. This covers the Dynamic Authorization Client, without adding a dependency on RFC 3576bis. Suggested text: The following algorithms apply to any client that originates RADIUS packets, including but not limited to Access-Request, Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576]. This also adds an informative reference to RFC 3576. > Is the retransmission algorithm OPTIONAL or RECOMMENDED? The first > paragraph seems to suggest that only congestive backoff is RECOMMENDED, > and that the rest of the text is non-normative. Is that what is > intended? I'd suggest that we say something like "A potential > retransmission algorithm is included below" to make that that clear, if > that is what is meant. Sure. It's RECOMMENDED. We can simply say "... the RECOMMENDED retransmission algorithm below is..." [ MRD and MRC] > This could have some unforseen (and potentially adverse) impacts on > RADIUS accounting. Today, some RADIUS accounting clients continue to > retransmit for long periods of time, intentionally, in order to improve > reliability. If there is an upper bound on the number of times a sender > may retransmit an accounting message, then accounting messages could be > lost in situations where today they would be delivered. So I think this > needs to be changed. We can add a note: For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non- zero, then the accounting information could potentially be discarded without being recorded. > Section 2.5 > > The issue that this section is attempting to address is the seeming > contradiction between > [RFC2865] Section 1.1 which states: ... > and [RFC2865] Section 5 which states: ... > As I recall, the conclusion was that the advice of Section 1.1 applies > to known attributes, so that if a NAS receives an attribute that is > known and represents a service, but is not implemented, it is treated as > an Access-Reject. Whereas if the attribute is not known, then it MAY be > ignored. It's difficult to know if a new attribute defines a new server. > The question was then what the behavior is for a NAS encountering an > unknown attribute. Given the MAY in Section 5, behavior can only be > recommended, not mandated, because of backward compatibility. Yes. The text in 2.5 use SHOULD, not MUST. > It is possible for either a standard attribute or VSA to represent a > request for an unavailable service. However, where the Type or > Vendor-ID is unknown, a RADIUS client will not know whether the > attribute defines a service or not. > > [BA] Actually the problem could also arise if the Vendor-ID is known, > but the Vendor Type is not, right? Yes. We can update it "Type, Vendor-Id, or Vendor-Type". > [BA] My recommendation would be to add a clarification of the meaning of > Section 1.1: >... On receiving an > Access-Accept including an attribute of known Type for an unimplemented > service, a RADIUS client MUST treat it as an Access-Reject, as directed > in [RFC2865] Section 1.1. It's difficult to know that an unknown type is for an unimplemented service. But I think I know what you mean. > I think what we are trying to say here is that existing implementations > that ignore unknown attributes should probably not change to treating > them as an Access-Reject by default, or else on upgrading the NAS, the > users could see an unexpected change in behavior. In this situation, > configuration would be helpful, but the legacy behavior should be the > default, probably. However, where the existing implementation already > implements the recommended behavior, there is no point in introducing > configuration. Here is a recommended rewrite: OK. > In order to avoid introducing changes in default behavior, existing > implementations that do not obey this recommendation should make the > behavior configurable, with the legacy behavior being enabled by > default. A configuration flag such as "treat unknown attributes as > reject" can be exposed to the system administrator. If the flag is set > to true, then Access-Accepts containing unknown attributes are treated > as Access-Rejects. If the flag is set to false, then unknown > attributes in Access-Accepts are be silently ignored. Looks good to me. 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, 20 Aug 2007 12:08:06 +0000 From: "David B. Nelson" To: Subject: FW: review of "Issues and Fixes" Date: Mon, 20 Aug 2007 08:06:51 -0400 Message-ID: <00c301c7e322$97de7400$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcfjIhyBF7qIYBxyThC2yY1p15L3qAAAFsog Forwarding to the list... From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Monday, August 20, 2007 8:03 AM To: aland@freeradius.org; d.b.nelson@comcast.net; Bernard Aboba Subject: review of "Issues and Fixes" =A0 First comment: =A0 In the following text: =A0 =A0As defined in [RFC 2865] Table 5.44, Access-Request packets MAY =A0=A0 contain a State attribute.=A0 We extend that definition here, to = say =A0=A0 that Access-Request packets that contain an authentication = attribute =A0=A0 or a Service-Type attribute with the value Call Check (10) MAY =A0=A0 contain a State attribute.=A0 Access-Request packets not matching = the =A0=A0 above description MUST contain a State attribute. The term authentication attribute is not defined.=A0 What is an = authentication attribute?=A0 Is Message-Authenticator an authetication attribute. =A0 Second Comment: =A0 The State attribute is needed to be included in an Access-Request with Service-Type set to "Authorize-Only". =A0 Currently it is not clear how the State attribute is available at the = NAS.=A0 In the case of COA we are very explicit.=A0 Currently 2865 states: =A0 This Attribute(State) is available to be sent by the server to the = client =A0=A0=A0=A0=A0 in an Access-Accept that also includes a = Termination-Action =A0=A0=A0=A0=A0 Attribute with the value of RADIUS-Request.=A0=20 =A0 The assumption here is that Termination-Action can trigger another Access-Request and thus we want to use the State attribute to link them together.=A0 However, today a NAS can send an Access-Request with = Service-Type Authorize-Only for other reasons.=A0=A0 Thus it would be helpful to = allow a State attribute to be included in an Access-Accept period. =A0 I would suggest the following text or something similar for Issues and Fixes. =A0 A RADIUS server MAY include the State attribute in an Access-Accept.=A0 = A RADIUS server MUST include the State attribute in an Access-Accept if it = is anticipated that the RADIUS client will generate an Access-Request with Service-Type set to "Authorize-Only". =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Avi = Lior=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 Bridgewater Systems Corporation=20 Phone :=A0 +1 (613) 591-9104 x6417 Cell=A0=A0=A0=A0:=A0 +1 (613)=A0796-4183 E-mail : mailto:avi@bridgewatersystems.com www.bridgewatersystems.com=A0 =A0 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Aug 2007 22:00:18 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Update on RFC 4590bis Date: Sat, 18 Aug 2007 15:00:05 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed As noted on July 8, 2007, the publication of RFC 4590bis was approved by the IESG: http://ops.ietf.org/lists/radiusext/2007/msg00501.html In the process of review of Appendix A, it was noted that the addresses used were not compatible with the address space allocated for example usage. As a result, an RFC Editor Note is required. The corrected text required for Appendix A is enclosed below as prepared by Wolfgang: -----Ursprüngliche Nachricht----- Von: Beck, Wolfgang Gesendet: Montag, 9. Juli 2007 11:37 An: 'Bernard Aboba' Betreff: AW: idnits warnings in rfc4590bis Bernard, here's a corrected version. Wolfgang ----------------------------------- This is an example selected from the traffic between a softphone (A), a Proxy Server (B), and an example.com RADIUS server (C). The communication between the Proxy Server and a SIP Public Switched Telephone Network (PSTN) gateway is omitted for brevity. The SIP messages are not shown completely. The password of user '12345678' is 'secret'. The shared secret between RADIUS client and server is 'secret'. To ease testing, only the last byte of the RADIUS authenticator changes between requests. In a real implementation, this would be a serious flaw. A->B INVITE sip:97226491335@example.com SIP/2.0 From: To: B->A SIP/2.0 100 Trying B->C Code = Access-Request (1) Packet identifier = 0x7c (124) Length = 97 Authenticator = F5E55840E324AA49D216D9DBD069807C NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B C->B Code = Access-challenge (11) Packet identifier = 0x7c (124) Length = 72 Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D Digest-Nonce = 3bada1a0 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3 B->A SIP/2.0 407 Proxy Authentication Required Proxy-Authenticate: Digest realm="example.com" ,nonce="3bada1a0",qop=auth,algorithm=MD5 Content-Length: 0 A->B ACK sip:97226491335@example.com SIP/2.0 A->B INVITE sip:97226491335@example.com SIP/2.0 Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0" ,realm="example.com" ,response="7679b84a560835846ec553174dbabb69" ,uri="sip:97226491335@example.com",username="12345678" ,qop=auth,algorithm=MD5 ,cnonce="56593a80,nc="00000001" From: To: B->C Code = Access-Request (1) Packet identifier = 0x7d (125) Length = 221 Authenticator = F5E55840E324AA49D216D9DBD069807D NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = INVITE Digest-URI = sip:97226491335@example.com Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = 3bada1a0 Digest-Nonce-Count = 00000001 Digest-Response = 7679b84a560835846ec553174dbabb69 Digest-Username = 12345678 SIP-AOR = sip:12345678@example.com Message-Authenticator = BD037498E8385878A46ECF4D5F8D2B48 C->B Code = Access-Accept (2) Packet identifier = 0x7d (125) Length = 72 Authenticator = 36E1201AD4377664E720184CE7B3D8C6 Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64 B->A SIP/2.0 180 Ringing B->A SIP/2.0 200 OK A->B ACK sip:97226491335@example.com SIP/2.0 A second example shows the traffic between a web browser (A), web server (B), and a RADIUS server (C). A->B GET /index.html HTTP/1.1 B->C Code = Access-Request (1) Packet identifier = 0x7e (126) Length = 68 Authenticator = F5E55840E324AA49D216D9DBD069807E NAS-IP-Address = 192.0.2.38 NAS-Port = 5 Digest-Method = GET Digest-URI = /index.html Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992 C->B Code = Access-challenge (11) Packet identifier = 0x7e (126) Length = 72 Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E Digest-Nonce = a3086ac8 Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A B->A HTTP/1.1 401 Authentication Required WWW-Authenticate: Digest realm="example.com", nonce="a3086ac8",qop=auth,algorithm=MD5 Content-Length: 0 A->B GET /index.html HTTP/1.1 Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8" ,nc="00000001",cnonce="56593a78" ,realm="example.com" ,response="ba623217b5ec024d30c4aaef9d8494de" ,uri="/index.html",username="12345678" B->C Code = Access-Request (1) Packet identifier = 0x7f (127) Length = 176 Authenticator = F5E55840E324AA49D216D9DBD069807F NAS-IP-Address = 192.0.2.38 NAS-Port = 5 User-Name = 12345678 Digest-Method = GET Digest-URI = /index.html Digest-Realm = example.com Digest-Qop = auth Digest-Algorithm = MD5 Digest-CNonce = 56593a80 Digest-Nonce = a3086ac8 Digest-Nonce-Count = 00000001 Digest-Response = ba623217b5ec024d30c4aaef9d8494de Digest-Username = 12345678 Message-Authenticator = C360BFCEDFFBCE893469E802013DA5AA C->B Code = Access-Accept (2) Packet identifier = 0x7f (127) Length = 72 Authenticator = F1ECAC22D3C88E0260B287FA35595F80 Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c Message-Authenticator = 956312EC57AF51ABC4F6965270F34982 B->A HTTP/1.1 200 OK ... ... -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2007 21:54:13 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Completion of Review of RADIUS GEOPRIV Location Specification Date: Sat, 18 Aug 2007 14:54:04 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed On Wednesday, July 4, 2007 a request for review was posted to the RADEXT WG mailing list relating to the RADIUS Geopriv specification: http://ops.ietf.org/lists/radiusext/2007/msg00484.html The specification is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-15.txt So far, no comments have been received. The document has now completed IESG review and is awaiting resolution of IESG DISCUSS comments. If there are any further comments on this document, please speak up NOW. -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2007 21:49:17 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for review of "AAA Framework for Multicasting" Date: Sat, 18 Aug 2007 14:49:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A request for review has been received relating to the document "AAA Framework for Multicasting" which is under development within the MBONED WG. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt The Request for Review will last until September 5, 2007. Please post your comments on this document to the RADEXT WG mailing list, CC:'ing the document authors. Information on the review request was previously posted to the RADEXT WG mailing list: http://ops.ietf.org/lists/radiusext/2007/msg00528.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Aug 2007 21:43:57 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG review of draft-nelson-radius-management-authorization Date: Sat, 18 Aug 2007 14:43:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed On August 2, 2007 a request for review of draft-nelson-radius-management-authorization was posted to the RADEXT WG mailing list: http://ops.ietf.org/lists/radiusext/2007/msg00581.html The review concluded on August 16, 2007. More than half a dozen individuals indicated interest and support for the document, and there were no dissenting opinions. As a result, the document has been adopted as a RADEXT WG work item. The following comments were received: http://ops.ietf.org/lists/radiusext/2007/msg00623.html (Bert Wijnen) http://ops.ietf.org/lists/radiusext/2007/msg00630.html (Stefan Winter) -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2007 21:39:12 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review of "Issues and Fixes" changes Date: Sat, 18 Aug 2007 14:38:55 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed On Firday, August 3, 2007 a request for review of the "Issues and Fixes" document changes to address IESG DISCUSS comments was posted to the RADEXT WG mailing list: http://ops.ietf.org/lists/radiusext/2007/msg00584.html The review request completed on August 17, 2007. A single review comment was received: http://ops.ietf.org/lists/radiusext/2007/msg00585.html If anyone has any further comments on the changes made between -04 and -05, please post them by Friday, August 25, 2007. Since this document has completed IESG evaluation, it can be put back on the IESG agenda once the IESG DISCUSS comments are resolved. The latest version is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-05.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Aug 2007 21:35:28 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG last call on "RADIUS Attributes for Filtering and Redirection" Date: Sat, 18 Aug 2007 14:34:43 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed On July 5, 2007 the RADEXT WG began WG last call on "RADIUS Attributes for Filtering and Redirection": http://ops.ietf.org/lists/radiusext/2007/msg00494.html http://ops.ietf.org/lists/radiusext/2007/msg00541.html This WG last call was to last until Monday, July 23, 2007. During the WG last call, only a single comment was received, from Hannes Tschofenig: http://ops.ietf.org/lists/radiusext/2007/msg00496.html No other messages were posted to the RADEXT WG mailing list indicating that WG participants had read the document. Given the light level of participation, we are going to extend the WG last call for 10 more days (until August 28, 2007). If you have read the document and approve of its publication as a Proposed Standard, please post your approval to the list, even if you have no comments to provide. If you have comments, please provide them in the format described on the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Aug 2007 13:18:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Date: Sat, 18 Aug 2007 09:17:03 -0400 Message-ID: From: "Avi Lior" To: "Bernard Aboba" , I have read through the document and I support it becoming a WG item. Thanx.=20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, August 14, 2007 10:32 AM To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization The WG review request ends on August 16, 2007. So far we have had only person express interest - not enough to adopt this document as a WG work item. Please post to the list if you support taking this on as a WG work item (even if you have no comments to post). >From: "Wijnen, Bert (Bert)" >To: , >CC: , "Bernard Aboba"=20 > >Subject: RE: [Isms] [bernard_aboba@hotmail.com: Review o=20 >fdraft-nelson-radius-management-authorization-05.txt] >Date: Tue, 14 Aug 2007 11:35:43 +0200 > >Some nits: > >Sect 4 > > The local application of the Management-Policy-Id within the managed > entity may take the form of (a) one of an enumeration of command > privilege levels, (b) a mapping into an SNMP View Based Access > Control Method (VACM) table [RFC3415], or (c) some other set of > >Did you intend to writhe "Method", or do you mean "Model"? >VACM stands for View Based Access Control Model in the SNMP context. > >Sect 7.3 > The Text field is one or more octets, and its contents are > implementation dependent. It is intended to be human readable and > MUST NOT affect operation of the protocol. It is recommended that > the message contain UTF-8 encoded 10646 [RFC2279] characters. > >The latest RFC for UTF-8 is RFC3629. >I guess it is better reference that one. > >I can support this work item as a topic for the RADEXT WG. >Not sure how much I can contribute though, but I will try to review=20 >revisions of the document > >Bert Wijnen -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Aug 2007 11:40:44 +0000 From: "David B. Nelson" To: Subject: RE: Review of draft-nelson-radius-management-authorization-05.txt Date: Thu, 16 Aug 2007 07:40:32 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001c01c7dffa$40cc7e30$6501a8c0@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcffymJdNcKlFfEBSnWZhs0iOXhEXgALrDYg Stefan Winter writes... > Is there a specific reason for not enumerating "Telnet" as one > of the Framed-Management-Protocol values? A loose definition of "framed management" is anything that is not CLI-based. Since Telnet is used, exclusively to my knowledge, to provide remote terminal emulation access to the CLI of the NAS, it is not considered a framed management protocol. That's why it was omitted. Rlogin falls into that same category. Of course, I would hope that the WG members would provide just this sort of comment during review of the draft prior to WGLC, so that we can include enumerated values covering the complete range of NAS management options. -- to unsubscribe send a message to radiusext-request@ops.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, 16 Aug 2007 05:52:48 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Bernard Aboba" Subject: Re: Review of draft-nelson-radius-management-authorization-05.txt Date: Thu, 16 Aug 2007 07:51:22 +0200 User-Agent: KMail/1.9.7 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1235753.SEP9XBH9n6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708160751.32507.stefan.winter@restena.lu> --nextPart1235753.SEP9XBH9n6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I also support its adoption. After having a quick glance: Is there a specif= ic=20 reason for not enumerating "Telnet" as one of the Framed-Management-Protoco= l=20 values? Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart1235753.SEP9XBH9n6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGw+Xk+jm90f8eFWYRAkUfAJwKDv01Dduykkt5asSU1dWPMGepQACfQBcO vslWT3zL++uUx3CiCR8Xx2c= =V6r2 -----END PGP SIGNATURE----- --nextPart1235753.SEP9XBH9n6-- -- to unsubscribe send a message to radiusext-request@ops.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, 16 Aug 2007 03:16:22 +0000 From: "Okita, Cat" To: "Rati, Shiddalinganagouda" , "radiusext@ops.ietf.org" Date: Thu, 16 Aug 2007 03:14:23 +0000 Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Topic: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Index: Acffm52CZnjPT5FsQtum9UtNcUh8TwAF+4Bw Message-ID: <6D4E09D6038512449B755825918981A816C18BC6B5@G1W0486.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I also agree - I have read through the document, and would like to see it a= s a WG item. Cat Okita Network and Security Services Hewlett-Packard (Canada) Co. cat.okita@hp.com +1 416 309 6438 ________________________________________ From: owner-radiusext@ops.ietf.org [owner-radiusext@ops.ietf.org] On Behalf= Of Rati, Shiddalinganagouda Sent: Wednesday, August 15, 2007 20:23 To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-autho= rization I have gone through the document and I support this document as a WG item. -Siddu Rati -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Aug 2007 00:24:00 +0000 From: "Rati, Shiddalinganagouda" To: "radiusext@ops.ietf.org" Date: Thu, 16 Aug 2007 00:23:05 +0000 Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Topic: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Index: Acffm52CZnjPT5FsQtum9UtNcUh8Tw== Message-ID: Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I have gone through the document and I support this document as a WG item. -Siddu Rati -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2007 19:54:25 +0000 From: "David B. Nelson" To: Subject: FW: Review of draft-nelson-radius-management-authorization-05.txt Date: Tue, 14 Aug 2007 15:54:12 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00b801c7deac$e2d99540$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcferGomqGyxgEqfEdyAJgAX8tamGQAAEJew Forwarding to the list... > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Tuesday, August 14, 2007 3:51 PM > To: David B. Nelson; Bernard Aboba > Subject: Re: Review of draft-nelson-radius-management-authorization-05.txt > > > Hi Bernard, David > > I would like to see this document taken on as a WG item. I believe > that beyond the usage for ISMS, the mechanisms described in this > document can be applied to other management protocols such as netconf. > > I will review the document and send in my comments. > > regards, > kaushik -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2007 18:12:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DE9E.963B426D" Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Date: Tue, 14 Aug 2007 11:09:53 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9DD@xmb-sjc-215.amer.cisco.com> Thread-Topic: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Index: AcfekmyrxslxrgS9TX+erGJVuyO0lAAC+O3S From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2496; t=1187115133; x=1187979133; c=relaxed/simple; s=sjdkim4002; 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=20REMINDER=3A=20RADEXT=20WG=20review=20of=20draft-nelso n-radius-management-authorization |Sender:=20; bh=GXWQ2+2UTwR1ZHQWK4GOa3CbTk9BcuHvs9mSB5brAnw=; b=lNcWyX6iGztwsVBW28SiXnV8Kxr7oEibWCZ5VpaECnXaemWy496MKfOWDt2pEOGRgNoBtdmr ZEq3hIZ9Wwep/RJXkPEXRggskRXoF8sp8M72kPBODFb+gVKKUCFmRTY0; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE9E.963B426D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > The WG review request ends on August 16, 2007. So far we have had = only > person express interest - not enough to adopt this document as a WG = work > item. Please post to the list if you support taking this on as a WG > work item (even if you have no comments to post). I support this document as a WG item. gwz> Me, too (though I'd like to point out that that does _not_ mean = that I support its rubberstaming ;-).=20 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: ------_=_NextPart_001_01C7DE9E.963B426D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: REMINDER: RADEXT WG review of = draft-nelson-radius-management-authorization=0A= =0A= =0A=
=0A=
Bernard Aboba wrote:
> The WG review = request =0A= ends on August 16, 2007.  So far we have had only
> person = express =0A= interest - not enough to adopt this document as a WG work
> = item.  =0A= Please post to the list if you support taking this on as a WG
> = work item =0A= (even if you have no comments to post).

  I support this = document as =0A= a WG item.
=0A=
gwz> = Me, too (though =0A= I'd like to point out that that does _not_ mean that I support its = rubberstaming =0A= ;-).=0A=


  Alan DeKok.

--
to unsubscribe = send a =0A= message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' = in a =0A= single line as the message text body.
archive: <http://psg.com/lists/radiusext/<= /A>>
=0A= =0A= =0A= ------_=_NextPart_001_01C7DE9E.963B426D-- -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2007 17:59: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: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Date: Tue, 14 Aug 2007 17:40:02 -0000 Message-ID: Thread-Topic: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Thread-Index: AcfegDGEH1gTGROwR8akiLQ0tMTb+QAGXmEg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , I have reviewed this document and believe it should be considered as a WG document. There is significant value in leveraging the AAA framework for management access and as this draft points out there are enhancements required and additional attributes needed to represent and authorize the how devices are managed today. Paul Congdon=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, August 14, 2007 7:32 AM > To: radiusext@ops.ietf.org > Subject: REMINDER: RADEXT WG review of=20 > draft-nelson-radius-management-authorization >=20 > The WG review request ends on August 16, 2007. So far we=20 > have had only person express interest - not enough to adopt=20 > this document as a WG work item. Please post to the list if=20 > you support taking this on as a WG work item (even if you=20 > have no comments to post). >=20 >=20 > >From: "Wijnen, Bert (Bert)" > >To: , > >CC: , "Bernard Aboba"=20 > > > >Subject: RE: [Isms] [bernard_aboba@hotmail.com: Review o=20 > >fdraft-nelson-radius-management-authorization-05.txt] > >Date: Tue, 14 Aug 2007 11:35:43 +0200 > > > >Some nits: > > > >Sect 4 > > > > The local application of the Management-Policy-Id within=20 > the managed > > entity may take the form of (a) one of an enumeration of command > > privilege levels, (b) a mapping into an SNMP View Based Access > > Control Method (VACM) table [RFC3415], or (c) some other set of > > > >Did you intend to writhe "Method", or do you mean "Model"? > >VACM stands for View Based Access Control Model in the SNMP context. > > > >Sect 7.3 > > The Text field is one or more octets, and its contents are > > implementation dependent. It is intended to be human=20 > readable and > > MUST NOT affect operation of the protocol. It is=20 > recommended that > > the message contain UTF-8 encoded 10646 [RFC2279] characters. > > > >The latest RFC for UTF-8 is RFC3629. > >I guess it is better reference that one. > > > >I can support this work item as a topic for the RADEXT WG. > >Not sure how much I can contribute though, but I will try to review=20 > >revisions of the document > > > >Bert Wijnen >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Aug 2007 16:44:41 +0000 Message-ID: <46C1DBD3.7050107@deployingradius.com> Date: Tue, 14 Aug 2007 12:44:03 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > The WG review request ends on August 16, 2007. So far we have had only > person express interest - not enough to adopt this document as a WG work > item. Please post to the list if you support taking this on as a WG > work item (even if you have no comments to post). I support this document as a WG item. 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, 14 Aug 2007 15:25:51 +0000 From: "David B. Nelson" To: Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Date: Tue, 14 Aug 2007 11:25:53 -0400 Organization: Elbrys Networks, Inc. Message-ID: <007501c7de87$67440250$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfegG7VasSLTHGJRty1ameu2f9k/AABG4VQ Bernard Aboba writes... > The WG review request ends on August 16, 2007. Thanks for issuing the reminder. I didn't previously see this post, as it went to my previous employment address, and apparently not to the RADEXT list. I'll comment in-line, below. Bert Wijnen writes... > >Sect 4 > > > > The local application of the Management-Policy-Id within the managed > > entity may take the form of (a) one of an enumeration of command > > privilege levels, (b) a mapping into an SNMP View Based Access > > Control Method (VACM) table [RFC3415], or (c) some other set of > > > >Did you intend to writhe "Method", or do you mean "Model"? > >VACM stands for View Based Access Control Model in the SNMP context. Yes, "Model" was the intended word. Thanks, we'll fix that. > >Sect 7.3 > > The Text field is one or more octets, and its contents are > > implementation dependent. It is intended to be human readable and > > MUST NOT affect operation of the protocol. It is recommended that > > the message contain UTF-8 encoded 10646 [RFC2279] characters. > > > >The latest RFC for UTF-8 is RFC3629. > >I guess it is better reference that one. Good catch. We'll fix that one, too. > >I can support this work item as a topic for the RADEXT WG. > >Not sure how much I can contribute though, but I will try to > >review revisions of the document Thanks. Obviously, as an author, I support this work being adopted as a RADEXT WG work item, for what little that opinion may be worth. For those who may not yet have reviewed this draft, or those who have not reviewed a recent version, let me recap its purpose. This draft adds a couple of new attributes and a new value for an existing attribute to allow provisioning of management access authorization beyond the existing two-level authorization for access to the CLI of the NAS. The type of additional authorization supported includes specific authorization for management access methods and protocols other than CLI, such as SNMP, or HTTP. It also provides for more granular access levels than privileged and non-privileged. Many NASes in wide use today have multiple levels of management access permissions. This draft provides a standardized way to provision such access. Much of the body of RADIUS work is about provisioning securely authorized access to network resources, through the services of a NAS. This work is about provisioning securely authorized access to the management interfaces of the NAS itself, as part of an overall network infrastructure security solution. All of the attributes and value introduced in this draft can be implemented as new entries in the attribute dictionary of a dictionary driven RADIUS server implementation. -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2007 15:16:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Review of draft-nelson-radius-management-authorization-05.txt Date: Tue, 14 Aug 2007 15:13:01 -0000 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_007E_01C7DE5B.B22C8200" Message-ID: <2F2D38A4B8346F48A683750A46BAB21101EE2EC3@G3W0072.americas.hpqcorp.net> Thread-Topic: Review of draft-nelson-radius-management-authorization-05.txt Thread-Index: AcfVISQ8Mhd7tbM4RWmAoQFMXA/o4wJZBp9Q From: "Sanchez, Mauricio (ProCurve)" To: "Bernard Aboba" , This is a multipart message in MIME format. ------=_NextPart_000_007E_01C7DE5B.B22C8200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support this work and would like to see it become an official WG item. MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner- > radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, August 02, 2007 11:20 AM > To: radiusext@ops.ietf.org > Subject: Review of draft-nelson-radius-management-authorization-05.txt > > The ISMS WG has requested that RADEXT WG take on "Remote Authentication > Dial-In User Service (RADIUS) Authorization for Network Access Server > (NAS) > Management" as a WG work item. > > In response to this request, we are requesting reviews of the document, > which is found here: > http://www.ietf.org/internet-drafts/draft-nelson-radius-management- > authorization-05.txt > > The request for review will last until August 16, 2007. Please > indicate > whether you would like this document to be taken on as a WG work item. > Please respond even if you have no issues with the document; if you > have > comments, please send the issues to the RADEXT WG mailing list in the > format > provided on here: > http://www.drizzle.com/~aboba/RADEXT/ > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_007E_01C7DE5B.B22C8200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh2K9TSN0bRHs7 wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAIC20 InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLSzZW6NF4K3fkq NjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cYB0G8dY+vGp77 WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDgxNDE1MTMwMVowIwYJ KoZIhvcNAQkEMRYEFBNC120hPfn0mLjAWM7ThCnMcBy0MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgFQbbRXem2HBVVFCfePcjGmGOR0HRdP5oiAevMBaCrK2q9qqjZinf+Q9rN0a0H8N 9T5YdA3Qu8aiPKdYULu5u5320RmWkZRzge/fFdwl2b00m0aR2uRVQjJRkCaV1sH6aw1k7STdfsCU mZLQiuCT6dw8ZuMO2K3GdZEvXOp+0R7NAAAAAAAA ------=_NextPart_000_007E_01C7DE5B.B22C8200-- -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2007 14:32:27 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization Date: Tue, 14 Aug 2007 07:31:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The WG review request ends on August 16, 2007. So far we have had only person express interest - not enough to adopt this document as a WG work item. Please post to the list if you support taking this on as a WG work item (even if you have no comments to post). >From: "Wijnen, Bert (Bert)" >To: , >CC: , "Bernard Aboba" > >Subject: RE: [Isms] [bernard_aboba@hotmail.com: Review o >fdraft-nelson-radius-management-authorization-05.txt] >Date: Tue, 14 Aug 2007 11:35:43 +0200 > >Some nits: > >Sect 4 > > The local application of the Management-Policy-Id within the managed > entity may take the form of (a) one of an enumeration of command > privilege levels, (b) a mapping into an SNMP View Based Access > Control Method (VACM) table [RFC3415], or (c) some other set of > >Did you intend to writhe "Method", or do you mean "Model"? >VACM stands for View Based Access Control Model in the SNMP context. > >Sect 7.3 > The Text field is one or more octets, and its contents are > implementation dependent. It is intended to be human readable and > MUST NOT affect operation of the protocol. It is recommended that > the message contain UTF-8 encoded 10646 [RFC2279] characters. > >The latest RFC for UTF-8 is RFC3629. >I guess it is better reference that one. > >I can support this work item as a topic for the RADEXT WG. >Not sure how much I can contribute though, but I will try to review >revisions of the document > >Bert Wijnen -- to unsubscribe send a message to radiusext-request@ops.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, 12 Aug 2007 13:33:17 +0000 Message-ID: <46BF0BDB.9080702@deployingradius.com> Date: Sun, 12 Aug 2007 09:32:11 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: Leif Johansson , "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Harkins wrote: > Each RADIUS client MUST go through the step of obtaining the certificate > of the certification authority and affirmatively trusting it before it is > used to authenticate the TLS exchange. In the BOF that started RADEXT, I presented a "client kickstart" draft, co-authored with Robert Moskowitz. It's functionally equivalent to (D)TLS + DNS lookups to find the server, along with fingerprint validation. > There is a dangerous attraction to (D)TLS because people can do server- > side authentication only and base that on a self-signed certificate-- > they typically say something along the lines of "just click when > asked if you want to proceed!". They think that since they're using TLS > then everything is secure when, in fact, their deployment is patently > insecure. "Just use IPSec!" The issue that (D)TLS solves is one of mind-share. Administrators are familiar with TLS, and with the tools to deploy a TLS-based infrastructure. > This sort of provisioning is something that people who manage > RADIUS servers have done before since it's how the current RADIUS secret > is provisioned. Asking administrators to install a certificate in a > trusted store on every RADIUS client, in addition to asking them to install > a username and password, might be alot to ask. Would demanding that they > deploy a PKI and assign a certificate and private key to every RADIUS > client be too much to ask? For new deployments, it's possible. Existing ones are often beyond hope. 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: Sat, 11 Aug 2007 19:09:06 +0000 Message-ID: <46BE092D.6010505@it.su.se> Date: Sat, 11 Aug 2007 21:08:29 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: dharkins@lounge.org, d.b.nelson@comcast.net, radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> You can use x509 as a key-only mechanism too. Just configure >> each radius endpoint with a self-signed cert and use the (say) >> fingerprint to express trust. That is equivalent (in terms of >> the work involved) to a shared-secret database and can be >> automated (in tools) almost the same way. > > Is this something that current RADSEC implementations support? > > > I can't be absolutely sure but since openssl has hooks for certificate validation it would be a no-brainer to put it in. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2007 18:30:04 +0000 Message-ID: From: "Bernard Aboba" To: leifj@it.su.se, dharkins@lounge.org Cc: d.b.nelson@comcast.net, radiusext@ops.ietf.org Bcc: Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Sat, 11 Aug 2007 11:29:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >You can use x509 as a key-only mechanism too. Just configure >each radius endpoint with a self-signed cert and use the (say) >fingerprint to express trust. That is equivalent (in terms of >the work involved) to a shared-secret database and can be >automated (in tools) almost the same way. Is this something that current RADSEC implementations support? -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2007 08:59:25 +0000 Message-ID: <46BD7A6C.2000508@it.su.se> Date: Sat, 11 Aug 2007 10:59:24 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > Using (D)TLS does not absolve you of the requirement to have some > sort of credential on the client. To be secure you MUST enroll every > RADIUS client in a certification authority and install the server's > certificate in a trusted store. In addition you need to provision some > client-side credential, either a username and password or a certificate > and private key. > Correct. My point was that people know how to do that and that these steps need to be defined and well understood för keywrap. > Each RADIUS client MUST go through the step of obtaining the certificate > of the certification authority and affirmatively trusting it before it is > used to authenticate the TLS exchange. Now I happen to believe that PKI is > not that big of a deal. But the continued existence of this working group > underscores the fact that such a belief is a minority one. People are > much more comfortable with massive secret key databases than with PKI. > You can use x509 as a key-only mechanism too. Just configure each radius endpoint with a self-signed cert and use the (say) fingerprint to express trust. That is equivalent (in terms of the work involved) to a shared-secret database and can be automated (in tools) almost the same way. > There is a dangerous attraction to (D)TLS because people can do server- > side authentication only and base that on a self-signed certificate-- > they typically say something along the lines of "just click when > asked if you want to proceed!". They think that since they're using TLS > then everything is secure when, in fact, their deployment is patently > insecure. > Not unless you "click ok" by manually configuring the trust. This gives you the crypto agility of tls with almost no extra complexity from TLS. > The keywrap draft defines 2 new keys, one for wrapping the key and > another for integrity verification of the entire message. (Note that using > a different algorithm as "enc-type" could obviate the need for the second > one). This sort of provisioning is something that people who manage > RADIUS servers have done before since it's how the current RADIUS secret > is provisioned. Asking administrators to install a certificate in a > trusted store on every RADIUS client, in addition to asking them to install > a username and password, might be alot to ask. Would demanding that they > deploy a PKI and assign a certificate and private key to every RADIUS > client be too much to ask? > Sure but they don't have to :-) Also deployments of EAP-TLS already perform these steps today. Cheers Leif > Dan. > > > > -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2007 08:53:09 +0000 Message-ID: <46BD78CB.9000502@it.su.se> Date: Sat, 11 Aug 2007 10:52:27 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: Stefan Winter , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: [Re: Continued discussion of RADIUS Crypto-Agility] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > It's the ciphersuite in TLS provides the crypto-agility. Similarly > the "enc-type" in the keywrap draft provides the crypto-agility. One > value of "enc-type" is for RFC3394 style AES Keywrap. A different value > could define RFC3217-style 3DES or RC2 keywrapping. There are many nice > things about AES though that make something like SIV-AES style keywrapping > even more appealing that RFC3394. > > > Yes you're right, I missed this when reading the draft. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2007 00:37:54 +0000 Message-ID: <47211.69.12.173.8.1186792642.squirrel@www.trepanning.net> Date: Fri, 10 Aug 2007 17:37:22 -0700 (PDT) Subject: Re: Continued discussion of RADIUS Crypto-Agility From: "Dan Harkins" To: "Leif Johansson" Cc: "David B. Nelson" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Leif, On Fri, August 10, 2007 6:07 am, Leif Johansson wrote: > >> Glen has explained to us why he thinks that TLS is excluded on >> procedural >> grounds (charter exclusion). I haven't heard much debate about the >> relative >> merits of an internal vs. external solution. >> >> >> > I've tried to argue that I favor TLS/DTLS on the grounds that > the work required can be done by radius experts which there > are lots of in this wg as opposed to the aes-keywrap draft which > requires work by security protocol experts (to specify > how to do key agreement etc) of which there are few in this wg. Using (D)TLS does not absolve you of the requirement to have some sort of credential on the client. To be secure you MUST enroll every RADIUS client in a certification authority and install the server's certificate in a trusted store. In addition you need to provision some client-side credential, either a username and password or a certificate and private key. Each RADIUS client MUST go through the step of obtaining the certificate of the certification authority and affirmatively trusting it before it is used to authenticate the TLS exchange. Now I happen to believe that PKI is not that big of a deal. But the continued existence of this working group underscores the fact that such a belief is a minority one. People are much more comfortable with massive secret key databases than with PKI. There is a dangerous attraction to (D)TLS because people can do server- side authentication only and base that on a self-signed certificate-- they typically say something along the lines of "just click when asked if you want to proceed!". They think that since they're using TLS then everything is secure when, in fact, their deployment is patently insecure. The keywrap draft defines 2 new keys, one for wrapping the key and another for integrity verification of the entire message. (Note that using a different algorithm as "enc-type" could obviate the need for the second one). This sort of provisioning is something that people who manage RADIUS servers have done before since it's how the current RADIUS secret is provisioned. Asking administrators to install a certificate in a trusted store on every RADIUS client, in addition to asking them to install a username and password, might be alot to ask. Would demanding that they deploy a PKI and assign a certificate and private key to every RADIUS client be too much to ask? Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2007 00:14:58 +0000 Message-ID: <38370.69.12.173.8.1186791242.squirrel@www.trepanning.net> Date: Fri, 10 Aug 2007 17:14:02 -0700 (PDT) Subject: Re: [Re: Continued discussion of RADIUS Crypto-Agility] From: "Dan Harkins" To: "Leif Johansson" Cc: "Dan Harkins" , "Stefan Winter" , "Bernard Aboba" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Leif, On Fri, August 10, 2007 12:47 am, Leif Johansson wrote: > Dan Harkins wrote: >> Hello, >> >> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: >> [snip] >> >>> There are two fundamental ways to address this problem: reference >>> some work or roll your own. Radius+DTLS and RadSec fall into the >>> first category, keywrap falls into the second category. >>> >> >> I have to disagree. Keywrap is not "roll your own". It uses RFC3394 >> which itself describes a NIST specification of a mode of AES that came >> out of a draft standard from X9.102. It has received extensive vetting. >> The authors of the keywrap draft are proposing to use an existing >> standard to solve the problem it was created to solve-- >> cryptographically >> protecting keying material in transit. >> >> Dan. >> >> > Another thing that bothers me is the direct reference to AES. > > Introducing a dependency on any one algorithm does not > constitute agility in any sense of the word. The point (imho) is > not to demonstrate how much we trust AES today but to make > sure radius doesn't have to go through this again when AES > needs replacing. > > Cheers Leif It's the ciphersuite in TLS provides the crypto-agility. Similarly the "enc-type" in the keywrap draft provides the crypto-agility. One value of "enc-type" is for RFC3394 style AES Keywrap. A different value could define RFC3217-style 3DES or RC2 keywrapping. There are many nice things about AES though that make something like SIV-AES style keywrapping even more appealing that RFC3394. Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 21:34:09 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Fri, 10 Aug 2007 14:33:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Glen has explained to us why he thinks that TLS is excluded on procedural >grounds (charter exclusion). I haven't heard much debate about the >relative >merits of an internal vs. external solution. I am not sure that internal vs. external is the right point of comparison. To me the issue comes down to static vs. dynamic keying. To my mind, there are some major negatives associated with an approach that depends on static keying, whether it is internal or external. These involve both management issues as well as security concerns. >From a management perspective, the existing RADIUS shared-secret mechanism already seems to be more than many deployments can handle. We now have many deployments with hundreds or thousands of NASes, and in these situations, allocating a different shared secret for each NAS-RADIUS server pair is difficult to manage. As a result, in many cases, a single RADIUS shared secret is used, and this not only creates domino effect vulnerabilities, but negates many of the security guarantees that RADIUS is required to provide in key management applications. When combined with l ack of client or server conformance to the RFC 2865 recommendations on shared secret length, use of a single shared secret creates a vulnerability to offline dictionary attack. This is not an issue that crypto-agility by itself can address. On the other hand, with dynamic keying, it is possible to have some confidence that the keys used to protect traffic between NAS-RADIUS server pairs are unique and fresh, and are not susceptible to offline dictionary attack. Of course, a vulnerability to offline dictionary attack may still exist if the dynamic keys are themselves derived based on pre-shared keys (e.g. IKE or TLS pre-shared key authentication modes). If certificates are used instead of pre-shared keys, then the result is a substantial increase in footprint and certificate management issues on the NAS. The end result of this is that static keying, while probably more easily deployed than dynamic keying, will probably not improve RADIUS secruity substantially in the long-term, given existing practice. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 21:12:57 +0000 Message-ID: From: "Bernard Aboba" To: leifj@it.su.se, dharkins@lounge.org Cc: stefan.winter@restena.lu, radiusext@ops.ietf.org Bcc: Subject: RE: [Re: Continued discussion of RADIUS Crypto-Agility] Date: Fri, 10 Aug 2007 14:11:52 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Another thing that bothers me is the direct reference to AES. > >Introducing a dependency on any one algorithm does not >constitute agility in any sense of the word. The point (imho) is >not to demonstrate how much we trust AES today but to make >sure radius doesn't have to go through this again when AES >needs replacing. It is fine (required, really) to specify and reference a mandatory-to-implement algorithm for each usage. This includes not only keywrap but also the MIC. However, it should also be possible to negotiate alternative algorithms. That requires a mechanism negotiate algorithms, as well as IANA considerations to allocate code points to additional algorithms beyond those specified in the document. Are you saying that any of these things is missing from the document? -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 13:28:16 +0000 Message-ID: <46BC67BF.1040700@deployingradius.com> Date: Fri, 10 Aug 2007 09:27:27 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Glen has explained to us why he thinks that TLS is excluded on procedural > grounds (charter exclusion). I haven't heard much debate about the relative > merits of an internal vs. external solution. An internal solution involves changing the internal RADIUS implementation of servers and clients. An external solution involves encapsulating RADIUS as-is in another transport stream. Having spent time poking the internals of RADIUS servers and clients, I would prefer to avoid doing more of that. Many RADIUS implementations are fragile. Changing them, or trying to inter-operate with them is problematic. If we leverage (D)TLS, we gain the interoperability tests done for every other protocol (HTTP, SIP, etc.). We gain the momentum behind security fixes to implementations or protocol designs. An internal implementation involves yet another RADIUS-specific thing. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Aug 2007 13:07:56 +0000 Message-ID: <46BC6324.10209@it.su.se> Date: Fri, 10 Aug 2007 15:07:48 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Glen has explained to us why he thinks that TLS is excluded on procedural > grounds (charter exclusion). I haven't heard much debate about the relative > merits of an internal vs. external solution. > > > I've tried to argue that I favor TLS/DTLS on the grounds that the work required can be done by radius experts which there are lots of in this wg as opposed to the aes-keywrap draft which requires work by security protocol experts (to specify how to do key agreement etc) of which there are few in this wg. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 12:22:51 +0000 From: "David B. Nelson" To: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Fri, 10 Aug 2007 08:22:31 -0400 Message-ID: <004901c7db49$20379e80$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcfbFBKGJphxpA3rQ965xp0haG1bRgAM37lw Stefan Winter writes... > The point I tried to make was that the *security properties* > of a protocol can be made mostly independent of the layer 4 > transport. I agree. It seems to me that the decision tree for the RADEXT crypto-agility work would be something like: Internal security or external security? (Internal means defined within the application layer PDUs.) If internal, then keywrap & encrypted attributes or something else yet to be offered. If external, then DTLS or TLS? (Or something else yet to be offered.) I think it would help the discussion to debate the pros and cons of these choices. Glen has explained to us why he thinks that TLS is excluded on procedural grounds (charter exclusion). I haven't heard much debate about the relative merits of an internal vs. external solution. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 12:11:35 +0000 From: "David B. Nelson" To: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Fri, 10 Aug 2007 08:10:55 -0400 Message-ID: <004501c7db47$814915c0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcfbIv39ab+oSaIlS4eh2Hzh5AfjCgAI4O3w Leif Johansson writes... > Another thing that bothers me is the direct reference to AES. > > Introducing a dependency on any one algorithm does not > constitute agility in any sense of the word. The point (imho) is > not to demonstrate how much we trust AES today but to make > sure radius doesn't have to go through this again when AES > needs replacing. The keywrap draft was originally created for the purpose of obtaining FIPS-140 certification of an 802.11 WLAN solution. It pre-dates the RADEXT crypto-agility effort. The fact that it contains cipher-suite identifiers means that it can be considered in the more general sense for crypto-agility. As I said in my last post in this thread, we really need to consider the encrypted attributes draft together with the keywrap draft to meet the RADEXT crypto-agility requirements. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 07:47:37 +0000 Message-ID: <46BC1801.20508@it.su.se> Date: Fri, 10 Aug 2007 09:47:13 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: Stefan Winter , Bernard Aboba , radiusext@ops.ietf.org Subject: [Re: Continued discussion of RADIUS Crypto-Agility] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Harkins wrote: > Hello, > > On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: > [snip] > >> There are two fundamental ways to address this problem: reference >> some work or roll your own. Radius+DTLS and RadSec fall into the >> first category, keywrap falls into the second category. >> > > I have to disagree. Keywrap is not "roll your own". It uses RFC3394 > which itself describes a NIST specification of a mode of AES that came > out of a draft standard from X9.102. It has received extensive vetting. > The authors of the keywrap draft are proposing to use an existing > standard to solve the problem it was created to solve-- cryptographically > protecting keying material in transit. > > Dan. > > Another thing that bothers me is the direct reference to AES. Introducing a dependency on any one algorithm does not constitute agility in any sense of the word. The point (imho) is not to demonstrate how much we trust AES today but to make sure radius doesn't have to go through this again when AES needs replacing. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 06:00:48 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn \(gwz\)" Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Fri, 10 Aug 2007 08:00:25 +0200 User-Agent: KMail/1.9.7 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1276520.SQbAxGchIF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708100800.29887.stefan.winter@restena.lu> --nextPart1276520.SQbAxGchIF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, >> The impact of connectionless vs. connection is not very significant when >> discussing the protocol's *security*, IMO. > > So I gather that as far as you're concerned a network "protocol" solely > consistes of the format of the innermost PDU? No. The point I tried to make was that the *security properties* of a proto= col=20 can be made mostly independent of the layer 4 transport. That's why I put=20 *security* in *bold*. That's what I thought this thread was supposed to be= =20 about. I am not trying to argue that connectionless and connection-oriented= =20 transports are the same thing (what a fool would I be). TLS and DTLS are a good example in that respect: they deliver very similar,= =20 maybe even identical (I don't dare judge on that), security properties even= =20 though one is using a connection-oriented, the other one a connectionless=20 transport layer. >> Well, it's _almost_ RADIUS, especially if one takes into account the >> mechanisms in RADIUS to detect duplication, retransmission etc, which >> already contains parts of the merits of TCP. > > By that logic, a cobra is _almost_ a pidgeon. [...] > Only if snakes are almost birds... You lost me here. I thought I had provided some *arguments* that show the=20 similarities between RADIUS+DTLS and RadSec. Instead of countering that wit= h=20 reason, you counter it by throwing strange anatomical claims at me (which y= ou=20 don't bother to further explain - but I guess that's for the better since i= t=20 is largely OT anyway). Forgive me if I ignore that part of your post. Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart1276520.SQbAxGchIF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGu/79+jm90f8eFWYRAtoZAJ4zeH3Y18vJxt4k09msSEcWG5IxQACfWsNZ YksbAxPN3rzLZBnDRXcITic= =GcaR -----END PGP SIGNATURE----- --nextPart1276520.SQbAxGchIF-- -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 05:40:55 +0000 Message-ID: <46BBFA67.2070300@it.su.se> Date: Fri, 10 Aug 2007 07:40:55 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: Stefan Winter , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > No, and no. RFC3394 is a _use of_ AES. A specific use. It's to solve the > problem of transmitting keying material over an untrusted network. And > that is _exactly_ the problem the keywrap draft is solving. > > One thing the IETF does well (in addition to apparently referencing > existing crypto) is take work from outside the IETF and document it in > RFCs. TLS is a perfect example. So is RFC3394. Neither one is "roll your > own" and neither is a proposal to use one of them. > > Dan. > > > Yes I was unclear in my comment, sorry. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 05:40:02 +0000 Message-ID: <46BBFA0C.9090302@it.su.se> Date: Fri, 10 Aug 2007 07:39:24 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Leif Johansson writes... > > >> That is absolutely "roll your own" - RFC3394 is AES which is >> crypto not a security protocol. >> > > No. RFC 3394 is "Advanced Encryption Standard (AES) Key Wrap Algorithm". > That's not simply a definition of AES (crypto), which is normatively defined > in FIPS-197. It's a specific application of crypto for key wrapping. It is > not a key agreement, key distribution or key management protocol, of course. > > > Sorry I was not clear enough. What I meant to say is that in order to deploy radius+keywrap you actually need all of those things and they are (relatively) well understood in tls. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2007 00:30:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DAE5.92E11188" Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Thu, 9 Aug 2007 17:29:54 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C8A9BB@xmb-sjc-215.amer.cisco.com> Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfajZB1FqDnroJ0S0icaJtAZWJFfAAVo4zl From: "Glen Zorn \(gwz\)" To: "Stefan Winter" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4267; t=1186705797; x=1187569797; 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=20Continued=20discussion=20of=20RADIUS=20Crypto-Agility |Sender:=20; bh=II7e3appuRaTyStOaIZDRMnoO6UCIIX0yVS5Vkt5Db4=; b=db2iNyrEqZY31JzcQrs37KcY8xoTHA5o2u7afo4aiCVxIoIp/MfTAmF3k4r4zQMCs430N932 Yi1UpyNUG3p/sc4cM0iijlMMtqh42pCsst/cR/QFiQzDjKAXd7PX7bVQ; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DAE5.92E11188 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > Well, except that in order to place these things in a common category = it > is necessary to ignore one of the defining characteristics of RADIUS: > that it is only and intentionally defined as a connectionless = protocol. The impact of connectionless vs. connection is not very significant when discussing the protocol's *security*, IMO. So I gather that as far as you're concerned a network "protocol" solely = consistes of the format of the innermost PDU?=20 > might like to believe so, RadSec is _not_ RADIUS, Well, it's _almost_ RADIUS, especially if one takes into account the mechanisms in RADIUS to detect duplication, retransmission etc, which = already contains parts of the merits of TCP. By that logic, a cobra is _almost_ a pidgeon. > & therefore far out of > scope of not just the crypto-agility discussions but of this WG. > RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & > therefore _is_ in scope. I have understood that DTLS is considered in scope, while RadSec is out = of scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS itself requires even more characteristics of TCP, so when combining the RADIUS mechanisms that come on top of UDP + the transport mechanisms in = DTLS, the end result is getting very close to TCP already. So the distance = between in-scope and out-of-scope is a very thin line. Only if snakes are almost birds... ... ------_=_NextPart_001_01C7DAE5.92E11188 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: Continued discussion of RADIUS Crypto-Agility=0A= =0A= =0A=
=0A=
Hi,

> Well, except that in order = to place =0A= these things in a common category it
> is necessary to ignore one = of the =0A= defining characteristics of RADIUS:
> that it is only and = intentionally =0A= defined as a connectionless protocol.

The impact of = connectionless vs. =0A= connection is not very significant when
discussing the protocol's = *security*, =0A= IMO.
=0A=
So I = gather that as far =0A= as you're concerned a network "protocol" solely consistes of the format = of the =0A= innermost PDU? 

> might like to believe so, RadSec = is =0A= _not_ RADIUS,

Well, it's _almost_ RADIUS, especially if one takes = into =0A= account the
mechanisms in RADIUS to detect duplication, = retransmission etc, =0A= which already
contains parts of the merits of TCP.
=0A=
By that = logic, a cobra =0A= is _almost_ a pidgeon.

> & therefore far out = of
> =0A= scope of not just the crypto-agility discussions but of this WG.
> =0A= RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS = &
> =0A= therefore _is_ in scope.

I have understood that DTLS is = considered in =0A= scope, while RadSec is out of
scope (Reminder: I never claimed = otherwise). =0A= Just keep in mind that DTLS
itself requires even more characteristics = of TCP, =0A= so when combining the
RADIUS mechanisms that come on top of UDP + the =0A= transport mechanisms in DTLS,
the end result is getting very close to = TCP =0A= already. So the distance between
in-scope and out-of-scope is a very = thin =0A= line.
=0A=
Only if = snakes are =0A= almost birds...

...
=0A= =0A= =0A= ------_=_NextPart_001_01C7DAE5.92E11188-- -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 22:22:29 +0000 Message-ID: <45872.69.12.173.8.1186698091.squirrel@www.trepanning.net> Date: Thu, 9 Aug 2007 15:21:31 -0700 (PDT) Subject: Re: Continued discussion of RADIUS Crypto-Agility From: "Dan Harkins" To: "Leif Johansson" Cc: "Dan Harkins" , "Stefan Winter" , "Bernard Aboba" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit On Thu, August 9, 2007 1:58 pm, Leif Johansson wrote: > Dan Harkins wrote: >> Hello, >> >> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: >> [snip] >> >>> There are two fundamental ways to address this problem: reference >>> some work or roll your own. Radius+DTLS and RadSec fall into the >>> first category, keywrap falls into the second category. >>> >> >> I have to disagree. Keywrap is not "roll your own". It uses RFC3394 >> > That is absolutely "roll your own" - RFC3394 is AES which is > crypto not a security protocol. Of course no-one in the IETF > is silly enough not to reference existing crypto :-) No, and no. RFC3394 is a _use of_ AES. A specific use. It's to solve the problem of transmitting keying material over an untrusted network. And that is _exactly_ the problem the keywrap draft is solving. One thing the IETF does well (in addition to apparently referencing existing crypto) is take work from outside the IETF and document it in RFCs. TLS is a perfect example. So is RFC3394. Neither one is "roll your own" and neither is a proposal to use one of them. Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 21:10:30 +0000 From: "David B. Nelson" To: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Thu, 9 Aug 2007 17:10:16 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002501c7dac9$af66a590$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcfayJypjYbET7jKT8ed1qgLvyKU6wAAGxTQ Leif Johansson writes... > That is absolutely "roll your own" - RFC3394 is AES which is > crypto not a security protocol. No. RFC 3394 is "Advanced Encryption Standard (AES) Key Wrap Algorithm". That's not simply a definition of AES (crypto), which is normatively defined in FIPS-197. It's a specific application of crypto for key wrapping. It is not a key agreement, key distribution or key management protocol, of course. -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 20:58:52 +0000 Message-ID: <46BB8000.8000909@it.su.se> Date: Thu, 09 Aug 2007 22:58:40 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Dan Harkins CC: Stefan Winter , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Harkins wrote: > Hello, > > On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: > [snip] > >> There are two fundamental ways to address this problem: reference >> some work or roll your own. Radius+DTLS and RadSec fall into the >> first category, keywrap falls into the second category. >> > > I have to disagree. Keywrap is not "roll your own". It uses RFC3394 > That is absolutely "roll your own" - RFC3394 is AES which is crypto not a security protocol. Of course no-one in the IETF is silly enough not to reference existing crypto :-) Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 20:15:09 +0000 From: "David B. Nelson" To: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Thu, 9 Aug 2007 16:14:58 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002401c7dac1$f577a230$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcfawLw8ZdPzv9VRSSGdQmEWDRD9fwAAFhdw Dan Harkins writes ... > On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: > [snip] > > There are two fundamental ways to address this problem: reference > > some work or roll your own. Radius+DTLS and RadSec fall into the > > first category, keywrap falls into the second category. > > I have to disagree. Keywrap is not "roll your own". It uses RFC3394 > which itself describes a NIST specification of a mode of AES that came > out of a draft standard from X9.102. It has received extensive vetting. > The authors of the keywrap draft are proposing to use an existing > standard to solve the problem it was created to solve-- cryptographically > protecting keying material in transit. It would be more accurate to portray the two approaches as (a) wrap all the PDUs in a secure transport vs. (b) protect individual elements in selected PDUs, i.e., external (to the protocol) vs. internal (to the protocol) security. The other fact to keep in mind is that the protection of keying material does not address the complete scope of the RADEXT crypto-agility requirements. You need to consider both the keywrap draft and the encrypted attribute draft. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Aug 2007 20:02:03 +0000 Message-ID: <50522.69.12.173.8.1186689669.squirrel@www.trepanning.net> Date: Thu, 9 Aug 2007 13:01:09 -0700 (PDT) Subject: Re: Continued discussion of RADIUS Crypto-Agility From: "Dan Harkins" To: "Leif Johansson" Cc: "Stefan Winter" , "Bernard Aboba" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, On Wed, August 8, 2007 7:22 am, Leif Johansson wrote: [snip] > There are two fundamental ways to address this problem: reference > some work or roll your own. Radius+DTLS and RadSec fall into the > first category, keywrap falls into the second category. I have to disagree. Keywrap is not "roll your own". It uses RFC3394 which itself describes a NIST specification of a mode of AES that came out of a draft standard from X9.102. It has received extensive vetting. The authors of the keywrap draft are proposing to use an existing standard to solve the problem it was created to solve-- cryptographically protecting keying material in transit. Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 14:47:07 +0000 Message-ID: From: "Bernard Aboba" To: leifj@it.su.se, stefan.winter@restena.lu Cc: gwz@cisco.com, radiusext@ops.ietf.org Bcc: Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Thu, 09 Aug 2007 07:46:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >This sort of thing is problematic for the IETF - narrowly scoped >charters can be a tool for delivering on time but it can also be >a blunt instrument for beating people over the head with. As Dan has noted, the RADEXT WG has been given leeway to include RADSEC in the charter if there is consensus for doing that. -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 14:15:32 +0000 Message-ID: <46BB217D.9030709@it.su.se> Date: Thu, 09 Aug 2007 16:15:25 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stefan Winter CC: "Glen Zorn (gwz)" , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > the end result is getting very close to TCP already. So the distance between > in-scope and out-of-scope is a very thin line. > > This sort of thing is problematic for the IETF - narrowly scoped charters can be a tool for delivering on time but it can also be a blunt instrument for beating people over the head with. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 14:00:41 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn \(gwz\)" , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Thu, 9 Aug 2007 15:59:44 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8245323.VinDj1bgLn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708091559.51253.stefan.winter@restena.lu> --nextPart8245323.VinDj1bgLn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > Well, except that in order to place these things in a common category it > is necessary to ignore one of the defining characteristics of RADIUS: > that it is only and intentionally defined as a connectionless protocol. The impact of connectionless vs. connection is not very significant when=20 discussing the protocol's *security*, IMO. > might like to believe so, RadSec is _not_ RADIUS, Well, it's _almost_ RADIUS, especially if one takes into account the=20 mechanisms in RADIUS to detect duplication, retransmission etc, which alrea= dy=20 contains parts of the merits of TCP. > & therefore far out of=20 > scope of not just the crypto-agility discussions but of this WG. > RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & > therefore _is_ in scope. I have understood that DTLS is considered in scope, while RadSec is out of= =20 scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS=20 itself requires even more characteristics of TCP, so when combining the=20 RADIUS mechanisms that come on top of UDP + the transport mechanisms in DTL= S,=20 the end result is getting very close to TCP already. So the distance betwee= n=20 in-scope and out-of-scope is a very thin line. Greetings, Stefan =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart8245323.VinDj1bgLn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGux3X+jm90f8eFWYRAusFAJ9gOAg09qnqkSw+MXaT/d2LpKSeyQCfSWoD uRYVAkKGMfJeRcpIOQVup8Y= =5wAd -----END PGP SIGNATURE----- --nextPart8245323.VinDj1bgLn-- -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 08:14:43 +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: Continued discussion of RADIUS Crypto-Agility Date: Thu, 9 Aug 2007 10:13:27 +0200 Message-ID: Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfaWREWNPvYUN3KTWykl38aKrb0FQAA+hvA From: "Romascanu, Dan (Dan)" To: "Leif Johansson" , "Bernard Aboba" Cc: , =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Leif Johansson > Sent: Thursday, August 09, 2007 10:42 AM > To: Bernard Aboba > Cc: stefan.winter@restena.lu; radiusext@ops.ietf.org > Subject: Re: Continued discussion of RADIUS Crypto-Agility >=20 > Bernard Aboba wrote: > >> The wg should (imho) explicitly state if the issue is=20 > getting rid of=20 > >> MD5 or getting rid of MD5 at the same time as a whole=20 > bunch of other=20 > >> things are done. That will probably make this process go a=20 > whole lot=20 > >> easier. > > > > David has posted the set of requirements that a solution needs to=20 > > meet. Beyond those, the WG can also take into account=20 > other desirable=20 > > security characteristics in making a determination. > > > Draft? There is no I-D if this is what you are asking about, but the requirements were set in the following message from the WG co-chair:=20 https://ops.ietf.org/lists/radiusext/2007/msg00185.html Dan -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 07:42:35 +0000 Message-ID: <46BAC541.2050608@it.su.se> Date: Thu, 09 Aug 2007 09:41:53 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: stefan.winter@restena.lu, radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> The wg should (imho) explicitly state if the issue is getting rid of MD5 >> or getting rid of MD5 at the same time as a whole bunch of other >> things are done. That will probably make this process go a whole lot >> easier. > > David has posted the set of requirements that a solution needs to > meet. Beyond those, the WG can also take into account other desirable > security characteristics in making a determination. > Draft? > However, in doing so, I would warn against feature creep. RADIUS has > succeeded largely because of its simplicity and modest footprint. So > the goal is to address the crypto-agility issue with a minimum of > unrelated changes. > Very wise. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 09 Aug 2007 00:12:59 +0000 Message-ID: From: "Bernard Aboba" To: leifj@it.su.se, stefan.winter@restena.lu Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Wed, 08 Aug 2007 17:12:03 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >The wg should (imho) explicitly state if the issue is getting rid of MD5 >or getting rid of MD5 at the same time as a whole bunch of other >things are done. That will probably make this process go a whole lot >easier. David has posted the set of requirements that a solution needs to meet. Beyond those, the WG can also take into account other desirable security characteristics in making a determination. However, in doing so, I would warn against feature creep. RADIUS has succeeded largely because of its simplicity and modest footprint. So the goal is to address the crypto-agility issue with a minimum of unrelated changes. -- to unsubscribe send a message to radiusext-request@ops.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, 08 Aug 2007 20:53:48 +0000 Message-ID: <46BA2D3D.8060807@it.su.se> Date: Wed, 08 Aug 2007 22:53:17 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Stefan Winter , Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn (gwz) wrote: > Stefan Winter <> allegedly scribbled on Wednesday, August 08, 2007 5:06 > AM: > > >> Hello, >> >> >>> We can certainly entertain a discussion of whether RADSEC is >>> appropriate as a RADEXT WG work item. However, I am not entirely >>> clear that this question is relevant to the current crypto-agility >>> discussion (although I'm certainly willing to be convinced >>> otherwise). >>> >> I agree that it is not relevant for crypto-agility discussions. As I >> see it, DTLS and RadSec fall under a common category in this respect: >> whole packet encryption, with encryption negotiation happening >> outside of RADIUS. >> > > Well, except that in order to place these things in a common category it > is necessary to ignore one of the defining characteristics of RADIUS: > that it is only and intentionally defined as a connectionless protocol. > > A situation not unlike SIP btw which also started as a UDP-based protocol but which had to evolve in the face of among other things the requirement to protect the transport in the absence of deployable s/mime. Sure SIP could have rolled an in-band security layer but that would not have helped an already complex protocol. In-band authentication combined with channel-bindings to a lower security layer is imo a much simpler and cleaner solution for most protocols. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 08 Aug 2007 16:43:37 +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: Continued discussion of RADIUS Crypto-Agility Date: Wed, 8 Aug 2007 09:42:32 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C3BAD3@xmb-sjc-215.amer.cisco.com> Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfZtJ3yr5V5a0OVReicgDodZP9cQAAJNZIg From: "Glen Zorn \(gwz\)" To: "Stefan Winter" , "Bernard Aboba" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1838; t=1186591373; x=1187455373; 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=20Continued=20discussion=20of=20RADIUS=20Crypto-Agility |Sender:=20; bh=shkizPO3yl0kyQISBnX38DnruTeTYd6YQB3Y5QRf2Jo=; b=hnatjqFZ1FtNbUfZybFa/GBadFYp1wqFRKR1wGDS6Dc+HEv27wzyykGlJR66gougfV9qT3Te DS7tuiJBPYCI4FEgjVk3YK1sq/TUnkQmOkfDcVSiBhcsf0muv87umgeDgUjhXwm/DPuzBKNm0m TnAHfSsSqPlw4I13sUgTgPer4=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Stefan Winter <> allegedly scribbled on Wednesday, August 08, 2007 5:06 AM: > Hello, >=20 >> We can certainly entertain a discussion of whether RADSEC is >> appropriate as a RADEXT WG work item. However, I am not entirely >> clear that this question is relevant to the current crypto-agility >> discussion (although I'm certainly willing to be convinced >> otherwise).=20 >=20 > I agree that it is not relevant for crypto-agility discussions. As I > see it, DTLS and RadSec fall under a common category in this respect: > whole packet encryption, with encryption negotiation happening > outside of RADIUS. =20 Well, except that in order to place these things in a common category it is necessary to ignore one of the defining characteristics of RADIUS: that it is only and intentionally defined as a connectionless protocol. This is not an accidental result of the transport choice as you seem to imply below ("{some transport}+{the equivalent of TLS for that transport}"), but a fundamental quality of RADIUS itself. Much as you might like to believe so, RadSec is _not_ RADIUS, & therefore far out of scope of not just the crypto-agility discussions but of this WG. RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS & therefore _is_ in scope. > Basically everything that falls under {some transport}+{the > equivalent of TLS for that transport} would fall into this same class > (i.e. also yet-exotic combinations like DCCP+DTLS or SCTP+TLS would > be covered). keywrap represents a second, fundamentally different > class: per-attribute encryption, with encryption negotiation > happening inside the packet. I guess discussions re the general > crypto-agility problem could focus on discussing those two classes of > approach. =20 >=20 > Greetings, >=20 > Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.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, 08 Aug 2007 14:23:19 +0000 Message-ID: <46B9D1BC.1090108@it.su.se> Date: Wed, 08 Aug 2007 16:22:52 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stefan Winter CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Continued discussion of RADIUS Crypto-Agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > Hello, > > >> We can certainly entertain a discussion of whether RADSEC is appropriate as >> a RADEXT WG work item. However, I am not entirely clear that this question >> is relevant to the current crypto-agility discussion (although I'm >> certainly willing to be convinced otherwise). >> > > I agree that it is not relevant for crypto-agility discussions. As I see it, > I have to disagree. The purpose of the IESG crypto-agility "challenge" is to get rid of hard dependencies on vulnerable mechanisms, notably MD5 and to make sure that the current situation wrt to these mechs don't arise again in the future. There are two fundamental ways to address this problem: reference some work or roll your own. Radius+DTLS and RadSec fall into the first category, keywrap falls into the second category. There is no doubt that these 3 proposals aren't created equal and sort differently depending on what problems _besides_ crypto and hash agility you may want to solve at the same time but they clearly all solve the basic problem of crypto and hash agility. The wg should (imho) explicitly state if the issue is getting rid of MD5 or getting rid of MD5 at the same time as a whole bunch of other things are done. That will probably make this process go a whole lot easier. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 08 Aug 2007 12:06:45 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Bernard Aboba" Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Wed, 8 Aug 2007 14:05:35 +0200 User-Agent: KMail/1.9.7 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1294329.xytfafCASa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708081405.38669.stefan.winter@restena.lu> --nextPart1294329.xytfafCASa Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, > We can certainly entertain a discussion of whether RADSEC is appropriate = as > a RADEXT WG work item. However, I am not entirely clear that this questi= on > is relevant to the current crypto-agility discussion (although I'm > certainly willing to be convinced otherwise). I agree that it is not relevant for crypto-agility discussions. As I see it= ,=20 DTLS and RadSec fall under a common category in this respect: whole packet= =20 encryption, with encryption negotiation happening outside of RADIUS.=20 Basically everything that falls under {some transport}+{the equivalent of T= LS=20 for that transport} would fall into this same class (i.e. also yet-exotic=20 combinations like DCCP+DTLS or SCTP+TLS would be covered). keywrap represen= ts=20 a second, fundamentally different class: per-attribute encryption, with=20 encryption negotiation happening inside the packet. I guess discussions re the general crypto-agility problem could focus on=20 discussing those two classes of approach. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na= tionale et de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.: =C2=A0 =C2=A0+352 424= 409-1 http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax= : =C2=A0 =C2=A0 =C2=A0+352 422473 --nextPart1294329.xytfafCASa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGubGS+jm90f8eFWYRAgIFAJsEGjG003T/VtrbgBvvLYnMXluckwCdFlJr +kKHs3u32tuaFpOzdeteHPk= =gI7g -----END PGP SIGNATURE----- --nextPart1294329.xytfafCASa-- -- to unsubscribe send a message to radiusext-request@ops.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, 04 Aug 2007 20:24:29 +0000 Message-ID: <46B4E04D.2050200@it.su.se> Date: Sat, 04 Aug 2007 22:23:41 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba CC: dharkins@lounge.org, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> Crypto-agility isn't just the ability to substitute one algorithm for >> another, it should include the jettisoning any unnecessary baggage that >> might've been appropriate (or required) for one algorithm if it's not >> appropriate (or required) for another. > > Let's just say that crypto-agility includes negotiation of parameters > relating to the cryptographic algorithms, as well as the algorithms > themselves. > > One question that I'd like to understand is the extent to which the > negotiation can be protected in either of the proposals. > > WIth DTLS, in the absence of DNSSEC, I think that an attacker in the > middle could subvert the DTLS up-negotiation, so as to cause a client > and server that support DTLS to negotiate plain RADIUS. So some sort > of policy pre-configuration is required (e.g. RADIUS server requires > DTLS on these NASes). With DNSSEC, it is possible to specify whether > a NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected > negotiation would be possible. > > I'm not sure about the level of protection provided in draft-zorn. > > This problem crops up whenever a server-announced parameter needs to be negotiated securely (for instance SASL mechanisms). What you need to do, unless you can actually protect the parameter, is to verify the parameter against the first set you received from the server _after_ you negotiate a secure channel, and complain if it doesn't match. For instance, if your server was once DTLS and now isn't your client should not silently accept a "downgrade". This requires a basic leap-of- faith that the first negotiation was either non-intercepted or determined by policy. Cheers Leif -- to unsubscribe send a message to radiusext-request@ops.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, 04 Aug 2007 13:29:34 +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=lHYwzYAal40+ItqCsvpiDHT9gJsjdZZnOh/y+ZLVYuhUNXCcSyaxqvjAayyFxqur6saCR0sFyHSsQviH5Z8gq5fCm2Evst0KhQn/AoNGc4djU+nyoTa2uJXCp5IPa32YZDjboSfOnjgxGACXwpz/LGgHxhBe+TfOPElP5Ep3tcI= 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=VPkTvXOLfnczdz/igyA6stQy8pjO7x088LmpYa/CyM+YVxN1HSfJGRcftod5v+/fJM+YK4I2A77uciWiqQICeOSV+soD8HOiLcwzQJsDh6tTqomz/7q/A5Po/Ym9edWyehbxKkJFrCMksWkwlpht+Tn/sWflOA1T3JVYVN9jqqE= Message-ID: <46B47F05.4020606@lipetsk.ru> Date: Sat, 04 Aug 2007 17:28:37 +0400 From: Victor Gamov User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Internet Draft: RadSec - RADIUS over TCP+TLS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Stefan Winter wrote: > Hello! > > My name is Stefan Winter of the Luxembourg Research and Education Network. > Together with Stig Venaas (Norwegian REN) and Mike McCauley from Open Systems > Consultants (creators of the Radiator RADIUS server) I have created an > internet draft describing two implementations of a transport profile for > RADIUS that transports the RADIUS payload over a TCP+TLS link. (sorry for late response) Hi Stefan! I work with RADIUS protocol about 10 years and question "why UDP not TCP" is the biggest question without answer for me (yes I red RFC286 part 2.4). When I thinking about "UDP vs TCP" I found many arguments for TCP advantages like produced by your draft so I agree with it. I think that this draft is a good start point to think about new transport for RADIUS. (and may be to prepare new version of this simply and nice protocol without current problems even) -- 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: Sat, 04 Aug 2007 01:34:25 +0000 Message-ID: From: "Bernard Aboba" To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org Bcc: Subject: RE: Request for Review: "Issues and Fixes" changes Date: Fri, 03 Aug 2007 18:33:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Here is my review of the "Issues and Fixes" changes (taken from a diff of -04 and -05): < A State attribute is REQUIRED in Access-Request packets neither < including an authentication attribute nor a Service-Type attribute < with the value Call Check (10). < < < --- > As defined in [RFC 2865] Table 5.44, Access-Request packets MAY > contain a State attribute. We extend that definition here, to say > that Access-Request packets that contain an authentication attribute > or a Service-Type attribute with the value Call Check (10) MAY > contain a State attribute. Access-Request packets not matching the > above description MUST contain a State attribute. Does it make sense to include a State attribute in an Access-Request with a Service-Type attribute with value Call Check (10)? Typically in these cases there is no state to encode. I'd rewrite this as follows: As noted [RFC 2865] Table 5.44, Access-Request packets MAY contain a State attribute. An Access-Request packet not containing an authentication attribute or a Service-Type attribute with a value of Call Check (10) MUST contain a State attribute. If an authentication attribute is present, then a State Attribute MAY be included. Section 2.2.1 I think this section needs to note that the suggested algorithms apply not only to a RADIUS client, but also to a Dynamic Authorization Client, defined in RFC 3576bis. Either that, or the algorithm text needs to be transplanted into RFC 3576bis. Congestive backoff. While it is not necessary for RADIUS client implementations to implement complex retransmission algorithms, implementations SHOULD support congestive backoff within the limits suggested by [RFC2865] Section 2.4. RADIUS retransmission timers are based on the model used in DHCPv6 [RFC3315]. Variables used here are also borrowed from this specification. RADIUS is a request/response-based protocol. The message exchange terminates when the requester successfully receives the answer or the message exchange is considered to have failed according to the retransmission mechanism described below. Is the retransmission algorithm OPTIONAL or RECOMMENDED? The first paragraph seems to suggest that only congestive backoff is RECOMMENDED, and that the rest of the text is non-normative. Is that what is intended? I'd suggest that we say something like "A potential retransmission algorithm is included below" to make that that clear, if that is what is meant. MRD specifies an upper bound on the length of time a sender may retransmit a message. The message exchange fails once MRD seconds have elapsed since the client first transmitted the message. MRD MUST be set, and SHOULD have a value between 5 and 30 seconds. These values mirror the values for a servers duplicate detection cache, as described in the next section. MRC specifies an upper bound on the number of times a sender may retransmit a message. if MRC is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message. If MRC is non-zero, the message exchange fails when the either the sender has transmitted the message MRC times, or when MRD seconds have elapsed since the client first transmitted the message. This could have some unforseen (and potentially adverse) impacts on RADIUS accounting. Today, some RADIUS accounting clients continue to retransmit for long periods of time, intentionally, in order to improve reliability. If there is an upper bound on the number of times a sender may retransmit an accounting message, then accounting messages could be lost in situations where today they would be delivered. So I think this needs to be changed. Section 2.5 The issue that this section is attempting to address is the seeming contradiction between [RFC2865] Section 1.1 which states: A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer Apple Remote Access Protocol (ARAP) service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead. and [RFC2865] Section 5 which states: A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type. As I recall, the conclusion was that the advice of Section 1.1 applies to known attributes, so that if a NAS receives an attribute that is known and represents a service, but is not implemented, it is treated as an Access-Reject. Whereas if the attribute is not known, then it MAY be ignored. The question was then what the behavior is for a NAS encountering an unknown attribute. Given the MAY in Section 5, behavior can only be recommended, not mandated, because of backward compatibility. It is possible for either a standard attribute or VSA to represent a request for an unavailable service. However, where the Type or Vendor-ID is unknown, a RADIUS client will not know whether the attribute defines a service or not. [BA] Actually the problem could also arise if the Vendor-ID is known, but the Vendor Type is not, right? In general, it is best for RADIUS clients to err on the side of caution. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients. [BA] My recommendation would be to add a clarification of the meaning of Section 1.1: In general, it is best for a RADIUS clients to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients. As there may be interoperability issues with the above suggestion, client implementations SHOULD make the suggested behavior configurable. A configuration flag such as "treat unknown attributes as reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown attributes in Access-Accepts are be silently ignored. The default value for the flag SHOULD be set to true. I think what we are trying to say here is that existing implementations that ignore unknown attributes should probably not change to treating them as an Access-Reject by default, or else on upgrading the NAS, the users could see an unexpected change in behavior. In this situation, configuration would be helpful, but the legacy behavior should be the default, probably. However, where the existing implementation already implements the recommended behavior, there is no point in introducing configuration. Here is a recommended rewrite: In order to avoid introducing changes in default behavior, existing implementations that do not obey this recommendation should make the behavior configurable, with the legacy behavior being enabled by default. A configuration flag such as "treat unknown attributes as reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown attributes in Access-Accepts are be silently ignored. -- to unsubscribe send a message to radiusext-request@ops.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, 04 Aug 2007 00:39:07 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for Review: "Issues and Fixes" changes Date: Fri, 03 Aug 2007 17:37:57 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed In response to IESG comments, the "Issues and Fixes" document has been updated: http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-05.txt This version contains significant changes, including: 1. Addition of a suggested retransmission algorithm (Section 2.2.1) 2. Changes to RADIUS client and server processing of unknown attributes (Section 2.5) Given these changes, we are requesting that RADEXT WG participants review the document carefully. The request for review will last until August 17, 2007. Please post your comments to the RADEXT WG mailing list in the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Aug 2007 12:31:36 +0000 Message-ID: <46B31FE3.7070103@deployingradius.com> Date: Fri, 03 Aug 2007 08:30:27 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stefan Winter CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: >> Yes. The failure cases for DTLS negotiation are: >> >> a) server doesn't support DTLS (and thinks it's a bad RADIUS packet) >> b) server is slow / down >> c) attacker is faking (a) or (b) > > d) the network is unreliable and drops some negotiation datagrams? Which is indistinguishable from (b). 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, 02 Aug 2007 16:27:08 +0000 Message-ID: From: "Bernard Aboba" To: dromasca@avaya.com, gwz@cisco.com, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Thu, 02 Aug 2007 09:26:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Yes, at the same time Working Group meetings and mail lists can discuss >items that are candidates for future work. This includes items that do >not belong strictly within a current charter, but may become part of an >extended charter later. We can certainly entertain a discussion of whether RADSEC is appropriate as a RADEXT WG work item. However, I am not entirely clear that this question is relevant to the current crypto-agility discussion (although I'm certainly willing to be convinced otherwise). For practical reasons, the discussion has primarily centered on mechanisms applying to the RADIUS protocol as defined in RFC 2865. Virtually all RADIUS implementations today are based on UDP, and this is likely to remain the case for the forseeable future. Therefore, unless we think it is likely that RADIUS will migrate to TCP transport *exclusively*, then a crypto-agility solution needs to be provided for UDP transport as well. As a result, RADSEC cannot be considered a solution to the RADIUS crypto-agility problem as currently posed, though perhaps a combination of DTLS and RADSEC could qualify. -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 16:20:36 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review of draft-nelson-radius-management-authorization-05.txt Date: Thu, 02 Aug 2007 09:19:39 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The ISMS WG has requested that RADEXT WG take on "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" as a WG work item. In response to this request, we are requesting reviews of the document, which is found here: http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-05.txt The request for review will last until August 16, 2007. Please indicate whether you would like this document to be taken on as a WG work item. Please respond even if you have no issues with the document; if you have comments, please send the issues to the RADEXT WG mailing list in the format provided on here: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Aug 2007 11:14: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: Continued discussion of RADIUS Crypto-Agility Date: Thu, 2 Aug 2007 13:13:37 +0200 Message-ID: Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQAADQt2AAJTF20A== From: "Romascanu, Dan (Dan)" To: "Stephen Hanna" , "Glen Zorn (gwz)" , "David B. Nelson" Cc: =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Stephen Hanna >=20 > I have asked Juniper's RADIUS experts to join us for this=20 > discussion. They should be here within a few hours. Sorry for=20 > the delay. >=20 Just as a friendly note - anybody joining the discussion is welcome, but discussions in IETF are being conducted among individuals, not among experts representing companies.=20 Dan -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 11:02:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Thu, 2 Aug 2007 13:01:23 +0200 Message-ID: Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQAAYtyRAAH1jIoA== From: "Romascanu, Dan (Dan)" To: "Glen Zorn (gwz)" , "David B. Nelson" Cc: =20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: Wednesday, August 01, 2007 11:07 PM > To: Romascanu, Dan (Dan); David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: RE: Continued discussion of RADIUS Crypto-Agility >=20 > Romascanu, Dan (Dan) allegedly=20 > scribbled on Wednesday, August 01, 2007 10:12 AM: >=20 > ... >=20 > > Seriously, I was the one to recommend the author to ask for a time=20 > > slot on the RADEXT agenda. I believe that the RADSEC work is if not=20 > > within at least related to the WG scope (but not necessarily as a=20 > > crypto-agility solution), although undertaking it would mean an=20 > > extension of the charter. >=20 > OK, I'm confused: the scope of a WG is _not_ defined by its=20 > charter? If the charter doesn't define the scope of a WG, what does? >=20 Yes, at the same time Working Group meetings and mail lists can discuss items that are candidates for future work. This includes items that do not belong strictly within a current charter, but may become part of an extended charter later.=20 Dan -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 06:39:13 +0000 From: Stefan Winter Organization: Fondation RESTENA To: Alan DeKok Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Thu, 2 Aug 2007 08:39:01 +0200 User-Agent: KMail/1.9.7 Cc: Bernard Aboba , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1706593.6ueWxZqrgU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708020839.08754.stefan.winter@restena.lu> --nextPart1706593.6ueWxZqrgU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Yes. The failure cases for DTLS negotiation are: > > a) server doesn't support DTLS (and thinks it's a bad RADIUS packet) > b) server is slow / down > c) attacker is faking (a) or (b) d) the network is unreliable and drops some negotiation datagrams? =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart1706593.6ueWxZqrgU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsXwM+jm90f8eFWYRAgB+AJ9+7SacD/HwX9n5ahif4r+yWybdcQCfVuA+ 2tqlpoSu6f23AugIrmp3xr4= =PMVE -----END PGP SIGNATURE----- --nextPart1706593.6ueWxZqrgU-- -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 05:06:19 +0000 Message-ID: <46B1661A.1090805@nitros9.org> Date: Thu, 02 Aug 2007 01:05:30 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > WIth DTLS, in the absence of DNSSEC, I think that an attacker in the > middle could subvert the DTLS up-negotiation, so as to cause a client > and server that support DTLS to negotiate plain RADIUS. Yes. The failure cases for DTLS negotiation are: a) server doesn't support DTLS (and thinks it's a bad RADIUS packet) b) server is slow / down c) attacker is faking (a) or (b) > So some sort of > policy pre-configuration is required (e.g. RADIUS server requires DTLS > on these NASes). With DNSSEC, it is possible to specify whether a > NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected > negotiation would be possible. Yes. If the NAS has a static server certificate configured for DTLS, it can assume that this means the server supports DTLS. If the server accepts "known" NASes by certificate rather than by IP, an attacker can start many DTLS sessions. This may DoS the server. 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, 02 Aug 2007 04: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: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 1 Aug 2007 23:40:10 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59DC77@daebe104.NOE.Nokia.com> Thread-Topic: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjAAACHXSAAF29sUA== From: To: , , Cc: David, I copied Stephan on the mail, as he asked to be contacted for any follow-up questions.=20 With respect to being compatible to Open Source, what is meant is that Nokia will not assert its patents against open source implementations (as far as I know), though Stephan can correct me. John >-----Original Message----- >From: ext David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 >Sent: 01 August, 2007 20:40 >To: Loughney John (Nokia-NRC/PaloAlto); dime@ietf.org;=20 >radiusext@ops.ietf.org >Subject: RE: Nokia Patent discussion FW: [Dime] First results=20 >on Diameter vs. RadSec patent research:EP1147635 > >> Non-assert statements like this are widely used in the IETF, as they=20 >> are believed to provide sufficient defensive protection for=20 >the owner,=20 >> while still allowing implementers and users to exercise the=20 >protected=20 >> technology without a license and for free, as long as they behave=20 >> similarly nice... > >It is true that "non-assert" IPR statements are frequently=20 >issued these days. > >> In that, non-asserts are believed to be compatible with most open=20 >> source licenses. > >Compatible? What does that mean? > >A reciprocal non-assert is not quite the same thing as open=20 >source. Open source has to do with copyright IPR, not patent=20 >IPR. Additionally, reciprocal non-asserts would appear to=20 >apply to all patents that an organization may hold, not only=20 >those that are related to standards. In that regard, it is=20 >tantamount to an implicit (and broad) cross-licensing=20 >agreement, which would include patents covering proprietary=20 >technology as well as open standards based technology. > >Still, it is better than nothing, and very useful to companies=20 >that don't intend to enforce _any_ of their patent portfolio=20 >against infringement by the non-assert grantors. Of course,=20 >it also works out fine for companies that don't have patents=20 >to enforce. :-) > >Standard disclaimer: I am not a lawyer. > > > -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 04:25:21 +0000 Message-ID: From: "Bernard Aboba" To: jsalowey@cisco.com, gwz@cisco.com, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 01 Aug 2007 21:24:24 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >The fact that implementations of earlier >versions of our draft (of necessity using vendor-specific >equivalents to the attributes defined in the draft) have been >certified by NIST obviously does not entail (or even imply) >that the final product of this WG will also be thus >certifiable, even if it is based upon our work... >If our draft is chosen as the basis for the radext >crypto-agility work, it will certainly be changed Given that the current document describes existing implementations, it would probably make sense to publish it as an RFC, utilizing the VSAs that are actually used. That way, there would be no confusion between that RFC implementation documentation and another, evolving document utilizing IETF standards space 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: Thu, 02 Aug 2007 02:04:22 +0000 Message-ID: <55566.69.12.173.8.1186020233.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 19:03:53 -0700 (PDT) Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "Bernard Aboba" Cc: gwz@cisco.com, dharkins@lounge.org, radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Bernard On Wed, August 1, 2007 6:16 pm, Bernard Aboba wrote: [snip] > I'm not clear why the KEK ID or KM ID is a covert channel any more than > the > IPsec SPI is a covert channel in the case where manual keying is used. A SPI for IPsec (manual keying or not) uniquely identifies necessary context (the SA) to process the IPsec packet. It's possible that different SAs could apply to different selectors and therefore have different processessing requirements as well as different keys. The KEK ID does not identify necessary context to process a RADIUS message because the draft only defines one addition key for use as a KEK so that's all the context you need-- you implemented the draft you know what the KEK is, it's the one you added to implement the draft. No need to further identify it. The KM ID does not identify necessary context because the App ID says what the particular key is. It's either an EAP-MSK or an EAP-EMSK or an ERX-rMSK or an 11r-PMK or whatever. Sending multiple EAP-MSKs or multiple ERX-rMSKs or muultiple 11r-PMKs in a single message to a single RADIUS client for a single peer does not seem to be a requirement of any EAP method or any application (HOKEY, 11i, etc) so there's no need to further identify the key. The point being that there is nothing that could take the place of the SPI to identify an IPsec SA but there is something that could take the place of a KEK ID to identify a KEK (implicit context) and there is something that could take the place of a KM ID to identify the keying material being disclosed (App ID). > However, two other questions come to mind: > > 1. As I understood it, the need for an explicit RADIUS shared secret name > arises from the potential for key rollover and dynamic key management. > Given the use of AES as the algorithm, is rollover support really > necessary? I think the number of AES key wraps that can be safely done with a single KEK is 2^48. I don't think that's a limit we need to worry about. We could do one per second for 8.9 million years before we reach the "unsafe" point. > Also, is there really a need for dynamic key management? If not, could > we get by with the RADIUS shared secret key naming scheme (using the IP > addresses of the client and server as the key name)? Yes, that is the key name of the KEK. And the name of the KM is " for " where is the identity in the App ID field and is the username of the peer being authenticated. There is no need for a KEK ID and a KM ID unless you want to send some information over a covert channel. Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 01:28:49 +0000 Message-ID: From: "Bernard Aboba" To: dharkins@lounge.org, jsalowey@cisco.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 01 Aug 2007 18:28:22 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > Crypto-agility isn't just the ability to substitute one algorithm for >another, it should include the jettisoning any unnecessary baggage that >might've been appropriate (or required) for one algorithm if it's not >appropriate (or required) for another. Let's just say that crypto-agility includes negotiation of parameters relating to the cryptographic algorithms, as well as the algorithms themselves. One question that I'd like to understand is the extent to which the negotiation can be protected in either of the proposals. WIth DTLS, in the absence of DNSSEC, I think that an attacker in the middle could subvert the DTLS up-negotiation, so as to cause a client and server that support DTLS to negotiate plain RADIUS. So some sort of policy pre-configuration is required (e.g. RADIUS server requires DTLS on these NASes). With DNSSEC, it is possible to specify whether a NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected negotiation would be possible. I'm not sure about the level of protection provided in draft-zorn. -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 01:20:36 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com, dnelson@elbrysnetworks.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 01 Aug 2007 18:20:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Attribute grouping. The reason why the various key IDs, etc. are all >part of the Keying-Material attribute is because they need to be >associated w/a specific key (it's possible to deliver more than one key >in a single message). Attribute grouping enables that association w/out >requiring the multiple sub-attribute technique that we use. This would be helpful for several reasons: 1. It would avoid a discussion of the merits/demerits of complex attributes. 2. It would disentangle discussion of the keywrap mechanism (which doesn't seem to have encountered objections) from the key naming issue. -- to unsubscribe send a message to radiusext-request@ops.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, 02 Aug 2007 01:17:12 +0000 Message-ID: From: "Bernard Aboba" To: gwz@cisco.com, dharkins@lounge.org Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 01 Aug 2007 18:16:09 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Since AES Key Wrap is the only one specified & SIV doesn't actually >exist as a standard, this doesn't make much sense to me. Since the proposal supports negotiation, SIV could be supported in the future, once it is specified. >Actually, this is largely irrelevant: the purpose of the Mac-Randomizer >is to facillitate the use of the Message-Authentication-Code in >accounting & CoA messages. It is actually independent of the >Keying-Material attribute. I suppose that we could further specify it >as only required if the Message-Authenticator-Attribute is used in one >of those messages... The Mac-Randomizer is designed to prevent against replay where RADIUS doesn't provide that protection, correct? > > - not everyone is comfortable with massive covert channels like KEK > > ID and KM ID. I suggest making them optional and using a bit it > > the reserved field to indicate their presense or absense. > >So having optional "massive covert channels" is somehow better? Why? I'm not clear why the KEK ID or KM ID is a covert channel any more than the IPsec SPI is a covert channel in the case where manual keying is used. However, two other questions come to mind: 1. As I understood it, the need for an explicit RADIUS shared secret name arises from the potential for key rollover and dynamic key management. Given the use of AES as the algorithm, is rollover support really necessary? Also, is there really a need for dynamic key management? If not, could we get by with the RADIUS shared secret key naming scheme (using the IP addresses of the client and server as the key name)? 2. There is also the question of compatibility with the keying naming scheme in the EAP Key Management Framework document as well as in the RADIUS ERX proposal. Couldn't we just wrap the MSK and send the MSK key name separately as specified in RFC 4072? -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 23:04:31 +0000 Message-ID: <58387.69.12.173.8.1186009445.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 16:04:05 -0700 (PDT) Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "Glen Zorn (gwz)" Cc: "Dan Harkins" , "David B. Nelson" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Yea, I get it Glen. But if you have different App IDs then the that field is used to identify different wrapped keys in the same message ("here's an EAP-MSK for and an EAP-EMSK for "). The KM ID still serves no purpose. Dan. On Wed, August 1, 2007 3:43 pm, Glen Zorn (gwz) wrote: > Dan Harkins allegedly scribbled on > Wednesday, August 01, 2007 3:35 PM: > >> Hi Glen, >> >> That's very interesting. The App ID field only defines an EAP-MSK. > > That's extensible, Dan. > > ... > -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 22:43:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 15:43:00 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC7CDE@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUjDBa4rwq6piSROKha8FPdC8htwAAPHeQ From: "Glen Zorn \(gwz\)" To: "Dan Harkins" Cc: "David B. Nelson" , DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=230; t=1186008177; x=1186872177; 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=20Crypto-agility=20requirement=20and=20=20=20=20=20=20d raft-zorn-radius-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=ZwHVe6LuG9/0aLXOGm2ExuSURTu5wbd9EJ9g1dvr6sw=; b=YXV7mLcO0U8RAoUEmHRg3O1gR148036EOzlt0nrfvVLu9cOVjfUv4/hnRRnTnIS2hLp76Puf l3S2nMjLnAgCPV+6Qfw5nu3NTmvSuT4HLqz3gp7HLBE3URBRInocixE7; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Dan Harkins allegedly scribbled on Wednesday, August 01, 2007 3:35 PM: > Hi Glen, >=20 > That's very interesting. The App ID field only defines an EAP-MSK. That's extensible, Dan. ... -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 22:35:22 +0000 Message-ID: <59360.69.12.173.8.1186007693.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 15:34:53 -0700 (PDT) Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "Glen Zorn (gwz)" Cc: "David B. Nelson" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Glen, That's very interesting. The App ID field only defines an EAP-MSK. I can see how a KEK ID could indicate what key was used to encrypt this EAP-MSK if the client and server had more than one KEK. I don't see a point in having more than one KEK and since your draft only adds one key to be used as a KEK (the other key it adds is for integrity protection) the KEK ID seems extranneous. But KEK ID aside, having multiple KM IDs would imply that there are more than one EAP-MSK being disclosed in a single message. What EAP methods produce more than one MSK that would require having different KM IDs but the same App ID in a single message? Dan. On Wed, August 1, 2007 3:09 pm, Glen Zorn (gwz) wrote: > David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 > 2:56 PM: > > ... > >>> ...the first thing _I_ think should be done is to modify the >>> attributes to align with the attribute extension work... >> >> What properties of the extended attribute format are particularly >> attractive for the crypto-agility work? > > Attribute grouping. The reason why the various key IDs, etc. are all > part of the Keying-Material attribute is because they need to be > associated w/a specific key (it's possible to deliver more than one key > in a single message). Attribute grouping enables that association w/out > requiring the multiple sub-attribute technique that we use. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Aug 2007 22:10:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 15:09:53 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC7CA2@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUeaW7w8Ulxk9ARpiA2NGZdsJQlgAAGsqQAAISTpAAAPgMcAAAcP8Q From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=683; t=1186006187; x=1186870187; 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=20Crypto-agility=20requirement=20and=20draft-zorn-radiu s-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=6txptcP5HXMTAg8rtUDhJ2Z8GJvlH5UdTcKIzUKcMxw=; b=VhITlhYzhDC1Ix9fY06mKhHRs6WcpZdK4iSUbDXaDw9BKT3Ats0ryINn88YVYqoCAtZjoK9d pEZnr3SAqCxGHCl1/w9dtkX8k6JqPTwjaKSuYXN2GM3w/ZGGx6204e0u; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 2:56 PM: ... >> ...the first thing _I_ think should be done is to modify the >> attributes to align with the attribute extension work... >=20 > What properties of the extended attribute format are particularly > attractive for the crypto-agility work?=20 Attribute grouping. The reason why the various key IDs, etc. are all part of the Keying-Material attribute is because they need to be associated w/a specific key (it's possible to deliver more than one key in a single message). Attribute grouping enables that association w/out requiring the multiple sub-attribute technique that we use. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 21:58:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 14:57:59 -0700 Message-ID: Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUeaW7w8Ulxk9ARpiA2NGZdsJQlgAAGsqQAAISTpAAAQWREA== From: "Joseph Salowey \(jsalowey\)" To: "Glen Zorn \(gwz\)" , "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3186; t=1186005474; x=1186869474; 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=20Crypto-agility=20requirement=20and=20draft-zorn-radiu s-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=zzIqWEvnbguqjPYwpGfEw1n6acQ//VDrlHtGq3hMbYo=; b=BbzlgbJ48jPONA5zvWRkBz9tA5l8eWFcHJMfGEBhGUiSOLdhg6t7x1aDe9mVHGMxmGHB5G/b 78Qzm0zrlfxDXhxIDWRxpTPQdtBDh7zhDZqmZntLicMcakOzYPAR5pmWsQ0oGf0IYb4dWUCLTz LW1byXjX+RILchvdbgaiZPXuU=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); When working on the key wrap draft we did consider crypto-agility, however we did not spend much time thinking about authenticating ciphers that Dan is referring to. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Wednesday, August 01, 2007 2:46 PM > To: David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: RE: Crypto-agility requirement and=20 > draft-zorn-radius-encattr/draft-zorn-radius-keywrap >=20 > David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 > 1:28 PM: >=20 > > Dan Harkins writes... > >=20 > >> If you're submitting a draft that only does AES Key wrap with no=20 > >> capability to substitute anything else then you can mandate other=20 > >> attributes that may be necessary. This isn't crypto-agile though. > >=20 > > That's a good point. True crypto-agility is about modularly=20 > > interchangeable cipher suites, not simply replacing a fixed, but=20 > > compromised, cipher suite with another fixed, but currently robust,=20 > > cipher suite. >=20 > I guess that I haven't been a model of clarity here ;-); I=20 > apologize & will try to clarify things now. This draft has=20 > been around for a long time, long enough I think that the=20 > term "crypto-agility" didn't exist when the work was begun. =20 > The purpose of our work was to enable the use of IEEE 802.11i=20 > networks in FIPS 140-2 environments, while providing a higher=20 > level of security RADIUSoIPsec. We accomplished that goal. > Again, although we made provisions for variations in the=20 > cryptographic algorithms used, crypto-agility was _not_ a=20 > primary goal. The fact that implementations of earlier=20 > versions of our draft (of necessity using vendor-specific=20 > equivalents to the attributes defined in the draft) have been=20 > certified by NIST obviously does not entail (or even imply)=20 > that the final product of this WG will also be thus=20 > certifiable, even if it is based upon our work. I think that=20 > what it _does_ say is that our overall approach is valid. If=20 > our draft is chosen as the basis for the radext=20 > crypto-agility work, it will certainly be changed: the first=20 > thing _I_ think should be done is to modify the attributes to=20 > align with the attribute extension work, which (along with=20 > some minor editorial > adjustments) take care of Dan's concerns. Of course, that=20 > would be up to WG consensus: the point I'm trying to make is=20 > that there's no need to worry about backward compatibility=20 > with existing implementations of our draft going forward=20 > since (whether it is accepted or not) we will likely publish=20 > an Informational RFC including the actual VSAs used in the=20 > implementation, purely for the convenience of other vendors=20 > that might wish to build their own version of the existing protocol. >=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, 01 Aug 2007 21:55:28 +0000 From: "David B. Nelson" To: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 17:55:38 -0400 Organization: Elbrys Networks, Inc. Message-ID: <010101c7d486$b2332170$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUeaW7w8Ulxk9ARpiA2NGZdsJQlgAAGsqQAAISTpAAAPgMcA== Glen Zorn writes... > This draft has been around for a long time, long enough I think > that the term "crypto-agility" didn't exist when the work was begun. Quite possibly. > The purpose of our work was to enable the use of IEEE 802.11i > networks in FIPS 140-2 environments... Yep. > ...the first thing _I_ think should be done is to modify the > attributes to align with the attribute extension work... What properties of the extended attribute format are particularly attractive for the crypto-agility work? -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 21:48:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 14:48:07 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC7C7D@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgADuxrAAABtQUAAAanRkAAAmR9gAAFW3BA= From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=225; t=1186004900; x=1186868900; 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=20Crypto-agility=20requirement=20and=20draft-zorn-radiu s-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=V6aUcSgFVzeZSh98nDVrXoXuYOrwkev366EK6zGc/bo=; b=jiYdu3yGhg2Uh04PvWfq+FYNoo2PfVOe83DFUv9zh7MPqGfBOugwknrICpPGTUxnBg6yM3Sq MsCqhyh5r8FVTHAPXhMwWTiIybFADNuBZ/xm5KRgECgs72Uj2wsYe+Il; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 2:10 PM: > Glen Zorn writes... >=20 >> ...the person @ Cisco who does is OOF... >=20 > OOF? Sorry, a Microsoft-ism, I guess: Out of the OFfice. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 21:45: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: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 14:45:32 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC7C7A@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUeaW7w8Ulxk9ARpiA2NGZdsJQlgAAGsqQAAISTpA= From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2262; t=1186004726; x=1186868726; 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=20Crypto-agility=20requirement=20and=20draft-zorn-radiu s-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=L+uDfwUWKfY6eJMaiRvpATKp6sexfbmcK+hNQ5GQI5I=; b=qOVecZDJT0xZSGRrLg4BLv9QQWQ6XPB7kupXI0gPZLM8VaqZvwZLaDLtSmfNub1c3BJ4xz7S REUTBDjQ5rxb74OGnnuDlAO0L9ZRZqNnRQO+aD5HZd5MIG3S3wJNSs26; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 1:28 PM: > Dan Harkins writes... >=20 >> If you're submitting a draft that only does AES Key wrap with no >> capability to substitute anything else then you can mandate other >> attributes that may be necessary. This isn't crypto-agile though. >=20 > That's a good point. True crypto-agility is about modularly > interchangeable cipher suites, not simply replacing a fixed, but > compromised, cipher suite with another fixed, but currently robust, > cipher suite.=20 I guess that I haven't been a model of clarity here ;-); I apologize & will try to clarify things now. This draft has been around for a long time, long enough I think that the term "crypto-agility" didn't exist when the work was begun. The purpose of our work was to enable the use of IEEE 802.11i networks in FIPS 140-2 environments, while providing a higher level of security RADIUSoIPsec. We accomplished that goal. Again, although we made provisions for variations in the cryptographic algorithms used, crypto-agility was _not_ a primary goal. The fact that implementations of earlier versions of our draft (of necessity using vendor-specific equivalents to the attributes defined in the draft) have been certified by NIST obviously does not entail (or even imply) that the final product of this WG will also be thus certifiable, even if it is based upon our work. I think that what it _does_ say is that our overall approach is valid. If our draft is chosen as the basis for the radext crypto-agility work, it will certainly be changed: the first thing _I_ think should be done is to modify the attributes to align with the attribute extension work, which (along with some minor editorial adjustments) take care of Dan's concerns. Of course, that would be up to WG consensus: the point I'm trying to make is that there's no need to worry about backward compatibility with existing implementations of our draft going forward since (whether it is accepted or not) we will likely publish an Informational RFC including the actual VSAs used in the implementation, purely for the convenience of other vendors that might wish to build their own version of the existing protocol. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 21:09:42 +0000 From: "David B. Nelson" To: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 17:09:39 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00fd01c7d480$45e73070$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgADuxrAAABtQUAAAanRkAAAmR9g Glen Zorn writes... > ...the person @ Cisco who does is OOF... OOF? -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 20:58:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 13:58:00 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B64994@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgADuxrAAABtQUAAAanRkA== From: "Glen Zorn \(gwz\)" To: "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1246; t=1186001875; x=1186865875; 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=20Crypto-agility=20requirement=20and=20draft-zorn-radiu s-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=vsOHfrSUyVoQ1Hb+nDfXgItg59fx6rEdD7EHA+b1Yj4=; b=geEXkPWqv9hpgZ9h0EgR80RsZopQYSN9S5SlwoDeg3tDT8+1xkL31j1WtWsVmzSrllMuKXlJ w7XX4zm5PoNJykDc54VEvxwC50UTiBSgU+QMHIT8oODvM0w34t/8qwlKO5cyUr2mzQWJ9grwRt w1E+JlLH1n517syl6ZmcXiXRg=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007 1:09 PM: > Glen Zorn writes... >=20 >> There are multiple interoperable implementations which have been NIST >> (& at in least one case) Common Criteria certified, however, so we'll >> just be leaving it as is for now. >=20 > I has previously asked if information on the implementations and the > certifications you mention could (and would) be made available to the > WG. I didn't get a response, so I'll ask again.=20 Since I don't deal with government affairs or crypto validation & the person @ Cisco who does is OOF, I am unable to provide detailed information on the certifications at this time. The independent implementations are by 3eTI & Cisco & I believe that the certifications include FIPS 140-2. =20 >=20 > Since the "certifyability" seems to be a selling point for this > approach, it seems relevant for the WG to evaluate that information, > in deciding on a solution.=20 If the WG can actually evaluate that information they are better humans than I ;-). However, I would think that anybody qualified to evaluate it (that's not me) would be able to find it (also not me, but I do know it's somewhere on the NIST Web site).=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, 01 Aug 2007 20:42:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Wed, 1 Aug 2007 13:42:15 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B64974@xmb-sjc-215.amer.cisco.com> Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQAADQt2AABqZW8A== From: "Glen Zorn \(gwz\)" To: "Stephen Hanna" , "Romascanu, Dan \(Dan\)" , "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=749; t=1186000930; x=1186864930; 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=20Continued=20discussion=20of=20RADIUS=20Crypto-Agility |Sender:=20; bh=GdtgCuY775IEHPy0u0uPPjvaQenNOQNG5ad1epna8jQ=; b=hQ/4i2NXHKxK4lW9Fyc6ioD0+Lx3QjKs1DTuEumWgvO92YA9xVc/AFMQr0mFnHtx3Z6MXc3q TbJH8dVDi6fCcpzmaY3OyG01paPKb1e85qa52Ms9Ks/V0T7XlwZLRgZwo5i1+myEaSVUZnMZQx Oua2T2YxOyYhJaE0Lek242AMg=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); Stephen Hanna allegedly scribbled on Wednesday, August 01, 2007 10:32 AM: > Thanks, Dan. I'm glad you did suggest that we consider the RADSEC > work.=20 > Now we can consider the alternatives on their technical merits Hang on a minute, here. This is absolutely NOT "an alternative" for the crypto-agility work. > and set aside the charter or process questions for the moment (to be > revisited if necessary). =20 >=20 > I have asked Juniper's RADIUS experts to join us for this discussion. Since it is pretty painfully obvious that RADSEC is NOT RADIUS, what will they have to say? > They should be here within a few hours. Sorry for the delay.=20 >=20 > Thanks, >=20 > Steve >=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, 01 Aug 2007 20:28:04 +0000 From: "David B. Nelson" To: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 16:28:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00fc01c7d47a$7fd43220$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUeaW7w8Ulxk9ARpiA2NGZdsJQlgAAGsqQ Dan Harkins writes... > If you're submitting a draft that only does AES Key wrap with no > capability to substitute anything else then you can mandate other > attributes that may be necessary. This isn't crypto-agile though. That's a good point. True crypto-agility is about modularly interchangeable cipher suites, not simply replacing a fixed, but compromised, cipher suite with another fixed, but currently robust, cipher suite. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 20:26:43 +0000 Message-ID: <56027.69.12.173.8.1185999979.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 13:26:19 -0700 (PDT) Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "David B. Nelson" Cc: radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit I agree completely. I'd also request that, to the fullest extent possible, this information address some of the more unexplained parts of the draft, like key ids. If NIST requires a KEK ID and a KM ID as well as (the more obvious requirement of) using an approved cipher in an approved mode then I'd like to know why. Dan. On Wed, August 1, 2007 1:08 pm, David B. Nelson wrote: > Glen Zorn writes... > >> There are multiple interoperable implementations which >> have been NIST (& at in least one case) Common Criteria certified, >> however, so we'll just be leaving it as is for now. > > I has previously asked if information on the implementations and the > certifications you mention could (and would) be made available to the WG. > I > didn't get a response, so I'll ask again. > > Since the "certifyability" seems to be a selling point for this approach, > it > seems relevant for the WG to evaluate that information, in deciding on a > solution. > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Aug 2007 20:19:34 +0000 Message-ID: <56259.69.12.173.8.1185999541.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 13:19:01 -0700 (PDT) Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "Glen Zorn (gwz)" Cc: "Dan Harkins" , radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Glen, On Wed, August 1, 2007 12:51 pm, Glen Zorn (gwz) wrote: > Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04 > AM: > >> Hi Joe, >> >> As I mentioned at the mic during the meeting at IETF69 >> draft-zorn-radius-keywrap is not really very (crypto-)agile and I >> think with some minor modifications could be made more so. For >> example: >> >> - do not require that Message-Authentication-Code MUST be present >> if Keying-Material is present. SIV is a much preferrable key >> wrapping technique than RFC3394 and if SIV was specified in the >> enc-type of Keying-Material then Message-Authentication-Code would >> be redundant. Please say that if enc-type is RFC3394 then >> Message-Authentication-Code MUST also be present. Other enc-types >> can mandate it or not as needed. > > Since AES Key Wrap is the only one specified & SIV doesn't actually > exist as a standard, this doesn't make much sense to me. It makes sense if you think about it in terms of crypto-agility. If you're submitting a draft that only does AES Key wrap with no capability to substitute anything else then you can mandate other attributes that may be necessary. This isn't crypto-agile though. The subject of this thread concerns the crypto-agility requirement and to be crypto-agile it doesn't make sense to mandate use of attributes that are only necessary if you're using one particular enc-type. The whole idea is that we're going to be plugging in other enc-types, no? >> >> - do not require Mac-Randomizer if Message-Authentication-Code is >> present. The reason a deterministic authenticated encryption >> scheme like RFC3394 can provide what amounts to probabilistic >> authenticated encryption is because what it's wrapping is, >> itself, random. The further addition of randomness is unnecessary. > > Actually, this is largely irrelevant: the purpose of the Mac-Randomizer > is to facillitate the use of the Message-Authentication-Code in > accounting & CoA messages. It is actually independent of the > Keying-Material attribute. I suppose that we could further specify it > as only required if the Message-Authenticator-Attribute is used in one > of those messages... That would work I think. My comment was not very good because my real concern is the dependency on having a Mac-Randomizer if you have a Keying-Material attribute. The dependency may be happenstance but according to the draft if you have the Keying-Material attribute then you MUST also have a Mac-Randomizer. If that dependency was not there then I don't think I'd care so much. (Unrelated to crypto-agility, but an informative note on the point behind the Mac-Randomizer-- replay? some esoteric security property?-- would be most helpful and some text in the Security Considerations regarding the implications on reuse of this "random" number in different messages would be very important). >> >> - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its >> key wrapping varient) is deterministic. RFC3394 has a default IV >> which is used to determine whether the unwrapping was successful >> or not but that does not need to be communicated. >> draft-zorn-radius-keywrap even says that if RFC3394 is being used >> as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves >> no useful purpose. > > Fine. > >> >> - not everyone is comfortable with massive covert channels like KEK >> ID and KM ID. I suggest making them optional and using a bit it >> the reserved field to indicate their presense or absense. > > So having optional "massive covert channels" is somehow better? Why? Actually no they're not but I was trying to be generous since it is claimed that there are implementations using this already. But you're right. Get rid of the whole key id stuff. That is certainly acceptable. You're only recommending the creation of 2 new keys to implement this draft so key id fields are, strictly speaking, unnecessary. Dan. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 20:08:32 +0000 From: "David B. Nelson" To: Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 16:08:48 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00fb01c7d477$c56229d0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgADuxrAAABtQUA= Glen Zorn writes... > There are multiple interoperable implementations which > have been NIST (& at in least one case) Common Criteria certified, > however, so we'll just be leaving it as is for now. I has previously asked if information on the implementations and the certifications you mention could (and would) be made available to the WG. I didn't get a response, so I'll ask again. Since the "certifyability" seems to be a selling point for this approach, it seems relevant for the WG to evaluate that information, in deciding on a solution. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 20:07:58 +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: Continued discussion of RADIUS Crypto-Agility Date: Wed, 1 Aug 2007 13:07:12 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B6492F@xmb-sjc-215.amer.cisco.com> Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQAAYtyRA= From: "Glen Zorn \(gwz\)" To: "Romascanu, Dan \(Dan\)" , "David B. Nelson" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1146; t=1185998835; x=1186862835; 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=20Continued=20discussion=20of=20RADIUS=20Crypto-Agility |Sender:=20; bh=UwRyVM0jJwqc6ivfnGBkypaLEpZDOTTfvYlw/wycx8I=; b=OawmOn4MLWII4+JNyaJJN8qvWp9yS0YqIGNU3XlJ1Fi7aR315Zg5u7EQJhZ5HRMcEexDsLKc SipySqZBrKoHiwGjMZLJumXuc/IxtNOpQqoVyP8jhnfpYblnOVS/UD7x; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); Romascanu, Dan (Dan) allegedly scribbled on Wednesday, August 01, 2007 10:12 AM: ... > Seriously, I was the one to recommend the author to ask for a time > slot on the RADEXT agenda. I believe that the RADSEC work is if not > within at least related to the WG scope (but not necessarily as a > crypto-agility solution), although undertaking it would mean an > extension of the charter.=20 OK, I'm confused: the scope of a WG is _not_ defined by its charter? If the charter doesn't define the scope of a WG, what does? > I believe it was good for the working group > to hear it and discuss whether there is consensus to include it as a > future work item. This discussion is happening right now, and it's > good. =20 Just a historical note: in the beginnings of Diameter development, the adoption of TCP as a transport for RADIUS between servers was discussed at length (how this perfectly reasonable idea evolved into TCP/SCTP everywhere I don't know). If the IESG's goal is still to avoid having RADIUS & Diameter compete then adopting RADSEC is a very bad idea.=20 =20 >=20 > Dan -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 19:56:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 12:55:53 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B6491E@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgADuxrA From: "Glen Zorn \(gwz\)" To: "Dan Harkins" , "Joseph Salowey \(jsalowey\)" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=339; t=1185998147; x=1186862147; 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=20Crypto-agility=20requirement=20and=20=20=20=20=20=20d raft-zorn-radius-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=GFAZsh8K87AL+SlcV7EvLAFwZQmK/iU1iTZBPofhY1s=; b=T6ivdO36/Ju5DhYT1nhdZ/f1kT85Ci4Nzy6xNC6wFRlP9IUj7KjKNmntrjzJiVLPUoulkxsl hLU1Ct2B5caJ37WEz3kRL95n/W6kfTBVv9dcAyWfqd6hKqGqGWn/aMmS; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); BTW, I forgot to mention in my reply: if our draft is adopted as a WG item, we will be more than amenable to your (and any other) suggestions for improvement. There are multiple interoperable implementations which have been NIST (& at in least one case) Common Criteria certified, however, so we'll just be leaving it as is for now. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 19:51:43 +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: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Date: Wed, 1 Aug 2007 12:51:11 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B64911@xmb-sjc-215.amer.cisco.com> Thread-Topic: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap Thread-Index: AcfUZm7Xqud68gOYTsKDZ9Z+vnhPhgABY5jw From: "Glen Zorn \(gwz\)" To: "Dan Harkins" Cc: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2391; t=1185997873; x=1186861873; 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=20Crypto-agility=20requirement=20and=20=20=20=20=20=20d raft-zorn-radius-encattr/draft-zorn-radius-keywrap |Sender:=20; bh=o/6Z8L32L8nCACee0hOcySWjHRbACKBJROIbf4/Kg2Q=; b=WJm6hIPQ43ymQCrYl9mLDNlC1TpVfk06oDXuv+Kn+ruyBO6XJsmgVT9YMN1/+5N2G9T+YUOP tKHJ0E1THJsA4CX3B8OXbdhPatW//6B2TPBr8VwXfBlHhn8guffdudQh; Authentication-Results: sj-dkim-2; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04 AM: > Hi Joe, >=20 > As I mentioned at the mic during the meeting at IETF69 > draft-zorn-radius-keywrap is not really very (crypto-)agile and I > think with some minor modifications could be made more so. For > example: =20 >=20 > - do not require that Message-Authentication-Code MUST be present > if Keying-Material is present. SIV is a much preferrable key > wrapping technique than RFC3394 and if SIV was specified in the > enc-type of Keying-Material then Message-Authentication-Code would > be redundant. Please say that if enc-type is RFC3394 then > Message-Authentication-Code MUST also be present. Other enc-types > can mandate it or not as needed. Since AES Key Wrap is the only one specified & SIV doesn't actually exist as a standard, this doesn't make much sense to me. >=20 > - do not require Mac-Randomizer if Message-Authentication-Code is > present. The reason a deterministic authenticated encryption > scheme like RFC3394 can provide what amounts to probabilistic > authenticated encryption is because what it's wrapping is, > itself, random. The further addition of randomness is unnecessary. Actually, this is largely irrelevant: the purpose of the Mac-Randomizer is to facillitate the use of the Message-Authentication-Code in accounting & CoA messages. It is actually independent of the Keying-Material attribute. I suppose that we could further specify it as only required if the Message-Authenticator-Attribute is used in one of those messages... >=20 > - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its > key wrapping varient) is deterministic. RFC3394 has a default IV > which is used to determine whether the unwrapping was successful > or not but that does not need to be communicated. > draft-zorn-radius-keywrap even says that if RFC3394 is being used > as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves > no useful purpose.=20 Fine. >=20 > - not everyone is comfortable with massive covert channels like KEK > ID and KM ID. I suggest making them optional and using a bit it > the reserved field to indicate their presense or absense. So having optional "massive covert channels" is somehow better? Why? ... -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 19:15:34 +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-09.txt Message-Id: Date: Wed, 01 Aug 2007 15:15:01 -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-09.txt Pages : 37 Date : 2007-8-1 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-09.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-09.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-09.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-8-1142431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-rfc3576bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-rfc3576bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-1142431.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, 01 Aug 2007 19:00:57 +0000 Message-ID: From: "Bernard Aboba" To: opsawg@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 01 Aug 2007 12:00:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Please note that the publication date of RFC 3588 (which included a Nokia author) was September 2003, and that this Nokia IPR claim was submitted to the IETF on January 6, 2004, several months after the Diameter RFC was published. As co-chair of the AAA WG, I would not have allowed RFC 3588 to be submitted to the IESG for publication without WG discussion of the IPR claim, had the IPR claim been submitted prior to publication of the Diameter RFC. >From: >To: , , >Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter >vs. RadSec patent research:EP1147635 >Date: Wed, 1 Aug 2007 12:15:02 -0500 > >Hi all, > >I was asked to forward this to the DiME, RADext and OPSA WG mailing lists. > >Thanks, >John > > > Dear Stefan, > > I asked John to forward this message as I'm not a regular on the DIME >list. I'm responsible for handling IETF related IPR cases in Nokia. > > As you suggested, Nokia believes EP1147635, and other members of the same >patent family, are essential to practice RFC3588. > > However, I do suggest that you, and other folks interested, contact your >respective legal folks regarding the implication of the existence of the >patent, in conjunction with our patent declaration. I do not believe that >Stefan's claim is correct: > > Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > > > In order to help the group to understand our declaration, please allow me >to provide a simplistic explanation. As for the binding legal language, >please see the declaration itself (cited correctly by Stefan in his >original email): > > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > > Our licensing declaration is what is commonly known as a "non-assert" >statement. What it says is that if you don't come after Nokia with your >patents, Nokia will not use its patents against your RFC 3588 >implementation. > > Non-assert statements like this are widely used in the IETF, as they are >believed to provide sufficient defensive protection for the owner, while >still allowing implementers and users to exercise the protected technology >without a license and for free, as long as they behave similarly nice (i.e. >not going after Nokia with their patents). In that, non-asserts are >believed to be compatible with most open source licenses. > > > Feel free to contact me in private if you have more questions. > > Best regards, > Stephan Wenger > Stephan.Wenger@nokia.com > > -----Original Message----- > > From: ext Stefan Winter [mailto:stefan.winter@restena.lu] > Sent: 01 August, 2007 15:28 > To: radiusext@ops.ietf.org; dime@ietf.org > Subject: [Dime] First results on Diameter vs. RadSec patent > research:EP1147635 > > Hello all, > > (sorry for cross-posting, this may also be of interest for dime) > > when presenting the RadSec draft in IETF69 Chicago, I > mentioned the patent claims of Nokia concerning Diameter. As a > reaction, some participants claimed that RadSec itself > implements a subset of the Diameter features and may very well > itself be subject to these patents. So I started an > investigation in this respect. > > I started the research myself by grabbing a copy of patent > EP1147635 by Nokia, which is claiming to affect Diameter. My > focus of the patent's examination was whether this patent > might also affect RadSec. > > The content of this patent is, in short, that packets on a > network get tagged as "possible duplicate" on retransmission > in order to make the endpoint aware that the received content > may be a duplicate of a previous packet. It also provides a > mechanism to correlate the multiple copies even when the > packets took different paths through the network. > > Diameter does exactly that, described in section 5.5.4 > "Failover and Failback Procedures" of RFC3588: a bit in the > Diameter header, the "T" bit, is set whenever a Diameter > packet needed to be retransmitted. Also, Diameter packets > carry an end-to-end identifier that makes it possible to > identify duplicates. > > This means that at least from my point of view, Nokia's claim > concerning Diameter is true. Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > (Note: I am not a lawyer. This is just my interpretation; > consider my knowledge being "Slashdot-level"). > From the wording in this section 5.5.4 and the explanation of > the T bit in chapter 3, it seems that setting the T bit is > mandatory on retransmissions, so adhering to the protocol > specification leaves no room for circumventing the content of > the patent (e.g., by keeping it 0 at all times). > > Luckily, RadSec does not implement such a sophisticated > duplicate packet detection algorithm. So, this particular > patent appears not to be of any concern for implementors of RadSec. > > I will continue investigating the bunch of other patents and > patent applications relating to Diameter as soon as I get > copies of them. For reference, here is Nokia's claim statement > concerning Diameter (as submitted to the IETF IPR tracker): > > ---------- > > Title: Nokia's Statement About IPR Claimed in RFC 3588 > Received: January 6, 2004 > From: harri.t.honkasalo@nokia.com > > This is to advise the IETF that Nokia believes the Nokia > patents: EP1147635 and AU757984, and the related patent > applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, > JP2000-595452 and US09/903863 may be relevant to Diameter Base > Protocol RFC3588. > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > Regards, > > Harri Honkasalo > > Director of IPR, Standard Technology > > Nokia Corporation > > ---------- > > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > > RESTENA Foundation - Réseau Téléinformatique de l'Education > Nationale et de la Recherche R&D Engineer > > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > email: stefan.winter@restena.lu Tel.: +352 424409-1 > http://www.restena.lu Fax: +352 422473 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 18:04:38 +0000 Message-ID: <50956.69.12.173.8.1185991451.squirrel@www.trepanning.net> Date: Wed, 1 Aug 2007 11:04:11 -0700 (PDT) Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" Cc: radiusext@ops.ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Joe, As I mentioned at the mic during the meeting at IETF69 draft-zorn-radius-keywrap is not really very (crypto-)agile and I think with some minor modifications could be made more so. For example: - do not require that Message-Authentication-Code MUST be present if Keying-Material is present. SIV is a much preferrable key wrapping technique than RFC3394 and if SIV was specified in the enc-type of Keying-Material then Message-Authentication-Code would be redundant. Please say that if enc-type is RFC3394 then Message-Authentication-Code MUST also be present. Other enc-types can mandate it or not as needed. - do not require Mac-Randomizer if Message-Authentication-Code is present. The reason a deterministic authenticated encryption scheme like RFC3394 can provide what amounts to probabilistic authenticated encryption is because what it's wrapping is, itself, random. The further addition of randomness is unnecessary. - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its key wrapping varient) is deterministic. RFC3394 has a default IV which is used to determine whether the unwrapping was successful or not but that does not need to be communicated. draft-zorn-radius-keywrap even says that if RFC3394 is being used as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves no useful purpose. - not everyone is comfortable with massive covert channels like KEK ID and KM ID. I suggest making them optional and using a bit it the reserved field to indicate their presense or absense. Crypto-agility isn't just the ability to substitute one algorithm for another, it should include the jettisoning any unnecessary baggage that might've been appropriate (or required) for one algorithm if it's not appropriate (or required) for another. Some of this stuff might be needed if you're using RFC3394 and some stuff might be useful for whatever your existing implementation is using them for but I don't think I should be forced to add covert channels, repeat known information (A6A6A6A6...), or unnecessarily integrity protect an already integrity protected message. It surely isn't (crypto-)agile to force me to. thanks, Dan. On Mon, July 23, 2007 9:03 am, Joseph Salowey (jsalowey) wrote: > > > SECURITY SERVICES > > 2. Proposals MUST support the negotiation of cryptographic algorithms > for per-packet integrity/authentication protection. > Support for confidentiality of entire RADIUS packets is OPTIONAL. > However, proposals MUST support the negotiation of algorithms for > encryption (sometimes referred to as "hiding") of RADIUS attributes. > If possible, it is desirable for proposals to provide for the encryption > of existing attributes. This includes existing "hidden" > attributes as well as attributes (such as location attributes) that > require confidentiality. > > Included in negotiation techniques are "hint and consent" mechanisms > where the NAS provides a list of algorithms and the server selects one. > > [Joe] Algorithms within the proposal are identified so they can be > replaced. The client can specify the algorithm it wishes the server to > use. > > > 3. Proposals MUST support replay protection. The existing mechanisms > for replay protection are considered adequate and should be maintained. > > [Joe] Existing replay protection mechanisms are maintained > > 4. Crypto-agility solutions MUST specify mandatory-to-implement > algorithms for each mechanism. > > [Joe] Mandatory to implement algorithms are specified (AES-CBC, > AES-Keywrap, HMAC-SHA1) > > BACKWARD COMPATIBILITY > > 5. Solutions to the problem MUST demonstrate backward compatibility with > existing RADIUS implementations. That is, a crypto-agility solution > needs to be able to send packets that a legacy RADIUS client or server > will receive and process successfully. Similarly, a crypto-agility > solution needs to be capable of receiving and processing packets from a > legacy RADIUS client or server. > > [Joe] The proposal requires the use of new RADIUS attributes. All > other aspects of the RADIUS protocol can remain the same, so backward > compatibility is possible. However it is important to note that if > stronger that current security algorithms are required then backwards > compatibility is not possible. > > 6. Crypto-agility solutions MUST avoid security compromise, even in > situations where the existing cryptographic algorithms utilized by > RADIUS implementations are shown to be weak enough to provide little or > no security (e.g. in event of compromise of the "legacy" RADIUS shared > secret). Included in this would be protection against bidding down > attacks. > > [Joe] Depending upon the selection of the key the new protection can be > completely separate from the existing protection. The selection of the > key is currently a deployment choice. > > > INTEROPERABILITY AND CHANGE CONTROL > > 7. Proposals MUST indicate a willingness to cede change control to the > IETF. > > [Joe] Change control can be cede. An informational RFC may be published > to document existing implementations. > > 8. Crypto-agility solutions MUST be interoperable between independent > implementations based purely on the information provided in the > specification. > > [Joe] Interoperable implementations exist based on this specification. > These implementations use VSAs instead of standard attributes. > > SCOPE OF WORK > > 9. Crypto-agility solutions MUST apply to all RADIUS packet types, > including Access-Request, Challenge, Reject & Accept, > Accounting-Request/Response, and CoA/Disconnect messages. > > [Joe] The attributes described can be added to any of these mechanisms. > > 10. Proposals MUST include a Diameter compatibility section, although it > is expected that the work will occur purely within RADIUS or in the > transport, and therefore does not affect message data that is exchanged > with Diameter. > > [Joe] A Diameter compatibility section will need to be added. > > 11. Crypto-agility solutions SHOULD NOT require fundamental changes to > The RADIUS operational model, such as the introduction of new commands > Or maintenance of state on the RADIUS server. Similarly, a proposal > Should focus on the crypto-agility problem and nothing else. For > example, proposals should not require new attribute formats or include > definition of new RADIUS services. Unless modified, the restrictions in > the RADEXT WG charter apply. > > [Joe] This solution works well with the existing implementations. It > does not require major changes to the RADIUS protocol. In particular it > does not necessarily introduce new "session" state maintenance > requirements on the server. > > Note that for the purposes of this work, the RADEXT WG charter > Restriction against definition of "new security mechanisms" should be > interpreted as prohibiting changes to the basic RADIUS packet format > (e.g. headers), but permits new crypto-algorithms to be substituted For > use in existing security mechanisms. > > [Joe] This is what the proposal does. It is very close to existing > RADIUS protection mechanisms requiring minimal change to existing > 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: > -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 17:40:08 +0000 From: "David B. Nelson" To: , , Subject: RE: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 1 Aug 2007 13:40:17 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00ec01c7d463$06547e80$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjAAACHXSA= > Non-assert statements like this are widely used in the IETF, > as they are believed to provide sufficient defensive protection > for the owner, while still allowing implementers and users to > exercise the protected technology without a license and for > free, as long as they behave similarly nice... It is true that "non-assert" IPR statements are frequently issued these days. > In that, non-asserts are believed to be compatible with most > open source licenses. Compatible? What does that mean? A reciprocal non-assert is not quite the same thing as open source. Open source has to do with copyright IPR, not patent IPR. Additionally, reciprocal non-asserts would appear to apply to all patents that an organization may hold, not only those that are related to standards. In that regard, it is tantamount to an implicit (and broad) cross-licensing agreement, which would include patents covering proprietary technology as well as open standards based technology. Still, it is better than nothing, and very useful to companies that don't intend to enforce _any_ of their patent portfolio against infringement by the non-assert grantors. Of course, it also works out fine for companies that don't have patents to enforce. :-) Standard disclaimer: I am not a lawyer. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 17:32:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued discussion of RADIUS Crypto-Agility Date: Wed, 1 Aug 2007 13:32:09 -0400 Message-ID: Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQAADQt2A= From: "Stephen Hanna" To: "Romascanu, Dan (Dan)" , "Glen Zorn (gwz)" , "David B. Nelson" Cc: Thanks, Dan. I'm glad you did suggest that we consider the RADSEC work. Now we can consider the alternatives on their technical merits and set aside the charter or process questions for the moment (to be revisited if necessary). I have asked Juniper's RADIUS experts to join us for this discussion. They should be here within a few hours. Sorry for the delay. Thanks, Steve -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, August 01, 2007 1:12 PM To: Glen Zorn (gwz); David B. Nelson Cc: radiusext@ops.ietf.org Subject: RE: Continued discussion of RADIUS Crypto-Agility =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Tuesday, July 31, 2007 10:08 PM > To: David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: RE: Continued discussion of RADIUS Crypto-Agility >=20 > David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 11:25 > AM: >=20 > > Glen Zorn writes... > >=20 > >> To 1) ignore our charter (not to mention the (at best)=20 > disingenuous=20 > >> '?' regarding it in the presentation)... > >=20 > > To be fair, the authors of this ID did indicate they knew=20 > it was out=20 > > of charter scope, and therefore not eligible for the Crypto-Agility=20 > > solution, at the time that they requested the presentation slot in=20 > > RADEXT. The "?" apparently came about as a result of=20 > discussions in=20 > > the O&M Area WG earlier in the week. >=20 > So can we appropriately blame this nonsense (surprise!) on the IESG?=20 >=20 If finding somebody to blame solves the problem or at least half of it, I'll step ahead :-) Seriously, I was the one to recommend the author to ask for a time slot on the RADEXT agenda. I believe that the RADSEC work is if not within at least related to the WG scope (but not necessarily as a crypto-agility solution), although undertaking it would mean an extension of the charter. I believe it was good for the working group to hear it and discuss whether there is consensus to include it as a future work item. This discussion is happening right now, and it's good.=20 Dan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Aug 2007 17:27:53 +0000 Date: Wed, 1 Aug 2007 13:27:20 -0400 From: Barney Wolff Cc: opsawg@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Subject: Re: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Message-ID: <20070801172720.GA17072@pit.databus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) In the 1970s, Western Union's Infomaster message switch attached a "Suspected Duplicate" tag to every retransmitted message. I wonder if this tidbit was known to the examiners as relevant prior art. -- Barney Wolff I never met a computer I didn't like. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Aug 2007 17:15:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D45F.8194DEFE" Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 1 Aug 2007 12:15:02 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> Thread-Topic: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjA From: To: , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I was asked to forward this to the DiME, RADext and OPSA WG mailing = lists. =20 =20 Thanks, John Dear Stefan, I asked John to forward this message as I'm not a regular on the DIME = list. I'm responsible for handling IETF related IPR cases in Nokia. As you suggested, Nokia believes EP1147635, and other members of the = same patent family, are essential to practice RFC3588. However, I do suggest that you, and other folks interested, contact = your respective legal folks regarding the implication of the existence = of the patent, in conjunction with our patent declaration. I do not = believe that Stefan's claim is correct: Every implementation of the =20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 In order to help the group to understand our declaration, please allow = me to provide a simplistic explanation. As for the binding legal = language, please see the declaration itself (cited correctly by Stefan = in his original email): Nokia agrees not to assert those claims in Nokia above =20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Our licensing declaration is what is commonly known as a "non-assert" = statement. What it says is that if you don't come after Nokia with your = patents, Nokia will not use its patents against your RFC 3588 = implementation. =20 Non-assert statements like this are widely used in the IETF, as they = are believed to provide sufficient defensive protection for the owner, = while still allowing implementers and users to exercise the protected = technology without a license and for free, as long as they behave = similarly nice (i.e. not going after Nokia with their patents). In = that, non-asserts are believed to be compatible with most open source = licenses. =09 =09 Feel free to contact me in private if you have more questions. =20 Best regards, Stephan Wenger Stephan.Wenger@nokia.com =20 -----Original Message----- From: ext Stefan Winter [mailto:stefan.winter@restena.lu]=20 Sent: 01 August, 2007 15:28 To: radiusext@ops.ietf.org; dime@ietf.org Subject: [Dime] First results on Diameter vs. RadSec patent=20 research:EP1147635 Hello all, (sorry for cross-posting, this may also be of interest for dime) when presenting the RadSec draft in IETF69 Chicago, I=20 mentioned the patent claims of Nokia concerning Diameter. As a=20 reaction, some participants claimed that RadSec itself=20 implements a subset of the Diameter features and may very well=20 itself be subject to these patents. So I started an=20 investigation in this respect. I started the research myself by grabbing a copy of patent=20 EP1147635 by Nokia, which is claiming to affect Diameter. My=20 focus of the patent's examination was whether this patent=20 might also affect RadSec. The content of this patent is, in short, that packets on a=20 network get tagged as "possible duplicate" on retransmission=20 in order to make the endpoint aware that the received content=20 may be a duplicate of a previous packet. It also provides a=20 mechanism to correlate the multiple copies even when the=20 packets took different paths through the network. Diameter does exactly that, described in section 5.5.4=20 "Failover and Failback Procedures" of RFC3588: a bit in the=20 Diameter header, the "T" bit, is set whenever a Diameter=20 packet needed to be retransmitted. Also, Diameter packets=20 carry an end-to-end identifier that makes it possible to=20 identify duplicates. This means that at least from my point of view, Nokia's claim=20 concerning Diameter is true. Every implementation of the=20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 (Note: I am not a lawyer. This is just my interpretation;=20 consider my knowledge being "Slashdot-level"). From the wording in this section 5.5.4 and the explanation of=20 the T bit in chapter 3, it seems that setting the T bit is=20 mandatory on retransmissions, so adhering to the protocol=20 specification leaves no room for circumventing the content of=20 the patent (e.g., by keeping it 0 at all times). Luckily, RadSec does not implement such a sophisticated=20 duplicate packet detection algorithm. So, this particular=20 patent appears not to be of any concern for implementors of RadSec. I will continue investigating the bunch of other patents and=20 patent applications relating to Diameter as soon as I get=20 copies of them. For reference, here is Nokia's claim statement=20 concerning Diameter (as submitted to the IETF IPR tracker): ---------- Title: Nokia's Statement About IPR Claimed in RFC 3588 Received: January 6, 2004 From: harri.t.honkasalo@nokia.com This is to advise the IETF that Nokia believes the Nokia patents: EP1147635 and AU757984, and the related patent applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, JP2000-595452 and US09/903863 may be relevant to Diameter Base=20 Protocol RFC3588. Nokia agrees not to assert those claims in Nokia above=20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Regards, Harri Honkasalo Director of IPR, Standard Technology Nokia Corporation ---------- Greetings, Stefan Winter -- Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education=20 Nationale et de la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu Tel.: +352 424409-1=20 http://www.restena.lu Fax: +352 422473 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I was asked to forward this to the DiME, = RADext=20 and OPSA WG mailing lists.  
 
Thanks,
John

Dear Stefan,

I asked John to forward this message as I'm not a regular on the = DIME=20 list.  I'm responsible for handling IETF related IPR cases in=20 Nokia.

As you suggested, Nokia believes EP1147635, and other members of = the same=20 patent family, are essential to practice RFC3588.

However, I do suggest that you, and other folks interested, = contact your=20 respective legal folks regarding the implication of the existence of = the=20 patent, in conjunction with our patent declaration.  I do not = believe=20 that Stefan's claim is correct:
Every=20 implementation of the 
Diameter base protocol will use the patented = technology=20 and 
needs to either license it or will violate=20 it. 

In order to help the group to understand our declaration, please = allow me=20 to provide a simplistic explanation.  As for the binding legal = language,=20 please see the declaration itself (cited correctly by Stefan in his = original=20 email):

Nokia agrees not to assert those claims in = Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Our licensing declaration is what is commonly known as a = "non-assert"=20 statement.  What it says is that if you don't come after Nokia = with your=20 patents, Nokia will not use its patents against your RFC 3588=20 implementation.
  
Non-assert statements like this are widely used in the IETF, as = they are=20 believed to provide sufficient defensive protection for the owner, = while still=20 allowing implementers and users to exercise the protected technology = without a=20 license and for free, as long as they behave similarly nice (i.e. not = going=20 after Nokia with their patents).  In that, non-asserts are = believed to be=20 compatible with most open source licenses.
Feel free to contact me in private if you have more = questions.
 
Best regards,
Stephan Wenger
Stephan.Wenger@nokia.com
 
 -----Original=20 Message-----
From: ext Stefan Winter [mailto:stefan.winter@restena.lu<= /A>] 
Sent: 01 August, 2007 15:28
To: radiusext@ops.ietf.org; = dime@ietf.org
Subject: [Dime] First results on = Diameter vs.=20 RadSec patent 
research:EP1147635

Hello all,

(sorry for cross-posting, this may also = be of=20 interest for dime)

when presenting the RadSec draft in = IETF69=20 Chicago, I 
mentioned the patent claims of Nokia = concerning=20 Diameter. As a 
reaction, some participants claimed = that RadSec=20 itself 
implements a subset of the Diameter = features and=20 may very well 
itself be subject to these patents. So = I started=20 an 
investigation in this respect.

I started the research myself by = grabbing a copy=20 of patent 
EP1147635 by Nokia, which is claiming = to affect=20 Diameter. My 
focus of the patent's examination was = whether=20 this patent 
might also affect RadSec.

The content of this patent is, in = short, that=20 packets on a 
network get tagged as "possible = duplicate" on=20 retransmission 
in order to make the endpoint aware = that the=20 received content 
may be a duplicate of a previous = packet. It also=20 provides a 
mechanism to correlate the multiple = copies even=20 when the 
packets took different paths through = the=20 network.

Diameter does exactly that, described = in section=20 5.5.4 
"Failover and Failback Procedures" of = RFC3588: a=20 bit in the 
Diameter header, the "T" bit, is set = whenever a=20 Diameter 
packet needed to be retransmitted. = Also, Diameter=20 packets 
carry an end-to-end identifier that = makes it=20 possible to 
identify duplicates.

This means that at least from my point = of view,=20 Nokia's claim 
concerning Diameter is true. Every = implementation=20 of the 
Diameter base protocol will use the = patented=20 technology and 
needs to either license it or will = violate=20 it. 
(Note: I am not a lawyer. This is just = my=20 interpretation; 
consider my knowledge being=20 "Slashdot-level").
From the wording in this section 5.5.4 = and the=20 explanation of 
the T bit in chapter 3, it seems that = setting the=20 T bit is 
mandatory on retransmissions, so = adhering to the=20 protocol 
specification leaves no room for = circumventing=20 the content of 
the patent (e.g., by keeping it 0 at = all=20 times).

Luckily, RadSec does not implement such = a=20 sophisticated 
duplicate packet detection algorithm. = So, this=20 particular 
patent appears not to be of any concern = for=20 implementors of RadSec.

I will continue investigating the bunch = of other=20 patents and 
patent applications relating to = Diameter as soon=20 as I get 
copies of them. For reference, here is = Nokia's=20 claim statement 
concerning Diameter (as submitted to = the IETF IPR=20 tracker):

----------

Title: Nokia's Statement About IPR = Claimed in RFC=20 3588
Received: January 6, 2004
From: harri.t.honkasalo@nokia.com

This is to advise the IETF that Nokia = believes=20 the Nokia
patents: EP1147635 and AU757984, and = the related=20 patent
applications: BRPI0007603-1, CA2360093, = CN00804050.8, FI990102,
JP2000-595452 and US09/903863 may be = relevant to=20 Diameter Base 
Protocol RFC3588.

Nokia agrees not to assert those claims = in Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Regards,

Harri Honkasalo

Director of IPR, Standard = Technology

Nokia Corporation

----------


Greetings,

Stefan Winter

--
Stefan WINTER

RESTENA Foundation - R=E9seau = T=E9l=E9informatique de=20 l'Education 
Nationale et de la Recherche R&D=20 Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: stefan.winter@restena.lu =  =20   Tel.:     +352 424409-1 
http://www.restena.lu   =  =20           Fax:      +352=20 422473

<signature.asc>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime

------_=_NextPart_001_01C7D45F.8194DEFE-- -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 17:12:58 +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: Continued discussion of RADIUS Crypto-Agility Date: Wed, 1 Aug 2007 19:12:04 +0200 Message-ID: Thread-Topic: Continued discussion of RADIUS Crypto-Agility Thread-Index: AcfTjP9Rl5JnZ3ylS36H8v+QtrB48AADljmgAAD8OOAAAZLMoAAuExhQ From: "Romascanu, Dan (Dan)" To: "Glen Zorn (gwz)" , "David B. Nelson" Cc: =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Tuesday, July 31, 2007 10:08 PM > To: David B. Nelson > Cc: radiusext@ops.ietf.org > Subject: RE: Continued discussion of RADIUS Crypto-Agility >=20 > David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 11:25 > AM: >=20 > > Glen Zorn writes... > >=20 > >> To 1) ignore our charter (not to mention the (at best)=20 > disingenuous=20 > >> '?' regarding it in the presentation)... > >=20 > > To be fair, the authors of this ID did indicate they knew=20 > it was out=20 > > of charter scope, and therefore not eligible for the Crypto-Agility=20 > > solution, at the time that they requested the presentation slot in=20 > > RADEXT. The "?" apparently came about as a result of=20 > discussions in=20 > > the O&M Area WG earlier in the week. >=20 > So can we appropriately blame this nonsense (surprise!) on the IESG?=20 >=20 If finding somebody to blame solves the problem or at least half of it, I'll step ahead :-) Seriously, I was the one to recommend the author to ask for a time slot on the RADEXT agenda. I believe that the RADSEC work is if not within at least related to the WG scope (but not necessarily as a crypto-agility solution), although undertaking it would mean an extension of the charter. I believe it was good for the working group to hear it and discuss whether there is consensus to include it as a future work item. This discussion is happening right now, and it's good.=20 Dan -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 12:28:10 +0000 From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org, dime@ietf.org Subject: First results on Diameter vs. RadSec patent research: EP1147635 Date: Wed, 1 Aug 2007 14:28:01 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7300169.drvr3jyHbZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708011428.05998.stefan.winter@restena.lu> --nextPart7300169.drvr3jyHbZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, (sorry for cross-posting, this may also be of interest for dime) when presenting the RadSec draft in IETF69 Chicago, I mentioned the patent= =20 claims of Nokia concerning Diameter. As a reaction, some participants claim= ed=20 that RadSec itself implements a subset of the Diameter features and may ver= y=20 well itself be subject to these patents. So I started an investigation in=20 this respect. I started the research myself by grabbing a copy of patent EP1147635 by Nok= ia,=20 which is claiming to affect Diameter. My focus of the patent's examination= =20 was whether this patent might also affect RadSec. The content of this patent is, in short, that packets on a network get tagg= ed=20 as "possible duplicate" on retransmission in order to make the endpoint awa= re=20 that the received content may be a duplicate of a previous packet. It also= =20 provides a mechanism to correlate the multiple copies even when the packets= =20 took different paths through the network. Diameter does exactly that, described in section 5.5.4 "Failover and Failba= ck=20 Procedures" of RFC3588: a bit in the Diameter header, the "T" bit, is set=20 whenever a Diameter packet needed to be retransmitted. Also, Diameter packe= ts=20 carry an end-to-end identifier that makes it possible to identify duplicate= s. This means that at least from my point of view, Nokia's claim concerning=20 Diameter is true. Every implementation of the Diameter base protocol will u= se=20 the patented technology and needs to either license it or will violate it.= =20 (Note: I am not a lawyer. This is just my interpretation; consider my=20 knowledge being "Slashdot-level"). =46rom the wording in this section 5.5.4 and the explanation of the T bit i= n=20 chapter 3, it seems that setting the T bit is mandatory on retransmissions,= =20 so adhering to the protocol specification leaves no room for circumventing= =20 the content of the patent (e.g., by keeping it 0 at all times). Luckily, RadSec does not implement such a sophisticated duplicate packet=20 detection algorithm. So, this particular patent appears not to be of any=20 concern for implementors of RadSec. I will continue investigating the bunch of other patents and patent=20 applications relating to Diameter as soon as I get copies of them. For=20 reference, here is Nokia's claim statement concerning Diameter (as submitte= d=20 to the IETF IPR tracker): =2D--------- Title: Nokia's Statement About IPR Claimed in RFC 3588 Received: January 6, 2004 =46rom: harri.t.honkasalo@nokia.com This is to advise the IETF that Nokia believes the Nokia=20 patents: EP1147635 and AU757984, and the related patent=20 applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102,=20 JP2000-595452 and US09/903863 may be relevant to Diameter Base=20 Protocol RFC3588. Nokia agrees not to assert those claims in Nokia above mentioned=20 patents that apply to the RFC3588 and are technically necessary=20 to implement this IETF standard specification against any other=20 party in respect of its implementation of the specification, provided=20 that the party relying on this commitment does not assert its patents=20 against Nokia. Regards, Harri Honkasalo Director of IPR, Standard Technology Nokia Corporation =2D--------- Greetings, Stefan Winter =2D-=20 Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale= et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224= 73 --nextPart7300169.drvr3jyHbZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsHxV+jm90f8eFWYRAk80AJ9wcXaA0GQY378kr+rg5QUcyq+CngCfRVqQ CTn9jCcaLF/s8ZCXvyWe7G4= =NX7w -----END PGP SIGNATURE----- --nextPart7300169.drvr3jyHbZ-- -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 11:05:41 +0000 From: "David B. Nelson" To: "'radext mailing list'" Subject: RE: Crypto-agility Date: Wed, 1 Aug 2007 07:05:29 -0400 Message-ID: <003201c7d42b$e20f3c40$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcfUFOPS7FOLeAFvRj2x4apLhNQZfAAFJZAg Hannes Tschofenig writes... > Can someone explain me the scope and the planned timeframe > of the work? We discussed what crypto-agility meant, in general, terms at IETF-68. Basically, it means that IETF protocols that use cryptography need to have a reasonably modular way to substitute new algorithms and modes (new cipher suites). As one algorithm (e.g. MD5) weakens in the face of new attacks, it can then be replaced without redesigning the protocol and without undue difficulty of deployment. Designing protocols with a cipher suite identifier and/or cipher suite negotiation is one component of this effort. Modular implementations, that allow crypto-libraries to "plug in" to the base protocol module is another. In terms of RADIUS specific issues, the goal is to define alternative cryptographic primitives to replace the use of MD5 hashes and MD5-based stream ciphers, for things like the Message Authenticator and the "hidden" attributes, such as User-Password. It also encompasses the MS-PPE VSAs that are commonly used for solutions such as IEEE 802.11 WLANs. In RADIUS today there is only one key, the shared secret. In any new scheme, we need to understand what key(s) replaces the legacy shared secret and how those keys is distributed to all parties that need them. The goal is not to add general-purpose key management features to RADIUS, in the way a Kerberos KDC manages keys, for example. That would probably be going too far. The current RADEXT charter page says the timeframe is "done by December 2006", so we're quite late! :-) Hence the sense of urgency in our discussions. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 08:15:15 +0000 Message-ID: <46B03A88.20909@gmx.net> Date: Wed, 01 Aug 2007 09:47:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: 'radext mailing list' Subject: Crypto-agility Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Until the last meeting I thought that the goal was to address a quite limited scope, namely http://psg.com/lists/radiusext/2007/msg00053.html. Key management, for example, has not been subject of discussions in the past and I thought it would even be outside the scope. Can someone explain me the scope and the planned timeframe of the work? -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 08:15:08 +0000 Message-ID: <46B03A90.2060109@gmx.net> Date: Wed, 01 Aug 2007 09:47:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: 'radext mailing list' Subject: Attributes for Filtering & Redirection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Based on my old mail I wonder if someone has had time to think about the extensibility story. -- to unsubscribe send a message to radiusext-request@ops.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, 01 Aug 2007 07:01:56 +0000 From: Stefan Winter Organization: Fondation RESTENA To: "Glen Zorn \(gwz\)" Subject: Re: Continued discussion of RADIUS Crypto-Agility Date: Wed, 1 Aug 2007 09:01:24 +0200 User-Agent: KMail/1.9.7 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2372691.scbP7hd1D1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200708010901.29793.stefan.winter@restena.lu> --nextPart2372691.scbP7hd1D1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, a few clarifications below. > Not only is it out of scope of the charter, it directly violates a > number of the restrictions placed on the crypto-agility submissions from > the actual members of the WG. I, for one, have at least been aware of > the RADSEC activities for a couple of years now but for some reason they > have not deigned to inform the radext WG of them until now. Just to make this clear: I am in no way affiliated with the guys who=20 originally created the RadSec implementation (OSC). I'm not part of "them". I don't know why OSC didn't report on their implementation here earlier.=20 Probably because there were no interoperable other implementations, and so= =20 taking it to a *standardisation* organisation wasn't deemed urgent. Just=20 speculating though. OTOH, you mentioned in the session that you read their whitepaper when it w= as=20 new. You could have brought it to the attention of radiusext yourself, even= =20 if only to rebut it. > To 1) ignore our charter (not to mention the (at best) disingenuous '?' > regarding it in the presentation) and=20 As David said already: the same presentation was held at the opsawg meeting= ,=20 and I received word there that it *may* be possible that radiusext might =20 interpret its charter more loosely in the future. That's why I added that=20 question mark after the opsawg discussion took place. I did not act=20 disingenuous in any way. And I think I even said this during the=20 presentation. > 2) ignore the written requirements that every one else had to follow seems > to me at the very least arrogant. You mean the charter? I think I expressed myself quite clearly on audio dur= ing=20 the presentation that the proposal is not in the charter, submitted=20 independently and for information of interested RADIUS experts only. See al= so=20 my original post announcing the draft. I asked for presentation slots=20 sufficient time ahead of the meeting. You mean formality-wise? I submitted -00 before the deadline. If there are some other written requirements to follow, please enlighten me= =2E=20 It was my first IETF meeting after all, I may have missed something. > Note that I am _not_ 'hostile to the idea' -- I am, however,=20 > hostile toward arrogant academics proffering "new" schemes (that have > been around for years in one form or another) in direct contradiction of > the rules the rest of us (who actually participate in the WG, not just > drop by with our works of genius ;-) must follow. =46irst, I am not an academic. I work at an ISP that caters universities an= d=20 schools, that's about it. Second, I never said this was either new or genious. I hope I made clear th= at=20 this is a writeup to despcribe interoperability between existing=20 implementations. Both OSC and Stig Venaas got their due credit, and I also= =20 *did* mention that RadSec has been around for some years now. Third, I didn't just drop by. I kept reading radiusext for quite some time,= =20 since RADIUS is of vital relevance when operating a global-scale RADIUS wla= n=20 proxy environment, and knowing what's up is important. It's just that I=20 didn't have anything incredibly urgent or genious to say yet. > Therefore, I must=20 > insist that the RADSEC proposal be treated as only a an informative > presentation (in the nature of an informative liaison) Which is precisely what I wanted it to be in the first place. > and not accepted as a candidate for the crypto-agility solution. While it wasn't the intention of the draft to intersect with crypto-agility= =20 work items (the dynamic discovery part is the reason why we found the conce= pt=20 sexy), the number of people that consider it as worth investigating accordi= ng=20 to the straw poll provides some obvious evidence that it is at least worth= =20 discussing. To add a bit of constructivity to this mail, and leverage it above the=20 flame-war barrier, there is one aspect that RadSec or DTLS don't solve (and= =20 I'm not sure either if keywrap can do): in some situations, it might be=20 useful to have end-to-end security between the first RADIUS server in a pro= xy=20 chain (the one that the NAS is directly attached to, let's call it A) and t= he=20 last one (the home server which verifies the credentials, lets call it C),= =20 while all intermediates can not (lets call the set of those B). Our use cas= e=20 for this is when A receives an Access-Accept, but needs more info about the= =20 user ("How old is the user?") to put him either in a porn-filter VLAN or no= t,=20 and so asks C. AFAICT, none of the proposals can make sure that only A can= =20 ask this question - a server in B can always pretend to have its upstream=20 connection directly connected as a NAS, not another proxy server, assuming= =20 that the servers in B also have (other) NASes directly connected and so in= =20 some situations *could* legitimately ask this question (i.e. in keywrap=20 terms: they also have keying material to legitimately query C). A clean solution to this problem seems tough. BTW, solving this particular age verification problem could technically als= o=20 be solved without such an end-to-end assertion by pushing the info from C t= o=20 A unconditionally in the Access-Accept, not caring about A's backchannel or= =20 the presence of B in the middle. Unfortunately, this is personal data which= =20 can easily be tied to a real-life person, and so probably unconditionally=20 advertising it violates privacy laws in many countries. In other news, the IPR discussion about Diameter and a possible affection o= f=20 the patents in question by RadSec will be investigated from the side of=20 eduroam operations; I will let the group know what came out of this=20 investigation when it's done. Given the swamp that international patent=20 regulations are, this may take some time though. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart2372691.scbP7hd1D1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsC/J+jm90f8eFWYRAh9EAJ4uKJvYWlWg2fc9N3v6GeON5hSfngCfZFGq 4iJRFYkeFW9oml1ynmT/m2A= =qCry -----END PGP SIGNATURE----- --nextPart2372691.scbP7hd1D1-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: