Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Feb 2006 02:09:48 +0000 Date: Mon, 27 Feb 2006 21:09:21 -0500 From: Barney Wolff To: radiusext@ops.ietf.org Subject: Extended-Space attribute draft available Message-ID: <20060228020921.GA2717@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Greg Weber and I have written a draft defining an Extended-Space attribute. Here's the abstract: The RADIUS protocol is being extended beyond the wildest imaginations of its original designers. These extensions are pushing up against the existing limitations on the numbers, length, base types and grouping of RADIUS attributes. This document specifies a method of relaxing those limitations. While it works its way to the IETF draft directory, you're welcome to retrieve it here: http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html This draft is a companion piece the the design guidelines draft, and, we hope, will be adopted as a RADEXT work item. Comments and corrections are welcome, and if necessary I can try to get a -01 version in before next week's deadline. Barney Wolff -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Feb 2006 23:50:32 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-filter-rules-00.txt Message-Id: Date: Mon, 27 Feb 2006 18:50:02 -0500 --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 : Filter Attributes Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-filter-rules-00.txt Pages : 28 Date : 2006-2-27 In certain scenarios it is desirable to limit user access using filters or redirection. This document proposes additional attributes for this purpose, for use with the Remote Authentication Dial In User Server (RADIUS). The attributes described in this document are expected to be useful in a variety of environments, including enterprise and service provider scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-filter-rules-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-filter-rules-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-27155643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-filter-rules-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-filter-rules-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27155643.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Feb 2006 22:32:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility work item Date: Mon, 27 Feb 2006 17:34:45 -0500 Message-ID: Thread-Topic: Crypto-agility work item Thread-Index: AcY5phywRs2FLkYvTB+0OtVT2SfitACR6W4A From: "Avi Lior" To: "Alan DeKok" , "Nelson, David" Cc: You are right about that free radius dictionaries. FWIW there are many more then the list you have posted.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Friday, February 24, 2006 6:47 PM > To: Nelson, David > Cc: radiusext@ops.ietf.org > Subject: Re: Crypto-agility work item >=20 > ... > > Are there others I've overlooked? >=20 > $ grep encrypt=3D freeradius/share/dictionary* | sed .... >=20 > User-Password 2 string encrypt=3D1 > Tunnel-Password 69 string=09 > has_tag,encrypt=3D2 > MS-CHAP-MPPE-Keys 12 octets encrypt=3D1 > MS-MPPE-Send-Key 16 octets encrypt=3D2 > MS-MPPE-Recv-Key 17 octets encrypt=3D2 >=20 > Message-Authenticator doesn't need any flags in the=20 > implementation, so it isn't listed here. The 'encrypt=3D1'=20 > means "like User-Password", > 2 means "like Tunnel-Password", and (below) 3 means "like=20 > Ascend-Send-Secret". >=20 > We also have encrypted VSA's. >=20 > 3GPP2-MN-HA-Shared-Key 58 string encrypt=3D2 > Ascend-Send-Secret 214 string encrypt=3D3 > Ascend-Receive-Secret 215 string encrypt=3D3 > X-Ascend-Send-Secret 214 string encrypt=3D3 > X-Ascend-Receive-Secret 215 string encrypt=3D3 > ERX-LI-Action 58 integer encrypt=3D2 > ERX-Med-Dev-Handle 59 octets encrypt=3D2 > ERX-Med-Ip-Address 60 ipaddr encrypt=3D2 > ERX-Med-Port-Number 61 integer encrypt=3D2 > Lucent-Send-Secret 214 string encrypt=3D3 > Lucent-Receive-Secret 215 string encrypt=3D3 >=20 > It looks like that's it. The FreeRADIUS dictionaries=20 > aren't authoritative, but they do have a large number of=20 > vendor dictionaries. >=20 > Alan DeKok. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 23:40:26 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Crypto-agility work item cc: radiusext@ops.ietf.org Date: Fri, 24 Feb 2006 18:47:11 -0500 Message-Id: <20060224234711.6676A16CC1@mail.nitros9.org> ... > Are there others I've overlooked? $ grep encrypt= freeradius/share/dictionary* | sed .... User-Password 2 string encrypt=1 Tunnel-Password 69 string has_tag,encrypt=2 MS-CHAP-MPPE-Keys 12 octets encrypt=1 MS-MPPE-Send-Key 16 octets encrypt=2 MS-MPPE-Recv-Key 17 octets encrypt=2 Message-Authenticator doesn't need any flags in the implementation, so it isn't listed here. The 'encrypt=1' means "like User-Password", 2 means "like Tunnel-Password", and (below) 3 means "like Ascend-Send-Secret". We also have encrypted VSA's. 3GPP2-MN-HA-Shared-Key 58 string encrypt=2 Ascend-Send-Secret 214 string encrypt=3 Ascend-Receive-Secret 215 string encrypt=3 X-Ascend-Send-Secret 214 string encrypt=3 X-Ascend-Receive-Secret 215 string encrypt=3 ERX-LI-Action 58 integer encrypt=2 ERX-Med-Dev-Handle 59 octets encrypt=2 ERX-Med-Ip-Address 60 ipaddr encrypt=2 ERX-Med-Port-Number 61 integer encrypt=2 Lucent-Send-Secret 214 string encrypt=3 Lucent-Receive-Secret 215 string encrypt=3 It looks like that's it. The FreeRADIUS dictionaries aren't authoritative, but they do have a large number of vendor dictionaries. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 21:48:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility work item Date: Fri, 24 Feb 2006 16:47:58 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021909E@MABOSEVS2.ets.enterasys.com> Thread-Topic: Crypto-agility work item thread-index: AcY5feTDUl9oeLpfQAy3yTu3pn4oFgABLNXwAAIOXHA= From: "Nelson, David" To: > The existing RADIUS security mechanisms include: >=20 > -- The MD5-based stream cipher used to obscure the User-Password > attribute. >=20 > -- The MD5-based MAC used to create the Response-Authenticator header > field. >=20 > -- The HMAC-MD5 MAC used to create the Message-Authenticator attribute. I neglected to mention: -- The MD5 based stream cipher used to obscure MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes. -- The MD5 based stream cipher used to obscure the Tunnel-Password attribute. Are there others I've overlooked? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 21:24:15 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Crypto-agility work item cc: radiusext@ops.ietf.org Date: Fri, 24 Feb 2006 16:30:53 -0500 Message-Id: <20060224213053.6199C16CC1@mail.nitros9.org> "Nelson, David" wrote: > There are other ways of securing RADIUS, most notably running it over a > protected transport, such as IPsec, TLS, DTLS, etc. I don't consider > these as RADIUS security mechanisms, however, as they are external to > RADIUS. In my experience, that's why people add security mechanisms to RADIUS. They can't trust that the external security mechanisms exist, or that they work. e.g. the IETF where the wireless sniffer grabbed someone's userid & password, because their admin had un-checked the "use encryption" box on the VPN box. There was no warning or notification to the end applications (or user) that traffic was being sent in the clear. > When we discuss new cryptographic algorithms for existing RADIUS > security mechanisms do we mean simply replacing MD5 or HMAC-MD5, as they > appear above, with some other algorithm? I would say that is a good first step. > Do we anticipate the creation of new attributes, such as a > Message-Authentication-Code attribute, to replace/supplement the > Message-Authenticator attribute? That is an option. I'm not sure how else we would add security to RADIUS. > Since the scope of this work includes key-wrap, we anticipate the > definition of new attributes, for key distribution, that are protected > by reversible encryption, using one or more algorithms. It would seem so. > Do we anticipate that other new attributes, similarly protected, could > be defined for use in transmission of other information besides keys? If we're defining encryption methods using new algorithms, we might as well use them for attributes other than keys. It would be minimal additional work, either in the spec or implementations, and could have significant utility in deployments. > Do we anticipate defining, by reference to other work, how key agreement > for the KEK (and other keys) shared by RADIUS clients and servers is > accomplished in an interoperable fashion? I would guess so. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 21:05:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Crypto-agility work item Date: Fri, 24 Feb 2006 16:04:57 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021909C@MABOSEVS2.ets.enterasys.com> Thread-Topic: Crypto-agility work item thread-index: AcY5feTDUl9oeLpfQAy3yTu3pn4oFgABLNXw From: "Nelson, David" To: Bernard Aboba writes... > The focus is on negotiation of cryptographic algorithms for > existing RADIUS security mechanisms.=20 Let's poke into this a little deeper. The existing RADIUS security mechanisms include: -- The MD5-based stream cipher used to obscure the User-Password attribute. -- The MD5-based MAC used to create the Response-Authenticator header field. -- The HMAC-MD5 MAC used to create the Message-Authenticator attribute. There are other ways of securing RADIUS, most notably running it over a protected transport, such as IPsec, TLS, DTLS, etc. I don't consider these as RADIUS security mechanisms, however, as they are external to RADIUS. When we discuss new cryptographic algorithms for existing RADIUS security mechanisms do we mean simply replacing MD5 or HMAC-MD5, as they appear above, with some other algorithm? Do we anticipate the creation of new attributes, such as a Message-Authentication-Code attribute, to replace/supplement the Message-Authenticator attribute? Since the scope of this work includes key-wrap, we anticipate the definition of new attributes, for key distribution, that are protected by reversible encryption, using one or more algorithms. Do we anticipate that other new attributes, similarly protected, could be defined for use in transmission of other information besides keys? Do we anticipate defining, by reference to other work, how key agreement for the KEK (and other keys) shared by RADIUS clients and servers is accomplished in an interoperable fashion? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 20:06:51 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Crypto-agility work item Date: Fri, 24 Feb 2006 12:06:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The fundamental goal of this work is to develop an openly specified, secure, interoperable mechanism for the negotiation of cryptographic algorithms within RADIUS. This includes algorithms for per-packet authentication and integrity protection, as well as keywrap. The focus is on negotiation of cryptographic algorithms for existing RADIUS security mechanisms. It is not about fundamental changes to the RADIUS security model, or changes to AAA key management models (that work is occurring in EAP WG). While this work item may enable implementations to satisfy FIPS 140-2 requirements, there are no guarantees that NIST will bless the resulting specification, or that the algorithms to be supported will remain on the list of FIPS 140-2 approved algorithms indefinitely. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 15:09:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RADIUS Keywrap (was RE: RADEXT Milestone revisions) Date: Fri, 24 Feb 2006 10:09:02 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219097@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADIUS Keywrap (was RE: RADEXT Milestone revisions) thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8AAFE1t8AAS6pOAACBByTAAEeg30AAfYi9A From: "Nelson, David" To: Glen Zorn writes... =20 > Just humor a moron a bit longer: how do you expect to "address modularity > of cipher suites" in RADIUS w/o modifying (at the very least the > processing of) the RADIUS headers? At a very simplistic level, adding new attributes is OK; changing the headers or PDU format is not. There are other things that are out of scope, of course, such as new commands. > Neither do I. Are you saying now that key management _is_ in scope of the > radext charter? No. I think that the definition new key management protocol(s) for use between RADIUS entities (clients, servers, proxies) is out of scope for RADEXT. I would not suggest that RADEXT invent its own key management protocol, in any event. I'm quite certain our friends in the Security Area would frown upon any such effort. Surely there are existing RFCs for such protocols that could have been referenced. What would satisfy my concerns would be a reference to existing key agreement protocols. I would like to see statement similar to: "Agreement of the KEK among RADIUS entities is not specified in this document. The following existing key agreement protocols are potentially suitable for this use: . To obtain global interoperability, the following method SHALL be mandatory to implement for RADIUS Keywrap." > Rather than, oh, say, discussing them on the list. Let's do so now. Starting with the issue around key agreement protocols for the KEK, and any other keys required in your draft that SHOULD NOT be derived from the RADIUS shared secret. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 07:00:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Diameter compatibility of VLAN-00 Date: Fri, 24 Feb 2006 02:00:42 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6013A844F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5Ds53Z/zFwelWTzi5vsWAmivLEwAAMDgw From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" Cc: , =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Friday, February 24, 2006 1:52 AM > To: Greg Weber (gdweber) > Cc: radiusext@ops.ietf.org; john.loughney@nokia.com > Subject: RE: Diameter compatibility of VLAN-00 >=20 > >I agree, but does 4072 say anything about future > >RADIUS attributes? I don't see this in section 5, > >but I'll have to look again at section 6. >=20 > That should probably be in RFC 4005, since that deals with=20 > RADIUS/Diameter=20 > gateways. >=20 > >Certainly hope not, or we don't have a very extensible > >framework. :-) >=20 > While RFC 3588 indicates that a new application ID is not=20 > required to add=20 > optional attributes to Diameter, addition of mandatory=20 > attributes do require=20 > a new application ID. =20 Yes, you made a similar comment earlier which I did=20 fully grok. Why is adding a RADIUS attribute to a=20 Diameter application equated with 'mandatory'? =20 I would think that RADIUS attributes carried in Diameter do not have the 'required' bit set in the attribute header, as RADIUS does not have the 'required' concept. No? Greg > This has proven to be something of a=20 > problem since=20 > there have been quite a few occasions where it has been=20 > necessary to add new=20 > attributes and allocating a new application ID ever time is=20 > not convenient. =20 > As a result, I'm not entirely clear that the VLAN attributes=20 > can be added to=20 > Diameter EAP or NASREQ without allocation of an application=20 > ID, although=20 > that hardly seems logical. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:56:53 +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: Diameter compatibility of VLAN-00 Date: Thu, 23 Feb 2006 22:56:45 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404714EE3@cacexc07.americas.cpqcorp.net> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5BGC1PN1RGsIgSZGLzy3ExNWUVwAAaXxgAADPyBAAADJdMAABRPjQ From: "Congdon, Paul T (ProCurve)" To: "Greg Weber (gdweber)" , Cc: , Not sure I see the need to break new ground here... If there is an existing mechanism to allow Diameter support we should continue to use it. I'd rather reference the mechanism that start including portions of text that are trying to represent it... Pass by reference, not by value for better portability in this case. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber=20 > (gdweber) > Sent: Thursday, February 23, 2006 10:30 PM > To: john.loughney@nokia.com > Cc: radiusext@ops.ietf.org; bernard_aboba@hotmail.com > Subject: RE: Diameter compatibility of VLAN-00 >=20 >=20 > I guess I am just observing that this is an opportunity to=20 > set a precedent. I do not feel strongly about this issue for=20 > this particular draft, but in general, how do we comply with=20 > this part of the charter: > "RADEXT WG work items MUST contain a Diameter=20 > compatibility section, outlining how > interoperability with Diameter will be=20 > maintained." > Saying, essentially, this RADIUS attribute can be used with=20 > so-and-so application may not be a clear specification given=20 > some of the complicated Diameter applications that may occur.=20 > I don't think a Diameter AVP table is out of the question- do you? >=20 > Greg >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Friday, February 24, 2006 1:13 AM > > To: Greg Weber (gdweber); bernard_aboba@hotmail.com > > Cc: radiusext@ops.ietf.org > > Subject: RE: Diameter compatibility of VLAN-00 > >=20 > > Are you suggesting havinging Diameter AVP tables in the draft? > >=20 > > John > >=20 > > >> How would this work? > > >>=20 > > >> Fix the typo. > > >>=20 > > >> Insert a section 4 that says the following: > > >>=20 > > >> 4. Diameter Considerations > > >>=20 > > >> Diameter needs to define identical attributes with=20 > the same Type > > >> values. The attributes should be available as part of > > the NASREQ > > >> application [RFC4005], as well as the Diameter EAP application > > >> [RFC4072]. > > >>=20 > > >> Add Informative references to [RFC4005] and [RFC4072]. > > > > > >It might be beneficial to set a more useful and=20 > informative precedent=20 > > >than was established with CUI, e.g. which messages in which=20 > > >applications may contain the attribute. This would seem to be=20 > > >analogous to the rigor of the typical RADIUS attribute=20 > table found in=20 > > >most RADIUS drafts. Disagree? > > > > > >Greg > > > > > >>=20 > > >> -------------------------------------------------------------- > > >> --------------------------- > > >> Description of issue: Diameter compatibility of VLAN-00 Submitter > > >> name: Greg Weber Submitter email address: gdweber@cisco.com > > >Date first > > >> submitted: February 21, 2006 > > >> Reference: NA > > >> Document: VLAN-00 > > >> Comment type: Editorial > > >> Priority: S > > >> Section: NA > > >> Rationale/Explanation of issue: > > >>=20 > > >> In the RADEXT charter, I see: > > >> "...all RADEXT WG work items MUST contain a Diameter > > >> compatibility section, outlining how interoperability > > >> with Diameter will be maintained." > > >>=20 > > >> The VLAN draft does not contain a Diameter compatibility > > >> section, but does mention (in the abstract) that these > > >> attributes can be used with Diameter. > > >>=20 > > >> Requested change: > > >> The table of attributes in section 3 shows which attributes > > >> may be in which RADIUS messages. Maybe another similar > > >> table is needed in a Diameter Compatibility section showing > > >> which Diameter applications/messages may include these > > attributes. > > >>=20 > > >> Also, I see one typo that wasn't in the previous version :) > > >> Section 1.3: 'Unsupported Attribute"' -> > > >> '"Unsupported Attribute"' (missing=20 > double quote). > > >>=20 > > >>=20 > > >>=20 > > >> -- > > >> to unsubscribe send a message to > > radiusext-request@ops.ietf.org with > > >> the word 'unsubscribe' in a single line as the message text body. > > >> archive: > > >>=20 > > > > > >-- > > >to unsubscribe send a message to > > >radiusext-request@ops.ietf.org with the word 'unsubscribe' in a=20 > > >single line as the message text body. > > >archive: > > > > >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:52:00 +0000 Message-ID: From: "Bernard Aboba" To: gdweber@cisco.com Cc: radiusext@ops.ietf.org, john.loughney@nokia.com Bcc: Subject: RE: Diameter compatibility of VLAN-00 Date: Thu, 23 Feb 2006 22:51:54 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I agree, but does 4072 say anything about future >RADIUS attributes? I don't see this in section 5, >but I'll have to look again at section 6. That should probably be in RFC 4005, since that deals with RADIUS/Diameter gateways. >Certainly hope not, or we don't have a very extensible >framework. :-) While RFC 3588 indicates that a new application ID is not required to add optional attributes to Diameter, addition of mandatory attributes do require a new application ID. This has proven to be something of a problem since there have been quite a few occasions where it has been necessary to add new attributes and allocating a new application ID ever time is not convenient. As a result, I'm not entirely clear that the VLAN attributes can be added to Diameter EAP or NASREQ without allocation of an application ID, although that hardly seems logical. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:48:45 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT Milestone revisions Date: Thu, 23 Feb 2006 22:48:36 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Neither do I. Are you saying now that key management _is_ in scope of the >radext charter? Negotiation of cryptographic algorithms is in scope. This would include keywrap algorithms. >Rather than, oh, say, discussing them on the list. So much for the "heart >of the IETF process", I >guess. Actually, a discussion was started on the list: http://ops.ietf.org/lists/radiusext/2005/msg00730.html However, a number of questions came up during that discussion that were not answered. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:44:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Diameter compatibility of VLAN-00 Date: Fri, 24 Feb 2006 01:44:34 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6013A844D@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5DCy6tFuzSUeDTLaTlS++LnZEfAAALwoA From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" Cc: , =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Friday, February 24, 2006 1:33 AM > To: Greg Weber (gdweber); john.loughney@nokia.com > Cc: radiusext@ops.ietf.org > Subject: RE: Diameter compatibility of VLAN-00 >=20 > It would seem awkward for this document to Update RFC 4005=20 > and 4072. =20 I agree, but does 4072 say anything about future=20 RADIUS attributes? I don't see this in section 5, but I'll have to look again at section 6.=20 > I'm also not entirely clear whether it would be necessary to=20 > change the ABNFs in those documents. Certainly hope not, or we don't have a very extensible framework. :-) Greg >=20 >=20 > >From: "Greg Weber (gdweber)" > >To: > >CC: , > >Subject: RE: Diameter compatibility of VLAN-00 > >Date: Fri, 24 Feb 2006 01:30:27 -0500 > > > > > >I guess I am just observing that this is an opportunity > >to set a precedent. I do not feel strongly about this > >issue for this particular draft, but in general, how do > >we comply with this part of the charter: > > "RADEXT WG work items MUST contain a Diameter > > compatibility section, outlining how > > interoperability with Diameter will be > > maintained." > >Saying, essentially, this RADIUS attribute can be used > >with so-and-so application may not be a clear specification > >given some of the complicated Diameter applications that > >may occur. I don't think a Diameter AVP table is out of > >the question- do you? > > > >Greg > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Friday, February 24, 2006 1:13 AM > > > To: Greg Weber (gdweber); bernard_aboba@hotmail.com > > > Cc: radiusext@ops.ietf.org > > > Subject: RE: Diameter compatibility of VLAN-00 > > > > > > Are you suggesting havinging Diameter AVP tables in the draft? > > > > > > John > > > > > > >> How would this work? > > > >> > > > >> Fix the typo. > > > >> > > > >> Insert a section 4 that says the following: > > > >> > > > >> 4. Diameter Considerations > > > >> > > > >> Diameter needs to define identical attributes with=20 > the same Type > > > >> values. The attributes should be available as part of > > > the NASREQ > > > >> application [RFC4005], as well as the Diameter EAP=20 > application > > > >> [RFC4072]. > > > >> > > > >> Add Informative references to [RFC4005] and [RFC4072]. > > > > > > > >It might be beneficial to set a more useful and informative > > > >precedent than was established with CUI, e.g. which messages > > > >in which applications may contain the attribute. This would > > > >seem to be analogous to the rigor of the typical RADIUS > > > >attribute table found in most RADIUS drafts. Disagree? > > > > > > > >Greg > > > > > > > >> > > > >> -------------------------------------------------------------- > > > >> --------------------------- > > > >> Description of issue: Diameter compatibility of=20 > VLAN-00 Submitter > > > >> name: Greg Weber Submitter email address: gdweber@cisco.com > > > >Date first > > > >> submitted: February 21, 2006 > > > >> Reference: NA > > > >> Document: VLAN-00 > > > >> Comment type: Editorial > > > >> Priority: S > > > >> Section: NA > > > >> Rationale/Explanation of issue: > > > >> > > > >> In the RADEXT charter, I see: > > > >> "...all RADEXT WG work items MUST contain a Diameter > > > >> compatibility section, outlining how interoperability > > > >> with Diameter will be maintained." > > > >> > > > >> The VLAN draft does not contain a Diameter compatibility > > > >> section, but does mention (in the abstract) that these > > > >> attributes can be used with Diameter. > > > >> > > > >> Requested change: > > > >> The table of attributes in section 3 shows which attributes > > > >> may be in which RADIUS messages. Maybe another similar > > > >> table is needed in a Diameter Compatibility section showing > > > >> which Diameter applications/messages may include these > > > attributes. > > > >> > > > >> Also, I see one typo that wasn't in the previous version :) > > > >> Section 1.3: 'Unsupported Attribute"' -> > > > >> '"Unsupported Attribute"' (missing=20 > double quote). > > > >> > > > >> > > > >> > > > >> -- > > > >> to unsubscribe send a message to > > > radiusext-request@ops.ietf.org with > > > >> the word 'unsubscribe' in a single line as the message=20 > text body. > > > >> archive: > > > >> > > > > > > > >-- > > > >to unsubscribe send a message to > > > >radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > > >a single line as the message text body. > > > >archive: > > > > > > > >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:33:08 +0000 Message-ID: From: "Bernard Aboba" To: gdweber@cisco.com, john.loughney@nokia.com Cc: radiusext@ops.ietf.org Bcc: Subject: RE: Diameter compatibility of VLAN-00 Date: Thu, 23 Feb 2006 22:33:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed It would seem awkward for this document to Update RFC 4005 and 4072. I'm also not entirely clear whether it would be necessary to change the ABNFs in those documents. >From: "Greg Weber (gdweber)" >To: >CC: , >Subject: RE: Diameter compatibility of VLAN-00 >Date: Fri, 24 Feb 2006 01:30:27 -0500 > > >I guess I am just observing that this is an opportunity >to set a precedent. I do not feel strongly about this >issue for this particular draft, but in general, how do >we comply with this part of the charter: > "RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how > interoperability with Diameter will be > maintained." >Saying, essentially, this RADIUS attribute can be used >with so-and-so application may not be a clear specification >given some of the complicated Diameter applications that >may occur. I don't think a Diameter AVP table is out of >the question- do you? > >Greg > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Friday, February 24, 2006 1:13 AM > > To: Greg Weber (gdweber); bernard_aboba@hotmail.com > > Cc: radiusext@ops.ietf.org > > Subject: RE: Diameter compatibility of VLAN-00 > > > > Are you suggesting havinging Diameter AVP tables in the draft? > > > > John > > > > >> How would this work? > > >> > > >> Fix the typo. > > >> > > >> Insert a section 4 that says the following: > > >> > > >> 4. Diameter Considerations > > >> > > >> Diameter needs to define identical attributes with the same Type > > >> values. The attributes should be available as part of > > the NASREQ > > >> application [RFC4005], as well as the Diameter EAP application > > >> [RFC4072]. > > >> > > >> Add Informative references to [RFC4005] and [RFC4072]. > > > > > >It might be beneficial to set a more useful and informative > > >precedent than was established with CUI, e.g. which messages > > >in which applications may contain the attribute. This would > > >seem to be analogous to the rigor of the typical RADIUS > > >attribute table found in most RADIUS drafts. Disagree? > > > > > >Greg > > > > > >> > > >> -------------------------------------------------------------- > > >> --------------------------- > > >> Description of issue: Diameter compatibility of VLAN-00 Submitter > > >> name: Greg Weber Submitter email address: gdweber@cisco.com > > >Date first > > >> submitted: February 21, 2006 > > >> Reference: NA > > >> Document: VLAN-00 > > >> Comment type: Editorial > > >> Priority: S > > >> Section: NA > > >> Rationale/Explanation of issue: > > >> > > >> In the RADEXT charter, I see: > > >> "...all RADEXT WG work items MUST contain a Diameter > > >> compatibility section, outlining how interoperability > > >> with Diameter will be maintained." > > >> > > >> The VLAN draft does not contain a Diameter compatibility > > >> section, but does mention (in the abstract) that these > > >> attributes can be used with Diameter. > > >> > > >> Requested change: > > >> The table of attributes in section 3 shows which attributes > > >> may be in which RADIUS messages. Maybe another similar > > >> table is needed in a Diameter Compatibility section showing > > >> which Diameter applications/messages may include these > > attributes. > > >> > > >> Also, I see one typo that wasn't in the previous version :) > > >> Section 1.3: 'Unsupported Attribute"' -> > > >> '"Unsupported Attribute"' (missing double quote). > > >> > > >> > > >> > > >> -- > > >> to unsubscribe send a message to > > radiusext-request@ops.ietf.org with > > >> the word 'unsubscribe' in a single line as the message text body. > > >> archive: > > >> > > > > > >-- > > >to unsubscribe send a message to > > >radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > >a single line as the message text body. > > >archive: > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:30:53 +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: Diameter compatibility of VLAN-00 Date: Fri, 24 Feb 2006 01:30:27 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6013A844B@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5BGC1PN1RGsIgSZGLzy3ExNWUVwAAaXxgAADPyBAAADJdMA== From: "Greg Weber \(gdweber\)" To: Cc: , I guess I am just observing that this is an opportunity to set a precedent. I do not feel strongly about this issue for this particular draft, but in general, how do we comply with this part of the charter: "RADEXT WG work items MUST contain a Diameter=20 compatibility section, outlining how interoperability with Diameter will be=20 maintained." Saying, essentially, this RADIUS attribute can be used with so-and-so application may not be a clear specification given some of the complicated Diameter applications that may occur. I don't think a Diameter AVP table is out of the question- do you? Greg > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Friday, February 24, 2006 1:13 AM > To: Greg Weber (gdweber); bernard_aboba@hotmail.com > Cc: radiusext@ops.ietf.org > Subject: RE: Diameter compatibility of VLAN-00 >=20 > Are you suggesting havinging Diameter AVP tables in the draft? >=20 > John >=20 > >> How would this work? > >>=20 > >> Fix the typo. > >>=20 > >> Insert a section 4 that says the following: > >>=20 > >> 4. Diameter Considerations > >>=20 > >> Diameter needs to define identical attributes with the same Type > >> values. The attributes should be available as part of=20 > the NASREQ > >> application [RFC4005], as well as the Diameter EAP application > >> [RFC4072]. > >>=20 > >> Add Informative references to [RFC4005] and [RFC4072]. > > > >It might be beneficial to set a more useful and informative=20 > >precedent than was established with CUI, e.g. which messages=20 > >in which applications may contain the attribute. This would=20 > >seem to be analogous to the rigor of the typical RADIUS=20 > >attribute table found in most RADIUS drafts. Disagree? > > > >Greg > > > >>=20 > >> -------------------------------------------------------------- > >> --------------------------- > >> Description of issue: Diameter compatibility of VLAN-00 Submitter=20 > >> name: Greg Weber Submitter email address: gdweber@cisco.com=20 > >Date first=20 > >> submitted: February 21, 2006 > >> Reference: NA > >> Document: VLAN-00 > >> Comment type: Editorial > >> Priority: S > >> Section: NA > >> Rationale/Explanation of issue: > >>=20 > >> In the RADEXT charter, I see: > >> "...all RADEXT WG work items MUST contain a Diameter > >> compatibility section, outlining how interoperability > >> with Diameter will be maintained." > >>=20 > >> The VLAN draft does not contain a Diameter compatibility > >> section, but does mention (in the abstract) that these > >> attributes can be used with Diameter. > >>=20 > >> Requested change: > >> The table of attributes in section 3 shows which attributes > >> may be in which RADIUS messages. Maybe another similar > >> table is needed in a Diameter Compatibility section showing > >> which Diameter applications/messages may include these=20 > attributes. > >>=20 > >> Also, I see one typo that wasn't in the previous version :) > >> Section 1.3: 'Unsupported Attribute"' -> > >> '"Unsupported Attribute"' (missing double quote). > >>=20 > >>=20 > >>=20 > >> -- > >> to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: > >>=20 > > > >-- > >to unsubscribe send a message to=20 > >radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > >a single line as the message text body. > >archive: > > >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 06:14:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Diameter compatibility of VLAN-00 Date: Fri, 24 Feb 2006 08:12:56 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869CCE@esebe100.NOE.Nokia.com> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5BGC1PN1RGsIgSZGLzy3ExNWUVwAAaXxgAADPyBA= From: To: , Cc: Are you suggesting havinging Diameter AVP tables in the draft? John >> How would this work? >>=20 >> Fix the typo. >>=20 >> Insert a section 4 that says the following: >>=20 >> 4. Diameter Considerations >>=20 >> Diameter needs to define identical attributes with the same Type >> values. The attributes should be available as part of the NASREQ >> application [RFC4005], as well as the Diameter EAP application >> [RFC4072]. >>=20 >> Add Informative references to [RFC4005] and [RFC4072]. > >It might be beneficial to set a more useful and informative=20 >precedent than was established with CUI, e.g. which messages=20 >in which applications may contain the attribute. This would=20 >seem to be analogous to the rigor of the typical RADIUS=20 >attribute table found in most RADIUS drafts. Disagree? > >Greg > >>=20 >> -------------------------------------------------------------- >> --------------------------- >> Description of issue: Diameter compatibility of VLAN-00 Submitter=20 >> name: Greg Weber Submitter email address: gdweber@cisco.com=20 >Date first=20 >> submitted: February 21, 2006 >> Reference: NA >> Document: VLAN-00 >> Comment type: Editorial >> Priority: S >> Section: NA >> Rationale/Explanation of issue: >>=20 >> In the RADEXT charter, I see: >> "...all RADEXT WG work items MUST contain a Diameter >> compatibility section, outlining how interoperability >> with Diameter will be maintained." >>=20 >> The VLAN draft does not contain a Diameter compatibility >> section, but does mention (in the abstract) that these >> attributes can be used with Diameter. >>=20 >> Requested change: >> The table of attributes in section 3 shows which attributes >> may be in which RADIUS messages. Maybe another similar >> table is needed in a Diameter Compatibility section showing >> which Diameter applications/messages may include these attributes. >>=20 >> Also, I see one typo that wasn't in the previous version :) >> Section 1.3: 'Unsupported Attribute"' -> >> '"Unsupported Attribute"' (missing double quote). >>=20 >>=20 >>=20 >> -- >> to unsubscribe send a message to radiusext-request@ops.ietf.org with=20 >> the word 'unsubscribe' in a single line as the message text body. >> archive: >>=20 > >-- >to unsubscribe send a message to=20 >radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 >a single line as the message text body. >archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 05:53:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Diameter compatibility of VLAN-00 Date: Fri, 24 Feb 2006 00:53:27 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6013A843F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Diameter compatibility of VLAN-00 Thread-Index: AcY5BGC1PN1RGsIgSZGLzy3ExNWUVwAAaXxg From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" Cc: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, February 24, 2006 12:37 AM > To: radiusext@ops.ietf.org > Subject: Re: Diameter compatibility of VLAN-00 >=20 > How would this work? >=20 > Fix the typo. >=20 > Insert a section 4 that says the following: >=20 > 4. Diameter Considerations >=20 > Diameter needs to define identical attributes with the same Type > values. The attributes should be available as part of the NASREQ > application [RFC4005], as well as the Diameter EAP application > [RFC4072]. >=20 > Add Informative references to [RFC4005] and [RFC4072]. It might be beneficial to set a more useful and informative precedent than was established with CUI, e.g. which messages in which applications may contain the attribute. This would seem to be analogous to the rigor of the typical RADIUS attribute table found in most RADIUS drafts. Disagree? Greg >=20 > -------------------------------------------------------------- > --------------------------- > Description of issue: Diameter compatibility of VLAN-00 > Submitter name: Greg Weber > Submitter email address: gdweber@cisco.com > Date first submitted: February 21, 2006 > Reference: NA > Document: VLAN-00 > Comment type: Editorial > Priority: S > Section: NA > Rationale/Explanation of issue: >=20 > In the RADEXT charter, I see: > "...all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability > with Diameter will be maintained." >=20 > The VLAN draft does not contain a Diameter compatibility > section, but does mention (in the abstract) that these > attributes can be used with Diameter. >=20 > Requested change: > The table of attributes in section 3 shows which attributes > may be in which RADIUS messages. Maybe another similar > table is needed in a Diameter Compatibility section showing > which Diameter applications/messages may include these attributes. >=20 > Also, I see one typo that wasn't in the previous version :) > Section 1.3: 'Unsupported Attribute"' -> > '"Unsupported Attribute"' (missing double quote). >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 05:37:14 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Diameter compatibility of VLAN-00 Date: Thu, 23 Feb 2006 21:37:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed How would this work? Fix the typo. Insert a section 4 that says the following: 4. Diameter Considerations Diameter needs to define identical attributes with the same Type values. The attributes should be available as part of the NASREQ application [RFC4005], as well as the Diameter EAP application [RFC4072]. Add Informative references to [RFC4005] and [RFC4072]. ----------------------------------------------------------------------------------------- Description of issue: Diameter compatibility of VLAN-00 Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 21, 2006 Reference: NA Document: VLAN-00 Comment type: Editorial Priority: S Section: NA Rationale/Explanation of issue: In the RADEXT charter, I see: "...all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained." The VLAN draft does not contain a Diameter compatibility section, but does mention (in the abstract) that these attributes can be used with Diameter. Requested change: The table of attributes in section 3 shows which attributes may be in which RADIUS messages. Maybe another similar table is needed in a Diameter Compatibility section showing which Diameter applications/messages may include these attributes. Also, I see one typo that wasn't in the previous version :) Section 1.3: 'Unsupported Attribute"' -> '"Unsupported Attribute"' (missing double quote). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 05:24:47 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: RADEXT WG last call on the VLAN and Priroity Attributes document Date: Thu, 23 Feb 2006 21:24:17 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Correction: the VLAN/Priority document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt ---------------------------------------------------------------------------------------------------------- This is an announcement of RADEXT WG last call on the VLAN and Priority Attributes document, prior to sending it on to the IESG for consideration as a Proposed Standard. RADEXT WG last call will last until Friday, March 17, 2006. Please send your comments to the RADEXT WG mailing list (radext@ops.ietf.org) in the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Feb 2006 00:48:29 +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: RADEXT Milestone revisions Date: Thu, 23 Feb 2006 16:47:46 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC61@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8AAFE1t8AAS6pOAACBByTAAEeg30A== From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >> For the record, I didn't say that "keywrap" is out of scope, I said >> that our draft is out of scope. >=20 > I see that as a distinction without any difference. Would you care > to elaborate? =20 Not really: the document is & has been publicly available for some time; = if it's not self-explanatory there is a serious problem. > Is your keywrap draft about more than just keywrap?=20 >=20 >> Is that a WG document? >=20 > The WLAN Attributes ID is an individual submission in pre-WG review, > as a WLAN Attributes RFC is a WG milestone.=20 I see. So all we really had to do was associate it with WLAN (kind of = like wrapping up, say, oil drilling in a wildlife refuge with a military = budget proposal) & everything would have been OK? This technology is = not specific to WLANs; the smallest possible enclosing scope might be = EAP. Limiting it to the delivery of EAP-related keying material is far = too restrictive, IMHO, but that's neither here nor there. >=20 >> Or are we to assume that anything one of the Chairs proposes is >> automatically in scope? >=20 > No, of course not. The inference I had hoped to convey is that the > chairs would likely be particularly careful about limiting the scope > of their submissions to the scope of the WG charter. =20 See above. >=20 >> The interesting questions are how this scope change occurred w/o a >> change in the charter... >=20 > The issue is a matter of interpretation, as to whether or not new > keywap mechanisms, specifically new cipher suites for keywrap, are a > new security mechanism for RADIUS. The initial interpretation was > that they were. After a fair amount of discussion of this issue on > the list, and a discussion with Russ Housley, I decided that they > were not. A new security mechanism for RADIUS would have PDU-wide > scope,=20 What does that mean? Can't change the header? No new messages? If = that is the case, then why is draft-zorn-radius-encattr-02.txt out of = scope? > while a new cipher suite for keywrap affects only individual > attributes. =20 > Additionally, the discussion in SAAG of the need to address > modularity of cipher suites in IETF protocols, arising out of the > hash attacks, played into the revised interpretation. =20 Just humor a moron a bit longer: how do you expect to "address = modularity of cipher suites" in RADIUS w/o modifying (at the very least = the processing of) the RADIUS headers? Is that not "PDU-wide scope"? = Have the rules changed? Would it be too much to ask that the rules be = clearly stated? (More stupidity: I thought that that was what the WG = charter was for.) > I believe that > this was all explained in previous postings to the list. =20 Instead of revising the interpretation of the charter, how about = revising the charter, so that the WG may be spared the need to follow = these theological discussions? =20 >=20 >> Perhaps it also captured the fact that the conversation was an offer >> of cooperation by myself and his "take it to the list" response was >> in the nature of a rather curt rebuff to that offer. >=20 > No. That nuance did not come through. Generally speaking, however, > a request to discuss technical issues, the relative merits of various > solution approaches and Internet Draft submissions on the WG mailing > list is not considered a "rebuff". I believe it to be at the very > heart of the IETF process. No?=20 Since we're talking about roles, the conversation in question was not = between a WG member & a WG chair, but between two individual = contributors, just in case that wasn't clear. =20 >=20 >> What issues would those be? The only one I recall is the one raised >> again by Hannes, which is patently out of scope. >=20 > I'll review the minutes, but I recall that other issues were raised.=20 > I raised one issue about how the KEK management would occur. Your > response was that was out of scope of the document. I never found > that a satisfying answer. =20 Neither do I. Are you saying now that key management _is_ in scope of = the radext charter? =20 >=20 > Following up on issues, and pro-actively driving their discussion on > the list, is incumbent upon document authors, in seeking to advance > their drafts. =20 >=20 >> Every indication is that our draft_is considered to be unacceptable >> by the chairs. Bernard undoubtedly had reasons to ignore work by WG >> members that had been in progress for more than a year at the in >> favor of proposing a novel scheme but I, at least, am not privy to >> them.=20 >=20 > I believe that Bernard has technical issues with your draft. That > fact that he chose to propose an alternate solution underscores that > assumption. =20 Rather than, oh, say, discussing them on the list. So much for the = "heart of the IETF process", I guess. > However, it is not fair to assume that *both* co-chairs > share the same opinion in this matter. We often agree, and typically > work out any disagreements off-list. =20 I'm not assuming anything, merely observing your actions. =20 >=20 > In the case where one co-chair is acting in the capacity of an > individual WG member, by submitting an Internet Draft for > consideration as a WG work item, that co-chair recuses himself from > acting in the capacity of chair in determining consensus on that > submission. Just as I recused myself and asked Bernard to determine > consensus on the revised MIB IDs, I would expect Bernard to recuse > himself and ask me to determine consensus on the WLAN ID. (As a > process point, we're probably in trouble on the Issues & Fixes ID, as > both co-chairs are co-authors. :-) =20 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Feb 2006 15:52:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Thu, 23 Feb 2006 10:51:50 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219092@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8AAFE1t8AAS6pOAACBByTA= From: "Nelson, David" To: "Glen Zorn \(gwz\)" Cc: Glen Zorn writes... =20 > For the record, I didn't say that "keywrap" is out of scope, I said that > our draft is out of scope. I see that as a distinction without any difference. Would you care to elaborate? Is your keywrap draft about more than just keywrap? > Is that a WG document? The WLAN Attributes ID is an individual submission in pre-WG review, as a WLAN Attributes RFC is a WG milestone. > Or are we to assume that anything one of the Chairs proposes is > automatically in scope? No, of course not. The inference I had hoped to convey is that the chairs would likely be particularly careful about limiting the scope of their submissions to the scope of the WG charter. > The interesting questions are how this scope change occurred w/o a=20 > change in the charter... The issue is a matter of interpretation, as to whether or not new keywap mechanisms, specifically new cipher suites for keywrap, are a new security mechanism for RADIUS. The initial interpretation was that they were. After a fair amount of discussion of this issue on the list, and a discussion with Russ Housley, I decided that they were not. A new security mechanism for RADIUS would have PDU-wide scope, while a new cipher suite for keywrap affects only individual attributes. Additionally, the discussion in SAAG of the need to address modularity of cipher suites in IETF protocols, arising out of the hash attacks, played into the revised interpretation. I believe that this was all explained in previous postings to the list. > Perhaps it also captured the fact that the conversation was an offer of > cooperation by myself and his "take it to the list" response was in the > nature of a rather curt rebuff to that offer. No. That nuance did not come through. Generally speaking, however, a request to discuss technical issues, the relative merits of various solution approaches and Internet Draft submissions on the WG mailing list is not considered a "rebuff". I believe it to be at the very heart of the IETF process. No? > What issues would those be? The only one I recall is the one raised again > by Hannes, which is patently out of scope. I'll review the minutes, but I recall that other issues were raised. I raised one issue about how the KEK management would occur. Your response was that was out of scope of the document. I never found that a satisfying answer. Following up on issues, and pro-actively driving their discussion on the list, is incumbent upon document authors, in seeking to advance their drafts.=20 > Every indication is that our draft_is considered to be unacceptable by > the chairs. Bernard undoubtedly had reasons to ignore work by WG members > that had been in progress for more than a year at the in favor of > proposing a novel scheme but I, at least, am not privy to them. I believe that Bernard has technical issues with your draft. That fact that he chose to propose an alternate solution underscores that assumption. However, it is not fair to assume that *both* co-chairs share the same opinion in this matter. We often agree, and typically work out any disagreements off-list. In the case where one co-chair is acting in the capacity of an individual WG member, by submitting an Internet Draft for consideration as a WG work item, that co-chair recuses himself from acting in the capacity of chair in determining consensus on that submission. Just as I recused myself and asked Bernard to determine consensus on the revised MIB IDs, I would expect Bernard to recuse himself and ask me to determine consensus on the WLAN ID. (As a process point, we're probably in trouble on the Issues & Fixes ID, as both co-chairs are co-authors. :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Feb 2006 09:13:40 +0000 Date: Thu, 23 Feb 2006 10:09:54 +0100 From: Julien Bournelle To: "Tschofenig, Hannes" Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: RADEXT Milestone revisions Message-ID: <20060223090954.GA21700@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi all, A quick comment below, On Tue, Feb 21, 2006 at 06:13:07PM +0100, Tschofenig, Hannes wrote: > Hi David, > > > Hannes Tschofenig writes... > > > > > wouldn't be something like radius domain of interopretation > > for isakmp > > > be appropriate here. > > > > I don't know. We're talking about keywrap for specific uses, e.g. > > 802.11. OTOH, there is a charter prohibition on developing a new > > security model for RADIUS. > > Here is my understanding what is going on with the keywrap: > > The Problem: > > EAP-derived keying material has to be sent confidentiality protected > from the RADIUS server to the RADIUS client. > Intermediate proxies MUST NOT see the EAP-derived keying material. I'm not sure that this is really important but I was thinking that maybe it could be sufficient to require that the keying material MUST be confidentiality protected between the home AAA server to the Visited AAA server. The reason is that even if the Keying material is protected from the home AAA server to the NAS, the NAS may send the keying material to its local AAA server. Just my 2 cents, -- Julien > > The Solution: > > KeyWrap keys* need to be available at the RADIUS server and the RADIUS > client to allow protected key transport between these two endpoints. > > *: These keys can either be static or dynamically established. Key > management is known to be difficult. > > The Open Question: > > Is an out-of-band based key management really an option? > My argument is that you also have to care about the key management. > Dealing also with the encryption of the EAP-derived keying material is > not enough. > > > > > > there is also a rule that says "adding manpower to a late project > > makes > > > it later." > > > > Yes. "The Mythical Man-Month". :-) It is a balance, to be sure. > > > > > in ecrit we scheduled an interim meeting that helped a lot > > to speedup > > > the work on the document. > > > you might also want to think about it. > > > > This is something that we could consider. Sometimes a couple > > of days of > > face-time is very helpful. The other alternative is teleconferences. > > yes, we also investigated this option. the problem is: the rules for > official phone conferences and interim meetings are the same. this gives > very little time for phone conferences and a face-to-face meeting is > more efficient. > these rules are also probably something to revisit. > > > While providing less bandwidth, teleconferences have the > > benefit of not > > requiring travel (and travel budget). > sure. > > i am willing to host a meeting in munich, if you would like to schedule > one. > > ciao > hannes > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Feb 2006 00:43:46 +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: RADEXT Milestone revisions Date: Wed, 22 Feb 2006 16:43:16 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC50@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8AAFE1t8AAS6pOA From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >> Since the WG Chairs informed us that our draft was outside the scope >> of the charter, we requested publication of > draft-zorn-radius-keywrap-09.txt >> as an Informational RFC yesterday. >=20 > For the record, this isn't an accurate portrayal of the situation. > Early on, the chairs did indicate that all of your proposed > extensions to RADIUS, including the keywrap draft, were out of scope. In that case, you wouldn't mind if I request publication of the rest of = those documents? > Prior to IETF 63, however, we stated that keywrap was indeed in > scope. I posted that opinion to the list. =20 For the record, I didn't say that "keywrap" is out of scope, I said that = our draft is out of scope. > Further evidence that the > keywrap work is in scope is obtained by its inclusion in Bernard's > WLAN attributes draft. =20 Is that a WG document? Or are we to assume that anything one of the = Chairs proposes is automatically in scope? Or maybe keywrap magically = became in scope when Bernard included it in a draft? The interesting = questions are how this scope change occurred w/o a change in the charter = and whether the ADs share your opinion on this reversal. =20 > We discussed the pros and cons of each approach, and speculated about > requirements for NIST certification at IETF 63. Going out of the > meeting, the action item was to continue discussion on the list. I > know that you discussed this draft with Bernard immediately after the > closing of the RADEXT session at IETF 64, because the streaming audio > captured your conversation. =20 Perhaps it also captured the fact that the conversation was an offer of = cooperation by myself and his "take it to the list" response was in the = nature of a rather curt rebuff to that offer. > Bernard advised you to discuss the draft > on the list, and address any issue that had been raised at IETF 63.=20 What issues would those be? The only one I recall is the one raised = again by Hannes, which is patently out of scope. =20 >=20 > While you may have other reasons to choose to pursue advancement of > your keywrap draft as an individual submission Informational RFC, the > work being out of scope for RADEXT is certainly not one of them. =20 Every indication is that _our draft_ is considered to be unacceptable by = the chairs. Bernard undoubtedly had reasons to ignore work by WG = members that had been in progress for more than a year at the in favor = of proposing a novel scheme but I, at least, am not privy to them. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 23:47:48 +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: RADEXT Milestone revisions Date: Wed, 22 Feb 2006 15:47:34 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC4E@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuAAG0BygAAH/RvQAAhO/xA= From: "Glen Zorn \(gwz\)" To: "Tschofenig, Hannes" Cc: "Nelson, David" , Tschofenig, Hannes supposedly = scribbled: > Hi Glen, >=20 >>> ok. that's a different story. i remember these two proposals. what i >>> disliked with them was that they do not provide a solution for >>> dynamic authentication and key management. >>=20 >> What do you mean by "dynamic authentication and key management"? >=20 > Let me give you two examples: >=20 > 1) IPsec >=20 > IPsec AH and IPsec ESP can be used with manually configured IPsec SAs. > You just need to create two SAs (symmetric key, algorithms, ..) at > each end point (if you want to protect the traffic in both > directions). =20 >=20 > Alternatively, you can use IKEv2 (or IKEv2) to establish these > security associations. The advantage: you use a signaling protocol > for authentication and key management. =20 >=20 > 2) TLS >=20 > The TLS Record Layer provides protection of the data traffic. In > order to be used you need to have fresh keying material suitable for > the record layer available. =20 >=20 > Since the TLS Record Layer and the TLS Handshake protocol are tightly > coupled within TLS you need to run the Handshake protocol to run the > authentication and key exchange protocol to establish the necessary > keying material. =20 >=20 > Currently it seems that you worry about the actual protection of the > keying material delivery but you don't worry about the other part of > the story. =20 On the contrary, I'm quite concerned about the stuff you're talking = about; problem is, the IETF is apparently not. >=20 >=20 > Ciao > Hannes >>=20 >>> why isn't something >>> tackling this issue? this would also solve the aspect of algorithm >>> negotiation. wouldn't be something like radius domain of >>> interopretation for isakmp be appropriate here. >>=20 >> ... >>=20 >> ~gwz >>=20 >> Why is it that most of the world's problems can't be solved by simply >> listening to John Coltrane? -- Henry Gabriel Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 20:50:32 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-vlan-00.txt Message-Id: Date: Wed, 22 Feb 2006 15:50:02 -0500 --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 VLAN and Priority Attributes Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-vlan-00.txt Pages : 13 Date : 2006-2-22 This document proposes additional attributes for dynamic VLAN assignment and prioritization, for use by IEEE 802.1X authenticators. These attributes are usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-vlan-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-vlan-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-22135500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-vlan-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-vlan-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-22135500.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 15:05:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Wed, 22 Feb 2006 10:05:14 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219087@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8AAFE1t8A== From: "Nelson, David" To: "Glen Zorn \(gwz\)" Cc: Glen Zorn writes... =20 > Since the WG Chairs informed us that our draft was outside the scope of > the charter, we requested publication of draft-zorn-radius-keywrap-09.txt > as an Informational RFC yesterday. For the record, this isn't an accurate portrayal of the situation. Early on, the chairs did indicate that all of your proposed extensions to RADIUS, including the keywrap draft, were out of scope. Prior to IETF 63, however, we stated that keywrap was indeed in scope. I posted that opinion to the list. Further evidence that the keywrap work is in scope is obtained by its inclusion in Bernard's WLAN attributes draft. We discussed the pros and cons of each approach, and speculated about requirements for NIST certification at IETF 63. Going out of the meeting, the action item was to continue discussion on the list. I know that you discussed this draft with Bernard immediately after the closing of the RADEXT session at IETF 64, because the streaming audio captured your conversation. Bernard advised you to discuss the draft on the list, and address any issue that had been raised at IETF 63. While you may have other reasons to choose to pursue advancement of your keywrap draft as an individual submission Informational RFC, the work being out of scope for RADEXT is certainly not one of them. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 14:33:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Wed, 22 Feb 2006 15:33:29 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E038A4F75@SEHAN021MB.tcad.telia.se> Thread-Topic: RADEXT Agenda for IETF65, Take Two Thread-Index: AcY3NJcopR8XVC0GSVGli360ntfF4AAgvWUA From: To: , , > >Some early versions of the ieee802 draft (when it wasn't a WG draft) > >had the Redirect-Host attribute. Would there be any chance of taking > >it back and include e.g. to the redirection attributes draft? > > > >Actually I don't remember why it got dropped out of the WG draft > >in the first place. >=20 > As I recall, the Redirect-Host attribute was somewhat=20 > different in usage=20 > from the redirection attributes, since it related to RADIUS=20 > re-direction (a=20 > la Diameter) rather than redirection of data packets. Yep. > If I remember correctly, the WG feedback was that this was=20 > something that=20 > probably would only be implemented in Diameter. I was just asking because recently e.g. in 3GPP use cases have popped up that would have use for Redirect-Host also in RADIUS (and then remembered early draft revision having the attribute). cheers, Jouni -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 10:39:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Wed, 22 Feb 2006 11:38:29 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuAAG0BygAAH/RvQ From: "Tschofenig, Hannes" To: "Glen Zorn \(gwz\)" Cc: "Nelson, David" , Hi Glen,=20 > > ok. that's a different story. i remember these two proposals. what i > > disliked with them was that they do not provide a solution for > > dynamic authentication and key management.=20 >=20 > What do you mean by "dynamic authentication and key management"? Let me give you two examples: 1) IPsec IPsec AH and IPsec ESP can be used with manually configured IPsec SAs. You just need to create two SAs (symmetric key, algorithms, ..) at each end point (if you want to protect the traffic in both directions).=20 Alternatively, you can use IKEv2 (or IKEv2) to establish these security associations. The advantage: you use a signaling protocol for authentication and key management.=20 2) TLS The TLS Record Layer provides protection of the data traffic. In order to be used you need to have fresh keying material suitable for the record layer available.=20 Since the TLS Record Layer and the TLS Handshake protocol are tightly coupled within TLS you need to run the Handshake protocol to run the authentication and key exchange protocol to establish the necessary keying material.=20 Currently it seems that you worry about the actual protection of the keying material delivery but you don't worry about the other part of the story.=20 =20 Ciao Hannes >=20 > > why isn't something > > tackling this issue? this would also solve the aspect of algorithm > > negotiation. wouldn't be something like radius domain of > > interopretation for isakmp be appropriate here. > =20 > ... >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 06:18: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: [Dime] RE: RADEXT Agenda for IETF65, Take Two Date: Wed, 22 Feb 2006 08:18:09 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869CBC@esebe100.NOE.Nokia.com> Thread-Topic: [Dime] RE: RADEXT Agenda for IETF65, Take Two Thread-Index: AcY3I+lie98gVy4QTH6mVGD0CeGvWQABUJfAABObHMA= From: To: , Cc: David, My opinion is: >> One of the items on the DIME WG agenda will probably be RFC 3588bis,=20 >> which includes the definition of the NAS-Filter-Rule syntax. >> However, the DIME WG milestones involve bringing RFC 3588 to Draft=20 >> Standard, which typically precludes addition of new features. > >Does that mean that DIME has to choose between advancing to=20 >the base Diameter protocol to DS and maintaining compatibility=20 >with RADIUS Extensions? Both are charter items for DIME. =20 >Tough choice. > >I think it would be a mistake for RADEXT to standardize a=20 >non-interoperable extension to NAS-Filter-Rule, and that our=20 >charter requirement of maintaining Diameter compatibility=20 >would potentially preclude such action, in any event. Better to do what is correct. The DiME wg would like feedback about the NAS-Filter-Rule - is the communitity happy with the current definition, or does it want to be improved or changed. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 05:29:34 +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: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 21:28:51 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC44@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuAAG0BygA== From: "Glen Zorn \(gwz\)" To: "Tschofenig, Hannes" Cc: "Nelson, David" , Tschofenig, Hannes <> supposedly scribbled: ... > ok. that's a different story. i remember these two proposals. what i > disliked with them was that they do not provide a solution for > dynamic authentication and key management.=20 What do you mean by "dynamic authentication and key management"? > why isn't something > tackling this issue? this would also solve the aspect of algorithm > negotiation. wouldn't be something like radius domain of > interopretation for isakmp be appropriate here. =20 ... ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 05:29:26 +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: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 21:28:57 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC47@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAABxLm8A= From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: > Hannes Tschofenig writes... >=20 >> i know about these activites. i wasn't quite sure how it effects the >> http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt >> document. >=20 > There are two proposals that deal with key management and > distribution via RADIUS, Bernard's draft and a draft from Glen Zorn.=20 > These were discussed in more depth at IETF 63. =20 >=20 Since the WG Chairs informed us that our draft was outside the scope of = the charter, we requested publication of = draft-zorn-radius-keywrap-09.txt as an Informational RFC yesterday. ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 00:30:48 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Cc: dime@ietf.org Bcc: Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 16:30:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Does that mean that DIME has to choose between advancing to the base >Diameter protocol to DS and maintaining compatibility with RADIUS >Extensions? Not necessarily. It may be possible to bring RFC 3588bis to Draft Standard while handling NAS-Filter-Rule extensions in another document, at Proposed Standard. At this point, I'm not clear about what will be covered in the Diameter Interop event (for example, how will interop testing of the "NAS-Filter-Rule" feature be handled?) >I think it would be a mistake for RADEXT to standardize a >non-interoperable extension to NAS-Filter-Rule, and that our charter >requirement of maintaining Diameter compatibility would potentially >preclude such action, in any event. Right. The original NAS-Filter-Rule syntax was defined in RFC 3588, and the NAS-Filter-Rule attribute is defined in RFC 4005, so that changes to the syntax cannot evolve independently without impacting Diameter. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Feb 2006 00:09:34 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: [Issue] Diameter compatibility of VLAN-00 Date: Tue, 21 Feb 2006 16:09:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Good point. For example, RFC 4372 Section 4 says: " Diameter needs to define an identical attribute with the same Type value. The CUI should be available as part of the NASREQ application [RFC4005]." Something along those lines might work here. Since the RADIUS Type values would already have been allocated, Diameter would inherit these attributes, but still needs to define their behavior. It seems like these attributes would be used primarily with the Diameter EAP application (wouldn't CUI be used there too?), and perhaps Diameter NASREQ. One question comes to mind though. Diameter requires a new application ID to be allocated when mandatory attributes are added. I'm not sure whether use of these attributes with Diameter EAP or Diameter NASREQ would require that, however. >From: "Greg Weber (gdweber)" >To: >Subject: [Issue] Diameter compatibility of VLAN-00 >Date: Tue, 21 Feb 2006 17:34:42 -0500 > > >Description of issue: Diameter compatibility of VLAN-00 >Submitter name: Greg Weber >Submitter email address: gdweber@cisco.com >Date first submitted: February 21, 2006 >Reference: NA >Document: VLAN-00 >Comment type: Editorial >Priority: S >Section: NA >Rationale/Explanation of issue: > > In the RADEXT charter, I see: > "...all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability > with Diameter will be maintained." > > The VLAN draft does not contain a Diameter compatibility > section, but does mention (in the abstract) that these > attributes can be used with Diameter. > >Requested change: > The table of attributes in section 3 shows which attributes > may be in which RADIUS messages. Maybe another similar > table is needed in a Diameter Compatibility section showing > which Diameter applications/messages may include these attributes. > > Also, I see one typo that wasn't in the previous version :) > Section 1.3: 'Unsupported Attribute"' -> > '"Unsupported Attribute"' (missing double quote). > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 23:03:24 +0000 From: "Alan DeKok" To: "Tschofenig, Hannes" Subject: Re: RADIUS-Geopriv: Request for review cc: radiusext@ops.ietf.org, geopriv@ietf.org Date: Tue, 21 Feb 2006 18:10:04 -0500 Message-Id: <20060221231004.EF77916E17@mail.nitros9.org> On Sun, Feb 12, 2006 at 10:10:45PM +0100, Tschofenig, Hannes wrote: > I have submitted an update for the RADIUS-Geopriv draft. Before it > appears on the draft announcement list please find it at: > > http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt > http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html The Operator-Name attribute does not follow existing RADIUS data types. Packing multiple pieces of data into one attribute should be discouraged. The Location-Information attribute is even more complicated. And the format of the attribute changes depending on field values. This is a recipe for disaster. At the minimum, the Location-Info field should be removed from Location-Information, and replaced with two new attributes: Location-Civic-Information and Location-Geospatial-Information. And defining the resolution & latitude data as non-byte aligned is another recipe for disaster. It would cost almost nothing to align the fields, and would significantly increase inter-operability and decrease deployment problems. If the unaligned data is taken from another standard, then the fields should be left undefined here. Rather than explicitely describing them, the attribute contents should instead be a normitive reference to another data structure. And I don't see any normitive reference to a document describing these fields, so it looks like the geospatial attribute format was created specifically for this I-D. In that case, it is even more of a requirement that the format be fixed before this document moves forward. For the Requested-Info attribute, it would be best to describe it as a bit array, rather than saying things like "a numerical value of this attribute is 8". If it's a bit array, then the fields have offsets with the array, but have no numerical value. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 22:34:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Diameter compatibility of VLAN-00 Date: Tue, 21 Feb 2006 17:34:42 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6013A7AC1@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Diameter compatibility of VLAN-00 Thread-Index: AcY3NwHfPOgLmtf5R+GfeFbLaJ/JMw== From: "Greg Weber \(gdweber\)" To: Description of issue: Diameter compatibility of VLAN-00 Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 21, 2006 Reference: NA Document: VLAN-00 Comment type: Editorial Priority: S Section: NA Rationale/Explanation of issue: In the RADEXT charter, I see: "...all RADEXT WG work items MUST contain a Diameter=20 compatibility section, outlining how interoperability=20 with Diameter will be maintained." The VLAN draft does not contain a Diameter compatibility section, but does mention (in the abstract) that these=20 attributes can be used with Diameter. Requested change: The table of attributes in section 3 shows which attributes may be in which RADIUS messages. Maybe another similar table is needed in a Diameter Compatibility section showing which Diameter applications/messages may include these attributes. Also, I see one typo that wasn't in the previous version :) Section 1.3: 'Unsupported Attribute"' ->=20 '"Unsupported Attribute"' (missing double quote). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 22:17:30 +0000 Message-ID: From: "Bernard Aboba" To: jouni.korhonen@teliasonera.com, dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 14:17:19 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Some early versions of the ieee802 draft (when it wasn't a WG draft) >had the Redirect-Host attribute. Would there be any chance of taking >it back and include e.g. to the redirection attributes draft? > >Actually I don't remember why it got dropped out of the WG draft >in the first place. As I recall, the Redirect-Host attribute was somewhat different in usage from the redirection attributes, since it related to RADIUS re-direction (a la Diameter) rather than redirection of data packets. If I remember correctly, the WG feedback was that this was something that probably would only be implemented in Diameter. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 21:46:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: New WG Milestones on-line Date: Tue, 21 Feb 2006 16:46:29 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219085@MABOSEVS2.ets.enterasys.com> Thread-Topic: New WG Milestones on-line thread-index: AcY3MEWsW91hj8n4RbeMbjSQJ51FOg== From: "Nelson, David" To: The RADEXT WG Charter page at http://www.ietf.org/html.charters/radext-charter.html has been updated with the current documents and milestone dates. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 21:45:29 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 22:45:11 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E038A4F29@SEHAN021MB.tcad.telia.se> Thread-Topic: RADEXT Agenda for IETF65, Take Two Thread-Index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7QAfujOOAANapk8AAAL20QAAZQ4MA= From: To: , Hi, > With respect to the new milestones for the 802-related documents, they > are: >=20 > April 2006 RADIUS VLAN and Priority Attributes draft submitted as a > Proposed Standard RFC (reduced in scope) >=20 > Oct 2006 RADIUS Filtering Attributes draft submitted as a Proposed > Standard RFC (split out from VLAN & Priority draft) >=20 > Dec 2006 RADIUS Redirection Attributes draft submitted as=20 > a Proposed > Standard RFC (split out from VLAN & Priority draft) Some early versions of the ieee802 draft (when it wasn't a WG draft) had the Redirect-Host attribute. Would there be any chance of taking it back and include e.g. to the redirection attributes draft? Actually I don't remember why it got dropped out of the WG draft in the first place. > The original plan for agenda item D.2.1 was to review and discuss any > WGLC issues on the VLAN & Priority draft. If there is time left over, > other 802-related issues could also be discussed in that slot. >=20 > It is my opinion that the work on Filtering Attributes will require > coordination with the DIME WG. The work on Redirection is=20 > dependent on > the Filtering work. Cheers, Jouni -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 21:03:14 +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: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 16:02:21 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219083@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcY3I+lie98gVy4QTH6mVGD0CeGvWQABUJfA From: "Nelson, David" To: Cc: Bernard Aboba writes... =20 > One of the items on the DIME WG agenda will probably be RFC 3588bis, > which includes the definition of the NAS-Filter-Rule syntax. =20 > However, the DIME WG milestones involve bringing RFC 3588 to Draft > Standard, which typically precludes addition of new features. Does that mean that DIME has to choose between advancing to the base Diameter protocol to DS and maintaining compatibility with RADIUS Extensions? Both are charter items for DIME. Tough choice. I think it would be a mistake for RADEXT to standardize a non-interoperable extension to NAS-Filter-Rule, and that our charter requirement of maintaining Diameter compatibility would potentially preclude such action, in any event. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 20:18:05 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 12:17:49 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Will there also be time available for other items? Unless there are a lot of unforseen issues posted relating to the VLAN/Priority draft, it seems unlikely that discussion of this item will take 30 minutes. The rest of the time can be devoted to other features of the IEEE 802 document. >It is my opinion that the work on Filtering Attributes will require >coordination with the DIME WG. One of the items on the DIME WG agenda will probably be RFC 3588bis, which includes the definition of the NAS-Filter-Rule syntax. However, the DIME WG milestones involve bringing RFC 3588 to Draft Standard, which typically precludes addition of new features. The NEA BOF may also be discussing filtering issues. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 18:47:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 13:46:53 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219082@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7QAfujOOAANapk8AAAL20Q From: "Nelson, David" To: Mauricio Sanchez writes... =20 > Does D.2.1 incorporate all the topics of the ieee802 draft (now split)? It *could*, *if* all those issues can be thoroughly covered in the allotted time. The theme for RADEXT at IETF 65 is "Getting to Done", which means focusing sufficient time on short-term deliverables to support the new milestone dates, which will appear on the RADEXT WG web page later today (or so the Secretariat informs me). Having negotiated and established new deliverable dates, the chairs obviously wish to avoid any future schedule slips. With respect to the new milestones for the 802-related documents, they are: April 2006 RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Oct 2006 RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Dec 2006 RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) The original plan for agenda item D.2.1 was to review and discuss any WGLC issues on the VLAN & Priority draft. If there is time left over, other 802-related issues could also be discussed in that slot. It is my opinion that the work on Filtering Attributes will require coordination with the DIME WG. The work on Redirection is dependent on the Filtering work. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 18:32:26 +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: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 10:31:54 -0800 Message-ID: Thread-Topic: RADEXT Agenda for IETF65, Take Two Thread-Index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7QAfujOOAANapk8A== From: "Sanchez, Mauricio (PNB Roseville)" To: "Nelson, David" , Cc: Does D.2.1 incorporate all the topics of the ieee802 draft (now split)? MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, February 20, 2006 9:13 AM > To: radiusext@ops.ietf.org > Cc: aboba@internaut.com > Subject: RADEXT Agenda for IETF65, Take Two >=20 >=20 > Agenda for the RADEXT WG Meeting at IETF 65 TUESDAY, March=20 > 21, 2006 0900-1130 Morning Session I >=20 > A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes) >=20 > B. Agenda Bashing >=20 > C. Milestone Revisions (5 minutes) >=20 > D. Document Status >=20 > D.1 Documents in IESG review (20 minutes): >=20 > D.1.1 RADIUS Digest Authentication: 10 minutes for=20 > discussion of IESG review. > =20 > D.1.2 RFC 3576 MIBs: 5 minutes for discussion of IESG review. > =20 > D.1.2 RFC 2618bis-2621bis: 5 minutes for discussion of IESG review. > =20 > D.2 Documents in WGLC issue resolution (30 minutes): >=20 > D.2.1 VLAN/Priority: 30 minutes for discussion of WGLC issues. > =20 > D.3 Documents in Pre-WG review (60 minutes): >=20 > D.3.1 WLAN Attributes: 10 minutes for discussion of current status. > =20 > D.3.2 Design Guidelines: 30 minutes to discuss the open=20 > issues, including any "capabilities" discussion. It this=20 > document ready for formal acceptance as a WG work item? > =20 > D.3.3 Issues & Fixes: 10 minutes discussion. It this=20 > document ready for formal acceptance as a WG work item? >=20 > D.3.4 Prepaid Extensions: 10 minutes for discussion of=20 > revised (-10) draft. >=20 > D.4 Documents requiring cross-WG review (25 minutes): >=20 > D.4.1 GEOPRIV-RADIUS: 20 minutes to discuss the status of=20 > the solution being crafted by Emile & Hannes. > =20 > D.4.2 RADIUS Prefix Delegation: 5 Minutes to discuss the=20 > review was posted to the mailing list. >=20 > E. Wrap-Up (5 minutes) >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 18:30:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: QoS and IEEE 802 Date: Tue, 21 Feb 2006 13:29:23 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219081@MABOSEVS2.ets.enterasys.com> Thread-Topic: QoS and IEEE 802 thread-index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACQ+EwAAGdyVAAAU6QoA== From: "Nelson, David" To: Cc: Hannes Tschofenig writes... > it is interesting to hear that you think that the generic RADIUS QoS will > also be done in Dime. That is my understanding of the agreement among the affected WG Chairs and Area Directors, coming out of the discussion of where to do this work, held at IETF 63. DIME will coordinate with RADEXT as may be necessary. That's not to say that the generic QoS solution for RADIUS will be at parity with that for Diameter. That remains to be discussed. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 18:17:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT WG last call on the VLAN and Priority Attributes document Date: Tue, 21 Feb 2006 19:16:40 +0100 Message-ID: Thread-Topic: RADEXT WG last call on the VLAN and Priority Attributes document thread-index: AcY3ED5iUHhOL62MS1uXukzAg6O0mgABeGtw From: "Tschofenig, Hannes" To: "Bernard Aboba" , i guess it was unnecessary for me to ask what will go into the document. = i should have just waited a few more minutes.=20 i always thought that i quickly write ietf drafts.... > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Dienstag, 21. Februar 2006 18:57 > An: radiusext@ops.ietf.org > Betreff: RADEXT WG last call on the VLAN and Priority=20 > Attributes document >=20 > This is an announcement of RADEXT WG last call on the VLAN=20 > and Priority=20 > Attributes document, prior to sending it on to the IESG for=20 > consideration as=20 > a Proposed Standard. >=20 > When it shows up on the IETF archive, the document will be=20 > available here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-pri > ority-00.txt >=20 > Until then, it is available for inspection here: > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-pr > iority-00.txt >=20 > RADEXT WG last call will last until Friday, March 17, 2006. =20 > Please send=20 > your > comments to the RADEXT WG mailing list (radext@ops.ietf.org)=20 > in the format > described on the RADEXT Issues list: > http://www.drizzle.com/~aboba/RADEXT/ >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 18:09:16 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 10:09:00 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The crypto-agility work item will focus on the negotiation of cryptographic algorithms within existing RADIUS security mechanisms. As has been discussed recently in SAAG, the recent attacks against popular hashes such as MD5 and SHA1 have raised awareness of this problem. The IETF will be undertaking work on crypto-agility within a number of protocols, including TLS. It has been suggested that the issue is serious in RADIUS because the protocol uses straight MD5 in places, rather than HMAC-MD5 or HMAC-SHA1. Given the rate of advance of hash attacks, and the lag time involved in producing standards, it is best to get work on RADIUS crypto-agility underway sooner rather than later. Note that this work item does not require solving all the security problems in RADIUS, just providing support for the negotiation of algorithms within exitsing security mechanisms. For example, issues relating to end-to-end encryption of RADIUS attributes or integration of RADIUS and Kerberos are out of scope. It is also not an explicit goal to enable RADIUS to be certified for FIPS 140-2, although support for negotiation of FIPS approved algorithms is likely to be an end result. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:57:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: QoS and IEEE 802 Date: Tue, 21 Feb 2006 18:34:29 +0100 Message-ID: Thread-Topic: QoS and IEEE 802 thread-index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACQ+EwAAGdyVA= From: "Tschofenig, Hannes" To: "Nelson, David" , Cc: Hi David,=20 it is interesting to hear that you think that the generic RADIUS QoS = will also be done in Dime.=20 Fine for me.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Nelson, David > Gesendet: Dienstag, 21. Februar 2006 18:07 > An: radiusext@ops.ietf.org > Cc: dime@ietf.org > Betreff: RE: QoS and IEEE 802 >=20 > Hannes Tschofenig writes... >=20 > > > draft-ietf-radext-vlan-priority-00.txt > > > draft-ietf-radext-filter-rules-00.txt > > > draft-ietf-radext-redirection-00.txt > >=20 > > Is the first document about QoS (is priority QoS for you)? >=20 > No. The draft includes IEEE 802.1 priority queues. It does=20 > not extend > to anything like RSVP or DiffServ. We agreed that the "full" QoS work > would take place in the DIME WG, with coordination with RADEXT as > needed. >=20 > > What are your thoughts about a common QoS approach?=20 > Different IEEE 802 > > standards specify different QoS parameters and require RADIUS > > interaction. There is work in 3GPP2 and ongoing work in Wimax. > Recently > > someone posted a draft about the DSL proposal in this area.=20 > I ask this > > question because I noticed that you seem to like a unified approach. >=20 > Yes, a unified approach would be highly desirable. As indicated, DIME > has the lead on this. >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:57:03 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG last call on the VLAN and Priority Attributes document Date: Tue, 21 Feb 2006 09:56:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is an announcement of RADEXT WG last call on the VLAN and Priority Attributes document, prior to sending it on to the IESG for consideration as a Proposed Standard. When it shows up on the IETF archive, the document will be available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-priority-00.txt Until then, it is available for inspection here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-priority-00.txt RADEXT WG last call will last until Friday, March 17, 2006. Please send your comments to the RADEXT WG mailing list (radext@ops.ietf.org) in the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:45:19 +0000 From: "Alan DeKok" To: "Tschofenig, Hannes" Subject: Re: AW: AW: RADEXT Milestone revisions cc: "Nelson, David" , radiusext@ops.ietf.org Date: Tue, 21 Feb 2006 12:52:17 -0500 Message-Id: <20060221175217.8D45416E17@mail.nitros9.org> "Tschofenig, Hannes" wrote: > This work tried to accomplish a different goal. It tried to develop a > solution for initial enrollment between the RADIUS client and the RADIUS > server if they are in the same administrative domain. BUT: The problem > we are dealing with appears if you consider cases where the RADIUS > client and the RADIUS server are in different administrative domains. I think the problems are related. The client has to somehow start a trust session with a server. It doesn't really matter if the server is in the same administrative domain or another one. The "bootstrap" problem still exists. And the bootstrap of the remote trust first depends on bootstrapping local trust. So why not use the same process for both? Within the same domain, the client kickstart proposal works. Going across domains, the "local" admin can get a key from the "remote" admin, and give it to the client. The client can then use a procedure similar to kickstart to initiate a session with the remote administrative domain. The problem then is that the client has to manage trust with a large number of remote domains, and that trust may not be tied to any one authentication session. That's a serious problem. > In the first place I wanted to better understand the problem that needs > to be solved. Exactly. If it's end-to-end encryption, Diameter would appear to be the solution. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:44:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 18:43:51 +0100 Message-ID: Thread-Topic: AW: RADEXT Milestone revisions thread-index: AcY3DG92eVrraKvGQcC4Y0z72u/wHwAB3OCA From: "Tschofenig, Hannes" To: "Bernard Aboba" , Hi Bernard,=20 I wasn't aware of this work. It would be good to know whether there is = interesting to solve the key management aspect given the limitations of = RADIUS.=20 Are you (and Glen) going to provide a solution as part of the keywrap = work?=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Dienstag, 21. Februar 2006 18:30 > An: radiusext@ops.ietf.org > Betreff: Re: AW: RADEXT Milestone revisions >=20 > >There was also the Kerberos & RADIUS draft, but I can't find=20 > a link to it,=20 > >either. >=20 > Here it is: > http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt >=20 > Note that this approach was discussed in AAA WG, and rejected=20 > in favor of=20 > CMS. However, there was subsequently not enough interest in=20 > CMS to proceed.=20 > I believe that the approach described in the document was=20 > in the process=20 > of being implemented. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:41:19 +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: QoS and IEEE 802 Date: Tue, 21 Feb 2006 09:41:01 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824046B234C@cacexc07.americas.cpqcorp.net> Thread-Topic: QoS and IEEE 802 Thread-Index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACMwawAAF3kBAAACMmIA== From: "Congdon, Paul T (ProCurve)" To: "Tschofenig, Hannes" , Yes, I was talking about 2.4. If there is to be a separate draft-ietf-radext-vlan-priority-00.txt draft. I would suggest it contain the following attributes from the following current sections: 2.1. Egress-VLANID=20 2.2. Ingress-Filters=20 2.3. Egress-VLAN-Name=20 2.4. User-Priority-Table Paul =20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Tuesday, February 21, 2006 9:34 AM > To: Congdon, Paul T (ProCurve); radiusext@ops.ietf.org > Subject: AW: QoS and IEEE 802 >=20 > Hi Paul,=20 >=20 > thanks for your quick response.=20 >=20 > > > Is the first document about QoS (is priority QoS for you)?=20 > >=20 > > The 802 priority attributes define a standard mechanism to=20 > configure=20 > > the standard 802.1 priority regeneration table. They do=20 > not deal with=20 > > bandwidth allocations, reservations, schedulers, markers, meters... > > They simply make a mapping of the incoming priority of a=20 > frame to one=20 > > of the eight 802 classes of service. This is fairly simple and in=20 > > support of an existing standard, so I would argue they do=20 > not need to=20 > > become part of a larger common QoS approach. There are no current=20 > > open issues related to this attribute. > >=20 >=20 > Do you refer to the Section 2.4. User-Priority-Table ? >=20 > I will take a look at the referenced document ([IEEE802.1D]).=20 > a few references are missing, btw. >=20 > Is the content of this attribute going to be dumped into=20 > > draft-ietf-radext-vlan-priority-00.txt > What else will go into this draft?=20 >=20 > Ciao > Hannes >=20 > > Paul > >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:34:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: QoS and IEEE 802 Date: Tue, 21 Feb 2006 18:34:28 +0100 Message-ID: Thread-Topic: QoS and IEEE 802 thread-index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACMwawAAF3kBA= From: "Tschofenig, Hannes" To: "Congdon, Paul T \(ProCurve\)" , Hi Paul,=20 thanks for your quick response.=20 > > Is the first document about QoS (is priority QoS for you)?=20 >=20 > The 802 priority attributes define a standard mechanism to=20 > configure the > standard 802.1 priority regeneration table. They do not deal with > bandwidth allocations, reservations, schedulers, markers, meters... > They simply make a mapping of the incoming priority of a=20 > frame to one of > the eight 802 classes of service. This is fairly simple and=20 > in support > of an existing standard, so I would argue they do not need to become > part of a larger common QoS approach. There are no current=20 > open issues > related to this attribute. >=20 Do you refer to the Section 2.4. User-Priority-Table ? I will take a look at the referenced document ([IEEE802.1D]). a few references are missing, btw. Is the content of this attribute going to be dumped into=20 > draft-ietf-radext-vlan-priority-00.txt What else will go into this draft?=20 Ciao Hannes > Paul >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:34:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 18:34:27 +0100 Message-ID: Thread-Topic: AW: RADEXT Milestone revisions thread-index: AcY3CeLq/EoKlUy4RN2MQeCcTon9hwABbnMg From: "Tschofenig, Hannes" To: "Alan DeKok" Cc: "Nelson, David" , Hi Alan,=20 > "Tschofenig, Hannes" wrote: > > ok. that's a different story. i remember these two proposals. what i > > disliked with them was that they do not provide a solution=20 > for dynamic > > authentication and key management. why isn't something tackling this > > issue? >=20 > Bob Moscowitz and I came up with something related a few years back: >=20 > http://www3.ietf.org/proceedings/03nov/slides/radext-4.pdf >=20 > I'll try to find a draft of the document, too. It never went > anywhere, though. This work tried to accomplish a different goal. It tried to develop a solution for initial enrollment between the RADIUS client and the RADIUS server if they are in the same administrative domain. BUT: The problem we are dealing with appears if you consider cases where the RADIUS client and the RADIUS server are in different administrative domains.=20 >=20 > There was also the Kerberos & RADIUS draft, but I can't find a link > to it, either. Interesting. I think I don't know this one.=20 In the first place I wanted to better understand the problem that needs to be solved.=20 Ciao Hannes >=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: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:29:48 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 09:29:35 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >There was also the Kerberos & RADIUS draft, but I can't find a link to it, >either. Here it is: http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt Note that this approach was discussed in AAA WG, and rejected in favor of CMS. However, there was subsequently not enough interest in CMS to proceed. I believe that the approach described in the document was in the process of being implemented. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:13:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 18:13:07 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuAAASvH0AABzR0Q From: "Tschofenig, Hannes" To: "Nelson, David" , Hi David,=20 > Hannes Tschofenig writes... >=20 > > wouldn't be something like radius domain of interopretation=20 > for isakmp > > be appropriate here. >=20 > I don't know. We're talking about keywrap for specific uses, e.g. > 802.11. OTOH, there is a charter prohibition on developing a new > security model for RADIUS. Here is my understanding what is going on with the keywrap: The Problem:=20 =20 EAP-derived keying material has to be sent confidentiality protected from the RADIUS server to the RADIUS client.=20 Intermediate proxies MUST NOT see the EAP-derived keying material. The Solution:=20 KeyWrap keys* need to be available at the RADIUS server and the RADIUS client to allow protected key transport between these two endpoints.=20 *: These keys can either be static or dynamically established. Key management is known to be difficult.=20 The Open Question:=20 Is an out-of-band based key management really an option?=20 My argument is that you also have to care about the key management. Dealing also with the encryption of the EAP-derived keying material is not enough.=20 >=20 > > there is also a rule that says "adding manpower to a late project > makes > > it later." >=20 > Yes. "The Mythical Man-Month". :-) It is a balance, to be sure. > =20 > > in ecrit we scheduled an interim meeting that helped a lot=20 > to speedup > > the work on the document. > > you might also want to think about it. >=20 > This is something that we could consider. Sometimes a couple=20 > of days of > face-time is very helpful. The other alternative is teleconferences. yes, we also investigated this option. the problem is: the rules for official phone conferences and interim meetings are the same. this gives very little time for phone conferences and a face-to-face meeting is more efficient.=20 these rules are also probably something to revisit.=20 =20 > While providing less bandwidth, teleconferences have the=20 > benefit of not > requiring travel (and travel budget). sure.=20 i am willing to host a meeting in munich, if you would like to schedule one. ciao hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:10:47 +0000 From: "Alan DeKok" To: "Tschofenig, Hannes" Subject: Re: AW: RADEXT Milestone revisions cc: "Nelson, David" , radiusext@ops.ietf.org Date: Tue, 21 Feb 2006 12:17:42 -0500 Message-Id: <20060221171742.C1D2416E17@mail.nitros9.org> "Tschofenig, Hannes" wrote: > ok. that's a different story. i remember these two proposals. what i > disliked with them was that they do not provide a solution for dynamic > authentication and key management. why isn't something tackling this > issue? Bob Moscowitz and I came up with something related a few years back: http://www3.ietf.org/proceedings/03nov/slides/radext-4.pdf I'll try to find a draft of the document, too. It never went anywhere, though. There was also the Kerberos & RADIUS draft, but I can't find a link to it, either. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:07:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: QoS and IEEE 802 Date: Tue, 21 Feb 2006 12:07:20 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021907F@MABOSEVS2.ets.enterasys.com> Thread-Topic: QoS and IEEE 802 thread-index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACQ+Ew From: "Nelson, David" To: Cc: Hannes Tschofenig writes... > > draft-ietf-radext-vlan-priority-00.txt > > draft-ietf-radext-filter-rules-00.txt > > draft-ietf-radext-redirection-00.txt >=20 > Is the first document about QoS (is priority QoS for you)? No. The draft includes IEEE 802.1 priority queues. It does not extend to anything like RSVP or DiffServ. We agreed that the "full" QoS work would take place in the DIME WG, with coordination with RADEXT as needed. > What are your thoughts about a common QoS approach? Different IEEE 802 > standards specify different QoS parameters and require RADIUS > interaction. There is work in 3GPP2 and ongoing work in Wimax. Recently > someone posted a draft about the DSL proposal in this area. I ask this > question because I noticed that you seem to like a unified approach. Yes, a unified approach would be highly desirable. As indicated, DIME has the lead on this. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:02:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: QoS and IEEE 802 Date: Tue, 21 Feb 2006 09:02:38 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824046B22E1@cacexc07.americas.cpqcorp.net> Thread-Topic: QoS and IEEE 802 Thread-Index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQgACMwaw From: "Congdon, Paul T (ProCurve)" To: "Tschofenig, Hannes" , >=20 > Is the first document about QoS (is priority QoS for you)?=20 The 802 priority attributes define a standard mechanism to configure the standard 802.1 priority regeneration table. They do not deal with bandwidth allocations, reservations, schedulers, markers, meters... They simply make a mapping of the incoming priority of a frame to one of the eight 802 classes of service. This is fairly simple and in support of an existing standard, so I would argue they do not need to become part of a larger common QoS approach. There are no current open issues related to this attribute. Paul -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 17:01:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 12:00:08 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021907E@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuAAASvH0A== From: "Nelson, David" To: Hannes Tschofenig writes... > wouldn't be something like radius domain of interopretation for isakmp > be appropriate here. I don't know. We're talking about keywrap for specific uses, e.g. 802.11. OTOH, there is a charter prohibition on developing a new security model for RADIUS. > there is also a rule that says "adding manpower to a late project makes > it later." Yes. "The Mythical Man-Month". :-) It is a balance, to be sure. =20 > in ecrit we scheduled an interim meeting that helped a lot to speedup > the work on the document. > you might also want to think about it. This is something that we could consider. Sometimes a couple of days of face-time is very helpful. The other alternative is teleconferences. While providing less bandwidth, teleconferences have the benefit of not requiring travel (and travel budget). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 16:57:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: QoS and IEEE 802 Date: Tue, 21 Feb 2006 17:56:50 +0100 Message-ID: Thread-Topic: QoS and IEEE 802 thread-index: AcY2/2PsuM4V9/cATRm8w5JVZP5DQg== From: "Tschofenig, Hannes" To: Hi Bernard,=20 Hi David,=20 > a. The work now represented by the IEEE 802 document will be=20 > split into=20 > three separate documents, one focused on VLAN/Priority, one on basic=20 > filtering, and another document on redirection. >=20 > The pre-approved WG work item draft file names are: >=20 > draft-ietf-radext-vlan-priority-00.txt > draft-ietf-radext-filter-rules-00.txt > draft-ietf-radext-redirection-00.txt Is the first document about QoS (is priority QoS for you)?=20 What are your thoughts about a common QoS approach? Different IEEE 802 standards specify different QoS parameters and require RADIUS interaction. There is work in 3GPP2 and ongoing work in Wimax. Recently someone posted a draft about the DSL proposal in this area. I ask this question because I noticed that you seem to like a unified approach.=20 Ciao Hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 16:48:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 17:48:21 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY3AHk3lnfimPDsRiC0M4uWhq4kLgAAmgaA From: "Tschofenig, Hannes" To: "Bernard Aboba" , interesting. maybe you want to add this type of background to the draft. = =20 > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Dienstag, 21. Februar 2006 17:03 > An: radiusext@ops.ietf.org > Betreff: RE: RADEXT Milestone revisions >=20 > >maybe i haven't paid enough attention to this document. i actually do > >not quite understand its background. the abstract says: > > > >This document proposes additional attributes for use by > >IEEE 802.11 authenticators. The attributes defined in this document > >are compatible with those used within Diameter EAP. > >http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt > > > >how does this relate to existing deployment? aren't we a=20 > little bit late > >specifying these attributes (although i think they are very useful). >=20 > 802.11 is developing new standards to enable applications=20 > such as Voice over=20 > WLAN (VoWLAN) (11k and 11r), automative use (WAVE), etc. New=20 > attributes may=20 > be needed for these applications, or there may be a need to=20 > specify how=20 > existing attributes are used with these applications. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 16:38:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 17:38:15 +0100 Message-ID: Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcY2xzydaASBFKw1TuSQwByOHBastAAL4nNAAAEaFzAAABhsoAAA1TfQ From: "Tschofenig, Hannes" To: "Nelson, David" , hi david,=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Nelson, David > Gesendet: Dienstag, 21. Februar 2006 16:41 > An: radiusext@ops.ietf.org > Betreff: RE: RADEXT Agenda for IETF65, Take Two >=20 > Hannes Tschofenig writes... > =20 > > do you want to tell us a little bit more about this design team? >=20 > This is an informal effort, at the suggestion of the WG Chairs, to > assist the author in moving the document along at a more=20 > rapid pace, as > it is very late (and was already late when Greg volunteered to work on > the draft). As this is still an individual submission draft,=20 > in pre-WG > review, this is not a formal RADEXT WG Design Team. The=20 > focus has been > on maturing the draft to the point of being ready for=20 > consideration as a > WG work item. >=20 > > who is part of this design team? >=20 > Greg Weber, Barney Wolff, Alan DeKok, Emile van Bergen, Dave Nelson >=20 thanks for the info on this subject.=20 =20 > > i have a collision with the ecrit working group. i have to be at the > > ecrit meeting. >=20 > Is there someone else who could present this material, or should we > attempt to resolve the schedule conflict between RADEXT ECRIT? i guess we will find someone.=20 ciao hannes >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 16:38:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 17:38:15 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SAAAFAmuA= From: "Tschofenig, Hannes" To: "Nelson, David" , hi david,=20 > Hannes Tschofenig writes... >=20 > > i know about these activites. i wasn't quite sure how it effects the > > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt > > document. >=20 > There are two proposals that deal with key management and distribution > via RADIUS, Bernard's draft and a draft from Glen Zorn. These were > discussed in more depth at IETF 63. ok. that's a different story. i remember these two proposals. what i disliked with them was that they do not provide a solution for dynamic authentication and key management. why isn't something tackling this issue? this would also solve the aspect of algorithm negotiation. wouldn't be something like radius domain of interopretation for isakmp be appropriate here.=20 > I'll let Bernard address your specific questions on his WLAN draft. >=20 > > where do you see the main benefit of the document split=20 > with regard to > > meeting the deadlines? >=20 > First, there are some elements of each of the drafts selected=20 > for spilt > that are well-baked, and close to ready for WGLC or=20 > submission to IESG. > There are other elements which have open issues, that will=20 > require some > time to work though. Separating the issues allows the well-baked > portions to progress immediately.=20 >=20 > > maybe because you want to see new document editors? >=20 > If additional parallelism of effort and a spreading of workload can be > achieved, so as to further accelerate the work progress, that=20 > would be a > side benefit. It is not clear that we will have additional=20 > editors for > each of the "child" documents. >=20 > All of this is a pretty straightforward application=20 > engineering project > management techniques. The fact of the matter is that the=20 > RADEXT WG is > way late in some of its deliverables, and the chairs have prepared a > "get well" plan, at the request of the ADs. The document=20 > splits are one > element of this plan. i know project management techniques. i hope the best for you that your document split plan works.=20 there is also a rule that says "adding manpower to a late project makes it later." in ecrit we scheduled an interim meeting that helped a lot to speedup the work on the document. =20 you might also want to think about it.=20 ciao hannes >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 16:02:56 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 08:02:45 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >maybe i haven't paid enough attention to this document. i actually do >not quite understand its background. the abstract says: > >This document proposes additional attributes for use by >IEEE 802.11 authenticators. The attributes defined in this document >are compatible with those used within Diameter EAP. >http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt > >how does this relate to existing deployment? aren't we a little bit late >specifying these attributes (although i think they are very useful). 802.11 is developing new standards to enable applications such as Voice over WLAN (VoWLAN) (11k and 11r), automative use (WAVE), etc. New attributes may be needed for these applications, or there may be a need to specify how existing attributes are used with these applications. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:56:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 10:55:35 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021907D@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AAAAU1SA From: "Nelson, David" To: Hannes Tschofenig writes... > i know about these activites. i wasn't quite sure how it effects the > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt > document. There are two proposals that deal with key management and distribution via RADIUS, Bernard's draft and a draft from Glen Zorn. These were discussed in more depth at IETF 63. I'll let Bernard address your specific questions on his WLAN draft. > where do you see the main benefit of the document split with regard to > meeting the deadlines? First, there are some elements of each of the drafts selected for spilt that are well-baked, and close to ready for WGLC or submission to IESG. There are other elements which have open issues, that will require some time to work though. Separating the issues allows the well-baked portions to progress immediately.=20 > maybe because you want to see new document editors? If additional parallelism of effort and a spreading of workload can be achieved, so as to further accelerate the work progress, that would be a side benefit. It is not clear that we will have additional editors for each of the "child" documents. All of this is a pretty straightforward application engineering project management techniques. The fact of the matter is that the RADEXT WG is way late in some of its deliverables, and the chairs have prepared a "get well" plan, at the request of the ADs. The document splits are one element of this plan. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:42:34 +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: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 10:41:27 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021907C@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcY2xzydaASBFKw1TuSQwByOHBastAAL4nNAAAEaFzAAABhsoA== From: "Nelson, David" To: Hannes Tschofenig writes... =20 > do you want to tell us a little bit more about this design team? This is an informal effort, at the suggestion of the WG Chairs, to assist the author in moving the document along at a more rapid pace, as it is very late (and was already late when Greg volunteered to work on the draft). As this is still an individual submission draft, in pre-WG review, this is not a formal RADEXT WG Design Team. The focus has been on maturing the draft to the point of being ready for consideration as a WG work item. > who is part of this design team? Greg Weber, Barney Wolff, Alan DeKok, Emile van Bergen, Dave Nelson > i have a collision with the ecrit working group. i have to be at the > ecrit meeting. Is there someone else who could present this material, or should we attempt to resolve the schedule conflict between RADEXT ECRIT? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:41:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 16:41:16 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGAAAS10AA== From: "Tschofenig, Hannes" To: "Nelson, David" , hi david,=20 thanks for the quick reply.=20 > Hannes Tschofenig writes... > =20 > > what do you mean by crypto-agility? >=20 > Generally speaking, it means the ability to treat cipher suites as > modular components of protocols such that they can be changed without > major upheaval to the protocol. For example, the recent concerns over > attacks against certain applications for hash functions used in IETF > protocols, as discussed in SAAG. More specifically, it means > changes/extensions to RADIUS to allow a system using RADIUS to obtain > FIPS-140 certification. i know about these activites. i wasn't quite sure how it effects the=20 http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt document.=20 maybe i haven't paid enough attention to this document. i actually do not quite understand its background. the abstract says: This document proposes additional attributes for use by IEEE 802.11 authenticators. The attributes defined in this document are compatible with those used within Diameter EAP. http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt how does this relate to existing deployment? aren't we a little bit late specifying these attributes (although i think they are very useful). btw, he abstract does not seem to be inline with section 4. the abstract says: " The attributes defined in this document are compatible with those used within Diameter EAP. " section 4 says: =20 " EAP-Key-Name attribute is aready defined as a RADIUS attributes within Diameter EAP=20 New attributes not previously defined in Diameter EAP include EAP- Peer-ID, EAP-Server-ID, Allowed-SSID, Allowed-Called-Station-ID, and Mobility-Domain-ID.=20 " >=20 > > > The desired goal would be to complete the split and have new > > > -00 documents submitted by the -00 deadline of Monday, February > > > 27. This is a bit aggressive. >=20 > > extremely agressive :-) >=20 > Yes, perhaps. We were waiting for formal approval from the=20 > ADs prior to > announcing the documents splits. OTOH, the initial split is, > conceptually at least, a large cut and paste operation. where do you see the main benefit of the document split with regard to meeting the deadlines?=20 maybe because you want to see new document editors?=20 ciao hannes >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:26:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 16:26:32 +0100 Message-ID: Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcY2xzydaASBFKw1TuSQwByOHBastAAL4nNAAAEaFzA= From: "Tschofenig, Hannes" To: "Nelson, David" , hi david,=20 > Greg has been working with an informal design team to revise=20 > the draft. > The plan has been to have the next version ready (well) prior to IETF > 65, in any event. do you want to tell us a little bit more about this design team?=20 who is part of this design team?=20 >=20 > > > D.4.1 GEOPRIV-RADIUS: 20 minutes to discuss the status of the > solution > > > being crafted by Emile & Hannes. > >=20 > > I won't be there in person due to lack of funds, so Hannes will have > to > > take this up I think. >=20 > We'll check with Hannes on this. i have a collision with the ecrit working group. i have to be at the ecrit meeting.=20 ciao hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:14:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 10:14:34 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219079@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAghNGA= From: "Nelson, David" To: Hannes Tschofenig writes... =20 > what do you mean by crypto-agility? Generally speaking, it means the ability to treat cipher suites as modular components of protocols such that they can be changed without major upheaval to the protocol. For example, the recent concerns over attacks against certain applications for hash functions used in IETF protocols, as discussed in SAAG. More specifically, it means changes/extensions to RADIUS to allow a system using RADIUS to obtain FIPS-140 certification. > > The desired goal would be to complete the split and have new > > -00 documents submitted by the -00 deadline of Monday, February > > 27. This is a bit aggressive. > extremely agressive :-) Yes, perhaps. We were waiting for formal approval from the ADs prior to announcing the documents splits. OTOH, the initial split is, conceptually at least, a large cut and paste operation. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:10:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 07:10:44 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824046B21D3@cacexc07.americas.cpqcorp.net> Thread-Topic: RADEXT Milestone revisions Thread-Index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQAAhphSA= From: "Congdon, Paul T (ProCurve)" To: "Tschofenig, Hannes" , "Bernard Aboba" , We are still planning on publishing draft-ietf-radext-ieee802-02.txt prior to IETF 65. It is expected to have addressed all current open items. There was no prior plan to split the document. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Tschofenig, Hannes > Sent: Tuesday, February 21, 2006 6:39 AM > To: Bernard Aboba; radiusext@ops.ietf.org > Subject: AW: RADEXT Milestone revisions >=20 > hi bernard,=20 >=20 > thanks for suggesting something.=20 >=20 > > As discussed at IETF 64, the O&M Area Directors have become=20 > > increasingly concerned about the rate of progress within the RADEXT=20 > > WG. > > Several work > > items are more than a year behind, and so there is a desire to=20 > > substantially increase the rate of progress, by completing=20 > late work=20 > > items as soon as possible. > >=20 > > To this end, the ADs have recently approved a modification to the=20 > > RADEXT WG milestones which separates several documents into=20 > multiple,=20 > > distinct work > > items: > >=20 > > a. The work now represented by the IEEE 802 document will be split=20 > > into three separate documents, one focused on VLAN/Priority, one on=20 > > basic filtering, and another document on redirection. > >=20 > > The pre-approved WG work item draft file names are: > >=20 > > draft-ietf-radext-vlan-priority-00.txt > > draft-ietf-radext-filter-rules-00.txt > > draft-ietf-radext-redirection-00.txt >=20 > how does the content of the current=20 > draft-ietf-radext-ieee802-01.txt document relate to these=20 > three documents? >=20 > i would like to know whether some of these documents above=20 > address the qos aspects (maybe the priority one)?=20 >=20 > >=20 > > b. The Design Guidelines document will be split into two=20 > work items,=20 > > one a Standard track work item relating to extending the RADIUS=20 > > attribute space, and another one a BCP on Design Guidelines. > >=20 > > The suggested individual submission (pre-WG) draft file names are: > >=20 > > draft-weber-radius-design-guidelines-nn.txt > > draft- >=20 > > c. The work on WLAN attributes will be split into two work=20 > items, one=20 > > relating purely to WLAN attributes, and another one focused on=20 > > crypto-agility. >=20 > i guess that this is your document > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt >=20 > what do you mean by crypto-agility? >=20 >=20 > >=20 > > d. The Issues & Fixes document will be split into two work=20 > items, one=20 > > relating to Issues & Fixes, and other one focussing on=20 > clarifications=20 > > (but not extensions) to RFC 3576. > >=20 > > The goal of this separation effort is to be able to complete the=20 > > following work items quickly: > >=20 > > 1. The VLAN/Priority document will be revised and brought=20 > to WG last=20 > > call immediately with a goal of getting it to the IESG in March. > >=20 > > 2. The Issues & Fixes document will be presented at IETF 65=20 > with the=20 > > goal of making it a WG work item and bringing it an initial WG last=20 > > call quickly. > >=20 > > 3. The WLAN attributes document will be presented at IETF=20 > 65 with the=20 > > goal of making it a WG work item and bringing it to an=20 > initial WG last=20 > > call quickly. > >=20 > > As part of this document re-organization, we have the=20 > opportunity to=20 > > further spread the workload by assigning distinct document=20 > editors to=20 > > each of the newly created "child documents". The chairs will be=20 > > contacting the existing "parent document" editors, as well as=20 > > potential new "child document" editors to assess interest and=20 > > availability. If you are interested in volunteering to edit=20 > a "child=20 > > document", let us know. > >=20 > > The desired goal would be to complete the split and have new -00=20 > > documents submitted by the -00 deadline of Monday, February=20 > 27. This=20 > > is a bit aggressive. > extremely agressive :-) >=20 > ciao > hannes >=20 > > Regards, > >=20 > > Bernard Aboba > > Dave Nelson > > RADEXT WG Chairs > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 15:00:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT Agenda for IETF65, Take Two Date: Tue, 21 Feb 2006 09:58:46 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219078@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcY2xzydaASBFKw1TuSQwByOHBastAAL4nNA From: "Nelson, David" To: Emile van Bergen writes... > > D.3.2 Design Guidelines: 30 minutes to discuss the open issues, > > including any "capabilities" discussion. It this document ready for > > formal acceptance as a WG work item? >=20 > Are you referring to the document as the split proposed by the chairs, > or the unsplit document? The *desire* is to have the split documents ready prior to IETF 65. The schedule for doing so is admittedly a bit tight, but I remain optimistic. > I think the split is a very good idea; I would > not consider the draft ready as as WG work item it is currently. > However, it seems that Greg hasn't been able to update it in a while. Greg has been working with an informal design team to revise the draft. The plan has been to have the next version ready (well) prior to IETF 65, in any event. > > D.4.1 GEOPRIV-RADIUS: 20 minutes to discuss the status of the solution > > being crafted by Emile & Hannes. >=20 > I won't be there in person due to lack of funds, so Hannes will have to > take this up I think. We'll check with Hannes on this. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 14:39:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Milestone revisions Date: Tue, 21 Feb 2006 15:39:14 +0100 Message-ID: Thread-Topic: RADEXT Milestone revisions thread-index: AcY2tgJqdhVaNRwZTAGrn4+ez5rCcQAIRzeQ From: "Tschofenig, Hannes" To: "Bernard Aboba" , hi bernard,=20 thanks for suggesting something.=20 > As discussed at IETF 64, the O&M Area Directors have become=20 > increasingly=20 > concerned about the rate of progress within the RADEXT WG. =20 > Several work=20 > items are more than a year behind, and so there is a desire=20 > to substantially=20 > increase the rate of progress, by completing late work > items as soon as possible. >=20 > To this end, the ADs have recently approved a modification to=20 > the RADEXT WG=20 > milestones which separates several documents into multiple,=20 > distinct work=20 > items: >=20 > a. The work now represented by the IEEE 802 document will be=20 > split into=20 > three separate documents, one focused on VLAN/Priority, one on basic=20 > filtering, and another document on redirection. >=20 > The pre-approved WG work item draft file names are: >=20 > draft-ietf-radext-vlan-priority-00.txt > draft-ietf-radext-filter-rules-00.txt > draft-ietf-radext-redirection-00.txt how does the content of the current draft-ietf-radext-ieee802-01.txt document relate to these three documents? i would like to know whether some of these documents above address the qos aspects (maybe the priority one)?=20 >=20 > b. The Design Guidelines document will be split into two work=20 > items, one a=20 > Standard track work item relating to extending the RADIUS=20 > attribute space,=20 > and another one a BCP on Design Guidelines. >=20 > The suggested individual submission (pre-WG) draft file names are: >=20 > draft-weber-radius-design-guidelines-nn.txt > draft-=20 > c. The work on WLAN attributes will be split into two work items, one=20 > relating purely to WLAN attributes, and another one focused on=20 > crypto-agility. i guess that this is your document http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-01.txt what do you mean by crypto-agility? >=20 > d. The Issues & Fixes document will be split into two work items, one=20 > relating to Issues & Fixes, and other one focussing on=20 > clarifications (but=20 > not extensions) to RFC 3576. >=20 > The goal of this separation effort is to be able to complete=20 > the following=20 > work items quickly: >=20 > 1. The VLAN/Priority document will be revised and brought to=20 > WG last call=20 > immediately with a goal of getting it to the IESG in March. >=20 > 2. The Issues & Fixes document will be presented at IETF 65=20 > with the goal of=20 > making it a WG work item and bringing it an initial WG last=20 > call quickly. >=20 > 3. The WLAN attributes document will be presented at IETF 65=20 > with the goal=20 > of making it a WG work item and bringing it to an initial WG=20 > last call=20 > quickly. >=20 > As part of this document re-organization, we have the=20 > opportunity to further=20 > spread the workload by assigning distinct document editors to=20 > each of the=20 > newly created "child documents". The chairs will be=20 > contacting the existing=20 > "parent document" editors, as well as potential new "child=20 > document" editors=20 > to assess interest and availability. If you are interested in=20 > volunteering=20 > to edit a "child document", let us know. >=20 > The desired goal would be to complete the split and have new=20 > -00 documents=20 > submitted by the -00 deadline of Monday, February 27. This is a bit=20 > aggressive. extremely agressive :-) ciao hannes > Regards, >=20 > Bernard Aboba > Dave Nelson > RADEXT WG Chairs >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 09:14:41 +0000 Date: Tue, 21 Feb 2006 10:14:18 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org, aboba@internaut.com Subject: Re: RADEXT Agenda for IETF65, Take Two Message-ID: <20060221091417.GC3629@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org, aboba@internaut.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Mon, Feb 20, 2006 at 12:13:01PM -0500, Nelson, David wrote: > D.3.2 Design Guidelines: 30 minutes to discuss the open issues, > including any "capabilities" discussion. It this document ready for > formal acceptance as a WG work item? Are you referring to the document as the split proposed by the chairs, or the unsplit document? I think the split is a very good idea; I would not consider the draft ready as as WG work item it is currently. However, it seems that Greg hasn't been able to update it in a while. > D.3.3 Issues & Fixes: 10 minutes discussion. It this document ready > for formal acceptance as a WG work item? > > D.3.4 Prepaid Extensions: 10 minutes for discussion of revised (-10) > draft. > > D.4 Documents requiring cross-WG review (25 minutes): > > D.4.1 GEOPRIV-RADIUS: 20 minutes to discuss the status of the solution > being crafted by Emile & Hannes. I won't be there in person due to lack of funds, so Hannes will have to take this up I think. > D.4.2 RADIUS Prefix Delegation: 5 Minutes to discuss the review was > posted to the mailing list. > > E. Wrap-Up (5 minutes) Kind regards, Emile van Bergen. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 09:09:26 +0000 Date: Tue, 21 Feb 2006 10:08:38 +0100 From: Emile van Bergen To: "Tschofenig, Hannes" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: RADIUS-Geopriv: Request for review Message-ID: <20060221090837.GB3629@note.evbergen.xs4all.nl> Mail-Followup-To: "Tschofenig, Hannes" , radiusext@ops.ietf.org, geopriv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.9i Hi, On Sun, Feb 12, 2006 at 10:10:45PM +0100, Tschofenig, Hannes wrote: > I have submitted an update for the RADIUS-Geopriv draft. Before it > appears on the draft announcement list please find it at: > > http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt > http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html > > I have incorporated the resolutions from the last IETF meeting > (including follow-up discussions), review comments by Yoshi Ohba and a > recent review by David Nelson. I just reviewed the new draft briefly, and I'm glad to see that my suggested approach towards challenges and capabilities was indeed useful (although that's clearer from the new design than from the credits ;-)) I have two small suggestions for now, to make things a bit more evolution-proof: * Set the value of the Challenge-Capable attribute to 1, reserve all other values and and require the value to be non-zero in order for it to be interpreted as described. This allows the NAS to be more specific later, without loss of compatibility or a change in semantics that would require a new attribute. * In Access-Challenges, I wonder whether Required-Information should be optional. The issues I see are as follows: - Challenge-Capable has potentially a wider applicability than just GEOPRIV. But in order to allow such later applications, and also to allow NASes to support challenges for purposeful withheld information as in GEOPRIV as well as the old PAP/CHAP-based OTP scheme, a mechanism is required to tell the NAS what it should do with a challenge following a request containing Challenge-Capable. - So, you can either have the NAS scan the challenge for anything that it can interpret as the reason for the challenge, and if it does not find anything, it should reissue the request as-is, including State, of course. This allows challenge reasons and required information sets to evolve without having to devise a new basic mechanism. - You can also require the server to be explicit in any challenge to a Challenge-Capable NAS, and create a Challenge-Cause attribute on the same architectural level as Challenge-Capable. Now, we can either promote Required-Information to that status, by *requiring* it in any challenge, and allow the IANA to assign other values, or reserve Required-Information for GEOPRIV alone, rename it Required-Location-Information and create a separate Challenge-Cause attribute. - But I think that one of the above two options is required for proper closure. Kind regards, Emile van Bergen. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl > > -----Ursprüngliche Nachricht----- > > Von: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > > Gesendet: Donnerstag, 26. Januar 2006 05:52 > > An: radiusext@ops.ietf.org > > Betreff: Request for review > > > > A new version of the RADIUS location draft has been posted to > > the Internet > > Drafts archive: > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius- > > lo-05.txt > > > > Please review this document and post comments to the GEOPRIV > > (and RADEXT) WG > > mailing lists. > > > > In particular, please review conformance to the framework > > posted by Emile in > > this message to the list: > > http://ops.ietf.org/lists/radiusext/2006/msg00028.html > > > > FYI, the GEOPRIV WG issue tracker for this document is located at: > > http://www.tschofenig.com:8080/radius-geopriv/ -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Feb 2006 07:11:04 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT Milestone revisions Date: Mon, 20 Feb 2006 23:10:16 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed As discussed at IETF 64, the O&M Area Directors have become increasingly concerned about the rate of progress within the RADEXT WG. Several work items are more than a year behind, and so there is a desire to substantially increase the rate of progress, by completing late work items as soon as possible. To this end, the ADs have recently approved a modification to the RADEXT WG milestones which separates several documents into multiple, distinct work items: a. The work now represented by the IEEE 802 document will be split into three separate documents, one focused on VLAN/Priority, one on basic filtering, and another document on redirection. The pre-approved WG work item draft file names are: draft-ietf-radext-vlan-priority-00.txt draft-ietf-radext-filter-rules-00.txt draft-ietf-radext-redirection-00.txt b. The Design Guidelines document will be split into two work items, one a Standard track work item relating to extending the RADIUS attribute space, and another one a BCP on Design Guidelines. The suggested individual submission (pre-WG) draft file names are: draft-weber-radius-design-guidelines-nn.txt draft- Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Feb 2006 17:14:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RADEXT Agenda for IETF65, Take Two Date: Mon, 20 Feb 2006 12:13:01 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219065@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65, Take Two thread-index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7QAfujOOA= From: "Nelson, David" To: Cc: Agenda for the RADEXT WG Meeting at IETF 65 TUESDAY, March 21, 2006 0900-1130 Morning Session I A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes) B. Agenda Bashing C. Milestone Revisions (5 minutes) D. Document Status D.1 Documents in IESG review (20 minutes): D.1.1 RADIUS Digest Authentication: 10 minutes for discussion of IESG review. =20 D.1.2 RFC 3576 MIBs: 5 minutes for discussion of IESG review. =20 D.1.2 RFC 2618bis-2621bis: 5 minutes for discussion of IESG review. =20 D.2 Documents in WGLC issue resolution (30 minutes): D.2.1 VLAN/Priority: 30 minutes for discussion of WGLC issues. =20 D.3 Documents in Pre-WG review (60 minutes): D.3.1 WLAN Attributes: 10 minutes for discussion of current status. =20 D.3.2 Design Guidelines: 30 minutes to discuss the open issues, including any "capabilities" discussion. It this document ready for formal acceptance as a WG work item? =20 D.3.3 Issues & Fixes: 10 minutes discussion. It this document ready for formal acceptance as a WG work item? D.3.4 Prepaid Extensions: 10 minutes for discussion of revised (-10) draft. D.4 Documents requiring cross-WG review (25 minutes): D.4.1 GEOPRIV-RADIUS: 20 minutes to discuss the status of the solution being crafted by Emile & Hannes. =20 D.4.2 RADIUS Prefix Delegation: 5 Minutes to discuss the review was posted to the mailing list. E. Wrap-Up (5 minutes) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Feb 2006 16:52:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RADEXT meeting slot at IETF 65 Date: Mon, 20 Feb 2006 11:50:36 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219064@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT meeting slot at IETF 65 thread-index: AcY2PcVCPHuWk4CpQJqmnqgTAX0Ytw== From: "Nelson, David" To: As of February 18, 2006, the DRAFT Agenda for IETF 65 has slotted the RADEXT WG on Tuesday AM. This is, of course, subject to change. TUESDAY, March 21, 2006 0800-1800 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I APP eai Email Address Internationalization BOF INT netlmm Network-based Localized Mobility Management WG INT trill Transparent Interconnection of Lots of Links WG OPS adslmib ADSL MIB WG OPS radext RADIUS Extensions WG RAI avt Audio/Video Transport WG RAI ecrit Emergency Context Resolution with Internet Technologies WG RTG forces Forwarding and Control Element Separation WG -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Feb 2006 22:14:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: New Editorial Issue (on draft-ietf-geopriv-radius-lo-05.txt) Date: Wed, 15 Feb 2006 17:13:01 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219040@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Editorial Issue (on draft-ietf-geopriv-radius-lo-05.txt) Thread-Index: AcYyfPvgQgVk2e3hRhimU05GPv7u3Q== From: "Nelson, David" To: Description of issue Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: February 15, 2006 Reference: Document: RADIUS-GEOPRIV-05 Comment type: 'E'ditorial Priority: '1' Should fix Section: 3.2 Rationale/Explanation of issue: Improper use of terminology. Requested change: Upon receiving the Authorize-Only message from the access network, the RADIUS server MUST respond with either an Access-Accept or an Access-Reject message. s/Authorize-Only message from the access network/Access-Request message containing the Service-Type hint attribute with a value of Authorize-Only from the NAS/ Section: 5 Rationale/Explanation of issue: Improper use of terminology. Requested change: Furthermore, the Basic-Policy-Rules and the Extended- Policy-Rules attributes are attached to the Location-Information attribute turning location information into a Location Object as defined in [12]. The term "attached" apparently has a well understood meaning in terms of GEOPRIV data objects, but its use in connection with RADIUS attributes is potentially confusing, and my lead the implementer to believe that RADIUS application-layer reassembly (i.e. concatenation of two attributes) is being performed. If this is the intended outcome (concatenation within the RADIUS client) then this wording may be OK. Otherwise, if the RADIUS client is supposed to deliver the individual attributes to GEOPRIV subsequent processing, rewording to that effect may be required. Section: 15.2 Rationale/Explanation of issue: Cut and paste error. Redundant words. Requested change: Following the policies outline in [10] new Operator-Namespaces will be assigned after Expert Review by the RADEXT working group or its designated successor. Updates can be provided based on expert approval only. A designated expert will be appointed by the O&M Area Directors. No mechanism to mark entries entries as "deprecated is envisioned. Based on expert approval it is possible to delete entries from the registry. s/Operator-Namespace/Requested-Info/ s/entries entries/entries/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Feb 2006 22:14:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: New Technical Issue (on draft-ietf-geopriv-radius-lo-05.txt) Date: Wed, 15 Feb 2006 17:13:26 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219041@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issue (on draft-ietf-geopriv-radius-lo-05.txt) Thread-Index: AcYyfQseyJOeMnm1SMe+YUEnDrT98g== From: "Nelson, David" To: Description of issue Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: February 15, 2006 Reference: Document: RADIUS-GEOPRIV-05 Comment type: 'T'echnical Priority: '0' Must fix Section: 5.2 Rationale/Explanation of issue: Overly complex attribute format. Requested change: This document describes two formats for conveying location information: civic and geospatial location information. Section 5.2.1 defines the civic location information format. Section 5.2.2 defines the geospatial location information format. Since there are two distinct attribute flied layouts, it would seem that this attribute should be represented as two distinct attributes, each with a fixed format. Variable format attributes are not encompassed within the standard RADIUS data model. Section: 9.2, 9.3 Rationale/Explanation of issue: The attributes described in these sections are quite complex. It is highly likely (based on the current draft work) that the RADIUS D3sign Guidelines BCP will very strongly discourage attributes of this complexity to be designed using the traditional RFC 2865 attribute format, but rather use the proposed Extended RADIUS Attribute format (or similar name) that will be proposed. This will mean that the GEORPIV-RADIUS RFC is out of compliance with the RADIUS Design Guidelines RFC. Requested change: The nature of requested change is somewhat dependent upon the relative schedules of the GEOPRIV-RADIUS draft and the RADIUS Design Guidelines draft. The most technically desirable solution would be to use the Extended RADIUS Attribute format, assuming that draft is sufficiently well-baked in a timely fashion to allow these attributes to be re-formatted, prior to WGLC of the GEOPRIV-RADIUS draft. I understand that this is a technical issue of major scope. Section: 9.6 Rationale/Explanation of issue: Unusual data type. Requested change: Requested-Info (48 bits): This text field contains a numerical value that encodes the requested information attributes. Each value represents a bit position. Why 48 bits? This does not correspond with any existing base RADIUS data types. Is this a bit-vector? Does it need to be a bit vector, or could it be an enumerated type, with multiple instances of the attribute allow in the appropriate messages? Section: Various. Rationale/Explanation of issue: Not all data fields within attribute formats have been designated with an existing base RADIUS data type. Requested change: Verify that all fields have a base data type designation. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Feb 2006 13:41:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63235.42F8BEAB" Subject: Diameter Interop URL Date: Wed, 15 Feb 2006 15:39:36 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869C27@esebe100.NOE.Nokia.com> Thread-Topic: Diameter Interop URL Thread-Index: AcYyNSU3dCNxYiiDS0a+iXDijJa+zQAAAfxg From: To: Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C63235.42F8BEAB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The previous link I gave out for the Diameter Interop event seemed to disappear. The correct URL is: http://www.ulticom.com/html/diameter-interop/index.asp John ------_=_NextPart_001_01C63235.42F8BEAB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

The previous link I gave = out for the Diameter Interop event seemed = to=20 disappear.  The correct URL is:

http://ww= w.ulticom.com/html/diameter-interop/index.asp

John
------_=_NextPart_001_01C63235.42F8BEAB-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Feb 2006 00:04: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: Proposed Resolution of Fixes Issue 141: State Attribute Date: Tue, 14 Feb 2006 16:04:21 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625018BEB0A@xmb-sjc-215.amer.cisco.com> Thread-Topic: Proposed Resolution of Fixes Issue 141: State Attribute Thread-Index: AcYxhUQV9WoTlMihR/iiRFxGNoB+4QAPgp9Q From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , Bernard Aboba <> supposedly scribbled: > The text of Issue 141 is enclosed below. The proposed resolution is > as=20 > follows: >=20 > Insert the following text at the end of Section 2.8: >=20 > "Since a State attribute is always initially provided by the server > in an Access-Accept, Access-Challenge, CoA-Request or > Disconnect-Request, a RADIUS client MUST NOT insert a State attribute > that it has not previously received from the server."=20 OK w/me. =20 >=20 > = -------------------------------------------------------------------------= -------------------------------------- > Issue 141: State Attribute > Submitter name: David Mitton > Submitter email address: david@mitton.com Date first submitted: > November 11, 2005=20 > Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html > Document: Fixes-01 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: >=20 > wrt State attribute; there was a case in the past where a vendor > decided that their client would sent a State attribute with Null data > to start a certain proprietary sequence. Non-Vendor's clients would > fail on this server due to this expectation. =20 >=20 > You should make it clear that a new Access-Request should not contain > a State attribute. State should always come from a server, and prior > context. =20 > Not manufactured by the client. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Feb 2006 16:39:44 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution of Fixes Issue 141: State Attribute Date: Tue, 14 Feb 2006 08:38:36 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of Issue 141 is enclosed below. The proposed resolution is as follows: Insert the following text at the end of Section 2.8: "Since a State attribute is always initially provided by the server in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request, a RADIUS client MUST NOT insert a State attribute that it has not previously received from the server." --------------------------------------------------------------------------------------------------------------- Issue 141: State Attribute Submitter name: David Mitton Submitter email address: david@mitton.com Date first submitted: November 11, 2005 Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html Document: Fixes-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: wrt State attribute; there was a case in the past where a vendor decided that their client would sent a State attribute with Null data to start a certain proprietary sequence. Non-Vendor's clients would fail on this server due to this expectation. You should make it clear that a new Access-Request should not contain a State attribute. State should always come from a server, and prior context. Not manufactured by the client. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Feb 2006 10:25:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Tue, 14 Feb 2006 15:53:54 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F8CDDCA1@xmb-blr-416.apac.cisco.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcYs3htqnVXg8ntFSbCV9v4LkLgAeAEcETVg From: "Nagi Reddy Jonnala \(njonnala\)" To: , Cc: "Bert Wijnen" Juergen, Your comments may be correct. We authors have discussed about your comments and realized that the comments are not directly related to these MIBs but in general whether the scalars should be grouped together or not. The recommended way can best be addressed in the IETF MIB guidelines. Since there seem to be plenty of MIBs that don't follow your commented approach, no recommended way in the IETF MIB guidelines and because it is a stylistic change, we leave the MIBs as they are. Thanks Nagi. =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, February 09, 2006 12:03 AM To: radiusext@ops.ietf.org Cc: Bert Wijnen Subject: radius dynauth client/server mibs structure Hi, I took a quick look at the radius dynauth client/server mibs today: draft-ietf-radext-dynauth-client-mib-03.txt draft-ietf-radext-dynauth-server-mib-03.txt While looking at the OID tree, I came up with the following stylistic change. Currently, the OID tree of the two MIBs basically looks like this (details of the tables and conformance nodes deleted): --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServer(1) | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(4) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClient(1) | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(3) | +--radiusDynAuthClientMIBConformance(2) I was wondering what the value of having the radiusDynAuthServer and radiusDynAuthClient nodes is. I do understand if people like to group related scalars together (so additions are numbered using consecutive identifiers), but then the OID structure should more look like the following: --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServerScalars(1) | | | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(2) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClientScalars(1) | | | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(2) | +--radiusDynAuthClientMIBConformance(2) The benefit of this change is that you can add scalars later while keep all the scalars rooted together and consecutively numbered while in the current scheme you end up to have tables intermixed with scalars over time. Please note that there is nothing technically wrong with the MIBs as they are right now. My suggestion is purely stylistic and basically just increases readability in case updates are done in the future. I am aware that these MIB modules have passed WG last call and MIB review and are in the hands of the ADs and as such I do not ask to make a change just for stylistic reasons. I just wanted to bring this to your attention and I like to leave it to the editors/chairs to decide whether you want to make the relatively simple changes at this point in time or prefer to go ahead with what you have. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 12 Feb 2006 21:11:54 +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: RADIUS-Geopriv: Request for review Date: Sun, 12 Feb 2006 22:10:45 +0100 Message-ID: Thread-Topic: RADIUS-Geopriv: Request for review Thread-Index: AcYiNGX+l8vao0q3Q/KvVA5Y1OWamgN3mbhg From: "Tschofenig, Hannes" To: , Hi all,=20 I have submitted an update for the RADIUS-Geopriv draft. Before it = appears on the draft announcement list please find it at: http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html I have incorporated the resolutions from the last IETF meeting = (including follow-up discussions), review comments by Yoshi Ohba and a = recent review by David Nelson. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba > Gesendet: Donnerstag, 26. Januar 2006 05:52 > An: radiusext@ops.ietf.org > Betreff: Request for review >=20 > A new version of the RADIUS location draft has been posted to=20 > the Internet=20 > Drafts archive: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius- > lo-05.txt >=20 > Please review this document and post comments to the GEOPRIV=20 > (and RADEXT) WG=20 > mailing lists. >=20 > In particular, please review conformance to the framework=20 > posted by Emile in=20 > this message to the list: > http://ops.ietf.org/lists/radiusext/2006/msg00028.html >=20 > FYI, the GEOPRIV WG issue tracker for this document is located at: > http://www.tschofenig.com:8080/radius-geopriv/ >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 12 Feb 2006 21:11:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RADEXT Agenda for IETF65 Date: Sun, 12 Feb 2006 22:10:48 +0100 Message-ID: Thread-Topic: RADEXT Agenda for IETF65 Thread-Index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7QAHAwEMA= From: "Tschofenig, Hannes" To: "Nelson, David" , hi david,=20 hi all,=20 i would like to discuss the following document: -------------- Prepaid extensions to RADIUS draft-lior-radius-prepaid-extensions-09.txt -------------- a draft update will be available soon based on the feedback we received. this document is not a new item and is also on the charter.=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Nelson, David > Gesendet: Freitag, 10. Februar 2006 15:58 > An: radiusext@ops.ietf.org > Betreff: RADEXT Agenda for IETF65 >=20 > Colleagues, >=20 > The chairs have requested one 2.5 hour meeting slot for RADEXT at > IETF65. We'll let you know the assigned slot, once it's been=20 > scheduled. >=20 > I would normally be sending a message, at about this time, to the WG > soliciting agenda items, submissions and presentations. The theme for > RADEXT at IETF65 will be "Getting to Done", and by that I=20 > mean focusing > our time and energies on completing the outstanding (and late) > milestones. For that reason, the chairs have proposed a rough agenda, > focused around work items that are nearing completion. We will be > soliciting submissions and presentations, and allocating discussion > slots, as indicated, with the idea of moving our committed work along. >=20 > Once we have "cleared the decks" of many of these outstanding=20 > items, the > WG will be in a position to consider some of the important submissions > and topics that are not currently milestones, and could entertain a > re-charter discussion to consider these items. For IETF65,=20 > we will not > be entertaining discussion of new work items. Please help us=20 > make some > needed progress. >=20 > First draft agenda: >=20 > RADIUS Digest Authentication: 10 minutes for discussion of=20 > IESG review. >=20 > RFC 3576 MIBs: 10 minutes for discussion of IESG review.=20 >=20 > RFC 2618bis-2621bis: 10 minutes for discussion of IESG review. >=20 > VLAN/Priority: 30 minutes for discussion of WGLC issues. >=20 > WLAN Attributes: 10 minutes for discussion of current status. >=20 > GEOPRIV-RADIUS: 20 minutes to discuss the status of the solution=20 > being crafted by Emile & Hannes.=20 >=20 > Design Guidelines: 30 minutes to discuss the open issues,=20 > including any > "capabilities" discussion. It this document ready for formal=20 > acceptance > as a WG work item? >=20 > Issues & Fixes: 10 minutes discussion. It this document ready for > formal acceptance as a WG work item? >=20 > RADIUS Prefix Delegation: 5 Minutes to discuss the review was=20 > posted to > the mailing list.=20 >=20 > Comments on this first draft proposed agenda are solicited, and > encouraged, keeping within the theme of "Getting to Done". >=20 > Thanks! >=20 > Dave Nelson >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Feb 2006 15:25:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA Date: Fri, 10 Feb 2006 10:21:12 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B85F@MABOSEVS2.ets.enterasys.com> Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA Thread-Index: AcYuA3zH7bZT184oQx6AO6FXxeJaagAUgdQQ From: "Nelson, David" To: As a reminder... There are two (2) Internet-Draft cutoff dates for the 65th=20 IETF Meeting in Dallas, TX, USA: February 27th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 February 27th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Monday,=20 February 20th at 9:00 AM ET. March 6th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, March 6th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, March 20th at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 65th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_65.html. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Feb 2006 14:58:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RADEXT Agenda for IETF65 Date: Fri, 10 Feb 2006 09:57:48 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B85D@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT Agenda for IETF65 Thread-Index: AcYdHiGLhWYWxr9ERrO/BinX9gX37gRMVU7Q From: "Nelson, David" To: Colleagues, The chairs have requested one 2.5 hour meeting slot for RADEXT at IETF65. We'll let you know the assigned slot, once it's been scheduled. I would normally be sending a message, at about this time, to the WG soliciting agenda items, submissions and presentations. The theme for RADEXT at IETF65 will be "Getting to Done", and by that I mean focusing our time and energies on completing the outstanding (and late) milestones. For that reason, the chairs have proposed a rough agenda, focused around work items that are nearing completion. We will be soliciting submissions and presentations, and allocating discussion slots, as indicated, with the idea of moving our committed work along. Once we have "cleared the decks" of many of these outstanding items, the WG will be in a position to consider some of the important submissions and topics that are not currently milestones, and could entertain a re-charter discussion to consider these items. For IETF65, we will not be entertaining discussion of new work items. Please help us make some needed progress. First draft agenda: RADIUS Digest Authentication: 10 minutes for discussion of IESG review. RFC 3576 MIBs: 10 minutes for discussion of IESG review.=20 RFC 2618bis-2621bis: 10 minutes for discussion of IESG review. VLAN/Priority: 30 minutes for discussion of WGLC issues. WLAN Attributes: 10 minutes for discussion of current status. GEOPRIV-RADIUS: 20 minutes to discuss the status of the solution=20 being crafted by Emile & Hannes.=20 Design Guidelines: 30 minutes to discuss the open issues, including any "capabilities" discussion. It this document ready for formal acceptance as a WG work item? Issues & Fixes: 10 minutes discussion. It this document ready for formal acceptance as a WG work item? RADIUS Prefix Delegation: 5 Minutes to discuss the review was posted to the mailing list.=20 Comments on this first draft proposed agenda are solicited, and encouraged, keeping within the theme of "Getting to Done". Thanks! Dave Nelson -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Feb 2006 21:36:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Allowed Usage Date: Thu, 9 Feb 2006 16:39:09 -0500 Message-ID: Thread-Topic: Issue: Allowed Usage Thread-Index: AcYlD68LAAvs63FIQQqH4TORomkVvwCgQW0gAAAqWSABi+gKoA== From: "Avi Lior" To: "Greg Weber \(gdweber\)" , "Bernard Aboba" , There is no reason to include even a flush in a disconnect request. If you are successful in disconnect, then the flush will happen anyway. If you are not successful in disconnecting then even if you included flush nothing will happen. Avi=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber=20 > (gdweber) > Sent: Wednesday, February 01, 2006 7:42 PM > To: Bernard Aboba; radiusext@ops.ietf.org > Subject: RE: Issue: Allowed Usage >=20 >=20 > Also, the textual description of Ingress-Filters says that it=20 > MUST NOT be included in Disconnect-Request messages (and some=20 > other types of messages). This is not reflected in the Table=20 > of Attributes in Section 4 which may be confusing. Would any=20 > of these attributes be used in Disconnect-Request messages? =20 > I'd guess not, except maybe a flush rule... :) >=20 > Greg >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > > Sent: Sunday, January 29, 2006 3:07 PM > > To: radiusext@ops.ietf.org > > Subject: Issue: Allowed Usage > >=20 > > Issue : Allowed Usage > > Submitter names: Bernard Aboba > > Submitter email address: aboba@internaut.com Date first submitted:=20 > > January 29, 2006 > > Reference: > > Document: IEEE 802-01 > > Comment type: 'T'echnical | > > Priority: S > > Section: Various > > Rationale/Explanation of issue: > >=20 > > In Section 4, the Table of Attributes states the following: > >=20 > > The following table provides a guide to which=20 > attributes may be > > found in which kinds of packets, and in what quantity. > >=20 > > Access- Access- Access- Access- CoA- > > Request Accept Reject Challenge Req # Attribute > > 0 0+ 0 0 0+ TBD Egress-VLANID > > 0 0-1 0 0 0-1 TBD Ingress-Filters > > 0 0-1 0 0 0-1 TBD User-Priority-Table > >=20 > > The Egress-VLAN-Name attribute is not included in this=20 > table, nor is=20 > > it included in the IANA considerations section. > >=20 > > Section 2.1: > >=20 > > Multiple Egress-VLANID attributes can be delivered in an > > authentication response; each attribute adds the specified=20 > > VLAN > > to the list of allowed egress VLANs for the port. > >=20 > > This would appear to indicate that the Egress-VLAN-Name=20 > attribute is=20 > > allowed in Access-Challenge, Access-Reject and=20 > Access-Accept packets. > > Yet, the attribute table in Section 4 does not seem to permit=20 > > inclusion in Reject or Challenge packets. > >=20 > > Section 2.3: > >=20 > > Multiple Egress-VLAN-Name attributes can be delivered in an > > authentication response; each attribute adds the=20 > named VLAN=20 > > to > > the list of allowed egress VLANs for the port. > >=20 > > This would appear to indicate that the Egress-VLAN-Name=20 > attribute is=20 > > allowed in Access-Challenge, Access-Reject and=20 > Access-Accept packets. > > There is no entry in the Attribute Table to confirm this. > >=20 > > Section 2.4: > >=20 > > There is no material on permitted usage of the User-Priority-Table=20 > > attribute. > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Feb 2006 21:18:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Issue] Authorize Only usage in HTTP redirect Date: Thu, 9 Feb 2006 16:20:40 -0500 Message-ID: Thread-Topic: [Issue] Authorize Only usage in HTTP redirect Thread-Index: AcYoS5Zp6eRWrogeQAu3eff/EkfSWgFcslmw From: "Avi Lior" To: "Greg Weber \(gdweber\)" , Greg is right. The spec is silent about whether or not the Access-Accept contains a Service-Type or even what value it will have.=20 I don't have a problem with the proposed text.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber=20 > (gdweber) > Sent: Thursday, February 02, 2006 5:54 PM > To: radiusext@ops.ietf.org > Subject: [Issue] Authorize Only usage in HTTP redirect >=20 > Description of issue: Authorize Only usage in HTTP redirect=20 > Submitter name: Greg Weber Submitter email address:=20 > gdweber@cisco.com Date first submitted: February 2, 2006 > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html > Document: IEEE802-01 > Comment type: Technical > Priority: S > Section: A.2.2 > Rationale/Explanation of issue: >=20 > Section A.2.2 Mid-session HTTP Redirection reads: >=20 > If HTTP redirection is required to be applied to a service that=20 > has already been started then the RADIUS server can push the=20 > redirection rules, and optionally the filter rules, to the NAS=20 > within a NAS-Filter-Rule(TBD) attribute using a CoA=20 > message. The=20 > NAS will then commence to apply the redirection rules=20 > and/or the=20 > filter rules. =20 > =20 > Alternatively, the RADIUS server can request that the NAS re- > authorize the session using the procedures defined in=20 > [RFC3576].=20 > The RADIUS server responds with an Access-Accept message (with=20 > Service-Type(6) set to "Authorize Only" that will contain the=20 > redirection and optionally filtering rules within a NAS-Filter- > Rule(TBD) attribute.=20 >=20 > I don't think "Authorize Only" is a valid Service-Type value=20 > in Access-Accept messages. The server should be indicating=20 > the assigned Service in the Access-Accept. Take a look at=20 > the last paragraph of RFC 3576's Section 1.1. I think that=20 > describes the process your referring to here. >=20 > Requested change: >=20 > I suggest replacing the above text with something like: >=20 > If HTTP redirection is required to be applied to a service=20 > that has already been started, then the RADIUS server may use=20 > either of the procedures defined in [RFC3576]: >=20 > - The server may send the NAS a CoA-Request message including > a NAS-Filter-Rule which contains redirection rules and > optionally filter rules. The NAS will then apply the new > rules to the existing services. > - The server may send the NAS a CoA-Request message including > a Service-Type attribute with the value of "Authorize Only". > This will trigger the NAS to reauthorize the existing service > by sending the server an Access-Request message containing a > Service-Type attribute with the value of "Authorize Only". > The server may then send the NAS new redirection and optionally > filter rules within a NAS-Filter-Rule as part of an Access- > Accept message. >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Feb 2006 19:46:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue Date: Wed, 8 Feb 2006 11:45:47 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250182C120@xmb-sjc-215.amer.cisco.com> Thread-Topic: Issue Thread-Index: AcYs6EG65Jnbp0hnTaSxcbyAmwGsYA== From: "Glen Zorn \(gwz\)" To: Cc: "Glen Zorn \(gwz\)" Description of issue: Typo, (presumably) incorrect phrasing Submitter name: Glen Zorn Submitter email address: gwz@cisco.com Date first submitted: 08 Feb 06 Document: ieee-802 Comment type: E Priority: 1 Section: 6 Rationale/Explanation of issue: Paragraph 1 says: "Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-nabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]." Are there threats present in RADIUS applications? Shouldn't we eradicate these things instead of referencing them? ;-)=20 Requested change:=20 Change "IEEE 802.1X-nabled" to "IEEE 802.1X-enabled" Re-word the paragraph to have the correct meaning; suggest "Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to the same threats as other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]."=20 ~gwz -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Feb 2006 18:33:01 +0000 Date: Wed, 8 Feb 2006 19:32:31 +0100 From: Juergen Schoenwaelder To: radiusext@ops.ietf.org Cc: Bert Wijnen Subject: radius dynauth client/server mibs structure Message-ID: <20060208183231.GA8312@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: radiusext@ops.ietf.org, Bert Wijnen Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i Hi, I took a quick look at the radius dynauth client/server mibs today: draft-ietf-radext-dynauth-client-mib-03.txt draft-ietf-radext-dynauth-server-mib-03.txt While looking at the OID tree, I came up with the following stylistic change. Currently, the OID tree of the two MIBs basically looks like this (details of the tables and conformance nodes deleted): --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServer(1) | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(4) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClient(1) | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(3) | +--radiusDynAuthClientMIBConformance(2) I was wondering what the value of having the radiusDynAuthServer and radiusDynAuthClient nodes is. I do understand if people like to group related scalars together (so additions are numbered using consecutive identifiers), but then the OID structure should more look like the following: --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) | +--radiusDynAuthServerMIBObjects(1) | | | +--radiusDynAuthServerScalars(1) | | | | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) | | +--radiusDynAuthServerIdentifier(3) | | | +--radiusDynAuthClientTable(2) | +--radiusDynAuthServerMIBConformance(2) --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) | +--radiusDynAuthClientMIBObjects(1) | | | +--radiusDynAuthClientScalars(1) | | | | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) | | | +--radiusDynAuthServerTable(2) | +--radiusDynAuthClientMIBConformance(2) The benefit of this change is that you can add scalars later while keep all the scalars rooted together and consecutively numbered while in the current scheme you end up to have tables intermixed with scalars over time. Please note that there is nothing technically wrong with the MIBs as they are right now. My suggestion is purely stylistic and basically just increases readability in case updates are done in the future. I am aware that these MIB modules have passed WG last call and MIB review and are in the hands of the ADs and as such I do not ask to make a change just for stylistic reasons. I just wanted to bring this to your attention and I like to leave it to the editors/chairs to decide whether you want to make the relatively simple changes at this point in time or prefer to go ahead with what you have. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Feb 2006 13:57:31 +0000 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB66C@S4DE9JSAAIG.ost.t-com.de> From: "Beck01, Wolfgang" To: hartmans-ietf@mit.edu Cc: radiusext@ops.ietf.org, Kurt@OpenLDAP.org, secdir@MIT.EDU, david.kessens@nokia.com, David.Schwartz@Kayote.com, Baruch.Sterman@Kayote.com, dscreat@dscreat.com, dwilli@cisco.com Subject: AW: [secdir] draft-ietf-radext-digest-auth06.txt, proposal Date: Wed, 8 Feb 2006 14:56:52 +0100 MIME-Version: 1.0 Content-Type: text/plain I think we have two options 1. remove the mode where the RADIUS client generates nonces 2. embed a time-stamp into the nonce Option 1. would be easy but it was rejected by the WG at the 64th IETF. Here's a proposal for option 1. I am fully aware that I am doing amateur cryptography. 3.2.5. Obtaining Nonces The RADIUS client has three ways to obtain nonces: it generates them locally, it has received one in a Digest-Nextnonce attribute of a previously received Access-Accept packet, or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. It adds a Message-Authenticator (see [RFC3579]) attribute to the Access-Request packet. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. The RADIUS client constructs a (Proxy-)Authenticate header using the received Digest-Nonce and Digest-Realm attributes to fill the nonce and realm directives. The RADIUS server can send Digest-Qop, Digest- Algorithm, Digest-Domain and Digest-Opaque attributes in the Access- Challenge carrying the nonce. If these attributes are present, the client MUST use them. If the RADIUS client generates nonces, the nonce must contain a time- stamp. The nonce is constructed as follows: nonce = base64(concat(ts, hn(concat(random-pad, ts), secret))) where 'base64(x)' encodes string x in base64 (see [RFC3548]) 'concat(a, b)' appends string b to string a 'ts' is an unsigned integer of 4 bytes in network byte order with the number of seconds since January 1, 1970 00:00 UTC. 'secret' is the shared secret between RADIUS client and server 'hn(secret, message)' produces a hash of 'message' using the pass phrase 'secret'. 'hn' is the HMAC MD5 function described in [RFC2104]. 'random-pad' is a string of 56 random characters that is uniquely generated for each nonce. The time-stamp enables the RADIUS server to reject replayed nonces. The clock difference between RADIUS client and RADIUS server MUST NOT exceed 10 s. [...] 3.3.2. Determining the Age of the Nonce If the RADIUS server generates nonces, it will determine the age of a nonce by using an embedded time-stamp, or by looking it up in a local table. The RADIUS server MUST check the integrity of the nonce, if it embeds the time-stamp in the nonce. Section 3.3.3 describes how the server handles old nonces. If the RADIUS client generates nonces, the RADIUS server checks the the embedded time-stamp. The RADIUS server responds to an Access- Request with a nonce that is too old or too young with an Access- Reject packet. RADIUS servers logging rejected requests should include a hint to the operator that a too big clock difference caused the rejection. A nonce is considered too young if the received time-stamp is greater than the current time plus 11 s, allowing 1 s of packet delay. A nonce is considered too old if the received time-stamp is less than the current time minus 9 s, allowing 1 s of packet delay. Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Feb 2006 19:09: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: digest-auth, nonce replay issue Date: Tue, 7 Feb 2006 11:08:15 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250179F974@xmb-sjc-215.amer.cisco.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYrHf8lpGfcPSyBTKWn0qBFR8cmbAAD39Ig From: "Glen Zorn \(gwz\)" To: "Beck01, Wolfgang" Cc: Beck01, Wolfgang supposedly scribbled: > Glen wrote >> However, your the draft doesn't say >>=20 >> o If the Digest-Qop attribute's value is 'auth-int' and at least >> one of the following conditions is true, the RADIUS server >> SHOULD put a Digest-HA1 attribute into the Access-Accept >> packet:=20 >> * The Digest-Algorithm attribute's value is 'MD5-sess' or >> 'AKAv1- MD5-sess'.=20 >> * The password was not posted on a mailing list (see Section >> 9). In all other cases, Digest-Response-Auth or Digest-HA1 MUST >> NOT be sent. Since the second condition is, AFAIK, unverifiable, >> it would make=20 >> sense to simply remove it as extraneous. However, my guess is that >> it's there for a reason; therefore, I would advise making it depend >> upon a form of security that the RADIUS client/server can actually >> check. >=20 > If I remove the IPSec-condition, I am sure somebody will complain > about it.=20 If they complain, let them tell how to verify whether or not the = condition has been met; if they cannot, their complaint has no validity. > In an earlier version, I used the phrase 'protected' > instead of IPSec which would have included future mechanisms, like > RADIUS attribute encryption. =20 > On request of the WG, this was replaced with IPSec. Of course: this being the RADIUS Extensions WG, the last thing we would = want is actual extensibility... >=20 > The above section of the draft is already hard to read, so I will add > something to the referenced Security Considerations, like:=20 >=20 > 'Some parameter combinations require the protection of the RADIUS > packet against eavesdropping and tampering. Implementations SHOULD > try to determine automatically whether RADIUS packets will be sent > and received over IPSec. If this is not possible, the implementation > checks a configuration parameter telling it whether RADIUS traffic > will be protected with IPSec. It must be explicitly set by the > operator. The default value of this parameter tells the > implementation that the RADIUS packet will not be protected.' Unfortunately, this still says very little about the actual state of = IPSec at the time the packets are transmitted or received, which is the = condition you are checking. If you make this change, you should also = note this in the Security Considerations section, & change the = condition(s) from "The packets between RADIUS client and RADIUS server = are protected with IPsec (see Section 9)." or similar to "IPSec is = configured to protect traffic between the RADIUS client and RADIUS = server (see Section 9)." or similar.=20 =20 >=20 > Wolfgang Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Feb 2006 13:05:14 +0000 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB669@S4DE9JSAAIG.ost.t-com.de> From: "Beck01, Wolfgang" To: gwz@cisco.com Cc: radiusext@ops.ietf.org Subject: AW: digest-auth, nonce replay issue Date: Mon, 6 Feb 2006 14:04:30 +0100 MIME-Version: 1.0 Content-Type: text/plain Glen wrote > However, your the draft doesn't say > > o If the Digest-Qop attribute's value is 'auth-int' and at least one > of the following conditions is true, the RADIUS server SHOULD put > a Digest-HA1 attribute into the Access-Accept packet: > * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- > MD5-sess'. > * The password was not posted on a mailing list (see Section 9). > In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be > sent. > Since the second condition is, AFAIK, unverifiable, it would > make sense to simply remove it as extraneous. However, my > guess is that it's there for a reason; therefore, I would > advise making it depend upon a form of security that the > RADIUS client/server can actually check. If I remove the IPSec-condition, I am sure somebody will complain about it. In an earlier version, I used the phrase 'protected' instead of IPSec which would have included future mechanisms, like RADIUS attribute encryption. On request of the WG, this was replaced with IPSec. The above section of the draft is already hard to read, so I will add something to the referenced Security Considerations, like: 'Some parameter combinations require the protection of the RADIUS packet against eavesdropping and tampering. Implementations SHOULD try to determine automatically whether RADIUS packets will be sent and received over IPSec. If this is not possible, the implementation checks a configuration parameter telling it whether RADIUS traffic will be protected with IPSec. It must be explicitly set by the operator. The default value of this parameter tells the implementation that the RADIUS packet will not be protected.' Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Feb 2006 17:15:24 +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: digest-auth, nonce replay issue Date: Fri, 3 Feb 2006 09:15:08 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250179F02C@xmb-sjc-215.amer.cisco.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYozf8l1cyP9ebZSauxThitF8OFHQAFNLIA From: "Glen Zorn \(gwz\)" To: "Beck01, Wolfgang" Cc: Beck01, Wolfgang supposedly scribbled: >> Searching about in the draft, I can't find any place where the words >> "MUST" and "IPSec" appear in the same sentence > You are right. I mixed it up with Digest-HA1. >=20 >> I do find several passages that assume that applications can know >> whether or not the application traffic is protected by IPSec, >> something that I was unaware was possible... > The application can not detect if the password was posted on a > mailing list either.=20 However, your the draft doesn't say=20 o If the Digest-Qop attribute's value is 'auth-int' and at least one of the following conditions is true, the RADIUS server SHOULD put a Digest-HA1 attribute into the Access-Accept packet: * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- MD5-sess'. * The password was not posted on a mailing list (see Section 9). In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent. It does, however, say this: o If the Digest-Qop attribute's value is 'auth-int' and at least one of the following conditions is true, the RADIUS server SHOULD put a Digest-HA1 attribute into the Access-Accept packet: * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1- MD5-sess'. * The packets between RADIUS client and RADIUS server are protected with IPsec (see Section 9). In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be sent. Since the second condition is, AFAIK, unverifiable, it would make sense = to simply remove it as extraneous. However, my guess is that it's there = for a reason; therefore, I would advise making it depend upon a form of = security that the RADIUS client/server can actually check. >=20 > For the argument's sake, an application could consult the local ipsec > policy database and look if the RADIUS address quadruple is covered > by an appropriate rule. I am aware that existing APIs are not > sufficient here and VPN tunnels can't be discovered this way. =20 >=20 > A pragmatic approach would be to spell out a warning in the manual or > in the syslog 'If you plan to use such and that option, make sure > your RADIUS traffic is protected or you'll be doomed'=20 The actual state of operation of IPSec is being used to determine the = operation of Digest-Auth (either send an Attribute or don't), but that = state cannot be used because it is undeterminable from the application = layer. >=20 >>> However, the RADIUS server has to trust the first timestamp it >>> receives from a RADIUS client. What if the RADIUS client's clock is >>> adjusted during operation? >>=20 >> That's why you have to specify the required level of clock >> synchronization...=20 > I feel a bit uneasy about this. When some technician plays with the > time zone, a whole SIP server won't be able to handle calls any > longer. =20 GMT/UCT. >=20 >>=20 >> ... >>=20 >>> Hope this helps, > It does. >=20 >=20 > Wolfgang Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Feb 2006 16:24:14 +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: digest-auth, nonce replay issue Date: Fri, 3 Feb 2006 11:23:28 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B83A@MABOSEVS2.ets.enterasys.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYozhTuDnltG003TTScRT2yHlz5ngADtiOA From: "Nelson, David" To: Wolfgang Beck writes... > The application can not detect if the password was posted on a > mailing list either. I'm not sure it helps to resort to sarcasm. > A pragmatic approach would be to spell out a warning in the > manual or in the syslog 'If you plan to use such and that > option, make sure your RADIUS traffic is protected or you'll > be doomed' I bet the marketing department will have something to say about your choice of phrasing. :-) In point of fact, I understand that there is not a standard API that an application can use to detect the current IPsec SAs in use for its network connections. IMHO, that is a severe failing of IPsec, but that's a whole different discussion. The question in this case, I think, is what assurances can the protocol implementation make, and what assurances depend upon correct configuration by human operators? It is important that the Security Considerations spell all this out in a clear fashion. If the potential attacks exceed the expectations of the threat model, then there are substantial security flaws in the design. > > That's why you have to specify the required level of clock > synchronization... > > I feel a bit uneasy about this. When some technician plays with the time > zone, a whole SIP server won't be able to handle calls any longer. That would be part of the "assurances that depend upon correct configuration by human operators", right? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Feb 2006 14:27:51 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121F40@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: gwz@cisco.com Cc: radiusext@ops.ietf.org Subject: AW: digest-auth, nonce replay issue Date: Fri, 3 Feb 2006 15:27:34 +0100 MIME-Version: 1.0 Content-Type: text/plain > Searching about in the draft, I can't find any place where > the words "MUST" and "IPSec" appear in the same sentence You are right. I mixed it up with Digest-HA1. > I do find several passages that assume that applications can > know whether or not the application traffic is protected by > IPSec, something that I was unaware was possible... The application can not detect if the password was posted on a mailing list either. For the argument's sake, an application could consult the local ipsec policy database and look if the RADIUS address quadruple is covered by an appropriate rule. I am aware that existing APIs are not sufficient here and VPN tunnels can't be discovered this way. A pragmatic approach would be to spell out a warning in the manual or in the syslog 'If you plan to use such and that option, make sure your RADIUS traffic is protected or you'll be doomed' > > However, the RADIUS server has to trust the first timestamp it > > receives from a RADIUS client. What if the RADIUS client's clock is > > adjusted during operation? > > That's why you have to specify the required level of clock synchronization... I feel a bit uneasy about this. When some technician plays with the time zone, a whole SIP server won't be able to handle calls any longer. > > ... > > > Hope this helps, It does. Wolfgang -- T-Systems Enterprise Services GmbH Technologiezentrum Next Generation IP Services and Systems +49 6151 9372863 Am Kavalleriesand 3 64295 Darmstadt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Feb 2006 13:43:01 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06F2FF70-FC38-4F79-BF79-49173C2503CE@enst-bretagne.fr> Cc: Laurent Toutain , softwires@ietf.org Content-Transfer-Encoding: 7bit From: Bruno STEVANT Subject: Proposal for extension of Radius Accounting Date: Fri, 3 Feb 2006 14:42:05 +0100 To: radiusext@ops.ietf.org Good day all We at Point6 are working in the Softwires WG on a solution for IPv6 access for Home Networks, as described in draft-toutain-softwire- point6box-00.txt In this solution we use L2TP/PPP for IPv6 tunneling. Access AAA parameters are managed with Radius. We found an issue with current FreeBSD PPP implementation on Radius accounting : Attributes Acct-{Input,Output}-Octets and Acct-{Input,Output}-Packets are only based on accounting informations from IPCP. Since our solution only use IPV6CP, we have to modify the code in PPP to send IPV6CP accounting information in these Radius attributes. The basic solution may be just to add IPCP and IPV6CP values and to transmit these sums as value for these attributes. Another solution may also to have separate accounting attributes for IPv4 and IPv6. We think this may be only relevant for packets (as it is done in system MIBs for instance). Our proposal is to have two more attributes for Radius accounting : Acct-IPv6-Input-Packets and Acct-IPv6-Output-Packets. The rational of this proposal is to give operators who deploy dual stack access solution some accounting information about IPv6/IPv4 usage ratio. We ask the Radext WG to take position on this proposal. Some inputs may also come from the Softwires WG. Regards, -- Bruno STEVANT - Point6 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Feb 2006 01:29:52 +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: digest-auth, nonce replay issue Date: Thu, 2 Feb 2006 17:29:18 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250179EEC1@xmb-sjc-215.amer.cisco.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYoN1HB7OybgiQjRw6VjvAOFseiUAAKWNig From: "Glen Zorn \(gwz\)" To: Cc: wolfgang.beck01@t-online.de = supposedly scribbled: ... >> Maybe not: I think that it is only necessary for the attacker to be >> capable of eavesdropping on the conversation between the RADIUS >> client & server & then masquerading as the client later, possibly by >> replaying the Access-Request.=20 >>=20 > RADIUS server and client must use IPSec in the relevant mode anyway, Searching about in the draft, I can't find any place where the words = "MUST" and "IPSec" appear in the same sentence. I do find several = passages that assume that applications can know whether or not the = application traffic is protected by IPSec, something that I was unaware = was possible... ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 23:13:58 +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: digest-auth, nonce replay issue Date: Thu, 2 Feb 2006 15:13:40 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250179EE40@xmb-sjc-215.amer.cisco.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYoN1HB7OybgiQjRw6VjvAOFseiUAAFnfhQ From: "Glen Zorn \(gwz\)" To: Cc: wolfgang.beck01@t-online.de = supposedly scribbled: ... >>> Is the granularity of minutes sufficient? >>=20 >> Depends upon the expected session length: are all (or a very high >> percentage of) sessions expected to last more than a minute? If so, >> then one minute granularity is fine. If you're going to use >> timestamps you need to define the required level of clock >> synchronization between the client and server... >>=20 > My intention was to use a 32 bit value that won't overflow in 2038 > (the German pension regulations are about to be changed, I might have > still to work then..). =20 >=20 > As the Event-Timestamp attribute uses seconds, we can use seconds > here as well.=20 >=20 > However, the RADIUS server has to trust the first timestamp it > receives from a RADIUS client. What if the RADIUS client's clock is > adjusted during operation? =20 That's why you have to specify the required level of clock = synchronization... >=20 > In the IESG review, you mentioned a similar problem with CHAP. Do you > have some pointers how it was solved?=20 AFAIK, it wasn't. >=20 >=20 > Wolfgang Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 22:54:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Handling an unparsable NAS-Filter-Rule Date: Thu, 2 Feb 2006 17:54:38 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231DE6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Handling an unparsable NAS-Filter-Rule Thread-Index: AcYoS6U4vAXZNbLeTsWbTJNeYYd22w== From: "Greg Weber \(gdweber\)" To: Description of issue: Handling an unparsable NAS-Filter-Rule Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html Document: IEEE802-01 Comment type: Technical Priority: S Section: 1.4, 6 Rationale/Explanation of issue: The NAS-Filter-Rule represents a *lot* of functionality. I think we can expect lots of variability in NASes which support various parts, e.g. maybe all the filtering, but not HTTP redirection, etc. I think we maybe need to be clearer on what is supposed to happen when the NAS gets a CoA-Request or Access-Request containing directives that it cannot parse or apply. In particular, in Section 1.4 "Attribute Interpretation", I see text indicating that non-understood attributes result in Access-Rejects. But, in Section 6 "Security Considerations", I see text like: "...a NAS could be configured to ... not accept any redirection rules if it is known they are not used in this environment." These would seem to be contradictory. Requested change: Need clarification on the intent. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 22:54:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Precedence and order for NAS-Filter-Rule Date: Thu, 2 Feb 2006 17:54:32 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231DE5@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Precedence and order for NAS-Filter-Rule Thread-Index: AcYoS6HQ07JtMW2CQ9KWPB4v8heK6g== From: "Greg Weber \(gdweber\)" To: Description of issue: Precedence and order for NAS-Filter-Rule Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html Document: IEEE802-01 Comment type: Technical Priority: S Section: 2.5 Rationale/Explanation of issue: At the very end of Section 2.5 on NAS-Filter-Rule, it says that the NAS can apply rules of its own before rules supplied via the interface in this document. I didn't understand the ordering and precedence=20 between filters originated from the different sources. Is that covered somewhere? If the server sends a=20 flush-rule via CoA-Request, does that remove the=20 NAS originated (configured) rules? The text is implying that the rules are applied in specific order based on=20 type, e.g. HTTP filter rules are last. What if the NAS defines the HTTP filter rule, and other types come via=20 CoA? What's the order then? This seems like an area of likely implementation confusion. Requested change: I think the precedence of locally configured rules relative to dynamic updates needs to be clarified. =20 It might also be useful to treat this in the examples of Appendix B. This seems similar to Issue 107 related to Acct-Interim-Interval. The NAS owner needs to be able to protect his resources, and the server owner needs predictable results for dynamic updates. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 22:54:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Tag option in VLAN attributes Date: Thu, 2 Feb 2006 17:54:20 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231DE4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Tag option in VLAN attributes Thread-Index: AcYoS5qHFBuBTf/oSGC2tzCB0x/pDA== From: "Greg Weber \(gdweber\)" To: Description of issue: Tag option in VLAN attributes Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html Document: IEEE802-01 Comment type: Technical Priority: S Section: 2.1, 2.3 Rationale/Explanation of issue: The Egress-VLANID attribute proposed in Section 2.1=20 is defined as data type "Integer": 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length | Tag Option | Pad (12-bit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Pad | VLANID (12-bit) | =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 I think this is going to be confusing because it similar formatting to the 'tagging mechanism' defined in RFC 2868. Also wondering if it's possible to not overload a single integer with two values? Won't this make configuring the value on the server more difficult. Can each VLAN have=20 an independent tagged/untagged value? Why are 0x31 & 0x32=20 used? =20 Requested change: At least, I'd suggest changing "Tag Option" to "VLAN Tag" or something like that. Guess I'd have to understand this better to suggest if the Tag and ID can be separated. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 22:54:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Authorize Only usage in HTTP redirect Date: Thu, 2 Feb 2006 17:54:13 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231DE3@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Authorize Only usage in HTTP redirect Thread-Index: AcYoS5Zp6eRWrogeQAu3eff/EkfSWg== From: "Greg Weber \(gdweber\)" To: Description of issue: Authorize Only usage in HTTP redirect Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 2, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00090.html Document: IEEE802-01 Comment type: Technical Priority: S Section: A.2.2 Rationale/Explanation of issue: Section A.2.2 Mid-session HTTP Redirection reads: If HTTP redirection is required to be applied to a service that=20 has already been started then the RADIUS server can push the=20 redirection rules, and optionally the filter rules, to the NAS=20 within a NAS-Filter-Rule(TBD) attribute using a CoA message. The=20 NAS will then commence to apply the redirection rules and/or the=20 filter rules. =20 =20 Alternatively, the RADIUS server can request that the NAS re- authorize the session using the procedures defined in [RFC3576].=20 The RADIUS server responds with an Access-Accept message (with=20 Service-Type(6) set to "Authorize Only" that will contain the=20 redirection and optionally filtering rules within a NAS-Filter- Rule(TBD) attribute.=20 I don't think "Authorize Only" is a valid Service-Type value in Access-Accept messages. The server should be indicating the assigned Service in the Access-Accept. Take a look at the last paragraph of RFC 3576's Section 1.1. I think that describes the process your referring to here. Requested change: I suggest replacing the above text with something like: If HTTP redirection is required to be applied to a service that=20 has already been started, then the RADIUS server may use either of the procedures defined in [RFC3576]: - The server may send the NAS a CoA-Request message including a NAS-Filter-Rule which contains redirection rules and optionally filter rules. The NAS will then apply the new rules to the existing services. - The server may send the NAS a CoA-Request message including a Service-Type attribute with the value of "Authorize Only". This will trigger the NAS to reauthorize the existing service by sending the server an Access-Request message containing a Service-Type attribute with the value of "Authorize Only". The server may then send the NAS new redirection and optionally filter rules within a NAS-Filter-Rule as part of an Access- Accept message. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 22:43:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt) Date: Thu, 2 Feb 2006 16:16:08 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B836@MABOSEVS2.ets.enterasys.com> Thread-Topic: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt) Thread-Index: AcYoNydoHrzPlLoXSRyZuKBN6KIYYwABbGpA From: "Nelson, David" To: Cc: Bert Wijnen writes... =20 > If WG A cannot reach (or has trouble reaching) > consensus/agreement on a specific work item, > then what arguments do we have that WG B > can do better? None. However, I don't think that the issue is that the RADEXT WG cannot come to consensus on a technical approach as much as it is the fact that a RADEXT draft is proposing to extend the existing Diameter NAS-Filter-Rule syntax. There are at least two problems here: (1) RADIUS is not supposed to be a super-set of Diameter in any of its features, and (2) failing to address a corresponding extension in Diameter causes difficulty for the translation gateway process. It was suggested that, if an extension to the Diameter NAS-Filter-Rule is required for use in RADIUS, that we actually extend the Diameter NAS-Filter-Rule, rather that defining a separate RADIUS-NAS-Filter-Rule attribute and syntax. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 21:19:57 +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: review of draft-ietf-radext-ieee802-01.txt Date: Thu, 2 Feb 2006 13:19:39 -0800 Message-ID: Thread-Topic: review of draft-ietf-radext-ieee802-01.txt Thread-Index: AcYnusNNfQonm528TR2hN4Yn3YHIBQAgvNlg From: "Sanchez, Mauricio (PNB Roseville)" To: "Bernard Aboba" , , I had suggested in a previous email that we change the name of NAS-Filter-Rule to something else to avoid any possibility that someone may confuse this RADIUS attribute from what is already defined in Diameter. Diameter is going to inherit this new attribute anyway, so I'm unsure what sort of compatibility issues may arise if we call the attribute something 'Traffic-Rule'? My expectation would be that NAS-Filter-Rule be deprecated. MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, February 01, 2006 9:37 PM > To: gdweber@cisco.com; radiusext@ops.ietf.org > Subject: Re: review of draft-ietf-radext-ieee802-01.txt >=20 > >I'd like to understand this too. I thought we didn't want=20 > to try & do=20 > >things in RADIUS that are not supported in Diameter. >=20 > The RADEXT WG charter requires that Diameter compatibility issues be=20 > examined as part of each work item. Extending the RFC 3588=20 > NAS-Filter-Rule=20 > syntax does bring up Diameter compatibility issues. This was=20 > pointed out in Issue 130, which was filed in August 2005. >=20 > As I understand it, the DIME WG is being chartered to produce=20 > RFC 3588bis, so one possibility is that they will consider a=20 > NAS-Filter-Rule syntax revision as part of that effort. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 21:06:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter Date: Thu, 2 Feb 2006 13:06:12 -0800 Message-ID: Thread-Topic: Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter Thread-Index: AcYoO9pz54sEgUITQ7SNqCJ4x8L56AAABi9Q From: "Sanchez, Mauricio (PNB Roseville)" To: Cc: "Bernard Aboba" Bernard asserted...=20 >=20 > Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter=20 > names: Bernard Aboba Submitter email address:=20 > aboba@internaut.com Date first submitted: January 30, 2006 > Reference: > Document: IEEE 802-01 > Comment type: Technical > Priority: S > Section: 1.4 > Rationale/Explanation of issue: >=20 > Section 1.4 states: >=20 > 1.4 Attribute Interpretation >=20 > Unless otherwise noted in the individual description of an > attribute contained herein, a NAS that conforms to this > specification and receives an Access-Accept message that contains > an attribute from this document that it cannot apply MUST > interpret this though an Access-Reject had been sent and MUST > terminate the session. If accounting is enabled on the NAS, it > MUST generate an Accounting-Request(Stop) message upon session > termination. >=20 > Similarly, if a NAS conforming to this specification and also > conforming to RFC 3576 [RFC3576] receives a CoA message that > contains an attribute from this document that it cannot apply, it > MUST NOT terminate the session and MUST generate a CoA-NAK packet > with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If > accounting is enabled on the NAS, it MUST NOT generate an > Accounting-Request(Stop) message in such instances. > RFC 2866 does not specify the generation of Accounting Stop=20 > messages resulting from Access-Reject packets. This document=20 > is therefore requiring RADIUS accounting clients to generate=20 > accounting records in circumstances where they would not=20 > otherwise do so. This raises the question of why this=20 > particular set of attributes would cause a special case=20 > modification to RFC 2866. We are amendable to removing contentious references to accounting behavior as noted in my email from yesterday (2/1/06) for Issue 111. =20 =20 > On inclusion of Error-Cause attributes: >=20 > It is possible that the NAS cannot honor Disconnect-Request or > CoA-Request messages for some reason. The Error-Cause Attribute > provides more detail on the cause of the problem. It MAY be > included within Disconnect-ACK, Disconnect-NAK and CoA-NAK > messages. >=20 > Since inclusion of an Error-Cause attribute is generally=20 > optional, the second paragraph mandates behavior not required=20 > by RFC 3576. We are amendable to removing this paragraph. Cheers, MS -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 20:52:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: References Date: Thu, 2 Feb 2006 12:52:24 -0800 Message-ID: Thread-Topic: Issue: References Thread-Index: AcYlEMyfDvQ900NVR9y+3ToPUERyrwDKWycA From: "Sanchez, Mauricio (PNB Roseville)" To: "Bernard Aboba" , =20 Bernard points out... > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, January 29, 2006 12:15 PM > To: radiusext@ops.ietf.org > Subject: Issue: References >=20 > Issue : References > Submitter names: Bernard Aboba > Submitter email address: aboba@internaut.com Date first=20 > submitted: January 29, 2006 > Reference: > Document: IEEE 802-01 > Comment type: Editorial > Priority: S > Section: Various > Rationale/Explanation of issue: >=20 > It is not clear to me why RFC 2868, 3162, 3576, 3579, 3580,=20 > 3748 are listed as Normative References. For example, an=20 > implementer would not be required to consult these documents=20 > in order to implement the specification. We agree and will change the references from normative to informative. >=20 > On the other hand, it seems like RFC 2674 and 3629 are=20 > referenced in a normative way; for example, if UTF-8 is=20 > supported, then an implementer would need to consult RFC=20 > 3629, no? The reference to IEEE 802 also seems to be normative. We agree and will change the references from informative to normative. >=20 > Some of the references do not appear to be referenced in the=20 > specification. =20 > For example, there is no reference to RFC 1321, RFC 2866, RFC=20 > 2867, RFC 3748. Good catch. This are remnants of previous drafts. This will be removed. Cheers, MS -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 20:29:16 +0000 To: "Glen Zorn \(gwz\)" cc: radiusext@ops.ietf.org Subject: Re: digest-auth, nonce replay issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9758.1138911770.1@big3> Date: Thu, 02 Feb 2006 21:22:50 +0100 From: wolfgang.beck01@t-online.de Message-ID: <1F4l4i-0yBVfk0@fwd29.sul.t-online.de> Glen Zorn wrote: > > nonce = concat(time-stamp, H(time-stamp ":" private-key), = second-part) > > > > time-stamp = minutes since Epoch in hexadecimal, padded to 8 digits > > second-part arbitrary data that might be interpreted > > by the nonce generator to check the authencity of the nonce. > > > > One could argue that private-key is useless as Glen's attack requires > > that the attacker has full access to the RADIUS client. > > Maybe not: I think that it is only necessary for the attacker to be > capable of eavesdropping on the conversation between the RADIUS client & > server & then masquerading as the client later, possibly by replaying > the Access-Request. > RADIUS server and client must use IPSec in the relevant mode anyway, but as the nonce is sent in the clear between HTTP-style client and RADIUS client, I think it should be protected. > > > > Is the granularity of minutes sufficient? > > Depends upon the expected session length: are all (or a very high > percentage of) sessions expected to last more than a minute? If so, > then one minute granularity is fine. If you're going to use timestamps > you need to define the required level of clock synchronization between > the client and server... > My intention was to use a 32 bit value that won't overflow in 2038 (the German pension regulations are about to be changed, I might have still to work then..). As the Event-Timestamp attribute uses seconds, we can use seconds here as well. However, the RADIUS server has to trust the first timestamp it receives from a RADIUS client. What if the RADIUS client's clock is adjusted during operation? In the IESG review, you mentioned a similar problem with CHAP. Do you have some pointers how it was solved? Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 20:27:23 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509391975@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: john.loughney@nokia.com, bernard_aboba@hotmail.com, gdweber@cisco.com, radiusext@ops.ietf.org Cc: dime@ietf.org Subject: RE: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01. txt) Date: Thu, 2 Feb 2006 21:26:43 +0100 MIME-Version: 1.0 Content-Type: text/plain Not that I do have concerns with this. In generic terms that concern is: If WG A cannot reach (or has trouble reaching) consensus/agreement on a specific work item, then what arguments do we have that WG B can do better? Bert > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Wednesday, February 01, 2006 23:49 > To: bernard_aboba@hotmail.com; gdweber@cisco.com; > radiusext@ops.ietf.org > Cc: dime@ietf.org > Subject: NAS-Filter-Rule (was: review of > draft-ietf-radext-ieee802-01.txt) > > > Hi all, > > >The RADEXT WG charter requires that Diameter compatibility issues be > >examined as part of each work item. Extending the RFC 3588 > >NAS-Filter-Rule > >syntax does bring up Diameter compatibility issues. This was > >pointed out in Issue 130, which was filed in August 2005. > > > >As I understand it, the DIME WG is being chartered to produce > >RFC 3588bis, so one possibility is that they will consider a > >NAS-Filter-Rule syntax revision as part of that effort. > > I'm copying the DiME WG. Is there interest in the Diameter community > in revising the NAS-Filter-Rule? For RADIUS, it is currently defined > here: > > http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-01.txt > > I suggest that if this is of interest to both RADIUS & Diameter, we > come-up with a common format that would be usable in both protocols. > > John > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 19:00:55 +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: digest-auth, nonce replay issue Date: Thu, 2 Feb 2006 11:00:36 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250179EC8C@xmb-sjc-215.amer.cisco.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYd106lUCgR5GPJQwmh/e89z7Fk2gKUVpiQ From: "Glen Zorn \(gwz\)" To: "Beck01, Wolfgang" , Cc: Beck01, Wolfgang <> supposedly scribbled: > During the IESG review Glen Zorn pointed out, that the draft allows a > nonce replay attack as the RADIUS server can't tell how old a nonce > is. =20 Actually, the problem is that a valid response can be replayed, because = the RADIUS server has no idea what the original nonce might have been, = but I suppose it doesn't matter. >=20 > So I've added some sentence like 'the nonce MUST contain some kind of > timestamp'.=20 > Just before submitting -07, it dawned to me that this is not > sufficient.=20 >=20 > In scenario 1, the RADIUS client communicates the nonce to the RADIUS > server.=20 > As generator and consumer of the nonce are not the same system, we > need to define a nonce format. RfC 2617 proposes=20 >=20 > time-stamp H(time-stamp ":" ETag ":" private-key) >=20 > This is fine, but many HTTP-style messages don't have an ETag header. > Even if there is one, the RADIUS server can't check it as there is no > RADIUS attribute for ETag. We might structure the nonce mentally in > two parts: =20 >=20 > nonce =3D concat(time-stamp, H(time-stamp ":" private-key), = second-part) >=20 > time-stamp =3D minutes since Epoch in hexadecimal, padded to 8 digits > second-part =3D arbitrary data that might be interpreted > by the nonce generator to check the authencity of the nonce.=20 >=20 > One could argue that private-key is useless as Glen's attack requires > that the attacker has full access to the RADIUS client.=20 Maybe not: I think that it is only necessary for the attacker to be = capable of eavesdropping on the conversation between the RADIUS client & = server & then masquerading as the client later, possibly by replaying = the Access-Request. >=20 > Is the granularity of minutes sufficient? Depends upon the expected session length: are all (or a very high = percentage of) sessions expected to last more than a minute? If so, = then one minute granularity is fine. If you're going to use timestamps = you need to define the required level of clock synchronization between = the client and server... >=20 >=20 > Wolfgang >=20 > -- > T-Systems International GmbH > Technologiezentrum > Next Generation IP Services and Systems > +49 6151 9372863 > Am Kavalleriesand 3 > 64295 Darmstadt Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 18:24:55 +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: digest-auth, nonce replay issue Date: Thu, 2 Feb 2006 13:23:46 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B832@MABOSEVS2.ets.enterasys.com> Thread-Topic: digest-auth, nonce replay issue Thread-Index: AcYd11KbnrGip7qDSmGV0XblrRvQ5gKTWk/g From: "Nelson, David" To: Wolfgang beck writes... > During the IESG review Glen Zorn pointed out, that the draft=20 > allows a nonce replay attack as the RADIUS server can't tell=20 > how old a nonce is. >=20 > So I've added some sentence like 'the nonce MUST contain some > kind of timestamp'. Just before submitting -07, it dawned to=20 > me that this is not sufficient. >=20 > In scenario 1, the RADIUS client communicates the nonce to=20 > the RADIUS server. As generator and consumer of the nonce are > not the same system, we need to define a nonce format.=20 > RfC 2617 proposes >=20 > time-stamp H(time-stamp ":" ETag ":" private-key) >=20 > This is fine, but many HTTP-style messages don't have an=20 > ETag header. Even if there is one, the RADIUS server can't=20 > check it as there is no RADIUS attribute for ETag. > We might structure the nonce mentally in two parts: >=20 > nonce =3D concat(time-stamp, H(time-stamp ":" private-key),=20 > second-part) >=20 > time-stamp =3D minutes since Epoch in hexadecimal, padded to=20 > 8 digits second-part =3D arbitrary data that might be interpreted > by the nonce generator to check the authenticity of the nonce. >=20 > One could argue that private-key is useless as Glen's attack=20 > requires that the attacker has full access to the RADIUS client. >=20 > Is the granularity of minutes sufficient? Time is ticking, and the IESG is waiting for a revised draft before completing their review. Would everyone on this WG list, who has an interest in the Digest Authentication draft, please take a moment to review this issue and respond to the list? If we don't get any responses, then maybe we can assume that no one needs this work? :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 07:50:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt) Date: Thu, 2 Feb 2006 09:49:26 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01A089A4@esebe100.NOE.Nokia.com> Thread-Topic: NAS-Filter-Rule (was: review of draft-ietf-radext-ieee802-01.txt) Thread-Index: AcYnutvON97zY+J9SGq8413Yh4flaAAEa6lA From: To: , , Cc: Hi all, >The RADEXT WG charter requires that Diameter compatibility issues be=20 >examined as part of each work item. Extending the RFC 3588=20 >NAS-Filter-Rule=20 >syntax does bring up Diameter compatibility issues. This was=20 >pointed out in Issue 130, which was filed in August 2005. > >As I understand it, the DIME WG is being chartered to produce=20 >RFC 3588bis, so one possibility is that they will consider a=20 >NAS-Filter-Rule syntax revision as part of that effort. I'm copying the DiME WG. Is there interest in the Diameter community in revising the NAS-Filter-Rule? For RADIUS, it is currently defined here: http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-01.txt I suggest that if this is of interest to both RADIUS & Diameter, we=20 come-up with a common format that would be usable in both protocols. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 05:36:57 +0000 Message-ID: From: "Bernard Aboba" To: gdweber@cisco.com, radiusext@ops.ietf.org Bcc: Subject: Re: review of draft-ietf-radext-ieee802-01.txt Date: Wed, 01 Feb 2006 21:36:47 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >I'd like to understand this too. I thought we didn't >want to try & do things in RADIUS that are not supported >in Diameter. The RADEXT WG charter requires that Diameter compatibility issues be examined as part of each work item. Extending the RFC 3588 NAS-Filter-Rule syntax does bring up Diameter compatibility issues. This was pointed out in Issue 130, which was filed in August 2005. As I understand it, the DIME WG is being chartered to produce RFC 3588bis, so one possibility is that they will consider a NAS-Filter-Rule syntax revision as part of that effort. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 05:31:21 +0000 Message-ID: From: "Bernard Aboba" To: gdweber@cisco.com, radiusext@ops.ietf.org Bcc: Subject: RE: Some questions about IEEE802-01 Date: Wed, 01 Feb 2006 21:30:53 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Thanks for your comments, Greg. It looks to me like each of the points you raise is a real issue, so please go ahead and file them. >*) In A.2.2, regarding mid-session HTTP redirection, >the text in the 2nd paragraph is talking about the >RADIUS server sending an Access-Accept with Service-Type >set to "Authorize Only". I didn't understand what that >was all about. I thought "Authorize Only" could only >be used in CoA-Request & Access-Request messages. >Did I miss something there? You didn't miss anything. I don't understand this usage of the "Authorize Only" Service-Type. >*) At the very end of Section 2.5 on NAS-Filter-Rule, >it says that the NAS can apply rules of its own before >rules supplied via the interface in this document. >I didn't understand the ordering and precendence >between filters originated from the different sources. >Is that covered somewhere? If the server sends a >flush-rule via CoA-Request, does that remove the >NAS originated (configured) rules? The text is implying >that the rules are applied in specific order based on >type, e.g. HTTP filter rules are last. What if the NAS >defines the HTTP filter rule, and other types come via >CoA? What's the order then? This seems like an area >of likely implementation confusion. Yes, I think this is an issue. >*) For Egress-VLANID & Egress-VLAN-Name, is there any >particular reason to overload the "Tag Option" into >the same attribute as the remainder values - instead >of making the "Tag Option" portion a separate attribute? >Wouldn't it be easier to configure on the server if >these were separated out? Also, if not separated, >isn't calling the first octet a 'tag' confusing with >the RADIUS tagged tunnel attributes? My impression was that the usage was similar to the 'Tag' in the tunnel attributes, but perhaps I'm misreading the document. >*) The NAS-Filter-Rule represents a *lot* of functionality. >I think we can expect lots of variability in NASes to >support various parts, e.g. maybe all the filtering, but >not HTTP redirection, etc. I think we maybe need to be >clearer on what is supposed to happen when the NAS gets >a CoA-Request or Access-Request containing directives >that it cannot parse or apply. In particular, in Section >1.4 "Attribute Interpretation", I text indicating that >non-understood attribute result in Access-Rejects. But, >in Section 6 "Security Considerations", I see text like: >"...a NAS could be configured to ... not accept any >redirection rules if it is known they are not used in >this environment." There seems to be some confusion >about whether the NAS or server is authoritative. Yes, I think there is a contradiction there. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 03:27:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Some questions about IEEE802-01 Date: Wed, 1 Feb 2006 22:27:12 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231A32@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Some questions about IEEE802-01 Thread-Index: AcYnqI6bQ1JcpWOLSdivTltxF2U+PQ== From: "Greg Weber \(gdweber\)" To: I have a couple questions about IEEE802-01. I'm not sure if these are issues, so thought I'd just ask first. I can file official=20 issues if needed. *) In A.2.2, regarding mid-session HTTP redirection, the text in the 2nd paragraph is talking about the RADIUS server sending an Access-Accept with Service-Type set to "Authorize Only". I didn't understand what that was all about. I thought "Authorize Only" could only be used in CoA-Request & Access-Request messages.=20 Did I miss something there? *) At the very end of Section 2.5 on NAS-Filter-Rule, it says that the NAS can apply rules of its own before rules supplied via the interface in this document. I didn't understand the ordering and precendence=20 between filters originated from the different sources. Is that covered somewhere? If the server sends a=20 flush-rule via CoA-Request, does that remove the=20 NAS originated (configured) rules? The text is implying that the rules are applied in specific order based on=20 type, e.g. HTTP filter rules are last. What if the NAS defines the HTTP filter rule, and other types come via=20 CoA? What's the order then? This seems like an area of likely implementation confusion. *) For Egress-VLANID & Egress-VLAN-Name, is there any particular reason to overload the "Tag Option" into the same attribute as the remainder values - instead=20 of making the "Tag Option" portion a separate attribute? Wouldn't it be easier to configure on the server if these were separated out? Also, if not separated,=20 isn't calling the first octet a 'tag' confusing with the RADIUS tagged tunnel attributes? *) The NAS-Filter-Rule represents a *lot* of functionality. I think we can expect lots of variability in NASes to support various parts, e.g. maybe all the filtering, but not HTTP redirection, etc. I think we maybe need to be clearer on what is supposed to happen when the NAS gets a CoA-Request or Access-Request containing directives that it cannot parse or apply. In particular, in Section 1.4 "Attribute Interpretation", I text indicating that non-understood attribute result in Access-Rejects. But, in Section 6 "Security Considerations", I see text like: "...a NAS could be configured to ... not accept any redirection rules if it is known they are not used in this environment." There seems to be some confusion about whether the NAS or server is authoritative. Greg -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 02:16:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: review of draft-ietf-radext-ieee802-01.txt Date: Wed, 1 Feb 2006 21:15:38 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601231A12@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Re: review of draft-ietf-radext-ieee802-01.txt Thread-Index: AcYnno9TR79voaM5RkqGwkKEdlJV8A== From: "Greg Weber \(gdweber\)" To: Regarding NAS-Filter-Rule: > > The changes we have made are not simply extensions and the attribute we > > are defining is not purely a superset.=20 > Can you list what the specific differences are? I'd like to understand this too. I thought we didn't want to try & do things in RADIUS that are not supported in Diameter. I noticed these in the text: Section 1=20 "...extend the filter language described in [RFC3588]." Section 2.5 "NAS-Filter-Rule is a superset in functionality..." Greg -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 01:42:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 165 - Allowed Usage Date: Wed, 1 Feb 2006 17:42:30 -0800 Message-ID: Thread-Topic: Issue 165 - Allowed Usage Thread-Index: AcYlD7qSghAcm+ivQ8au6xHZ36r8ZgCiSrMw From: "Sanchez, Mauricio (PNB Roseville)" To: "Bernard Aboba" Cc: Bernard rightly noticed...=20 > -----Original Message----- > In Section 4, the Table of Attributes states the following: >=20 > The following table provides a guide to which attributes may be > found in which kinds of packets, and in what quantity. >=20 > Access- Access- Access- Access- CoA- > Request Accept Reject Challenge Req # Attribute > 0 0+ 0 0 0+ TBD Egress-VLANID > 0 0-1 0 0 0-1 TBD Ingress-Filters > 0 0-1 0 0 0-1 TBD User-Priority-Table >=20 > The Egress-VLAN-Name attribute is not included in this table,=20 > nor is it included in the IANA considerations section. Oversight. We will add it in.=20 >=20 > Section 2.1: >=20 > Multiple Egress-VLANID attributes can be delivered in an > authentication response; each attribute adds the=20 > specified VLAN > to the list of allowed egress VLANs for the port. >=20 > This would appear to indicate that the Egress-VLAN-Name=20 > attribute is allowed in Access-Challenge, Access-Reject and=20 > Access-Accept packets. > Yet, the attribute table in Section 4 does not seem to permit=20 > inclusion in Reject or Challenge packets. Will changing "Multiple Egress-VLANID attributes can be delivered in an authentication response..." to "The RADIUS server can return multiple Egress-VLANID attributes in an Access-Accept or CoA-Request packet..." address this issue? > Section 2.3: >=20 > Multiple Egress-VLAN-Name attributes can be delivered in an > authentication response; each attribute adds the=20 > named VLAN to > the list of allowed egress VLANs for the port. >=20 > This would appear to indicate that the Egress-VLAN-Name=20 > attribute is allowed in Access-Challenge, Access-Reject and=20 > Access-Accept packets. > There is no entry in the Attribute Table to confirm this. Will changing "Multiple Egress-VLAN-Name attributes can be delivered in an authentication response..." to "The RADIUS server can return multiple Egress-VLAN-Name attributes in an Access-Accept or CoA-Request packet..." address this issue? >=20 > Section 2.4: >=20 > There is no material on permitted usage of the=20 > User-Priority-Table attribute. Will adding the following sentence address this issue? The RADIUS server MAY only send a single User-Priority-Table attribute within an Access-Accept or COA-Request; this attribute MUST NOT be sent within an Access-Request, Access-Challenge, Access-Reject, or Disconnect-Request. Cheers, MS -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 01:13:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 102 in ieee802-01 Date: Wed, 1 Feb 2006 17:12:11 -0800 Message-ID: Thread-Topic: Issue 102 in ieee802-01 Thread-Index: AcYhnVKSXpy+gwPCRaCQqthPuIPP0AE+T4awABrvoJAAJNcE8A== From: "Sanchez, Mauricio (PNB Roseville)" To: , Ok. MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > Pasi.Eronen@nokia.com > Sent: Tuesday, January 31, 2006 11:47 PM > To: Sanchez, Mauricio (PNB Roseville); radiusext@ops.ietf.org > Subject: RE: Issue 102 in ieee802-01 >=20 > Hi Mauricio, >=20 > Yes, that looks OK -- but the definition of TEXTDATA also=20 > needs to be aligned (it shouldn't include "%"). My proposal: >=20 > TEXTDATA =3D %x20-21 / %x23-24 / %x26-7E=20 >=20 > (In other words, exclude double quote '"' and percent sign '%') >=20 > Best regards, > Pasi >=20 > > -----Original Message----- > > From: Sanchez, Mauricio (PNB Roseville) > > Sent: 31 January, 2006 20:52 > > To: radiusext@ops.ietf.org > > Subject: RE: Issue 102 in ieee802-01 > >=20 > >=20 > > Pasi, > >=20 > > Would the following 'tunnel-id' syntax definition cover=20 > your concerns? > >=20 > > tunnel-id =3D DQUOTE 1*(TEXTDATA /("%" 2HEXDIG)) DQUOTE > >=20 > > Thanks, > > MS > >=20 > > > -----Original Message----- > > > From: owner-radiusext@ops.ietf.org > > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > > > Pasi.Eronen@nokia.com > > > Sent: Wednesday, January 25, 2006 2:52 AM > > > To: radiusext@ops.ietf.org > > > Subject: Issue 102 in ieee802-01 > > >=20 > > > Hi, > > >=20 > > > It looks like version -01 of the IEEE attributes draft=20 > solved my of=20 > > > my comments, but one resolution looks slightly buggy: > > >=20 > > > The ABNF includes two different ways to quoting "strange"=20 > > > octets in tunnel-id (backslashes and percent-hex-hex),=20 > but the text=20 > > > doesn't quite match the ABNF. > > >=20 > > > Also, I think we don't need two different quoting mechanisms; the=20 > > > percent-hex-hex notation makes the backslashes redundant (and is=20 > > > IMHO easier to implement in a way that really works with=20 > arbitrary=20 > > > octets, such as LF (the rule delimeter!) and NUL). > > >=20 > > > Best regards, > > > Pasi > > >=20 > > > -- > > > to unsubscribe send a message to > > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in a=20 > > > single line as the message text body. > > > archive: > > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 00:50:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 111: Accounting Date: Wed, 1 Feb 2006 16:50:03 -0800 Message-ID: Thread-Topic: Issue 111: Accounting Thread-Index: AcXo4zP4owynFIS2QNSRGzb5U8v1kQ+rl+Dw From: "Sanchez, Mauricio (PNB Roseville)" To: "Bernard Aboba" , Bernard noted a while back...=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, November 13, 2005 10:17 PM > To: radiusext@ops.ietf.org > Subject: Re: Issue 111: Accounting >=20 > Here is what RFC 2866 says about the notion of an Accounting Session: >=20 <...removed what RFC2866 says about accounting...> >=20 > As Greg noted, the Service-Type is not being changed here, so=20 > that the Service is continuing, and sending of additional=20 > Start/Stop messages is somewhat odd. Also, do we really want=20 > individual RADIUS attributes to provide their own definitions=20 > of when a new session is started and stopped? =20 > RADIUS accounting is a separate protocol from RADIUS=20 > authentication, and runs on a separate port. Authentication=20 > attributes that affect accounting (Class,=20 > Acct-Interim-Interval) have to date been general ones. =20 > Terminating the Accounting Session in mid-stream could cause=20 > issues with RADIUS implementations that use the Accounting=20 > Records for things like simultaneous usage control. >=20 > Paul Congdon said: >=20 > At IETF-64 we reviewed this issue. There did not seem to be=20 > any objection to having compliance statements in the Annex=20 > given that this Annex is where the context for the statements=20 > is developed. Also, since a new session is created, as=20 > stated in the draft, there is no need to use INTERM messages. >=20 > -------------------------------------------------------------- > ------------------- > Issue 111: Accounting > Submitter name: Greg Weber > Submitter email address: gdweber@cisco.com Date first=20 > submitted: August 10, 2005 > Reference: http://ops.ietf.org/lists/radiusext/2005/msg00636.html > Document: IEEE802-00 > Comment type: T > Priority: S > Section: A.3 > Rationale/Explanation of issue: >=20 > The accounting requirements do not seem to be fully treated=20 > by the draft. Section A.3 has a MUST requirement related to=20 > accounting. I would think that MUST requirements should be=20 > treated by the text, not in an appendix. Why does=20 > redirection require a STOP/START pair? Can't this=20 > information be conveyed via an INTERIM record for the same=20 > session? If the Service- Type is not changing, I'd think=20 > that an INTERIM would suffice. In light that the treatment of accounting behavior would be best treated elsewhere, such as in 3576bis, I would suggest that we omit any discussion of accounting behavior in this draft. This means that sections 1.4 would be modified and section A.3 would be eliminated to remove accounting references.=20 Does this seem like a reasonable path? Cheers, MS =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Feb 2006 00:42:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Allowed Usage Date: Wed, 1 Feb 2006 19:41:41 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6012319FD@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Issue: Allowed Usage Thread-Index: AcYlD68LAAvs63FIQQqH4TORomkVvwCgQW0gAAAqWSA= From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" , Also, the textual description of Ingress-Filters says=20 that it MUST NOT be included in Disconnect-Request messages (and some other types of messages). This is=20 not reflected in the Table of Attributes in Section 4 which may be confusing. Would any of these attributes be used in Disconnect-Request messages? I'd guess not, except maybe a flush rule... :) Greg > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, January 29, 2006 3:07 PM > To: radiusext@ops.ietf.org > Subject: Issue: Allowed Usage >=20 > Issue : Allowed Usage > Submitter names: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: January 29, 2006 > Reference: > Document: IEEE 802-01 > Comment type: 'T'echnical | > Priority: S > Section: Various > Rationale/Explanation of issue: >=20 > In Section 4, the Table of Attributes states the following: >=20 > The following table provides a guide to which attributes may be > found in which kinds of packets, and in what quantity. >=20 > Access- Access- Access- Access- CoA- > Request Accept Reject Challenge Req # Attribute > 0 0+ 0 0 0+ TBD Egress-VLANID > 0 0-1 0 0 0-1 TBD Ingress-Filters > 0 0-1 0 0 0-1 TBD User-Priority-Table >=20 > The Egress-VLAN-Name attribute is not included in this table, nor is > it included in the IANA considerations section. >=20 > Section 2.1: >=20 > Multiple Egress-VLANID attributes can be delivered in an > authentication response; each attribute adds the=20 > specified VLAN > to the list of allowed egress VLANs for the port. >=20 > This would appear to indicate that the Egress-VLAN-Name attribute is > allowed in Access-Challenge, Access-Reject and Access-Accept packets. > Yet, the attribute table in Section 4 does not seem to permit > inclusion in Reject or Challenge packets. >=20 > Section 2.3: >=20 > Multiple Egress-VLAN-Name attributes can be delivered in an > authentication response; each attribute adds the=20 > named VLAN to > the list of allowed egress VLANs for the port. >=20 > This would appear to indicate that the Egress-VLAN-Name attribute is > allowed in Access-Challenge, Access-Reject and Access-Accept packets. > There is no entry in the Attribute Table to confirm this. >=20 > Section 2.4: >=20 > There is no material on permitted usage of the User-Priority-Table=20 > attribute. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Feb 2006 19:32:19 +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: review of draft-ietf-radext-ieee802-01.txt Date: Wed, 1 Feb 2006 14:32:32 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6012318B1@xmb-rtp-20b.amer.cisco.com> Thread-Topic: review of draft-ietf-radext-ieee802-01.txt Thread-Index: AcYkPK+JLc0gb+TPQZeXG0YkaAUN+QDKSl2w From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" , =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, January 28, 2006 1:57 PM > To: radiusext@ops.ietf.org > Subject: RE: review of draft-ietf-radext-ieee802-01.txt >=20 > David Nelson writes: >=20 > >Given the ongoing work on RADIUS Design Guidelines to=20 > encompass additional=20 > >data types and foster greater compatibility with Diameter=20 > AVPs, and the=20 > >charter of the DIME WG, it is not inconceivable to come up=20 > with a single=20 > >"improved" filter > >rule that would make RADIUS-Diameter attribute translation=20 > much easier. > >It would, however, in all likelihood delay this work for many months. > >It seems to me we have to decide which we value more highly: a [more] > >unified data model between RADIUS and Diameter or timely=20 > delivery of the=20 > >802-related extensions in RADIUS. >=20 > I'm not sure we have to choose. We can split the document,=20 > removing the=20 > filter attributes and progressing the rest. From what I can=20 > see, there are=20 > no open issues relating to the VLAN/Priority attributes, so=20 > doing that could=20 > enable the VLAN/Priority document to be sent to the IESG > for review by IETF 65. That sounds like a good idea to me. It also nicely resolves issue #110. Greg > Unless we think that we can resolve the Diameter and Design=20 > Guidelines=20 > issues by the submission deadline for IETF 65, I don't see=20 > what other paths=20 > are available to completing this milestone in a timely way. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Feb 2006 19:28:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Editorial cmts on IEEE802-01 Date: Wed, 1 Feb 2006 14:28:01 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6012318AA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Editorial cmts on IEEE802-01 Thread-Index: AcYnZZ04xuyQotc5RbmXjc1975xfwQ== From: "Greg Weber \(gdweber\)" To: Description of issue: Editorial cmts on IEEE802-01 Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: February 1st, 2006 Reference: NA Document: IEEE802-01 Comment type: 'E'ditorial Priority: '1' Should fix Section: Various Rationale/Explanation of issue and requested changes: Section 1.1 "Authenticator" "an entity that require" -> "an entity that requires" Section 2.2 "Description" "IEEE 802.1Q" -> "[IEEE8021Q]" Section 2.3 "Description"=20 Please use either "VLAN ID" or "VLAN-ID" consistently. Section 2.3 "String" Should "802.1Q-2003" be "[IEEE8021Q]" or is this a new reference? The latter reference is dated January 1998=20 in Section 7.1. Section 2.5 "Description" "NAS-Filter-Rule process packets" -> "NAS-Filter-Rule processes packets" Section 2.5 "Description" There is a reference for HTTP, but not HTTPS. Section 2.5 "Description" "...if multiple NAS-Filter-Rule attributes are contained=20 within an Access-Request or Access-Accept..." -> "...if multiple NAS-Filter-Rule attributes are contained within an Access-Accept or CoA-Request..." Section 2.5 "Description" "flush rules" are mentioned a dozen paragraphs into=20 the section, but they're not explained until way down in the Text section. Shouldn't they be added as a type of rule in the Table after the second paragraph? Section 2.5 "Text" "ipv6-address" "match the rule" -> "match the rule." Section 2.5 "Text" "tcp-port" The text says this field can be used with UDP and SCTP in addition to TCP, so is it supposed to be called "port"? Section 2.5 "Text" "tcpoptions" Do you want Informative references for RFCs 1323 & 1644? Section 2.5 "Text" "redir_cnt" "redir_cnt Specifies" -> "redir_cnt Specifies"=20 Section 3.1 "String" "specify which filter rule the counter value is for." -> "specify for which filter rule the couter is a value." Section 5 "Allocation of seven updates..." -> "Allocation of five updates..." Section 6 "nabled networks" -> "enabled networks" "in message it sends." -> "in messages it sends." Section A.1.2 "(eg. Mobile-IP)" -> "(e.g. Mobile-IP)" Section A.1.4 "and in both directions" -> "Flow in a tunnel in two directions" Section A.1.4 "and an NAS-Filter-Rule" -> "and a NAS-Filter-Rule" "packet(as" -> "packet (as" Section A.2 "the users browser" -> "the user's browser" Section A.2.1 "the RADIUS MAY" -> "the RADIUS server MAY" Section A.2.2 "CoA message" -> "CoA-Request message" (several occurrences) Section A.2.3 "The RADIUS serve can" -> "The RADIUS server can" "in two way." -> "in two ways." Section A.4 "IEEE 8021X environment" -> "IEEE 802.1X environment" "their hotel room" -> "her hotel room" "WiFi is" -> "WiFi and is" Section B Examples #7 & #8 Replace "foo.org" and "goo.org" with domains from RFC 2606. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Feb 2006 08:06:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 102 in ieee802-01 Date: Wed, 1 Feb 2006 09:46:55 +0200 Message-ID: Thread-Topic: Issue 102 in ieee802-01 Thread-Index: AcYhnVKSXpy+gwPCRaCQqthPuIPP0AE+T4awABrvoJA= From: To: , Hi Mauricio, Yes, that looks OK -- but the definition of TEXTDATA also needs to be aligned (it shouldn't include "%"). My proposal: TEXTDATA =3D %x20-21 / %x23-24 / %x26-7E=20 (In other words, exclude double quote '"' and percent sign '%') Best regards, Pasi > -----Original Message----- > From: Sanchez, Mauricio (PNB Roseville) > Sent: 31 January, 2006 20:52 > To: radiusext@ops.ietf.org > Subject: RE: Issue 102 in ieee802-01 >=20 >=20 > Pasi, >=20 > Would the following 'tunnel-id' syntax definition cover your concerns? >=20 > tunnel-id =3D DQUOTE 1*(TEXTDATA /("%" 2HEXDIG)) DQUOTE >=20 > Thanks, > MS=20 >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org=20 > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > > Pasi.Eronen@nokia.com > > Sent: Wednesday, January 25, 2006 2:52 AM > > To: radiusext@ops.ietf.org > > Subject: Issue 102 in ieee802-01 > >=20 > > Hi, > >=20 > > It looks like version -01 of the IEEE attributes draft solved=20 > > my of my comments, but one resolution looks slightly buggy: > >=20 > > The ABNF includes two different ways to quoting "strange"=20 > > octets in tunnel-id (backslashes and percent-hex-hex), but=20 > > the text doesn't quite match the ABNF. > >=20 > > Also, I think we don't need two different quoting mechanisms;=20 > > the percent-hex-hex notation makes the backslashes redundant=20 > > (and is IMHO easier to implement in a way that really works=20 > > with arbitrary octets, such as LF (the rule delimeter!) and NUL). > >=20 > > Best regards, > > Pasi > >=20 > > -- > > to unsubscribe send a message to=20 > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > > a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: