submission of DNS-based dynamic discovery for RadSec (and DTLS)
Stefan Winter <stefan.winter@restena.lu> Fri, 27 February 2009 08:14 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324273A689C for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 27 Feb 2009 00:14:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Level:
X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqTH5r6TuKPK for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 27 Feb 2009 00:14:46 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7D0E3A688E for <radext-archive-IeZ9sae2@lists.ietf.org>; Fri, 27 Feb 2009 00:14:45 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1Lcxov-000Nyu-Ni for radiusext-data0@psg.com; Fri, 27 Feb 2009 08:11:45 +0000
Received: from [158.64.1.34] (helo=legolas.restena.lu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <stefan.winter@restena.lu>) id 1Lcxos-000NyT-2q for radiusext@ops.ietf.org; Fri, 27 Feb 2009 08:11:43 +0000
Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 209E7A98A3 for <radiusext@ops.ietf.org>; Fri, 27 Feb 2009 09:11:40 +0100 (CET)
Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 12650AF03C for <radiusext@ops.ietf.org>; Fri, 27 Feb 2009 09:11:40 +0100 (CET)
Message-ID: <49A7A03B.1010103@restena.lu>
Date: Fri, 27 Feb 2009 09:11:39 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
MIME-Version: 1.0
To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: submission of DNS-based dynamic discovery for RadSec (and DTLS)
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
Hello, I just uploaded the individual submission "NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS" ( http://tools.ietf.org/html/draft-winter-dynamic-discovery-00 ) ( http://tools.ietf.org/id/draft-winter-dynamic-discovery-00.txt ) with an intial attempt of - fixing the old diameter underscore-with-A-records algorithm - attempting to get internationalisation right (just a pathetic stub of what needs to be done) - described use cases where NAIs might be unrelated to DNS domains (please comment...) - reduced prose in the algorithm This is just a rough start, and I guess many things need discussion at SFO. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 27 Feb 2009 08:12:46 +0000 Message-ID: <49A7A03B.1010103@restena.lu> Date: Fri, 27 Feb 2009 09:11:39 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: submission of DNS-based dynamic discovery for RadSec (and DTLS) Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hello, I just uploaded the individual submission "NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS" ( http://tools.ietf.org/html/draft-winter-dynamic-discovery-00 ) ( http://tools.ietf.org/id/draft-winter-dynamic-discovery-00.txt ) with an intial attempt of - fixing the old diameter underscore-with-A-records algorithm - attempting to get internationalisation right (just a pathetic stub of what needs to be done) - described use cases where NAIs might be unrelated to DNS domains (please comment...) - reduced prose in the algorithm This is just a rough start, and I guess many things need discussion at SFO. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 26 Feb 2009 17:23:31 +0000 Message-ID: <BLU137-W4267E42820AD3DCB8F1DF393AD0@phx.gbl> Content-Type: multipart/alternative; boundary="_ab6632cf-3486-4839-a96c-c8cba327e2c9_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: Alan DeKok <aland@deployingradius.com> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: RE: Comments on "RADIUS Design Guidelines" document Date: Thu, 26 Feb 2009 09:23:14 -0800 MIME-Version: 1.0 --_ab6632cf-3486-4839-a96c-c8cba327e2c9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > OK. The question still remains=2C though. If an attribute is only use= d in > > Accounting-Request packets=2C does the argument against complex > > attributes still apply?=20 >=20 > My preference would be to say yes=2C especially where the contents of > that attribute are interpreted by *later* policies on the server. Now that we have RFC 5176=2C accounting data can be kept as "state" that is later used to construct CoA/Disconnect-Requests. Is this what you mean? --_ab6632cf-3486-4839-a96c-c8cba327e2c9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> >=3B >=3B OK. The question still remains=2C though. If an attribute i= s only used in<br>>=3B >=3B Accounting-Request packets=2C does the argu= ment against complex<br>>=3B >=3B attributes still apply? <br>>=3B <b= r>>=3B My preference would be to say yes=2C especially where the conten= ts of<br>>=3B that attribute are interpreted by *later* policies on the s= erver.<br><br>Now that we have RFC 5176=2C accounting data can be kept as "= state" that is<br>later used to construct CoA/Disconnect-Requests. =3B = Is this what you mean?<br><br><br></body> </html>= --_ab6632cf-3486-4839-a96c-c8cba327e2c9_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 26 Feb 2009 17:05:26 +0000 Message-ID: <49A6CBC7.1090403@deployingradius.com> Date: Thu, 26 Feb 2009 18:05:11 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Comments on "RADIUS Design Guidelines" document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> > Since [EXTEN] defines extensions to the standard RADIUS attribute >> > space and this section is talking about VSAs, the reference is a bit >> > confusing. Is the intent to suggest that VSAs other than type 0 >> > can also use the [EXTEN] format? >> >> Yes. > > You might say, "with a different vendor-type" to make that clear. OK. I'll add some text to that effect. >> RFC 2869, Section 5.19 (Table of Attributes) indicates that >> Connect-Info is permitted in Access-Request packets. Admins would like >> to use this information to perform policy checks. > > OK. The question still remains, though. If an attribute is only used in > Accounting-Request packets, does the argument against complex > attributes still apply? My preference would be to say yes, especially where the contents of that attribute are interpreted by *later* policies on 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 26 Feb 2009 16:58:45 +0000 Message-ID: <BLU137-W285F8A00E55A9EB7FA239B93AD0@phx.gbl> Content-Type: multipart/alternative; boundary="_a7cdaa28-eff1-4581-a693-4eb01b4958b3_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: Alan DeKok <aland@deployingradius.com> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: RE: Comments on "RADIUS Design Guidelines" document Date: Thu, 26 Feb 2009 08:58:03 -0800 MIME-Version: 1.0 --_a7cdaa28-eff1-4581-a693-4eb01b4958b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > Also=2C the use of SHOULD NOT implies that there are circumstances in w= hich > > protocol changes or new commands can be standardized outside the IETF. = Is > > this what was intended? >=20 > No. We can change this to a MUST NOT. >=20 > > Since [EXTEN] defines extensions to the standard RADIUS attribute > > space and this section is talking about VSAs=2C the reference is a bit > > confusing. Is the intent to suggest that VSAs other than type 0 > > can also use the [EXTEN] format? >=20 > Yes. You might say=2C "with a different vendor-type" to make that clear.=20 > RFC 2869=2C Section 5.19 (Table of Attributes) indicates that > Connect-Info is permitted in Access-Request packets. Admins would like > to use this information to perform policy checks. OK. The question still remains=2C though. If an attribute is only used in Accounting-Request packets=2C does the argument against complex attributes still apply? =20 --_a7cdaa28-eff1-4581-a693-4eb01b4958b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> <br>>=3B >=3B Also=2C the use of SHOULD NOT implies that there are circ= umstances in which<br>>=3B >=3B protocol changes or new commands can be= standardized outside the IETF. Is<br>>=3B >=3B this what was intended?= <br>>=3B <br>>=3B No. We can change this to a MUST NOT.<br>>=3B <b= r>>=3B >=3B Since [EXTEN] defines extensions to the standard RADIUS att= ribute<br>>=3B >=3B space and this section is talking about VSAs=2C the= reference is a bit<br>>=3B >=3B confusing. Is the intent to suggest t= hat VSAs other than type 0<br>>=3B >=3B can also use the [EXTEN] format= ?<br>>=3B <br>>=3B Yes.<br><br>You might say=2C "with a different ven= dor-type" to make that clear. <br><br>>=3B RFC 2869=2C Section 5.19 (Ta= ble of Attributes) indicates that<br>>=3B Connect-Info is permitted in Ac= cess-Request packets. Admins would like<br>>=3B to use this information = to perform policy checks.<br><br>OK. =3B The question still remains=2C = though. =3B If an attribute is only used in<br>Accounting-Request packe= ts=2C does the argument against complex<br>attributes still apply? =3B = <br></body> </html>= --_a7cdaa28-eff1-4581-a693-4eb01b4958b3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 26 Feb 2009 08:17:32 +0000 Message-ID: <49A64FDD.7070104@deployingradius.com> Date: Thu, 26 Feb 2009 09:16:29 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Comments on "RADIUS Design Guidelines" document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: ... > This document includes quotes from pre-5738 RFCs. Should we be using > the new "pre-5738" boilerplate? Likely, yes. > This would seem to suggest that support for new authentication mechanisms > can be standardized outside the IETF, as long as the guidelines are > followed. If it's SDO specific... > Also, the use of SHOULD NOT implies that there are circumstances in which > protocol changes or new commands can be standardized outside the IETF. Is > this what was intended? No. We can change this to a MUST NOT. > Since [EXTEN] defines extensions to the standard RADIUS attribute > space and this section is talking about VSAs, the reference is a bit > confusing. Is the intent to suggest that VSAs other than type 0 > can also use the [EXTEN] format? Yes. > s/discovery/discover/ Fixed, thanks. > Even though the type is Text, the rest of the description indicates > that it is a complex attribute: > > Since accounting data is typically only written to stable storage without > examination, does the reasoning against complex attributes really apply > here? RFC 2869, Section 5.19 (Table of Attributes) indicates that Connect-Info is permitted in Access-Request packets. Admins would like to use this information to perform policy checks. e.g. Customer X has service Y, which doesn't permit them access to the "high bandwidth" connection. Right now, they have to write regular expressions to parse the Connect-Info attribute into multiple fields, and then apply the bandwidth checks. This text was added as a direct result of seeing this problem occur in the field. 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 25 Feb 2009 16:11:26 +0000 Message-ID: <BLU137-W28E963586D36F1862428C993AC0@phx.gbl> Content-Type: multipart/alternative; boundary="_565f5acc-1fea-4ff9-a45d-1679ff0ec532_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Comments on "RADIUS Design Guidelines" document Date: Wed, 25 Feb 2009 08:10:43 -0800 MIME-Version: 1.0 --_565f5acc-1fea-4ff9-a45d-1679ff0ec532_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully=2C as they describe your rights and restrictions with respect to this document. This document includes quotes from pre-5738 RFCs. Should we be using the new "pre-5738" boilerplate? It is RECOMMENDED that SDOs and vendors seek review of RADIUS attribute specifications from the IETF. However=2C when specifications are SDO specific=2C re-use existing data types=2C and follow these guidelines=2C they do not require IETF review. . . . The advice in this document applies to attributes used to encode service-provisioning or authentication data. RADIUS protocol changes=2C or specification of attributes (such as Service-Type) that can be used to=2C in effect=2C provide new RADIUS commands require greater expertise and deeper review=2C as do changes to the RADIUS operational model=2C as described in Section 3.3 . Such changes SHOULD NOT be undertaken outside the IETF and when handled within the IETF require "IETF Consensus" for adoption=2C as noted in [RFC3575] Section 2.1. This would seem to suggest that support for new authentication mechanisms can be standardized outside the IETF=2C as long as the guidelines are follo= wed. Also=2C the use of SHOULD NOT implies that there are circumstances in which protocol changes or new commands can be standardized outside the IETF. Is this what was intended? Note that the Vendor type field in the recommended VSA format is only a single octet=2C like the RADIUS type field. While this limitation results in an efficient encoding=2C there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also=2C an SDO can be comprised of multiple subgroups=2C each of whom can desire autonomy over the definition of attributes within their group. In such a situation=2C a 16-bit Vendor type field would be more appropriate: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Vendor type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If additional functionality is required=2C the format defined in [EXTEN] SHOULD be used. Since [EXTEN] defines extensions to the standard RADIUS attribute space and this section is talking about VSAs=2C the reference is a bit confusing. Is the intent to suggest that VSAs other than type 0 can also use the [EXTEN] format? As a last resort=2C where the above techniques cannot be made to work=2C it may be possible to apply the techniques described in [RFC4821] to discovery the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. s/discovery/discover/ Even though the type is Text=2C the rest of the description indicates that it is a complex attribute: Since accounting data is typically only written to stable storage without examination=2C does the reasoning against complex attributes really apply here? --_565f5acc-1fea-4ff9-a45d-1679ff0ec532_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'>  =3B =3B Copyright (c) 2009 IETF Trust and the persons identified a= s the<br> =3B =3B document authors. =3B All rights reserved.<br= ><br> =3B =3B This document is subject to BCP 78 and the IETF Trust= 's Legal<br> =3B =3B Provisions Relating to IETF Documents in effec= t on the date of<br> =3B =3B publication of this document (http://t= rustee.ietf.org/license-info).<br> =3B =3B Please review these docu= ments carefully=2C as they describe your rights<br> =3B =3B and res= trictions with respect to this document.<br><br>This document includes quot= es from pre-5738 RFCs. =3B Should we be using<br>the new "pre-5738" boi= lerplate?<br><br> =3B =3B It is RECOMMENDED that SDOs and vendors s= eek review of RADIUS<br> =3B =3B attribute specifications from the = IETF. =3B However=2C when specifications<br> =3B =3B are SDO sp= ecific=2C re-use existing data types=2C and follow these<br> =3B = =3B guidelines=2C they do not require IETF review.<br><br> =3B. . .<br>= <br> =3B =3B The advice in this document applies to attributes used= to encode<br> =3B =3B service-provisioning or authentication data.=  =3B RADIUS protocol<br> =3B =3B changes=2C or specification of= attributes (such as Service-Type) that<br> =3B =3B can be used to= =2C in effect=2C provide new RADIUS commands require<br> =3B =3B gr= eater expertise and deeper review=2C as do changes to the RADIUS<br> = =3B =3B operational model=2C as described in Section 3.3 . =3B Such= changes SHOULD<br> =3B =3B NOT be undertaken outside the IETF and = when handled within the IETF<br> =3B =3B require "IETF Consensus" f= or adoption=2C as noted in [RFC3575] Section<br> =3B =3B 2.1.<br><b= r>This would seem to suggest that support for new authentication mechanisms= <br>can be standardized outside the IETF=2C as long as the guidelines are f= ollowed.<br>Also=2C the use of SHOULD NOT implies that there are circumstan= ces in which<br>protocol changes or new commands can be standardized outsid= e the IETF. Is<br>this what was intended?<br><br> =3B =3B Note that= the Vendor type field in the recommended VSA format is only<br> =3B&nb= sp=3B a single octet=2C like the RADIUS type field. =3B While this limi= tation<br> =3B =3B results in an efficient encoding=2C there are si= tuations in which a<br> =3B =3B vendor or SDO will eventually wish = to define more than 255<br> =3B =3B attributes. =3B Also=2C an = SDO can be comprised of multiple subgroups=2C<br> =3B =3B each of w= hom can desire autonomy over the definition of attributes<br> =3B = =3B within their group. =3B In such a situation=2C a 16-bit Vendor type= field<br> =3B =3B would be more appropriate:<br><br> =3B = =3B =3B 0 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B 1 =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B 2 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= 3<br> =3B =3B =3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1<br> =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br> =3B =3B | =3B =3B = =3B =3B Type =3B =3B =3B =3B =3B | =3B Length&n= bsp=3B =3B =3B =3B =3B =3B | =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B Vendor-Id<br>=  =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+<br> =3B =3B =3B =3B =3B =3B =3B Vendor-= Id (cont) =3B =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B | =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B Vendor type =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B |<br> =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br> =3B =3B | Vendor length |&n= bsp=3B =3B Attribute-Specific...<br> =3B =3B +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br> =3B =3B If additional functiona= lity is required=2C the format defined in<br> =3B =3B [EXTEN] SHOUL= D be used.<br><br>Since [EXTEN] defines extensions to the standard RADIUS a= ttribute<br>space and this section is talking about VSAs=2C the reference i= s a bit<br>confusing. =3B Is the intent to suggest that VSAs other than= type 0<br>can also use the [EXTEN] format?<br><br> =3B =3B =3B=  =3B =3B =3B =3B As a last resort=2C where<br> =3B = =3B =3B =3B =3B =3B =3B the above techniques cannot be = made to work=2C it may be possible<br> =3B =3B =3B =3B = =3B =3B =3B to apply the techniques described in [RFC4821] to disco= very the<br> =3B =3B =3B =3B =3B =3B =3B maximu= m supported RADIUS packet size on the path between a<br> =3B =3B&nb= sp=3B =3B =3B =3B =3B RADIUS client and a home server.<br><= br>s/discovery/discover/<br><br> =3B =3B Even though the type is Te= xt=2C the rest of the description indicates<br> =3B =3B that it is = a complex attribute:<br><br>Since accounting data is typically only written= to stable storage without<br>examination=2C does the reasoning against com= plex attributes really apply<br>here?<br><br><br><br><br><br><br><br><br><b= lockquote style=3D"border-left: 2px solid rgb(0=2C 0=2C 255)=3B padding-lef= t: 5px=3B margin-left: 5px=3B margin-right: 0px=3B"><table style=3D"border-= top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTaho= ma=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbody></table></blockquot= e></body> </html>= --_565f5acc-1fea-4ff9-a45d-1679ff0ec532_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 25 Feb 2009 14:17:26 +0000 Message-ID: <49A552D5.6030906@deployingradius.com> Date: Wed, 25 Feb 2009 15:16:53 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" <dromasca@avaya.com> CC: Bernard Aboba <bernard_aboba@hotmail.com>, radiusext@ops.ietf.org Subject: Re: Last look at "RADIUS Design Guidelines" document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Romascanu, Dan (Dan) wrote: > */Does the new version of the document address the issues raised by the > Secdir review? /* Yes. > *//* > */If the answer is positive it would be good to prompt the revised I-D > to the reviewer and ask him to confirm that the issues were addressed by > the document or clarified some other way. /* I'll send him a link. 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 25 Feb 2009 11:39:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9973D.9ABE0F3B" Subject: RE: Last look at "RADIUS Design Guidelines" document Date: Wed, 25 Feb 2009 12:38:38 +0100 Message-ID: <EDC652A26FB23C4EB6384A4584434A040145377A@307622ANEX5.global.avaya.com> Thread-Topic: Last look at "RADIUS Design Guidelines" document Thread-Index: AcmWnReB/NjxWNNyTAW+K+9INDyyMAAoDhvg From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "Bernard Aboba" <bernard_aboba@hotmail.com>, <radiusext@ops.ietf.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C9973D.9ABE0F3B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Does the new version of the document address the issues raised by the Secdir review?=20 =20 If the answer is positive it would be good to prompt the revised I-D to the reviewer and ask him to confirm that the issues were addressed by the document or clarified some other way.=20 =20 Thanks and Regards, =20 Dan =20 ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, February 24, 2009 6:28 PM To: radiusext@ops.ietf.org Subject: Last look at "RADIUS Design Guidelines" document =09 =09 This is an announcement of a "Last Look" at the RADIUS Design Guidelines document, prior to sending this back to the IESG for publication as a Best Current Practice (BCP).=20 =09 The document is available for inspection here: =09 http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt =09 This "last look" will last until March 10, 2009. Please send comments to the RADEXT WG mailing list in the Issue format used by the RADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/).=20 =09 =09 =09 =09 <http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood>=20 =09 ------_=_NextPart_001_01C9973D.9ABE0F3B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <STYLE>.hmmessage P { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: = 0px; PADDING-TOP: 0px } BODY.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY: Verdana } </STYLE> <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD> <BODY class=3Dhmmessage> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009>Does the new version of the document address = the issues=20 raised by the Secdir review? </SPAN></FONT></EM></STRONG></DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009></SPAN></FONT></EM></STRONG> </DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009>If the answer is positive it would be good=20 to prompt the revised I-D to the reviewer and ask him to = confirm=20 that the issues were addressed by the document or clarified some other = way.=20 </SPAN></FONT></EM></STRONG></DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009></SPAN></FONT></EM></STRONG> </DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009>Thanks and = Regards,</SPAN></FONT></EM></STRONG></DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009></SPAN></FONT></EM></STRONG> </DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009>Dan</SPAN></FONT></EM></STRONG></DIV> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20 class=3D670343611-25022009></SPAN></FONT></EM></STRONG> </DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma><B>From:</B> owner-radiusext@ops.ietf.org=20 [mailto:owner-radiusext@ops.ietf.org] <B>On Behalf Of </B>Bernard=20 Aboba<BR><B>Sent:</B> Tuesday, February 24, 2009 6:28 PM<BR><B>To:</B> = radiusext@ops.ietf.org<BR><B>Subject:</B> Last look at "RADIUS Design=20 Guidelines" document<BR></FONT><BR></DIV> <DIV></DIV>This is an announcement of a "Last Look" at the RADIUS = Design=20 Guidelines document, prior to sending this back to the IESG for = publication as=20 a Best Current Practice (BCP). <BR><BR>The document is available for=20 inspection=20 = here:<BR>http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.= txt<BR><BR>This=20 "last look" will last until March 10, 2009. Please send comments = to the=20 RADEXT WG mailing list in the Issue format used by the RADEXT Issues = list=20 (http://www.drizzle.com/~aboba/RADEXT/). <BR><BR><BR><BR> <TABLE=20 style=3D"BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: = 'Segoe UI',Tahoma,san-serif"> <TBODY> <TR> <TD><A=20 style=3D"FONT-SIZE: 9pt; COLOR: rgb(1,132,203); TEXT-DECORATION: = none"=20 = href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGo= od"><SPAN=20 style=3D"PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: = 8pt; PADDING-BOTTOM: 0px; COLOR: rgb(63,181,85); PADDING-TOP: 0px; = TEXT-DECORATION: = underline"></SPAN></A><BR></TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY><= /HTML> ------_=_NextPart_001_01C9973D.9ABE0F3B-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 24 Feb 2009 16:28:57 +0000 Message-ID: <BLU137-W53F361CCAAD44C8AF38EC693AF0@phx.gbl> Content-Type: multipart/alternative; boundary="_ad9722fa-1b3a-417b-bb89-11aada963bef_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Last look at "RADIUS Design Guidelines" document Date: Tue, 24 Feb 2009 08:27:40 -0800 MIME-Version: 1.0 --_ad9722fa-1b3a-417b-bb89-11aada963bef_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of a "Last Look" at the RADIUS Design Guidelines do= cument=2C prior to sending this back to the IESG for publication as a Best = Current Practice (BCP).=20 The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt This "last look" will last until March 10=2C 2009. Please send comments to= the RADEXT WG mailing list in the Issue format used by the RADEXT Issues l= ist (http://www.drizzle.com/~aboba/RADEXT/).=20 --_ad9722fa-1b3a-417b-bb89-11aada963bef_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> This is an announcement of a "Last Look" at the RADIUS Design Guidelines do= cument=2C prior to sending this back to the IESG for publication as a Best = Current Practice (BCP). <br><br>The document is available for inspection he= re:<br>http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt<= br><br>This "last look" will last until March 10=2C 2009. =3B Please se= nd comments to the RADEXT WG mailing list in the Issue format used by the R= ADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/). <br><br><br><br>= <table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-fa= mily: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://= im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font= -size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><spa= n style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 8= 5)=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody></tab= le></body> </html>= --_ad9722fa-1b3a-417b-bb89-11aada963bef_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 24 Feb 2009 16:16:49 +0000 Message-ID: <49A41D64.2030405@deployingradius.com> Date: Tue, 24 Feb 2009 17:16:36 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: 'radext mailing list' <radiusext@ops.ietf.org>, Greg Weber <gdweber@gmail.com> Subject: New version of the Design Guidelines document. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit http://tools.ietf.org/id/draft-ietf-radext-design-06.txt I've submitted a new version of the design guidelines document, with changes as noted earlier. Additional modifications: - add a few sentences to the Security Considerations section as per PHB's security review - update boilerplate. 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 24 Feb 2009 16:15:30 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090224161502.06ABE3A6B10@core3.amsl.com> Date: Tue, 24 Feb 2009 08:15:01 -0800 (PST) --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 : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-06.txt Pages : 37 Date : 2009-02-24 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-radext-design-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-24081154.I-D@ietf.org> --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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 24 Feb 2009 16:11:40 +0000 Message-ID: <BLU137-W22E7CDFB1A43CC054A5A1D93AF0@phx.gbl> Content-Type: multipart/alternative; boundary="_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: SECDIR Review of draft-ietf-radext-design-05 (fwd) Date: Tue, 24 Feb 2009 08:10:54 -0800 MIME-Version: 1.0 --_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --Forwarded Message Attachment-- Subject: SECDIR Review of draft-ietf-radext-design-05 Date: Mon=2C 9 Feb 2009 14:04:59 -0800 From: pbaker@verisign.com To: gdweber@gmail.com=3B aland@freeradius.org=3B radiusext@ops.ietf.org CC: secdir@ietf.org=3B iesg@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.=20 =20 The purpose of this document is to explain the workings of RADIUS attribute= s for the benefit of those involved in the design of future RADIUS attribut= e specifications. As such the document is very clear and provides advice th= at will no doubt prove useful. =20 The Security Considerations section could do with some additional work howe= ver. =20 The discussion of encryption of attributes is somewhat confusing. Mention i= s made of encryption=2C followed by mention of MD5 and SHA1. While it was c= ommon to describe the use of one way functions to obfusticate passwords as = 'encryption' in the 1980s=2C this is not current terminology and this needs= to be explained. =20 Also I would like to see specific mention made of whatever provisions are m= ade for message authentication in the protocol=2C if none=2C then this shou= ld also be specified. This is a major concern in what is essentially a prot= ocol that supports the authentication/authorization process. =20 Finally=2C I would like to see some mention of the use of a secure tunnel s= uch as IPSEC and which types of attributes might need superencryption withi= n such a tunnel.= --_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> <br>--Forwarded Message Attachment--<br>Subject: SECDIR Review of draft-iet= f-radext-design-05<br>Date: Mon=2C 9 Feb 2009 14:04:59 -0800<br>From: pbake= r@verisign.com<br>To: gdweber@gmail.com=3B aland@freeradius.org=3B radiusex= t@ops.ietf.org<br>CC: secdir@ietf.org=3B iesg@ietf.org<br><br> <div><font size=3D"2" color=3D"#000000">I have reviewed this document as pa= rt of the security directorate's<br>ongoing effort to review all IETF docum= ents being processed by the<br>IESG. =3B These comments were written pr= imarily for the benefit of the<br>security area directors. =3B Document= editors and WG chairs should treat<br>these comments just like any other l= ast call comments.<font size=3D"3"> </font></font></div> <div> =3B</div> <div>The purpose of this document is to explain the workings of RADIUS attr= ibutes for the benefit of those involved in the design of future RADIUS att= ribute specifications. As such the document is very clear and provides advi= ce that will no doubt prove useful.</div> <div> =3B</div> <div>The Security Considerations section could do with some additional work= however.</div> <div> =3B</div> <div>The discussion of encryption of attributes is somewhat confusing. Ment= ion is made of encryption=2C followed by mention of MD5 and SHA1. While it = was common to describe the use of one way functions to obfusticate password= s as 'encryption' in the 1980s=2C this is not current terminology and this = needs to be explained.</div> <div> =3B</div> <div>Also I would like to see specific mention made of whatever provisions = are made for message authentication in the protocol=2C if none=2C then this= should also be specified. This is a major concern in what is essentially a= protocol that supports the =3Bauthentication/authorization process.</d= iv> <div> =3B</div> <div>Finally=2C I would like to see some mention of the use of a secure tun= nel such as IPSEC and which types of attributes might need superencryption = within such a tunnel.</div></body> </html>= --_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 23 Feb 2009 23:04:53 +0000 Message-ID: <BLU137-W55835ADF658CDE117EA7B93AE0@phx.gbl> Content-Type: multipart/alternative; boundary="_7507b4f9-22c9-4ed3-9db4-9004ad360dea_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Several ways you can publish I-Ds with pre 5378 content - TODAY (fwd) Date: Mon, 23 Feb 2009 15:04:02 -0800 MIME-Version: 1.0 --_7507b4f9-22c9-4ed3-9db4-9004ad360dea_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI. > From: fluffy@cisco.com > To: wgchairs@ietf.org=3B ietf@ietf.org > Subject: Several ways you can publish I-Ds with pre 5378 content - TODAY > Date: Mon=2C 23 Feb 2009 15:19:13 -0700 >=20 >=20 > Method 1: (Not recommended) >=20 > Go read the BCP and Trust statement and edit your .txt to have the =20 > right text. >=20 > Method 2: (Recommended for people using word template) >=20 > Go look at a draft that did work=2C such as > http://tools.ietf.org/html/draft-jennings-http-srv-01 >=20 > And copy the Copyright Notice section into your draft >=20 > Method 3: XML2RFC approach recommended for folks that run xml2rfc =20 > locally >=20 > Get the very hacked version at > http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/1.34pre2-fluffy/xml2rf= c.tcl >=20 > This will soon be obsoleted when the real xml2rfc tool gets updated. =20 > Don't worry=2C Julian=2C Bill=2C and Marshal are working on that. They wi= ll =20 > produce something much better than my hack of xml2rfc >=20 > Set the ipr attribute in the <rfc> element to ipr=3D"pre5378Trust200902" = =20 > and it will produce a txt file that id submission tool will accept. >=20 > Method 4: XML2RFC approach for folks that run xml2rfc on the web >=20 > Use the experimental version from http://xml.resource.org/experimental.ht= ml=20 > . You can download the zip or tgz file on this page or use the online =20 > version at this page. >=20 > Make sure you have >=20 > <?rfc strict=3D"no" ?> > somewhere above the <rfc> element. > In the <rfc> element=2C set the ipr attribute to ipr=3D"trust200811" > Change your abstract to use a note. Do this by changing > <abstract> <t> This draft is about ... </t> </abstract> > To > <note title=3D"Abstract"><t> This draft is about ...</t> </note> > And before this not insert a note like > <note title=3D""> <t> This document may contain material from IETF =20 > Documents or IETF Contributions published or made publicly available =20 > before November 10=2C 2008. The person(s) controlling the copyright in =20 > some of this material may not have granted the IETF Trust the right to =20 > allow modifications of such material outside the IETF Standards =20 > Process. Without obtaining an adequate license from the person(s) =20 > controlling the copyright in such materials=2C this document may not be = =20 > modified outside the IETF Standards Process=2C and derivative works of =20 > it may not be created outside the IETF Standards Process=2C except to =20 > format it for publication as an RFC or to translate it into languages =20 > other than English. </t> </note> >=20 > You can seen the XML for an example I-D that does this at > http://svn.resiprocate.org/rep/ietf-drafts/fluffy/example.xml >=20 > That should work - good luck --_7507b4f9-22c9-4ed3-9db4-9004ad360dea_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> FYI.<br><br><br>>=3B From: fluffy@cisco.com<br>>=3B To: wgchairs@ietf.o= rg=3B ietf@ietf.org<br>>=3B Subject: Several ways you can publish I-Ds wi= th pre 5378 content - TODAY<br>>=3B Date: Mon=2C 23 Feb 2009 15:19:13 -07= 00<br>>=3B <br>>=3B <br>>=3B Method 1: (Not recommended)<br>>=3B <b= r>>=3B Go read the BCP and Trust statement and edit your .txt to have the= <br>>=3B right text.<br>>=3B <br>>=3B Method 2: (Recommended for pe= ople using word template)<br>>=3B <br>>=3B Go look at a draft that did = work=2C such as<br>>=3B http://tools.ietf.org/html/draft-jennings-http-sr= v-01<br>>=3B <br>>=3B And copy the Copyright Notice section into your d= raft<br>>=3B <br>>=3B Method 3: XML2RFC approach recommended for folks = that run xml2rfc <br>>=3B locally<br>>=3B <br>>=3B Get the very hack= ed version at<br>>=3B http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/= 1.34pre2-fluffy/xml2rfc.tcl<br>>=3B <br>>=3B This will soon be obsolete= d when the real xml2rfc tool gets updated. <br>>=3B Don't worry=2C Julia= n=2C Bill=2C and Marshal are working on that. They will <br>>=3B produce= something much better than my hack of xml2rfc<br>>=3B <br>>=3B Set the= ipr attribute in the <=3Brfc>=3B element to ipr=3D"pre5378Trust200902"= <br>>=3B and it will produce a txt file that id submission tool will ac= cept.<br>>=3B <br>>=3B Method 4: XML2RFC approach for folks that run xm= l2rfc on the web<br>>=3B <br>>=3B Use the experimental version from htt= p://xml.resource.org/experimental.html <br>>=3B . You can download the zi= p or tgz file on this page or use the online <br>>=3B version at this pa= ge.<br>>=3B <br>>=3B Make sure you have<br>>=3B <br>>=3B <=3B?rfc= strict=3D"no" ?>=3B<br>>=3B somewhere above the <=3Brfc>=3B elemen= t.<br>>=3B In the <=3Brfc>=3B element=2C set the ipr attribute to ipr= =3D"trust200811"<br>>=3B Change your abstract to use a note. Do this by c= hanging<br>>=3B <=3Babstract>=3B <=3Bt>=3B This draft is about ..= . <=3B/t>=3B <=3B/abstract>=3B<br>>=3B To<br>>=3B <=3Bnote ti= tle=3D"Abstract">=3B<=3Bt>=3B This draft is about ...<=3B/t>=3B &= lt=3B/note>=3B<br>>=3B And before this not insert a note like<br>>=3B= <=3Bnote title=3D"">=3B <=3Bt>=3B This document may contain materi= al from IETF <br>>=3B Documents or IETF Contributions published or made = publicly available <br>>=3B before November 10=2C 2008. The person(s) co= ntrolling the copyright in <br>>=3B some of this material may not have g= ranted the IETF Trust the right to <br>>=3B allow modifications of such = material outside the IETF Standards <br>>=3B Process. Without obtaining = an adequate license from the person(s) <br>>=3B controlling the copyrigh= t in such materials=2C this document may not be <br>>=3B modified outsid= e the IETF Standards Process=2C and derivative works of <br>>=3B it may = not be created outside the IETF Standards Process=2C except to <br>>=3B = format it for publication as an RFC or to translate it into languages <br>= >=3B other than English. <=3B/t>=3B <=3B/note>=3B<br>>=3B <br>&= gt=3B You can seen the XML for an example I-D that does this at<br>>=3B h= ttp://svn.resiprocate.org/rep/ietf-drafts/fluffy/example.xml<br>>=3B <br>= >=3B That should work - good luck<br></body> </html>= --_7507b4f9-22c9-4ed3-9db4-9004ad360dea_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 17:26:32 +0000 From: "Dave Nelson" <d.b.nelson@comcast.net> To: <Pasi.Eronen@nokia.com>, <radiusext@ops.ietf.org> Subject: RE: One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01 Date: Wed, 18 Feb 2009 12:25:49 -0500 Message-ID: <5469A4892C7E4C88A07BB3ECAF080E46@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcmRufNKVpYLR/vKSra3o37PAQ2SUgAMxGmA Pasi Eronen writes... > The outcome I'd really like to avoid is having IESG first approve > these requirements, and then getting a solution draft that in WG's > opinion meets the requiremnts, but is very different from how IESG > understood the requirements. So, the main intent of the remaining > comments is reducing the likelihood of this happening. Exactly! I can propose some text to resolve the editorial issues -- lack of clarity because of poor wording. I'll need assistance from the WG in resolving the substantive issues, such as whether RADIUS should have a true negotiation mechanism for cipher-suites and whether RADIUS needs forward secrecy or to be retrofitted with Automated Key Management. WG members, please comment on the issues that Pasi has raised in his review, ASAP. If we get some good discussion going, we could have a -02 version of the draft prior to IETF 74 (coming up real soon 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 14:34:07 +0000 Message-ID: <499C1C57.8070400@restena.lu> Date: Wed, 18 Feb 2009 15:33:59 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Alan DeKok <aland@deployingradius.com> CC: Bernard Aboba <bernard_aboba@hotmail.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Issue 282: backward compatibility, proposed text Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Alan DeKok schrieb: > Bernard Aboba wrote: > >> Question: At various points we have talked about separating out the >> material on DNS SRV-based discovery. How does this recommendation >> relate to that? For example, assuming that DNS SRV RR queries aren't >> protected by DNSSEC, couldn't the discovery process generate a "fallback >> to classic RADIUS"? >> > > Yes. > *If* classic RADIUS were to be specified with DNS SRV discovery, yes. AFAIK, there are no plans to do that - only TLS and DTLS. It would be rather tricky to do so, because the shared secret would need to be discovered, and the DNS channel offers no adequate protection for such a keying material exchange, AFAICT. >> (e.g. if only the FQDN of the server is provided and >> DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS >> was supported). For example, couldn't an attacker spoof a response to >> the DNS SRV RR query and convince the querier that only RADIUS was >> available? >> > > Systems should be implemented so that administrators can require > RADSEC for particular home servers. This turns the down-bidding attack > into a DoS attack, as the proxy will refuse to connect over plain RADIUS. > That sounds good. Configuration details are not a part of the on-wire protocol though, so: does it make sense to recommend this in the draft? This sounds like an issue to mention in the dynamic discovery draft itself (see below). >> And overall, I'm curious about where the text relating to DNS discovery >> is going/belongs. In the draft? Outside of it in a separate document? >> None of these? >> > > In a separate draft. DTLS and normal RADIUS could be using dynamic > discovery, too. > I have a stub of a draft on my disk, which is basically copy&paste from the contents of the earlier radsec-02 revision. The issues discussed in this thread (+i18n) should/will end up there. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 14:33:16 +0000 Message-ID: <499C0D64.8020908@restena.lu> Date: Wed, 18 Feb 2009 14:30:12 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> CC: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Issue 282: backward compatibility, proposed text Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, > Question: At various points we have talked about separating out the > material on DNS SRV-based discovery. How does this recommendation > relate to that? For example, assuming that DNS SRV RR queries aren't > protected by DNSSEC, couldn't the discovery process generate a > "fallback to classic RADIUS"? (e.g. if only the FQDN of the server is > provided and DNS SRV RR queries are used to determine whether RADSEC > and/or RADIUS was supported). For example, couldn't an attacker > spoof a response to the DNS SRV RR query and convince the querier that > only RADIUS was available? DNSSEC could secure the SRV response, yes. The overall security of discovery also depends on the subsequent A/AAAA lookups, and I think there's a loophole DNSSEC can't close. Which would in turn mean that adding DNSSEC doesn't completely secure the process in the end, and so manual configuration of a desired minimum security level is the only proper answer. In the (yet unpublished) dynamic discovery draft, I've just scribbled down the following (the second para relating to bidding down): When using DNS without security, the replies to NAPTR, SRV and A/AAAA requests as described in section Section 2 can not be trusted. RADIUS transports have an out-of-DNS-band means to verify that the discovery attempt led to the intended target (TLD/DTLS: ceritifcate verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared secret) and are safe from DNS-based redirection attacks. [Note: assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT deliver the shared secret in the DNS response!] The discovery process is always susceptible to bidding down attacks if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well as for RADIUS/TLS and/or RADIUS/DTLS. While the SRV query will expose both transports, an attacker in the routing path might suppress the subsequent A/AAAA results for the TLS or DTLS peer and trick the inititating peer into using the weakly protected UDP or TCP transports. The use of DNSSEC can not fully mitigate this attack, since it does not provide a means to detect packet suppression. The only way to disable such bidding down attacks is by intiating connections only to the peer(s) which match or exceed a configured minimum security level. An implementation SHOULD provide a means to configure the administratively desired minimum security level. Does that make sense? Greetings, 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 14:32:18 +0000 Message-ID: <499C1BBD.8010500@elbrysnetworks.com> Date: Wed, 18 Feb 2009 09:31:25 -0500 From: "David B. Nelson" <dnelson@elbrysnetworks.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Design Guidelines document Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Great. I guess we now have boilerplate to post drafts? We know what the boilerplate ought to be, but as far as I can tell, we don't yet have automated tool support in xml2rfc. Let's put it this way, there is no new version announced on the web site that supports February 2009 boilerplate text. I am also following the xlm2rfc mailing list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 13:25:53 +0000 Message-ID: <499C0C38.7070106@restena.lu> Date: Wed, 18 Feb 2009 14:25:12 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: Glen Zorn <glenzorn@comcast.net> CC: "'Joseph Salowey (jsalowey)'" <jsalowey@cisco.com>, radiusext@ops.ietf.org Subject: Re: Issue 282: cipher suites, discussion needed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, >> "RADSEC implementation MUST support he mandatory to implement cipher >> suites specified in TLS. For purposes of compatibility with some >> current deployments implementations SHOULD support >> TLS_RSA_WITH_RC4_128_SHA as well." >> > > Seems like a good idea to me. > Great! I'll update the document with this text and will likely post a new revision before the SF cutoff date. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 18 Feb 2009 11:15:00 +0000 From: <Pasi.Eronen@nokia.com> To: <radiusext@ops.ietf.org> Date: Wed, 18 Feb 2009 12:13:39 +0100 Subject: One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01 Thread-Topic: One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01 Thread-Index: AcmRufNKVpYLR/vKSra3o37PAQ2SUg== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E7A837C6@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi, At Dan Romascanu's request, I've taken an early look at draft-ietf- radext-crypto-agility-requirements-01. This was probably a good idea from Dan, since if I had sent a DISCUSS this long at IESG evaluation time, the WG might have (somewhat justifiably) suggested doing some rubber-hose discuss clearing on a dark San Francisco back alley :-) Overall comment: Currently, much of the text in this draft seems to be open to multiple interpretations. It's possible that the WG members agree on the interpretation (but it's also possible that they only *think* they agree...), but someone who hasn't participated in the WG discussions will be somewhat confused. Personally, I'm not really a big fan of requirements RFCs (and would rather spend the energy in getting the solutions right)... but the AAA space certainly has some history of requirements open to multiple interpretations (including the infamous "Housley criteria" that became RFC 4962), and a special branch of hermeneutics devoted to interpreting them in ways that were not always very productive :-) [and BTW -- I've certainly done some of that myself...] The outcome I'd really like to avoid is having IESG first approve these requirements, and then getting a solution draft that in WG's opinion meets the requiremnts, but is very different from how IESG understood the requirements. So, the main intent of the remaining comments is reducing the likelihood of this happening. Hop-by-hop/end-to-end: The document currently considers only "hop-by-hop" security mechanisms, not any "end-to-end" protection (across proxies). I think this is OK and perfectly reasonable -- but the document should say this, and explain what this means for interpreting RFC 4962 Much of RFC 4962 is open to multiple interpretations, and some parts of it can be read as requiring more than hop-by-hop security. IMHO exactly the same parts can also be read as saying hop-by-hop can be sufficient (when done properly), and I think this document should explicitly say it's interpreting 4962 the latter way. (And once the document has this explanation, you might want to run it by some other ADs, too -- e.g. Tim and Russ) Forward secrecy: Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be used (perhaps indirectly via additional key derivation steps) to encrypt information that may be valuable for a long time. Given this, the document needs some discussion about "forward secrecy" (whether revealing the long-term credential allows decrypting all past communications), and if the conclusion is that crypto-agility solutions don't need to support forward secrecy (even as optional-to-use feature), explain the rationale behind this conclusion. Authentication/long-term credentials: Authenticating the RADIUS client and server will require (manual) configuration of some kinds of credentials (currently, the RADIUS shared secret). The document should say something about what kinds of long-term authentication credentials (for RADIUS entities) the crypto-agility solutions are expected to support. Presumably, they MUST support pair-wise shared secrets. Other possibilities for long-term credentials could include e.g. X.509 certificates with PKI, public keys without certification infrastructure (generate keypair + configure fingerprint of peer's key), or Kerberos. Even if the conclusion is that nothing else than pairwise shared secrets is needed, that should be said in the document (with rationale explaining why). Replay protection: Section 4.2 says "Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained." I think the latter sentence needs some clarification. If the intent is to say replay protection provided by the current mechanisms (i.e., basically none for Access-Request messages) is good enough, I would disagree with that (or at least would expect to see an explanation why that's the case for Access-Requests). If the intent is something else, the text needs to be clearer. Meaning of negotiation: The document says proposals MUST support negotiation of cryptographic algorithms. Does "negotiation" here mean picking which algorithm to use in the protocol (RADIUS client and server figure out an algorithm supported by both of them), or would negotiation between system administrators meet this requirement? I assume the WG has rough consensus about what this means, and ordinarily, I would have automatically assumed it's the former. But some earlier proposals in this space have supported only the latter kind (which does provide some kind of algorithm agility -- it's better than hardcoding MD5 -- but could mean synchronized manual work for every transition)... Automated Key Management: Well... RADIUS certainly requires only O(n) keys, but on the other hand, the amount of data encrypted with a single key is not necessarily small (when considering the "value of the data" and time aspects -- in terms of gigabytes, it's probably small compared to what decent algorithms can handle). And if you anyway support negotiating the algorithms (in the protocol), generating a fresh session key may not be that much extra effort, and may be needed anyway since the key can depend on the selected algorithm (if you negotiate 256-bit AES, you need a 256-bit key; if it's 3DES, 168 bits, etc.). And the solutions should avoid using the same cryptographic key with multiple algorithms (and the easiest way to ensure this would probably be fresh session keys). Generating a fresh session key probably also simplifies replay protection (it's the obvious time to e.g. reset counters to zero), but other approaches to replays are certainly feasible. And obviously, forward secrecy and supporting any other types of long-term credentials than shared secrets requires automated key management of some kind. So, I think the conclusion here needs at the very least some qualification and additional explanation. *If* a solution not supporting forward secrecy and not supporting other types of credentials is acceptable, *and* replay protection is solved in certain way, *and* the solution can ensure that the negotiated algorithms get keys appropriate for them, *and* the solution can ensure that two algorithms don't use the same key, then you might get away with no AKM. But even then, AKM might be less work. Compromise of legacy shared secret: Section 4.2 says "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." If interpreted literally, this requirement could be very difficult to meet (perhaps impossible). It seems to assume that for this particular peer, the administrator has configured two different shared secrets (one for the current security mechanisms, another for the new ones), but has not configured whether to use the old or new mechanisms (with this particular peer), and instead, that is negotiated somehow. If the attacker knows the legacy shared secret, and has complete control over the communication channel (and in particular, can drop messages going from A to B), then it seems the attacker will be indistinguishable from a valid peer that supports only the legacy mechanisms (and does not know the new shared secret), and detecting bidding down will not be possible. Preventing bidding down in less extreme cases of compromise is of course both possible and desirable (e.g. if the algorithms are just weak but not breakable in real time, or if the attacker doesn't have complete control over the communications). And the administrator could always configure just the "new shared secret", if he/she knows that the peer supports it. Backward compatibility/negotiation: Section 4.3 says "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." The intent of this paragraph is probably right, but currently, it's somewhat open to multiple interpretations. Would something like this capture the intent? "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." Note that *not* meeting this requirement would actually be quite difficult... if the intent of this paragraph was to require some kind of negotiation (interpreted loosely -- anything more automatic than manual configuration), the text should say so. "Operational model"? Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server." I'm not sure what "operational" means here -- at first I thought it might mean "operations and management" (so the requirement would be basically "SHOULD not complicate life for administrators"), but the two examples given don't seem to fit that very well. And it seems any solution that e.g. derives fresh session keys will involve some small (but greater than zero) amount of additional state on clients and servers. If the intent was really operations and management, perhaps the should be rephased something like "When using long-term shared secrets for authentication, crypto-agility solutions SHOULD NOT require more operations and management work than the current solutions." "RADIUS service?" Section 4.3 says "For example, proposals SHOULD NOT [..] include definition of new RADIUS services." What's a RADIUS service -- i.e. what types of proposals this definition would disqualify? (In RFC 2865, "service" is defined as the service provided by the NAS to the user, but that definition doesn't seem applicable here.) Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 23:39:14 +0000 Message-ID: <BLU137-W5422085B1035CF0804560293B40@phx.gbl> Content-Type: multipart/alternative; boundary="_0655c766-b377-4186-a480-aee44d8e91c3_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: Alan DeKok <aland@deployingradius.com>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: RE: Design Guidelines document Date: Tue, 17 Feb 2009 15:38:25 -0800 MIME-Version: 1.0 --_0655c766-b377-4186-a480-aee44d8e91c3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great. I guess we now have boilerplate to post drafts? Also=2C could you post PHB's review to the list? > Date: Tue=2C 17 Feb 2009 11:39:17 +0100 > From: aland@deployingradius.com > To: radiusext@ops.ietf.org > Subject: Design Guidelines document >=20 > Hearing no major objections to the changes posted on > http://ietf.freeradius.org/=2C I will shortly submit an updated version. > This version will include comments coming from PHB's review. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> --_0655c766-b377-4186-a480-aee44d8e91c3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> Great. =3B =3B I guess we now have boilerplate to post drafts?<br><= br>Also=2C could you post PHB's review to the list?<br><br>>=3B Date: Tue= =2C 17 Feb 2009 11:39:17 +0100<br>>=3B From: aland@deployingradius.com<br= >>=3B To: radiusext@ops.ietf.org<br>>=3B Subject: Design Guidelines doc= ument<br>>=3B <br>>=3B Hearing no major objections to the changes pos= ted on<br>>=3B http://ietf.freeradius.org/=2C I will shortly submit an up= dated version.<br>>=3B This version will include comments coming from PHB= 's review.<br>>=3B <br>>=3B Alan DeKok.<br>>=3B <br>>=3B --<br>&g= t=3B to unsubscribe send a message to radiusext-request@ops.ietf.org with<b= r>>=3B the word 'unsubscribe' in a single line as the message text body.<= br>>=3B archive: <=3Bhttp://psg.com/lists/radiusext/>=3B<br></body> </html>= --_0655c766-b377-4186-a480-aee44d8e91c3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 12:43:20 +0000 From: "Glen Zorn" <glenzorn@comcast.net> To: "'Joseph Salowey \(jsalowey\)'" <jsalowey@cisco.com>, "'Stefan Winter'" <stefan.winter@restena.lu> Cc: <radiusext@ops.ietf.org> Subject: RE: Issue 282: cipher suites, discussion needed Date: Tue, 17 Feb 2009 19:42:22 +0700 Message-ID: <037a01c990fd$38b680a0$aa2381e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcmMKPZ7b4B30p22TNi06MFRHINH8AEmRuagAA68a7A= Content-Language: en-us Joseph Salowey [mailto:jsalowey@cisco.com] writes: > You could just leave this to the TLS specification. For version 1.0 > and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is > TLS_RSA_WITH_AES_128_CBC_SHA. If it is common today for > implementations also to implement the RC4 ciphers you can have that as > a recommendation as well. Something like: >=20 > "RADSEC implementation MUST support he mandatory to implement cipher > suites specified in TLS. For purposes of compatibility with some > current deployments implementations SHOULD support > TLS_RSA_WITH_RC4_128_SHA as well." Seems like a good idea to me. >=20 > Cheers, >=20 > Joe >=20 > > -----Original Message----- > > From: Stefan Winter [mailto:stefan.winter@restena.lu] > > Sent: Wednesday, February 11, 2009 1:13 AM > > To: Joseph Salowey (jsalowey) > > Cc: radiusext@ops.ietf.org > > Subject: Issue 282: cipher suites, discussion needed > > > > Hi, > > > > > 3. I'm not sure I understand the choice of ciphersuites. > > > > > > Why is TLS_RSA_WITH_RC4_128_SHA recommended? It seems that > > it would > > > be much preferable to use AES or 3DES? > > > > > > > I could use a little help here. Is there anyone willing to > > investigate cipher suite selection? An alternative would be > > to follow the path of e.g. the EAP tunnel reqs, which cite > > NIST references for acceptable cipher suites... > > > > Greetings, > > > > Stefan Winter > > > > -- > > Stefan WINTER > > Ingenieur de Recherche > > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education > > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > > L-1359 Luxembourg > > > > Tel: +352 424409 1 > > Fax: +352 422473 > > > > >=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: <http://psg.com/lists/radiusext/> -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 10:40:07 +0000 Message-ID: <499A93D5.7090007@deployingradius.com> Date: Tue, 17 Feb 2009 11:39:17 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: 'radext mailing list' <radiusext@ops.ietf.org> Subject: Design Guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hearing no major objections to the changes posted on http://ietf.freeradius.org/, I will shortly submit an updated version. This version will include comments coming from PHB's review. 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 07:32:06 +0000 Message-ID: <BLU137-W39782B014D25437FD8D0E093B40@phx.gbl> Content-Type: multipart/alternative; boundary="_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: Glen Zorn <glenzorn@comcast.net>, Russ Housley <housley@vigilsec.com>, <radiusext@ops.ietf.org> Subject: RE: New Version Notification - draft-ietf-geopriv-radius-lo-22.txt Date: Mon, 16 Feb 2009 23:31:43 -0800 MIME-Version: 1.0 --_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Watching the latest review comments=2C I wasn't sure whether the issue rela= ting to request for location data had been resolved. The draft states that = the RADIUS server can request location-data if the client indicated that it= was location capable. However=2C since the location data provided was to= be considered opaque=2C it can't check whether the actual data corresponde= d to the requested info without code modifications. =20 There was also the question of the meaning of "retransmission allowed" in t= his context=3B this issue has also arisen in http://www.ietf.org/internet-d= rafts/draft-ietf-geopriv-sip-lo-retransmission-01.txt. For example=2C tha= t document states: Bear in mind=2C however=2C that <retransmission-allowed> is not intended to provide any protocol-level mechanism to prevent unauthorized parties from learning location through means like eavesdropping. It is merely a way to express the preferences of the Rule Maker to the LR. If the LR were=2C for example=2C legally bound to follow the privac= y preferences expressed by Rule Makers=2C then they might incur liability of they ignored the <retransmission-allowed> parameter. No further privacy protection is assumed to be provided by <retransmission- allowed>.... In this architecture=2C the question of who is an "authorized recipient" from the point of view of the Rule Maker has been muddy. The ... elements along the path are authorized to receive and forward the ... message=3B does that make them automatically authorized recipients of the LI it contains? The final target of the ... message will receive the LI along with other information=2C but it may be different than the initial target in a variety of scenarios=3B is it authorized to read the LI? These questions and concerns are particularly problematic when <retransmission-allowed> is set to "no" (the default case). This core concern might be put as "to whom does <retransmission-allowed> apply in location-based routing?"=20 These issues also arise in RADIUS since standard RADIUS attributes like NAS= -IP-Address=2C=20 NAS-IPv6-Address=2C NAS-Identifier are required by [RFC2865] to be sent in = an Access-Request and also can be used for the purposes of location determination. RADIUS proxie= s will forward these=20 attributes along the path to the the RADIUS server regardless of whether th= e rules allow retransmission or not. Since the RADIUS protocol doesn't provide confident= iality=2C=20 user location is sent in the clear. Are any of these existing practices af= fected by the carriage of rules within RADIUS packets? =20 --_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> Watching the latest review comments=2C I wasn't sure whether the issue rela= ting to request for location data had been resolved. The draft states that = the RADIUS server can request location-data if the client indicated that it= was location capable. =3B However=2C =3B since the location data p= rovided was to be considered opaque=2C it can't check whether the actual da= ta corresponded to the requested info without code modifications. =3B <= br><br>There was also the question of the meaning of "retransmission allowe= d" in this context=3B this issue has also arisen in http://www.ietf.org/int= ernet-drafts/draft-ietf-geopriv-sip-lo-retransmission-01.txt. =3B = =3B For example=2C that document states:<br><br><pre> Bear in mind=2C how= ever=2C that <=3Bretransmission-allowed>=3B is not intended<br> to pr= ovide any protocol-level mechanism to prevent unauthorized<br> parties fr= om learning location through means like eavesdropping. It<br> is merely = a way to express the preferences of the Rule Maker to the<br> LR. If the= LR were=2C for example=2C legally bound to follow the privacy<br> prefer= ences expressed by Rule Makers=2C then they might incur liability<br> of = they ignored the <=3Bretransmission-allowed>=3B parameter. No further<= br> privacy protection is assumed to be provided by <=3Bretransmission-= <br> allowed>=3B....<br><br> In this architecture=2C the question of = who is an "authorized<br> recipient" from the point of view of the Rule M= aker has been muddy.<br> The ... elements along the path are authorized t= o receive and forward<br> the ... message=3B does that make them automati= cally authorized<br> recipients of the LI it contains? The final target = of the ...<br> message will receive the LI along with other information= =2C but it may<br> be different than the initial target in a variety of s= cenarios=3B is it<br> authorized to read the LI?<br><br> These question= s and concerns are particularly problematic when<br> <=3Bretransmission= -allowed>=3B is set to "no" (the default case). This<br> core concern = might be put as "to whom does <=3Bretransmission-allowed>=3B<br> appl= y in location-based routing?" <br><br>These issues also arise in RADIUS sin= ce standard RADIUS attributes like NAS-IP-Address=2C <br>NAS-IPv6-Address= =2C NAS-Identifier are required by [RFC2865] to be sent in an Access-Reques= t and<br>also can be used for the purposes of location determination. RADI= US proxies will forward these <br>attributes along the path to the the RADI= US server regardless of whether the rules allow<br>retransmission or not. = Since the RADIUS protocol doesn't provide confidentiality=2C <br>user locat= ion is sent in the clear. Are any of these existing practices affected by<= br>the carriage of rules within RADIUS packets? <br><br><br></pre></body> </html>= --_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 07:15:21 +0000 Message-ID: <499A63FA.1010906@deployingradius.com> Date: Tue, 17 Feb 2009 08:15:06 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bernard Aboba <bernard_aboba@hotmail.com> CC: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, Stefan Winter <stefan.winter@restena.lu>, "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: Re: Issue 282: backward compatibility, proposed text Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Question: At various points we have talked about separating out the > material on DNS SRV-based discovery. How does this recommendation > relate to that? For example, assuming that DNS SRV RR queries aren't > protected by DNSSEC, couldn't the discovery process generate a "fallback > to classic RADIUS"? Yes. > (e.g. if only the FQDN of the server is provided and > DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS > was supported). For example, couldn't an attacker spoof a response to > the DNS SRV RR query and convince the querier that only RADIUS was > available? Systems should be implemented so that administrators can require RADSEC for particular home servers. This turns the down-bidding attack into a DoS attack, as the proxy will refuse to connect over plain RADIUS. > I think you need to say a bit more about the assumed deployment model > and configuration/discovery. For example, that RADSEC is deployed for > use by proxies in talking to each other, and that as a result, these > proxies *only* talk RADSEC. And are configured to require RADSEC. > It's a bit trickier if a NAS is capable of > speaking both RADSEC and RADIUS. In that situation it seems that the > NAS would be configured to speak one or the other to a given RADIUS > server, and that DNS-based discovery would play no role. Is that > right? Likely, yes. However, it may be simple for clients to use SRV lookups, too, as it avoids manual reconfiguration when the network changes. Clients should also be configurable to require RADSEC. If you assume that the client DNS lookups are performed over a "secure" administrative network, then DNSSEC may not be required. > Is this advice still true if the RADIUS client has a > DNSSEC-validating stub resolver and therefore is able to do secure > discovery? Dynamic discover is always useful, and should be implemented where possible. > In the discussion of RADIUS over DTLS, there had been discussion of the > ability to distinguish RADIUS/DTLS from RADIUS on the fly. So I'm > wondering if this advice on manual configuration applies there too, or not. Yes. > And overall, I'm curious about where the text relating to DNS discovery > is going/belongs. In the draft? Outside of it in a separate document? > None of these? In a separate draft. DTLS and normal RADIUS could be using dynamic discovery, too. 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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 07:03:51 +0000 Message-ID: <BLU137-W3382FC5C76E36C12AAD1E493B40@phx.gbl> Content-Type: multipart/alternative; boundary="_9a21f70a-3fb1-468e-90ac-51bf57830343_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, Stefan Winter <stefan.winter@restena.lu> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: RE: Issue 282: cipher suites, discussion needed Date: Mon, 16 Feb 2009 23:03:39 -0800 MIME-Version: 1.0 --_9a21f70a-3fb1-468e-90ac-51bf57830343_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes=2C in general it's a good idea to acknowledge that TLS implementations = need to implement the mandatory-to-implement ciphersuites for the versions = they support. With respect to NIST guidance=2C I'm a bit puzzled (e.g. S= P 800-120 seems to imply that the 1.1 mandatory-to-implement ciphersuite is= ok=2C but the 1.2 one is not). =20 > Subject: RE: Issue 282: cipher suites=2C discussion needed > Date: Mon=2C 16 Feb 2009 21:48:38 -0800 > From: jsalowey@cisco.com > To: stefan.winter@restena.lu > CC: radiusext@ops.ietf.org >=20 > You could just leave this to the TLS specification. For version 1.0 and = 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is TLS_RSA_WITH_= AES_128_CBC_SHA. If it is common today for implementations also to implem= ent the RC4 ciphers you can have that as a recommendation as well. Somethi= ng like: >=20 > "RADSEC implementation MUST support he mandatory to implement cipher suit= es specified in TLS. For purposes of compatibility with some current deplo= yments implementations SHOULD support TLS_RSA_WITH_RC4_128_SHA as well."=20 >=20 > Cheers=2C >=20 > Joe=20 --_9a21f70a-3fb1-468e-90ac-51bf57830343_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> Yes=2C in general it's a good idea to acknowledge that TLS implementations = need to implement the mandatory-to-implement ciphersuites for the versions = they support. =3B =3B With respect to NIST guidance=2C I'm a bit pu= zzled =3B (e.g. SP 800-120 seems to imply that the 1.1 mandatory-to-imp= lement ciphersuite is ok=2C but the 1.2 one is not). =3B <br><br>>=3B= Subject: RE: Issue 282: cipher suites=2C discussion needed<br>>=3B Date:= Mon=2C 16 Feb 2009 21:48:38 -0800<br>>=3B From: jsalowey@cisco.com<br>&g= t=3B To: stefan.winter@restena.lu<br>>=3B CC: radiusext@ops.ietf.org<br>&= gt=3B <br>>=3B You could just leave this to the TLS specification. For v= ersion 1.0 and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it i= s TLS_RSA_WITH_AES_128_CBC_SHA. If it is common today for implementations= also to implement the RC4 ciphers you can have that as a recommendation as= well. Something like:<br>>=3B <br>>=3B "RADSEC implementation MUST su= pport he mandatory to implement cipher suites specified in TLS. For purpos= es of compatibility with some current deployments implementations SHOULD su= pport TLS_RSA_WITH_RC4_128_SHA as well." <br>>=3B <br>>=3B Cheers=2C<br= >>=3B <br>>=3B Joe <br><br></body> </html>= --_9a21f70a-3fb1-468e-90ac-51bf57830343_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 07:00:27 +0000 Message-ID: <BLU137-W53D202CC91D4881E6FFCC193B40@phx.gbl> Content-Type: multipart/alternative; boundary="_246a6d5a-ca91-412b-8044-3a11c120690b_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, Stefan Winter <stefan.winter@restena.lu> CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: RE: Issue 282: backward compatibility, proposed text Date: Mon, 16 Feb 2009 22:59:55 -0800 MIME-Version: 1.0 --_246a6d5a-ca91-412b-8044-3a11c120690b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > As a consequence=2C the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to classic RADIUS is NOT RECOMMENDED=2C as it may lead to > down-bidding attacks on the peer communication. Question: At various points we have talked about separating out the materi= al on DNS SRV-based discovery. How does this recommendation relate to that= ? For example=2C assuming that DNS SRV RR queries aren't protected by DNSS= EC=2C couldn't the discovery process generate a "fallback to classic RADIUS= "? (e.g. if only the FQDN of the server is provided and DNS SRV RR queries = are used to determine whether RADSEC and/or RADIUS was supported). For ex= ample=2C couldn't an attacker spoof a response to the DNS SRV RR query and = convince the querier that only RADIUS was available? =20 > Please comment if this text can satisfactorily close this sub-issue. I think you need to say a bit more about the assumed deployment model and c= onfiguration/discovery. For example=2C that RADSEC is deployed for use by = proxies in talking to each other=2C and that as a result=2C these proxies *= only* talk RADSEC. It's a bit trickier if a NAS is capable of speaking bot= h RADSEC and RADIUS. In that situation it seems that the NAS would be conf= igured to speak one or the other to a given RADIUS server=2C and that DNS-b= ased discovery would play no role. Is that right? Is this advice still t= rue if the RADIUS client has a DNSSEC-validating stub resolver and therefor= e is able to do secure discovery?=20 In the discussion of RADIUS over DTLS=2C there had been discussion of the a= bility to distinguish RADIUS/DTLS from RADIUS on the fly. So I'm wondering= if this advice on manual configuration applies there too=2C or not.=20 And overall=2C I'm curious about where the text relating to DNS discovery i= s going/belongs. In the draft? Outside of it in a separate document? Non= e of these? --_246a6d5a-ca91-412b-8044-3a11c120690b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> >=3B As a consequence=2C the selection of transports to communicate from = a<br>>=3B client to a server is a manual administrative action. An autom= atic<br>>=3B fallback to classic RADIUS is NOT RECOMMENDED=2C as it may l= ead to<br>>=3B down-bidding attacks on the peer communication.<br><br>Que= stion: =3B At various points we have talked about separating out the ma= terial on DNS SRV-based discovery. =3B How does this recommendation rel= ate to that? =3B For example=2C assuming that DNS SRV RR queries aren't= protected by DNSSEC=2C couldn't the discovery process generate a "fallback= to classic RADIUS"? (e.g. if only the FQDN of the server is provided and D= NS SRV RR queries are used to determine whether RADSEC and/or RADIUS was su= pported). =3B =3B For example=2C couldn't an attacker spoof a respo= nse to the DNS SRV RR query and convince the querier that only RADIUS was a= vailable? =3B <br><br>>=3B Please comment if this text can satisfacto= rily close this sub-issue.<br><br>I think you need to say a bit more about = the assumed deployment model and configuration/discovery. =3B For examp= le=2C that RADSEC is deployed for use by proxies in talking to each other= =2C and that as a result=2C these proxies *only* talk RADSEC. =3B It's = a bit trickier if a NAS is capable of speaking both RADSEC and RADIUS. = =3B In that situation it seems that the NAS would be configured to speak on= e or the other to a given RADIUS server=2C and that DNS-based discovery wou= ld play no role. =3B Is that right? =3B =3B Is this advice stil= l true if the RADIUS client has a DNSSEC-validating stub resolver and there= fore is able to do secure discovery? <br><br>In the discussion of RADIUS ov= er DTLS=2C there had been discussion of the ability to distinguish RADIUS/D= TLS from RADIUS on the fly. =3B So I'm wondering if this advice on manu= al configuration applies there too=2C or not. <br><br>And overall=2C I'm cu= rious about where the text relating to DNS discovery is going/belongs. = =3B In the draft? =3B Outside of it in a separate document? =3B Non= e of these?<br></body> </html>= --_246a6d5a-ca91-412b-8044-3a11c120690b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 05:49:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 282: cipher suites, discussion needed Date: Mon, 16 Feb 2009 21:48:38 -0800 Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE507739D2B@xmb-sjc-225.amer.cisco.com> Thread-Topic: Issue 282: cipher suites, discussion needed Thread-Index: AcmMKPZ7b4B30p22TNi06MFRHINH8AEmRuag From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> To: "Stefan Winter" <stefan.winter@restena.lu> Cc: <radiusext@ops.ietf.org> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1627; t=1234849720; x=1235713720; 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<jsalowey@ci sco.com> |Subject:=20RE=3A=20Issue=20282=3A=20cipher=20suites,=20dis cussion=20needed |Sender:=20; bh=mx8VjgjOIfg9KKT4gtg5eT8JHCRPFxoYtrGb+SioNzw=; b=lqWpxyfvwg9qBaIGGh1wxMbRNmEy9l5rE7K0DWHuYbcuM8Uy1g/ROTrvfe x/+V/C7kWCEhCpLW75Dxd/cWH6dCxWq3NPimijnXAdZkbhDNCE4njpDnt6Vx 0HfG7mqsLrLkc219Ar4L1Xp33oR05HpaMdFPRlGm/OI5/0nRjYN+E=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); You could just leave this to the TLS specification. For version 1.0 and = 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is = TLS_RSA_WITH_AES_128_CBC_SHA. If it is common today for = implementations also to implement the RC4 ciphers you can have that as a = recommendation as well. Something like: "RADSEC implementation MUST support he mandatory to implement cipher = suites specified in TLS. For purposes of compatibility with some = current deployments implementations SHOULD support = TLS_RSA_WITH_RC4_128_SHA as well."=20 Cheers, Joe=20 > -----Original Message----- > From: Stefan Winter [mailto:stefan.winter@restena.lu]=20 > Sent: Wednesday, February 11, 2009 1:13 AM > To: Joseph Salowey (jsalowey) > Cc: radiusext@ops.ietf.org > Subject: Issue 282: cipher suites, discussion needed >=20 > Hi, >=20 > > 3. I'm not sure I understand the choice of ciphersuites. > > > > Why is TLS_RSA_WITH_RC4_128_SHA recommended? It seems that=20 > it would=20 > > be much preferable to use AES or 3DES? > > =20 >=20 > I could use a little help here. Is there anyone willing to=20 > investigate cipher suite selection? An alternative would be=20 > to follow the path of e.g. the EAP tunnel reqs, which cite=20 > NIST references for acceptable cipher suites... >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 17 Feb 2009 05:35:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 282: backward compatibility, proposed text Date: Mon, 16 Feb 2009 21:34:49 -0800 Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE507739D27@xmb-sjc-225.amer.cisco.com> Thread-Topic: Issue 282: backward compatibility, proposed text Thread-Index: AcmMKOUhGj0kPgomSgOfc73z5q6c0AEl9VRQ From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> To: "Stefan Winter" <stefan.winter@restena.lu> Cc: <radiusext@ops.ietf.org> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3343; t=1234848891; x=1235712891; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20RE=3A=20Issue=20282=3A=20backward=20compatibili ty,=20proposed=20text |Sender:=20; bh=m6EjWw1S6yzIUnkfnqcuuNHmX0stk34n5kByFUc1LnU=; b=LaqruMVjKG6bR/a93+dtlDtSkph82/+E0cZ5tRD/q8bG7it3IAuYwSU72Q tdjrpSKL2XhJfRqFCv8bgF/JMwGRok6+wK69ZLbp0Rb1Ty4j9TNIhJuwplhU ImeY3q6FNf; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Hi Stefan, This looks good. Thanks, Joe > -----Original Message----- > From: Stefan Winter [mailto:stefan.winter@restena.lu]=20 > Sent: Wednesday, February 11, 2009 1:13 AM > To: Joseph Salowey (jsalowey) > Cc: radiusext@ops.ietf.org > Subject: Issue 282: backward compatibility, proposed text >=20 > Hi, >=20 > > 1. How is backward compatibility/forward migration of=20 > RADSEC handled? > > Operational recommendations in this area should be discussed. The > > potential for rollback attacks should also be covered in=20 > the security=20 > > considerations section. > > =20 >=20 > Section 4 of the new -03 revision reads: >=20 > 4. Compatibility with other RADIUS transports >=20 > Ongoing work in the IETF defines multiple alternative transports to > the classic UDP transport model as defined in [RFC2865], namely > RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS > [I-D.dekok-radext-dtls] and the present document on RadSec. >=20 > RadSec does not specify any inherent backwards compatibility to > classic RADIUS or cross compatibility to the other transports, i.e. > an implementation which implements RadSec only will not be able to > receive or send RADIUS packet payloads over other transports. An > implementation wishing to be backward or cross compatible (i.e. > wishes to serve clients using other transports than=20 > RadSec) will need > to implement the other transports and RadSec transport and be > prepared to send and receive on all implemented=20 > transports, which is > called a multi-stack implementation. >=20 > If a given IP device is able to receive RADIUS payloads on multiple > transports, this may or may not be the same instance of=20 > software, and > it may or may not serve the same purposes. It is not safe=20 > to assume > that both ports are interchangeable. In particular, it can not be > assumed that state is maintained for the packet payloads=20 > between the > transports. Two such instances MUST be considered separate RADIUS > server entities. >=20 > As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to > down-bidding attacks on the peer communication. >=20 > And the Security Consideration contains: >=20 > If peer communication between two devices is configured for both > RadSec and classic RADIUS, a failover from RadSec to classic RADIUS > opens the way for a down-bidding attack if an adversary can > maliciously close the TCP connection, or prevent it from being > established. In this case, security of the packet payload=20 > is reduced > from the selected TLS cipher suite packet encryption to the classic > MD5 per-attribute encryption. >=20 > Please comment if this text can satisfactorily close this sub-issue. >=20 > Greetings, >=20 > Stefan Winter >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 > Nationale et de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 13 Feb 2009 22:04:31 +0000 Message-ID: <BLU137-DAV2348B572202C594529A1D93B80@phx.gbl> From: "Bernard Aboba" <Bernard_Aboba@hotmail.com> To: "'David B. Nelson'" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org> Subject: RE: IETF Trustees announcement Date: Fri, 13 Feb 2009 14:03:53 -0800 Message-ID: <02c701c98e26$f5320fd0$df962f70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcmOEpD/xx9seH21QoeqRvjB/9LBzgAAO5awAATbBhA= Content-Language: en-us I am assuming this is in the works... does anyone know details? -----Original Message----- From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] Sent: Friday, February 13, 2009 11:45 AM To: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: IETF Trustees announcement Do we know the xml2rfc will be updated? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 13 Feb 2009 19:45:33 +0000 From: "David B. Nelson" <dnelson@elbrysnetworks.com> To: "'Bernard Aboba'" <bernard_aboba@hotmail.com>, <radiusext@ops.ietf.org> Subject: RE: IETF Trustees announcement Date: Fri, 13 Feb 2009 14:45:10 -0500 Organization: Elbrys Networks, Inc. Message-ID: <CEBFF6EEAE9C41778BA8AEEB95357626@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcmOEpD/xx9seH21QoeqRvjB/9LBzgAAO5aw Do we know the xml2rfc will be updated? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 13 Feb 2009 19:34:45 +0000 Message-ID: <BLU137-W23B40722ABE3618FE1CDB393B80@phx.gbl> Content-Type: multipart/alternative; boundary="_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_" From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: IETF Trustees announcement Date: Fri, 13 Feb 2009 11:33:57 -0800 MIME-Version: 1.0 --_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ed Juskevicius has recently sent a message to the IETF Announce list=2C upd= ating the IETF community on the status of the revision to the "Legal Provis= ions Relating to IETF Documents" policy:http://www.ietf.org/mail-archive/we= b/ietf-announce/current/msg05741.html =20 The approved text available now on the IETF Trust website at: http://trustee.ietf.org/policyandprocedures.html As Ed notes=2C the newly approved policy is dated February 12=2C 2009=2C an= d the effective date is February 15=2C 2009.=20 =20 If you are involved in authoring=2C editing or revising Internet Drafts=2C = then I would strongly encourage you familiarize yourself with the new polic= y so that you are aware of the latest copyright statements and other boiler= plate legend text that will be required on all contributions to the IETF st= arting on February 15=2C 2009.=20 =20 =20 = --_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px=3B padding:0px } body.hmmessage { font-size: 10pt=3B font-family:Verdana } </style> </head> <body class=3D'hmmessage'> Ed Juskevicius has recently sent a message to the IETF Announce list=2C upd= ating the IETF community on the status of =3Bthe revision to the "Legal= Provisions Relating to IETF Documents" policy:<BR><A href=3D"http://www.ie= tf.org/mail-archive/web/ietf-announce/current/msg05741.html">http://www.iet= f.org/mail-archive/web/ietf-announce/current/msg05741.html</A><BR>  =3B<BR> The approved text available now on the IETF Trust website at:<BR> <DIV> =3B<A href=3D"http://trustee.ietf.org/policyandprocedures.html" r= el=3Dnofollow>http://trustee.ietf.org/policyandprocedures.html</A></DIV> <DIV><BR>As Ed notes=2C the newly approved policy is dated February 12=2C 2= 009=2C and the effective date is February 15=2C 2009. </DIV> <DIV> =3B</DIV> <DIV>If you are involved in authoring=2C editing or revising Internet Draft= s=2C then I would strongly encourage you familiarize yourself with the new = policy so that you are aware of the latest copyright statements and other b= oilerplate legend text that will be required on all contributions to the IE= TF starting on February 15=2C 2009. </DIV> <DIV> =3B</DIV> <DIV><FONT face=3DVerdana color=3D#444444 size=3D2></FONT> =3B</DIV> <DIV><A href=3D"http://trustee.ietf.org/policyandprocedures.html" rel=3Dnof= ollow></A> =3B</DIV></body> </html>= --_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 22:02:31 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IPR Claim on RFC 2865 Date: Wed, 11 Feb 2009 16:59:28 -0500 Message-ID: <A6398B0DB62A474C82F61554EE93728707201B76@proton.jnpr.net> Thread-Topic: IPR Claim on RFC 2865 Thread-Index: AcmKCMv4knSgTfAGTMWeyNe+Xs5sUgCirrRQ From: Stephen Hanna <shanna@juniper.net> To: "Bernard Aboba" <bernard_aboba@hotmail.com>, <radiusext@ops.ietf.org> I would like to clarify Juniper's position on this IPR claim. The claim was filed erroneously. We have withdrawn it and do not intend to submit it again. Please disregard this claim. I apologize for this error, although I was not personally involved in it. Sorry, Steve=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, February 08, 2009 11:15 AM > To: radiusext@ops.ietf.org > Subject: IPR Claim on RFC 2865 >=20 >=20 > The IETF Secretariat has received an IPR claim relating to RF=20 > 2865, submitted by > Juniper Networks: >=20 > http://www.ietf.org/ietf/IPR/juniper-ipr-rfc-2865.txt >=20 > At this time, the IPR entry, available below, indicates that=20 > the claim has been withdrawn: > https://datatracker.ietf.org/ipr/1049/ >=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: <http://psg.com/lists/radiusext/> >=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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:15:13 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-radsec-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090211091501.4F6A93A63D2@core3.amsl.com> Date: Wed, 11 Feb 2009 01:15:01 -0800 (PST) --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 : TLS encryption for RADIUS over TCP (RadSec) Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-03.txt Pages : 17 Date : 2009-02-11 This document specifies security on the transport layer (TLS) for the RADIUS protocol [RFC2865] when transmitted over TCP [I-D.dekok-radext-tcp-transport]. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-radext-radsec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-11011037.I-D@ietf.org> --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: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:14:18 +0000 Message-ID: <499296A1.5000008@restena.lu> Date: Wed, 11 Feb 2009 10:13:05 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issue 281: new (separate) draft upcoming Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hello, the algorithm discussed in this issue has been clarified in the last meeting. As discussed in that meeting, the entire dynamic discovery part of the RadSec draft will go into a separate draft. This makes the issue obsolete for the RadSec document. A draft for dynamic discovery will follow soon. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:14:12 +0000 Message-ID: <4992968D.5010103@restena.lu> Date: Wed, 11 Feb 2009 10:12:45 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: cert validation, proposed text Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 2. I think the certificate handling and authorization section needs to > be more specific for supporting mandatory to implement options. > Currently, the document implicitly requires trust root based > authorization where all certs issued by a given trust root are > authorized. Some more specific rules are discussed in an informative > section. I believe some of this needs to be normative and more specific > in order to have interoperable implementations. This should also be > discussed in the security considerations. > Section 2.2 now reads: 2.2. Connection Setup RadSec nodes 1. establish TCP connections as per [I-D.dekok-radext-tcp-transport] 2. negotiate TLS sessions according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply: * The authentication MUST be mutual, i.e. both the RadSec server and the RadSec client authenticate each other. * The client MUST NOT negotiate cipher suites which only provide integrity protection. * The TLS session MAY use mutual PSKs for connection setup. * The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be supported. * The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2 (1) ) 3. If TLS is used in an X.509 certificate based operation mode, the following list of certificate validation options applies: * Implementations MUST allow to configure a list of acceptable Certification Authorities for incoming connections. * Certificate validation MUST include the verification rules as per [RFC5280]. If an SRV entry is present in the certificate and dynamic discovery based on DNS is used, the SRV entry SHOULD be validated. refence x.y.z here. * Implementations SHOULD indicate their acceptable Certification Authorities as per section 7.4.4 (server side) and x.y.z ["Trusted CA Indication"] (client side) of [RFC5246] (see Section 3.1 (1) ) * Implementations SHOULD allow to configure a list of acceptable certificates, identified via certificate fingerprint. * Peer validation always includes a check on whether the DNS name or the IP address of the server that is contacted matches its certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN. * Implementations SHOULD allow to configure a set of acceptable values for subjectAltName:URI. There's no additional text in Security Considerations since was not sure if additional text was needed with this new text. Please comment if this text can satisfactorily close this sub-issue. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:14:02 +0000 Message-ID: <49929691.8000208@restena.lu> Date: Wed, 11 Feb 2009 10:12:49 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: cipher suites, discussion needed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 3. I'm not sure I understand the choice of ciphersuites. > > Why is TLS_RSA_WITH_RC4_128_SHA recommended? It seems that it would be > much preferable to use AES or 3DES? > I could use a little help here. Is there anyone willing to investigate cipher suite selection? An alternative would be to follow the path of e.g. the EAP tunnel reqs, which cite NIST references for acceptable cipher suites... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:13:54 +0000 Message-ID: <49929699.3080000@restena.lu> Date: Wed, 11 Feb 2009 10:12:57 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: dynamic discovery text cleanup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 5. The terms "dynamic peer resolution" and "dynamic peer discovery" are > used in the document and not clearly defined. > The terms have been unified and clarified by referencing a (new) separate draft on dynamic peer discovery (which doesn't exist yet, but will be submitted soon). Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:13:46 +0000 Message-ID: <49929695.7050206@restena.lu> Date: Wed, 11 Feb 2009 10:12:53 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: shared secret for TCP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 4. The document should state that the fixed string "radsec" shared > secret MUST NOT be used when TLS is not available. > I propose to add text to tcp-transport and volunteer for writing it. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:13:38 +0000 Message-ID: <49929688.5090903@restena.lu> Date: Wed, 11 Feb 2009 10:12:40 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: backward compatibility, proposed text Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 1. How is backward compatibility/forward migration of RADSEC handled? > Operational recommendations in this area should be discussed. The > potential for rollback attacks should also be covered in the security > considerations section. > Section 4 of the new -03 revision reads: 4. Compatibility with other RADIUS transports Ongoing work in the IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS [I-D.dekok-radext-dtls] and the present document on RadSec. RadSec does not specify any inherent backwards compatibility to classic RADIUS or cross compatibility to the other transports, i.e. an implementation which implements RadSec only will not be able to receive or send RADIUS packet payloads over other transports. An implementation wishing to be backward or cross compatible (i.e. wishes to serve clients using other transports than RadSec) will need to implement the other transports and RadSec transport and be prepared to send and receive on all implemented transports, which is called a multi-stack implementation. If a given IP device is able to receive RADIUS payloads on multiple transports, this may or may not be the same instance of software, and it may or may not serve the same purposes. It is not safe to assume that both ports are interchangeable. In particular, it can not be assumed that state is maintained for the packet payloads between the transports. Two such instances MUST be considered separate RADIUS server entities. As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to down-bidding attacks on the peer communication. And the Security Consideration contains: If peer communication between two devices is configured for both RadSec and classic RADIUS, a failover from RadSec to classic RADIUS opens the way for a down-bidding attack if an adversary can maliciously close the TCP connection, or prevent it from being established. In this case, security of the packet payload is reduced from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. Please comment if this text can satisfactorily close this sub-issue. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 11 Feb 2009 09:13:31 +0000 Message-ID: <4992969D.3030107@restena.lu> Date: Wed, 11 Feb 2009 10:13:01 +0100 From: Stefan Winter <stefan.winter@restena.lu> User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> CC: radiusext@ops.ietf.org Subject: Issue 282: PSK / cert fingerprint operation Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, > 6. Would RADSEC benefit from a mechanism that did not require a PKI? > This could be achieved by specifying a certificate fingerprint or PSK > mode of operation. > The text in 2.2 has been clarified that a TLS PSK operation mode is allowed. Cert fingerprint as a means of validating a connection attempt has been added as a SHOULD. Please comment if this text can satisfactorily close this sub-issue. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 08 Feb 2009 16:15:43 +0000 Message-ID: <BLU137-W47766F65832E9632BF548D93BF0@phx.gbl> From: Bernard Aboba <bernard_aboba@hotmail.com> To: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org> Subject: IPR Claim on RFC 2865 Date: Sun, 8 Feb 2009 08:14:32 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 The IETF Secretariat has received an IPR claim relating to RF 2865=2C submi= tted by Juniper Networks: http://www.ietf.org/ietf/IPR/juniper-ipr-rfc-2865.txt At this time=2C the IPR entry=2C available below=2C indicates that the clai= m has been withdrawn: https://datatracker.ietf.org/ipr/1049/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/> Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 02 Feb 2009 10:01:21 +0000 Message-ID: <4986C43D.4050109@deployingradius.com> Date: Mon, 02 Feb 2009 11:00:29 +0100 From: Alan DeKok <aland@deployingradius.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dave Nelson <d.b.nelson@comcast.net> CC: radiusext@ops.ietf.org Subject: Re: Issue: Data Type Advice Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave Nelson wrote: > Bernard Aboba writes... > >> Right now, this section seems to suggest that SDO specifications utilizing >> existing RADIUS standard data types can avail themselves of IETF review. > > Yes, but what does that mean? Designated Expert? AAA Doctors? Certainly > not IETF Last Call. The document suggests requesting a review from AAA-doctors. 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: <http://psg.com/lists/radiusext/>
- submission of DNS-based dynamic discovery for Rad… Stefan Winter