Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Aug 2005 17:02:09 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Cc: radiusext@ops.ietf.org, geopriv@ietf.org Date: Wed, 31 Aug 2005 13:03:00 -0400 Message-Id: <20050831170300.C673516FAB@mail.nitros9.org> "Avi Lior" wrote: > There is a difference because unexptected seems to tie the Challenge to > the authentication method which is not true. PAP & CHAP don't currently use Access-Challenge, which is why I used the term "unexpected". The same NAS may support Access-Challenge for one authentication protocol, but not another. But "unsupported" is the more correct term. > My understanding is a Challenge is an indication that the Server > requires more information. Yes. That makes it the ideal place to put capabilities exchange. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 31 Aug 2005 10:08:48 +0000 Message-ID: <4315819B.7020709@nokia.com> Date: Wed, 31 Aug 2005 13:08:27 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Issue 126: Unresolved NITs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > References > > [I-D.ietf-aaa-diameter-sip-app] is not referenced in the document (except > in the change list) This is actually referred to in Section 1.2. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2005 09:49:28 +0000 Message-ID: <43157D14.3000105@nokia.com> Date: Wed, 31 Aug 2005 12:49:08 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Review of DIGEST-04 document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I checked issues 124 and 125 and they are properly addressed in this new version. /Miguel Bernard Aboba wrote: > A new version of the RADIUS Digest Authentication document is now > available for inspection: > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.txt > > When it shows up on the IETF archive, it will be available here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt > > Please check the specification over carefully. If you have submitted an > issue, please post mail to the RADEXT WG mailing list indicating whether > your issue has been resolved. > > We are asking that RADEXT WG participants complete their final review by > Friday, September 9, 2005. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- to unsubscribe send a message to radiusext-request@ops.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, 31 Aug 2005 08:51:43 +0000 Date: Wed, 31 Aug 2005 01:50:52 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 126: Unresolved NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 126: Unresolved NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 29, 2005 Reference: Document: DIGEST-04 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Section 4.4: possesion -> possession Section 4.14: ie -> i.e. Section 5: Change: TBD User-Name TBD Message-Authenticator To: 1 User-Name 80 Message-Authenticator References [I-D.ietf-aaa-diameter-sip-app] is not referenced in the document (except in the change list) [RFC2616] is not referenced. [RFC1750] is not referenced. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 23:59: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: Review of DIGEST-04 document Date: Tue, 30 Aug 2005 16:59:09 -0700 Message-ID: <16B87DE4F57C21449A34A4F2E25EA763018F3FC6@NAEX05.na.qualcomm.com> Thread-Topic: Review of DIGEST-04 document Thread-Index: AcWteS10CNsBGYZlTpeA62/xrmQIwAAQ3qcw From: "Mahendran, AC" To: "Bernard Aboba" , Wolfgang, thanks for uploading the -04 version. Bernard, as you already know, 3GPP2 is waiting on this draft for the publication of BCMCS specification (X.S0022). I would greatly appreciate if we can progress this draft at the earliest.=20 Thanks for your support. Thanks, -AC 3GPP2-IETF liaison -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, August 30, 2005 8:39 AM To: radiusext@ops.ietf.org Subject: Review of DIGEST-04 document A new version of the RADIUS Digest Authentication document is now=20 available for inspection: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.tx t When it shows up on the IETF archive, it will be available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt Please check the specification over carefully. If you have submitted an issue, please post mail to the RADEXT WG mailing list indicating whether your issue has been resolved. =20 We are asking that RADEXT WG participants complete their final review by Friday, September 9, 2005.=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: -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 22: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: RE: Review of draft-zorn-radius-keywrap-07.txt Date: Tue, 30 Aug 2005 15:28:20 -0700 Message-ID: <4FF84B0BC277FF45AA27FE969DD956A29565C2@xmb-sjc-235.amer.cisco.com> Thread-Topic: RE: Review of draft-zorn-radius-keywrap-07.txt Thread-Index: AcWtsiAj7FUvsM8NRnmHZuD1LkhrOw== From: "Pat Calhoun \(pacalhou\)" To: "Radius Ext Mailing List" >> >> In speaking with Russ Housely on the key-wrap issues, Russ indicated >> >> that it would need to be on an end-to-end basis. >>=20 >> Except that that's not how RADIUS works... > >Right. RADIUS security is between a RADIUS client and server. There are=20 >no other entities involved.=20 Correct. Further, while proxies exist in the RADIUS world, and are mentioned in various drafts, clearly fixing how proxies should work, from transport to security, is a much bigger work item, and one that I would caution the WG to embark on. I believe that for customers that have interest in secure, reliable proxies, then the work in AAA should be used instead. I'd like to thank Bernard on his excellent review and comments. I am encouraged to see that he is positive on the work in progress - this is goodness to the Internet Community, who really needs a more secure key delivery mechanism in RADIUS, while minimizing impact on backward compatibility. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 15:39:41 +0000 Date: Tue, 30 Aug 2005 08:39:10 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Review of DIGEST-04 document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A new version of the RADIUS Digest Authentication document is now available for inspection: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-04.txt When it shows up on the IETF archive, it will be available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-04.txt Please check the specification over carefully. If you have submitted an issue, please post mail to the RADEXT WG mailing list indicating whether your issue has been resolved. We are asking that RADEXT WG participants complete their final review by Friday, September 9, 2005. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 15:30:59 +0000 Date: Tue, 30 Aug 2005 08:30:46 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A simple solution would be that a NAS that knows both the NAS and > user location always sends both (when sending location information). > > (I don't think we need more fine-grained capability negotiation > for this.) I agree that this would work and also agree that capability negotiation is not needed. However, I thought that the idea was not to send any location data by default. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 15:29:50 +0000 Date: Tue, 30 Aug 2005 08:29:32 -0700 (PDT) From: Bernard Aboba To: John Schnizlein cc: Pasi.Eronen@nokia.com, geopriv@ietf.org, radiusext@ops.ietf.org Subject: Re: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The inclusion of the "entity" field reintroduces the problem we had with the > initial draft, which is that no practical mechanism has been identified > through which the NAS would know the location of the host attempting > attachment. Existing access points support user location determination, right? See: http://www.networkworld.com/news/2005/050505-cisco-airespace.html http://www.arubanetworks.com/pdf/rf-location.pdf -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 15:10:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 123/124 Radius Digest requirement to clients Date: Tue, 30 Aug 2005 11:10:16 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032559@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 123/124 Radius Digest requirement to clients Thread-Index: AcWsdBq/qCSSOzgtRA6lC9Bv30bjkgBACsVA From: "Nelson, David" To: "Beck01, Wolfgang" , Cc: I think the proposed language is acceptable. In reading it, I noticed that the draft does not appear to discuss RADIUS Proxy Servers. It talks about HTTP Proxy Servers. With regard to the normative requirements for nonce generation placed on RADIUS Clients and RADIUS Severs, would it be useful to note that the neither the RADIUS Client functionality with in a RADIUS Proxy Server, nor the RADIUS Server functionality contained within a RADIUS Proxy Server are ever expected to generate nonces? That is to say, RADIUS Proxy Servers perform no operation on the nonces other than pass-through.=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, 30 Aug 2005 14:10:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 10:10:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032553@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtaOY7LMGO4hcdSlSbJNxx23/IbgAAJLGAAACHRcA= From: "Nelson, David" To: , Pasi Eronen writes... > This depends on what kind of NASes you're considering. In=20 > PSTN dial-up, determining the host location probably isn't=20 > feasible ... It's probably more accurate to say that in PSTN dial-up it isn't always possible to determine the host location accurately. Technologies such as ANI or Caller-ID provide that information. For the traditional land-line subscriber loop, it is very likely that the host is located within the premises served by the subscriber loop. This is almost always the case with residential customers. It will more often not be the case with commercial customers, who may have centralized outgoing trunk lines that can be accessed from a variety of locations. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 13:56:07 +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: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 16:55:51 +0300 Message-ID: Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtaOY7LMGO4hcdSlSbJNxx23/IbgAAJLGA From: To: , Cc: , John Schnizlein wrote: >=20 > The inclusion of the "entity" field reintroduces the problem > we had with the initial draft, which is that no practical > mechanism has been identified through which the NAS would know > the location of the host attempting attachment. >=20 > Rather than prolong the illusion, it would be better to > eliminate this field and let the location attribute refer to > the location of the NAS. This depends on what kind of NASes you're considering. In PSTN dial-up, determining the host location probably isn't feasible, but there certainly are practical mechanisms for e.g. GSM/GPRS and IEEE 802.11 networks. Although they're not necessarily that=20 widely used, I would not call them an "illusion"... Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Aug 2005 13:47:16 +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: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 16:47:06 +0300 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWtZJNkIHh7ddaFT5aB36CeWz8F0wAAplxA From: To: Cc: , Bernard Aboba wrote: > > It looks like NAS could use this field to describe which location > > it's sending, or send two Location-Information attributes if it=20 > > knows both. >=20 > But the NAS isn't sending location by default. So how does=20 > the RADIUS server that requires a given kind of location indicate=20 > what it needs? Keep in mind that if the RADIUS server REQUIRES=20 > location then it may need to send an Access-Reject.=20 A simple solution would be that a NAS that knows both the NAS and=20 user location always sends both (when sending location information). (I don't think we need more fine-grained capability negotiation=20 for this.) Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 30 Aug 2005 13:43:15 +0000 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0f9b74a77664c73f376e8ee8de98ead1@cisco.com> Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, geopriv@ietf.org, radiusext@ops.ietf.org From: John Schnizlein Subject: Re: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 09:42:45 -0400 To: Bernard Aboba The inclusion of the "entity" field reintroduces the problem we had with the initial draft, which is that no practical mechanism has been identified through which the NAS would know the location of the host attempting attachment. Rather than prolong the illusion, it would be better to eliminate this field and let the location attribute refer to the location of the NAS. John On Aug 30, 2005, at 9:11 AM, Bernard Aboba wrote: >> Are you sure? The Location-Information attribute includes a field >> called "Entity", described as follows >> >> Entity (8 bits): >> Describes which location this attribute refers to: >> (0) describes the location of the user's client device >> (1) describes the location of the AAA client >> >> It looks like NAS could use this field to describe which location >> it's sending, or send two Location-Information attributes if it >> knows both. > > But the NAS isn't sending location by default. So how does the RADIUS > server that requires a given kind of location indicate what it needs? > Keep > in mind that if the RADIUS server REQUIRES location then it may need to > send an Access-Reject. > -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 13:12:03 +0000 Date: Tue, 30 Aug 2005 06:11:49 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Are you sure? The Location-Information attribute includes a field > called "Entity", described as follows > > Entity (8 bits): > Describes which location this attribute refers to: > (0) describes the location of the user's client device > (1) describes the location of the AAA client > > It looks like NAS could use this field to describe which location > it's sending, or send two Location-Information attributes if it > knows both. But the NAS isn't sending location by default. So how does the RADIUS server that requires a given kind of location indicate what it needs? Keep in mind that if the RADIUS server REQUIRES location then it may need to send an Access-Reject. -- to unsubscribe send a message to radiusext-request@ops.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, 30 Aug 2005 12:38:16 +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: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Tue, 30 Aug 2005 15:37:11 +0300 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWq0aSH0yKv60MWTQS1Fihbq8fCXACiR64w From: To: , Cc: Bernard Aboba wrote: > The "server-driven" approach also provides a mechanism to=20 > address RADEXT Issue 27 (Who's Location).=20 >=20 > One of the major problems with the RADIUS-GEOPRIV document is that=20 > it does not support user location determination, only NAS location.=20 Are you sure? The Location-Information attribute includes a field called "Entity", described as follows Entity (8 bits): Describes which location this attribute refers to: (0) describes the location of the user's client device (1) describes the location of the AAA client It looks like NAS could use this field to describe which location it's sending, or send two Location-Information attributes if it=20 knows both. Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 29 Aug 2005 23:54:33 +0000 Date: Mon, 29 Aug 2005 16:53:45 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "Nelson, David" , radiusext@ops.ietf.org Subject: RE: Review of draft-zorn-radius-keywrap-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >> In speaking with Russ Housely on the key-wrap issues, Russ indicated > >> that it would need to be on an end-to-end basis. > > Except that that's not how RADIUS works... Right. RADIUS security is between a RADIUS client and server. There are no other entities involved. > Under that interpretation, though, > I don't think that Kerberos would satisfy the criteria, either: a > Kerberos server has knowledge of lots of keys that are used by various > parties to protect things that are none of the server's business > (e.g., telnet data). With Kerberos, we get around that little problem > by declaring the Kerberos server to be unconditionally trusted. Right. It seems to me that the criteria may be too strict. I'm not sure why a Kerberos server can be "unconditionally trusted" but a RADIUS server would not be. -- to unsubscribe send a message to radiusext-request@ops.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, 29 Aug 2005 23:01:01 +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: Review of draft-zorn-radius-keywrap-07.txt Date: Mon, 29 Aug 2005 16:00:24 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26259E0B59@xmb-sjc-215.amer.cisco.com> Thread-Topic: Review of draft-zorn-radius-keywrap-07.txt Thread-Index: AcWs20E59wp1pCokQRmz/GPlOz6HJAAEDP0g From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , "Nelson, David" Cc: Bernard Aboba <> supposedly scribbled: >> There was a discussion at IETF-63 of whether the key-wrap in the Zorn >> draft was hop-by-hop or end-to-end. The answer was that it could be >> either. The RADEXT session minutes read: "They are passed along the >> path in the way they are set-up - may be hop-by-hop." >>=20 >> In speaking with Russ Housely on the key-wrap issues, Russ indicated >> that it would need to be on an end-to-end basis. Except that that's not how RADIUS works... >>=20 >> BTW, the hop-by-hop key-wrap is also an issue with the key-wrap >> attributes in the Aboba draft. >=20 > Right. Russ Housley has indicated that he will work with Sam Hartman > to=20 > provide a clear statement of requirements. >=20 > End-to-end key management support has been something of a "holy > grail" with the AAA community -- many attempts to find it, but little > in the way of documented success. =20 >=20 > AAA WG worked on Diameter CMS for several years before giving up, and > adopting support for Redirect within Diameter EAP (RFC 4072).=20 > However, I don't believe that it would be viable to retrofit Redirect > functionality within RADIUS.=20 I don't think it would be useful, either, in the absence of the elusive = "ubiquitous PKI". >=20 > IN terms of other alternatives, there was a Kerberos proposal a while > back: > http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt >=20 > There is also work ongoing within Terena on a DNSSEC-based approach: > http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf > http://www.lab.telin.nl/~arjan/pub/radius-dnssec.pdf Unfortunately, the solution proposed by Terena doesn't appear to satisfy = the "Housley Criteria" either -- the number of parties that "have access = to keying material that is not needed to perform their own role" is = reduced but not eliminated (presupposing that one interprets the = appropriate role of key-holders as being just to apply security to (for = example) the 802.11 traffic). Under that interpretation, though, I = don't think that Kerberos would satisfy the criteria, either: a Kerberos = server has knowledge of lots of keys that are used by various parties = for to protect things that are none of the server's business (e.g., = telnet data). With Kerberos, we get around that little problem by = declaring the Kerberos server to be unconditionally trusted. 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, 29 Aug 2005 20:49:06 +0000 Date: Mon, 29 Aug 2005 13:48:03 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Review of draft-zorn-radius-keywrap-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There was a discussion at IETF-63 of whether the key-wrap in the Zorn > draft was hop-by-hop or end-to-end. The answer was that it could be > either. The RADEXT session minutes read: "They are passed along the path > in the way they are set-up - may be hop-by-hop." > > In speaking with Russ Housely on the key-wrap issues, Russ indicated > that it would need to be on an end-to-end basis. > > BTW, the hop-by-hop key-wrap is also an issue with the key-wrap > attributes in the Aboba draft. Right. Russ Housley has indicated that he will work with Sam Hartman to provide a clear statement of requirements. End-to-end key management support has been something of a "holy grail" with the AAA community -- many attempts to find it, but little in the way of documented success. AAA WG worked on Diameter CMS for several years before giving up, and adopting support for Redirect within Diameter EAP (RFC 4072). However, I don't believe that it would be viable to retrofit Redirect functionality within RADIUS. IN terms of other alternatives, there was a Kerberos proposal a while back: http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt There is also work ongoing within Terena on a DNSSEC-based approach: http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf http://www.lab.telin.nl/~arjan/pub/radius-dnssec.pdf -- to unsubscribe send a message to radiusext-request@ops.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, 29 Aug 2005 18:16: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: Review of draft-zorn-radius-keywrap-07.txt Date: Mon, 29 Aug 2005 14:15:01 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032551@MAANDMBX2.ets.enterasys.com> Thread-Topic: Review of draft-zorn-radius-keywrap-07.txt Thread-Index: AcWroqdAJlY71XvUQK++bfovpwFhHwBIVq1A From: "Nelson, David" To: > Just like existing RADIUS shared secrets, the KEK and MAC Key are > hop-by-hop secrets. It seems to me that hop-by-hop protection of encryption keys potentially violates the following requirement of the Housely Criteria: Limit key scope Follow the principle of least privilege. Parties MUST NOT have access to keying material that is not needed to perform their own role. A party has access to a particular key if it has access to all of the secret information needed to derive it. And possibly this requirement, as well: Authenticate all parties Each party in the AAA key management protocol MUST be authenticated to the other parties with whom it communicates. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process. There was a discussion at IETF-63 of whether the key-wrap in the Zorn draft was hop-by-hop or end-to-end. The answer was that it could be either. The RADEXT session minutes read: "They are passed along the path in the way they are set-up - may be hop-by-hop." In speaking with Russ Housely on the key-wrap issues, Russ indicated that it would need to be on an end-to-end basis. BTW, the hop-by-hop key-wrap is also an issue with the key-wrap attributes in the Aboba draft. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 29 Aug 2005 08:31:39 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121E68@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: Miguel.An.Garcia@nokia.com Subject: Issue 123/124 Radius Digest requirement to clients Date: Mon, 29 Aug 2005 10:31:12 +0200 MIME-Version: 1.0 Content-Type: text/plain Proposal: Section 1.3 Overview [..] The nonces required by the digest algorithm are either generated by the RADIUS client or by the RADIUS server. A mix of nonce generation modes is not supported. This specification assumes that both the RADIUS client and server are appropriately configured to generate the nonces in either the RADIUS client or the RADIUS server, but not in both at the same time. Implementations, though, do not have the means to verify this behavior. New Section 2: 2. Interoperability An implementation supporting this extension MUST include a Digest- Response attribute within an Access-Request packet where Digest Authentication is desired. An Access-Request MUST NOT contain both a Digest-Response attribute and another authentication attribute, such as User-Password, CHAP-Password, or EAP-Message. RADIUS clients and servers MUST support both nonce generation modes. As there is no automatic capability exchange, the operator MUST make sure that the RADIUS client software uses the correct nonce generation mode when accessing a specific RADIUS server: o If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. o If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. o If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. RADIUS implementations MUST offer respective configuration options. (Section 2 removes also normative language from the overview section) 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: Sun, 28 Aug 2005 07:32:11 +0000 Date: Sun, 28 Aug 2005 00:31:33 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Review of draft-zorn-radius-keywrap-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Having looked at draft-zorn-radius-keywrap-07.txt, in general I think that the proposal is quite ingenious. If it I understand it correctly, the proposal addresses many of the weaknesses of MD5 usage in RADIUS while still enabling support for backward compatibility. It can therefore be introduced on a NAS and RADIUS server without requiring changes to RADIUS proxies, or on a RADIUS server but not all NAS devices. Of course, to address all the MD5 vulnerabilities all RADIUS clients and servers need to be upgraded eventually, but the transition can be graceful. However, since I may not fully grasp the proposal, I thought I'd summarize the main aspects as I understand it: a. If I read the document correctly, it is possible for an implementation to compute all the Request and Response authenticators based on a RADIUS shared secret, *exactly* as it is done today. As a result, the proposal is compatible with legacy RADIUS proxies and servers. In addition to a legacy shared secret, the proposal also creates additional shared secrets, namely the Key Encryption Key (KEK) and the MAC Key. These additional shared secrets are presumably independent of the RADIUS shared secret so that if the RADIUS shared secret is compromised, an attacker will still be unable to forge messages or decrypt the wrapped key. Just like existing RADIUS shared secrets, the KEK and MAC Key are hop-by-hop secrets. b. The document also includes definition of a new Message-Authentication-Code attribute, which is a MAC calculated over the RADIUS packet in a manner similar to the existing Message-Authenticator attribute, albeit using the new MAC key and more secure MAC algorithms, such as HMAC-SHA-1 and HMAC-SHA-256. To maintain backward compatibility, this attribute can be added to a RADIUS packet in addition to the existing Message-Authenticator attribute, which is required by RFC 3579 and the Digest Authentication document. A RADIUS server can tell whether a RADIUS client supports this new attribute by the presence of the attribute in an Access-Request, so that a server need not send the attribute to a RADIUS client that does not support it. Since the RADIUS client can compute *both* the Message-Authenticator and the new Message-Authentication-Code attribute, it need not worry about whether the RADIUS server supports the new attribute or not; it can just send both attributes. c. The document includes definition of a Random-Nonce attribute, which among other things can be used to address the replay protection problems that exist in Accounting-Request, CoA-Request and Disconnect-Request messsages. Since these messages do not include a Nonce in the Request Authenticator field, in existing usage there is a danger of replay. While the issue is handled for Accounting-Request messages by checking for duplication of Acct-Session-ID values in the billing engine, RFC 3576 relies on inclusion of the Event-Timestamp attribute in CoA-Request and Disconnect-Request messages. This requires RADIUS clients and servers to implement time synchronization, which may be inconvenient. As a result, it seems to me that the Random-Nonce attribute has general utility. However, on reading the proposal, I did have some questions: d. If the KEK and MAC Key are hop-by-hop secrets, are they similar to the existing RADIUS shared secret in that there can only be one secret between a given (client IP address, server IP address) pair? If so, then I don't understand the need for the MAC Key ID field in the Message-Authentication-Code attribute, or the Key-ID, KEK-ID and App-ID fields in the Key attribute. After all, the existing RADIUS shared secret does not need a key name because this is implicit in the source and destination addresses within the RADIUS packet. e. As described in IEEE 802.11i and the EAP Key Framework document, the lifetime of EAP keying material is determined by the Session-Time attribute. As a result, what is the purpose of the Lifetime field within the Key attribute? f. Since it is possible to mount an offline dictionary attack on the KEK and MAC Key just as with the existing RADIUS shared secret, presumably the KEK and MAC Key are not derived from a passphrase and users need to take care to maintain proper hygene (e.g. keys should be unique for each RADIUS client/server pair, minimum entropy is required. etc.), 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: Sun, 28 Aug 2005 04:11:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AB86.A7597EEE" Subject: RE: Review of draft-lior-radext-end-to-end-caps-01.txt Date: Sun, 28 Aug 2005 00:12:07 -0400 Message-ID: Thread-Topic: Review of draft-lior-radext-end-to-end-caps-01.txt Thread-Index: AcWrUXd55jfK4RlvT8aVn+wJp78FDAAMQ5Fw From: "Avi Lior" To: "Majdi Badarin" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AB86.A7597EEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Majdi =20 Thanx for the comments please see inline. ________________________________ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Majdi Badarin Sent: Saturday, August 27, 2005 5:51 PM To: radiusext@ops.ietf.org Subject: Review of draft-lior-radext-end-to-end-caps-01.txt =09 =09 I object to taking on the End-to-End Capabilities document as a RADEXT WG=20 work item. The document doesn't properly define the problem and the proposed solution =20 is excessively complex and is not compatible with existing mechanisms in Diameter.=20 =20 [Avi] The problem statement was discussed over the list and presented at IETF. As well there are some drafts that have indepementatly introduced a capability exchange. This is an attempt to try to get one consistant approach to solve the problem. =09 When adding new features, the RADEXT WG needs to try and maintain the simplicity of=20 RADIUS as I believe that this has accounted for much of its success. Questions=20 like "is this feature necessary at all?" And "can this feature be done in a simple way?"=20 should be answered first. =20 =09 [Avi] I agree that RADIUS as a Dialup AAA server is simple. But RADIUS has been evolving. The addition of EAP. Support for dynamic operations 3576. The evolution of RADIUS is necessary as it is being asked to be involved in more complex deployements. RADIUS is a simple protocol, and has existed without capability negotiation since its=20 inception. A very good case has to be made for adding this capability at this time,=20 especially in the complex manner that's being proposed. The document does not=20 make the case for the major changes it is proposing. In fact, many of the problems=20 it defines do not exist and many of the features it attempts to add duplicate existing=20 RADIUS functionality. =20 As a result, I believe that the WG should discard the End-to-End Capabilities document,=20 since its approach is so inherently complex and flawed that it cannot be fixed by=20 accepting the document as a WG work item. =20 A couple of specific problems, in addition to the unconvincing motivation are:=20 * The alternative mechanisms for detecting RFC 3576 support, something that=20 is already handled in RFC 3576.=20 [Avi] Very inefficiently. We have to try to disconnect or perform a change of authorization before we can learn that whether or not a NAS supports 3576. In deployments where you have millions of subscribers the facilities provided by 3576 are not usable. This is why for example 3GPP2 developed a capbility exchange specifically for determining whether a NAS support this capability or not,=20 * The use of capabilities negotiation for optional attributes. RADIUS implementations=20 have handled optional attributes for years, so this is unnecessary. [Avi] I dont think so. A NAS will ignore attirbutes that it does not support. Therefore for example in prepaid, when the server sends prepaid attributes to the NAS that are going to control the session, if the NAS ignores the attributes the prepaid user will be given unlimited access. =20 * Retroactive changes to the behaviour of existing RADIUS implementations.=20 [Avi] As long as we maintain backwards compatibility then I belive that we are okay. With a capability exchange the Server can detect that it is potentially dealing with an old NAS and apply its policies accordingly. Without a capability exchange we are blind.=20 * Creation of a registry for Capability IDs, including capabilities that don't=20 exist in RADIUS RFCs. =20 [Avi] We should only have a registry of capabilities that are supported by RFCs. This will cause interoperability problems -=20 RADIUS requires that VSAs be treated as optional so as to allow interoperability=20 between vendor implementations.=20 [Avi] I think SDOs that define VSAs should use the same scheme as proposed but they should maintian their own registry.=20 * Incompatibility with the Diameter optional/mandatory attribute marking. =20 The document doesn't even have a Diameter compatibility section. [Avi] We can add something to this document and perhaps write a Diameter version. Diameter also suffers from this problem btw. Diameter has serious problems which is to be expected for a new AAA protocol.=20 I can go on to list all the objections to this document, all the unnecessarily=20 functionality, the confused problem statement, etc. But that is hardly necessary;=20 other participants in the WG have already stated those objections during previous=20 discussions, more eloquently than I can. In fact, looking back at previous=20 RADEXT WG discussion which started in January 2005, it appears that many of=20 these issues were brought up before. Looking back at the discussion, it appears=20 that WG consensus previously existed to adopt an alternative (simpler) approach. =20 So why is it being brought back again?=20 [Avi] Because other works have required some of the approaches taken here. Look this document is a starting point. Lets make this a working group document and then we can shape it so that it makes sense. But as you noted first and foremost we need a capability exchange mechanism. What we should debate is what it looks like.=20 I have to wonder "How can this document even be considered as a WG work item=20 given the volume and seriousness of the criticisms that have been leveled=20 against it?"=20 =20 [Avi] I wish you wouldnt missrepresent the wishes of the group. At the last IETF there were no objections for having a capability excange. =20 And how can the RADEXT WG be bringing to WG last call=20 documents that have so many problems, such as the VLAN and Filters draft?=20 In its consideration of new WG items, the RADEXT WG seems to be asking the=20 wrong questions. The right question isn't "Are there any objections?"=20 but rather "Is there WG consensus that this document is an appropriate solution=20 to a real problem, and are there a significant base of vendors who consider this=20 functionality necessary and who will implement it?"=20 =20 ------_=_NextPart_001_01C5AB86.A7597EEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Majdi
 
Thanx for the comments please see=20 inline.

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Majdi=20 Badarin
Sent: Saturday, August 27, 2005 5:51 = PM
To:=20 radiusext@ops.ietf.org
Subject: Review of=20 draft-lior-radext-end-to-end-caps-01.txt

I object to taking on the = End-to-End=20 Capabilities document as a RADEXT WG
work item. The document = doesn’t=20 properly define the problem and the proposed solution 
is = excessively=20 complex and is not compatible with existing mechanisms in=20 Diameter. 
 

[Avi] The problem statement was=20 discussed over the list and presented at = IETF.  As=20 well there are some drafts that have indepementatly = introduced a=20 capability exchange.  This is an attempt to try to get one = consistant=20 approach to solve the problem.


When adding new features, the RADEXT WG needs to try and = maintain=20 the simplicity of
RADIUS as I believe that this has accounted for = much of=20 its success.  Questions
like “is this feature necessary = at=20 all?"  And “can this feature be done in a simple = way?”
should be=20 answered first. 


[Avi] I agree = that RADIUS as=20 a Dialup AAA server is simple.  But RADIUS has been = evolving.  The=20 addition of EAP.  Support for dynamic operations 3576.  The=20 evolution of RADIUS is necessary as it is being asked to be involved = in more=20 complex deployements.

 RADIUS is a simple protocol, = and has=20 existed without capability negotiation since its
inception.=20 A = very good=20 case has to be made for adding this capability at this time, =
especially in=20 the complex manner that’s being proposed.   The = document does not=20
make the case for the major changes it is proposing.  In = fact, many=20 of the problems
it defines do not exist and many of the features = it=20 attempts to add duplicate existing
RADIUS = functionality.  

As a result, I believe that the WG = should discard=20 the End-to-End Capabilities document,
since its approach is so = inherently=20 complex and flawed that it cannot be fixed by
accepting the = document as a=20 WG work item. 

A couple of specific problems, in = addition to the=20 unconvincing motivation are:

* The alternative mechanisms for = detecting=20 RFC 3576 support, something that
is already handled in RFC 3576. =
[Avi] Very=20 inefficiently.  We have to try to disconnect or perform a = change of=20 authorization before we can learn that whether or not a NAS = supports=20 3576.  In deployments where you have millions of=20 subscribers the facilities provided by 3576 are not = usable. =20 This is why for example 3GPP2 developed a capbility exchange=20 specifically for determining whether a NAS support this = capability or=20 not, 

* The use of capabilities negotiation = for optional=20 attributes.  RADIUS implementations
have handled optional = attributes=20 for years, so this is unnecessary.
[Avi] I dont think so.  A NAS will = ignore=20 attirbutes that it does not support.  Therefore for example = in=20 prepaid, when the server sends prepaid attributes to the = NAS that=20 are going to control the session, if the NAS ignores=20 the attributes the prepaid user will be given unlimited = access. 

* Retroactive changes to the = behaviour of=20 existing RADIUS implementations.
[Avi] As long as we maintain backwards = compatibility=20 then I belive that we are okay.  With a capability = exchange the=20 Server can detect that it is potentially dealing with an old NAS = and=20 apply its policies accordingly.  Without a capability exchange we = are=20 blind. 

* Creation of a registry for Capability = IDs,=20 including capabilities that don't
exist in RADIUS RFCs.  =
[Avi] We should = only have a=20 registry of capabilities that are supported  by=20 RFCs.

 This will cause = interoperability=20 problems -
RADIUS requires that VSAs be treated as optional so as = to allow=20 interoperability
between vendor implementations.
[Avi] I think SDOs that=20 define VSAs should use the same scheme as proposed but they=20 should maintian their own=20 registry. 

* Incompatibility with the = Diameter=20 optional/mandatory attribute marking. 
The document doesn't = even have=20 a Diameter compatibility section.
[Avi] We can add something to this document and = perhaps=20 write a Diameter version.  Diameter also suffers from this = problem=20 btw.  Diameter has serious problems which is to be = expected for a new AAA protocol. 

I can go on to list all the = objections to=20 this document, all the unnecessarily
functionality, the confused = problem=20 statement, etc.  But that is hardly necessary;
other = participants in=20 the WG have already stated those objections during previous =
discussions,=20 more eloquently than I can.  In fact, looking back at previous =
RADEXT=20 WG discussion which started in January 2005, it appears that many of =
these=20 issues were brought up before. Looking back at the discussion, it = appears=20
that WG consensus previously existed to adopt an alternative = (simpler)=20 approach. 
So why is it being brought back again?
[Avi]  Because = other works=20 have required some of the approaches taken here.  Look this = document is a=20 starting point.  Lets make this a working group document and then = we can=20 shape it so that it makes sense.  But as you noted first and = foremost we need a capability exchange mechanism.  What = we should=20 debate is what it looks like. 

I have to wonder "How can this = document even=20 be considered as a WG work item
given the volume and seriousness = of the=20 criticisms that have been leveled
 against = it?" 
 
[Avi] I wish you = wouldnt=20 missrepresent the wishes of the group.  At the last IETF = there were no=20 objections for having a capability excange. =20

 And how=20 can the RADEXT WG be bringing to WG last call
documents that have = so many=20 problems, such as the VLAN and Filters draft?

In its consideration of new WG = items, the=20 RADEXT WG seems to be asking the
wrong questions.  The right = question=20 isn't "Are there any objections?"
but rather "Is there WG = consensus that=20 this document is an appropriate solution
to a real problem, and = are there=20 a significant base of vendors who consider this
functionality = necessary=20 and who will implement it?" 
 

------_=_NextPart_001_01C5AB86.A7597EEE-- -- to unsubscribe send a message to radiusext-request@ops.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, 28 Aug 2005 03:40: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: RE: Capabilities negotiation problem statement Date: Sat, 27 Aug 2005 23:40:33 -0400 Message-ID: Thread-Topic: Capabilities negotiation problem statement Thread-Index: AcWq+ojYDAqutJVTTy2n73XDsBgwGwAhGUwg From: "Avi Lior" To: "Bernard Aboba" , Hi Bernard, Please see inline...=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, August 27, 2005 7:27 AM > To: radiusext@ops.ietf.org > Subject: RE: Capabilities negotiation problem statement >=20 > > 3GPP2 for example use advertisement for: > > Prepaid - Before we push down a Prepaid policy we need to=20 > know whether=20 > > the NAS supports that policy. Otherwise the NAS will ignore the=20 > > policy and allow the session to continue. As you can see this is a=20 > > serious problem. >=20 > This case sounds the same as the security issue with filter=20 > rules. That is, the RADIUS server needs to send an attribute=20 > that cannot be safely ignored by the NAS.=20 >=20 > > Dynamic Auth - we need to understand whether a NAS supports=20 > 3576 for=20 > > correct operation. >=20 > RFC 3576 already specifies how a RADIUS server can determine=20 > if a NAS supports it. Where the RADIUS client does not=20 > support RFC 3576, the server will receive an ICMP port=20 > unreachable message in reply to a Disconnect or CoA-Request. =20 > If the proxy supports RFC 3576, but the NAS does not, then=20 > the proxy replies with an Error-Cause value of "Unsupported > Extension": >=20 > "Unsupported Extension" is a fatal error sent due to lack=20 > of support > for an extension such as Disconnect and/or CoA messages. This will > typically be sent by a proxy receiving an ICMP port unreachable > message after attempting to forward a Request to the NAS. I am aware of that but this is inefficient! It requires that we send a message and try. It is more efficient if we know up front via a capability indication. =20 > > Sure for simple deployement scenarios like Dial up. But now we are=20 > > talking about more sophisticated usage for RADIUS. >=20 > The existing RADIUS mechanisms work for all services. They=20 > are not just for "dialup".=20 In some cases they don't work at all and in other cases they work but not efficiently. =20 > > But this is not efficient. Why send an attribute or a set of=20 > > attributes if they are not required by the Server? >=20 > RADIUS is a request/response protocol. There is no way for a=20 > NAS to know what the RADIUS server requires before sending an=20 > Access-Request. =20 But in subsequent interaction for that session -- either in accounting or in subsequent requests or in issuing commands such as proposed by LOG OFF then the Server can indicate what it may desire. =20 > > For one I need to be assured that the NAS supports the mandatory=20 > > semantics. >=20 > That's relatively simple though -- a NAS can signal support=20 > for the extended format with a single attribute.=20 Ahhhhh so you do support a capability exchange!!! I thought you didn't. So we have at least one. =20 > > I may support NAS Filter Rule but only some of its options. >=20 > To date, RADIUS documents have focused on a single subject=20 > and included clear guidelines about what is needed to be=20 > considered compliant. =20 Not true. Is 2865 focused? Is 2869 focused? I would even argue that 3576 presents two different capabilities, DM and COA Each may be supported independantly. > As an example, RFC 2868 is focused on=20 > tunnel attributes, so that a vendor can indicate that they=20 > are compliant with it, without being forced to implement=20 > attributes relating to a different capability.=20 Ideally sure but in some cases it is not possible to split a complex AAA application into smaller RFCs just to stay true to that ideal. =20 Diameter CC is a perfect example of that. Not all the features will be implemented by a given vendor or even be ever be implmented by anyone. > Similarly, existing RADIUS attributes are typically either=20 > implemented or not implemented. If an attribute covers=20 > divergent capabilities so that vendors are unlikely to fully=20 > implement it within a single device, I would argue that that=20 > attribute should be broken down into distinct attributes,=20 > each with a unitanry purpose. You mean like user-name? Perhaps let user-name carry the actual user name and have another attribute carry the routing information? I would agree. >=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: Sun, 28 Aug 2005 03:15: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: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 27 Aug 2005 23:13:57 -0400 Message-ID: Thread-Topic: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWq9f/r8tIwRk9USnWnCYobwlxEDAAhxoyQ From: "Avi Lior" To: "Bernard Aboba" , Cc: , "Alan DeKok" Hi Bernard, =20 > -----Original Message----- > From: geopriv-bounces@ietf.org=20 > [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, August 27, 2005 6:55 AM > To: radiusext@ops.ietf.org > Cc: geopriv@ietf.org; Alan DeKok > Subject: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt >=20 > > And blindly requesting for location information (as you=20 > propose) I run=20 > > the risk of having a rejection by getting to a NAS that does not=20 > > support Challenge in the first place. >=20 > The only reason a RADIUS server will need to send an=20 > Access-Challenge is if it *requires* location and it is not=20 > present. In that case, the RADIUS server cannot allow access=20 > if location isn't provided. =20 Not true at all! A RADIUS server may require to get location but if it does not that does not mean that its only action is to reject the session. It may still grant access but the access could be limited in scope. I can have a policy that states the service X may only provided at a certain location. I request for the location and if it is not provided then I grant access but do not grant access to service X. Blindly challenging the NAS -- requesting location without even knowing whether the NAS even supports a challenge let alone location information -- runs the risk of outright rejection of the session. > If the RADIUS server doesn't require location, then it can=20 > just request location in the Access-Accept. If it gets it,=20 > great. If not, it is willing to live with out it.=20 You mean for accounting purposes. I am not even talking about that. Above I am talking about needing location as part of the policy decision function for granting access. =20 > In either case (mandatory or optional), capability=20 > advertisement by the NAS is irrelevant.=20 I disagree. There is a distinct advantage of letting the RADIUS server know whether or not the NAS supports a particular function. Blindly challenging should only be done in cases where the NAS does not support a capability exchange mechanism. =20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=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: Sat, 27 Aug 2005 21:52:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AB51.778F382C" Subject: Review of draft-lior-radext-end-to-end-caps-01.txt Date: Sat, 27 Aug 2005 14:51:23 -0700 Message-ID: <3DE4493916EF824DB1CD4AA4064485130760ED78@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Review of draft-lior-radext-end-to-end-caps-01.txt thread-index: AcWrUXd55jfK4RlvT8aVn+wJp78FDA== From: "Majdi Badarin" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AB51.778F382C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I object to taking on the End-to-End Capabilities document as a RADEXT = WG=20 work item. The document doesn't properly define the problem and the = proposed solution =20 is excessively complex and is not compatible with existing mechanisms in = Diameter.=20 =20 When adding new features, the RADEXT WG needs to try and maintain the = simplicity of=20 RADIUS as I believe that this has accounted for much of its success. = Questions=20 like "is this feature necessary at all?" And "can this feature be done = in a simple way?"=20 should be answered first. =20 RADIUS is a simple protocol, and has existed without capability = negotiation since its=20 inception. A very good case has to be made for adding this capability at = this time,=20 especially in the complex manner that's being proposed. The document = does not=20 make the case for the major changes it is proposing. In fact, many of = the problems=20 it defines do not exist and many of the features it attempts to add = duplicate existing=20 RADIUS functionality.=20 As a result, I believe that the WG should discard the End-to-End = Capabilities document,=20 since its approach is so inherently complex and flawed that it cannot be = fixed by=20 accepting the document as a WG work item. =20 A couple of specific problems, in addition to the unconvincing = motivation are:=20 * The alternative mechanisms for detecting RFC 3576 support, something = that=20 is already handled in RFC 3576.=20 * The use of capabilities negotiation for optional attributes. RADIUS = implementations=20 have handled optional attributes for years, so this is unnecessary.=20 * Retroactive changes to the behaviour of existing RADIUS = implementations.=20 * Creation of a registry for Capability IDs, including capabilities that = don't=20 exist in RADIUS RFCs. This will cause interoperability problems -=20 RADIUS requires that VSAs be treated as optional so as to allow = interoperability=20 between vendor implementations.=20 * Incompatibility with the Diameter optional/mandatory attribute = marking. =20 The document doesn't even have a Diameter compatibility section.=20 I can go on to list all the objections to this document, all the = unnecessarily=20 functionality, the confused problem statement, etc. But that is hardly = necessary;=20 other participants in the WG have already stated those objections during = previous=20 discussions, more eloquently than I can. In fact, looking back at = previous=20 RADEXT WG discussion which started in January 2005, it appears that many = of=20 these issues were brought up before. Looking back at the discussion, it = appears=20 that WG consensus previously existed to adopt an alternative (simpler) = approach. =20 So why is it being brought back again?=20 I have to wonder "How can this document even be considered as a WG work = item=20 given the volume and seriousness of the criticisms that have been = leveled=20 against it?" And how can the RADEXT WG be bringing to WG last call=20 documents that have so many problems, such as the VLAN and Filters = draft?=20 In its consideration of new WG items, the RADEXT WG seems to be asking = the=20 wrong questions. The right question isn't "Are there any objections?"=20 but rather "Is there WG consensus that this document is an appropriate = solution=20 to a real problem, and are there a significant base of vendors who = consider this=20 functionality necessary and who will implement it?"=20 ------_=_NextPart_001_01C5AB51.778F382C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A=

I object to taking on the End-to-End Capabilities = document as a =0A= RADEXT WG
work item. The document = doesn’t properly =0A= define the problem and the proposed solution 
is =0A= excessively complex and is not compatible with existing mechanisms in = Diameter. =0A=
 
When adding = new features, =0A= the RADEXT WG needs to try and maintain the simplicity of =
RADIUS as I believe that this has accounted for much of its =0A= success.  Questions
like “is this = feature necessary =0A= at all?"  And “can this feature be done in a simple = way?”
should be answered first. 

=0A=

RADIUS is a simple protocol, and has existed without = capability =0A= negotiation since its
inception. A very good = case has to =0A= be made for adding this capability at this time,
especially in the complex manner that’s being = proposed.   The =0A= document does not
make the case for the major = changes it =0A= is proposing.  In fact, many of the problems
it =0A= defines do not exist and many of the features it attempts to add = duplicate =0A= existing
RADIUS functionality.

=0A=

As a result, I believe that the WG should discard the = End-to-End =0A= Capabilities document,
since its approach is = so =0A= inherently complex and flawed that it cannot be fixed by =
accepting the document as a WG work item. 

=0A=

A couple of specific problems, in addition to the = unconvincing =0A= motivation are:

=0A=

* The alternative mechanisms for detecting RFC 3576 = support, =0A= something that
is already handled in RFC 3576. =0A=

=0A=

* The use of capabilities negotiation for optional =0A= attributes.  RADIUS implementations
have = handled =0A= optional attributes for years, so this is unnecessary.

=0A=

* Retroactive changes to the behaviour of existing = RADIUS =0A= implementations.

=0A=

* Creation of a registry for Capability IDs, including =0A= capabilities that don't
exist in RADIUS = RFCs.  This =0A= will cause interoperability problems -
RADIUS = requires =0A= that VSAs be treated as optional so as to allow interoperability =0A=
between vendor implementations.

=0A=

* Incompatibility with the Diameter optional/mandatory = attribute =0A= marking. 
The document doesn't even have = a Diameter =0A= compatibility section.

=0A=

I can go on to list all the objections to this = document, all the =0A= unnecessarily
functionality, the confused = problem =0A= statement, etc.  But that is hardly necessary;
other participants in the WG have already stated those = objections during =0A= previous
discussions, more eloquently than I = can.  =0A= In fact, looking back at previous
RADEXT WG = discussion =0A= which started in January 2005, it appears that many of
these issues were brought up before. Looking back at the = discussion, it =0A= appears
that WG consensus previously existed = to adopt an =0A= alternative (simpler) approach. 
So why = is it being =0A= brought back again?

=0A=

I have to wonder "How can this document even be = considered as a =0A= WG work item
given the volume and seriousness = of the =0A= criticisms that have been leveled
 against it?" And =0A= how can the RADEXT WG be bringing to WG last call
documents that have so many problems, such as the VLAN and = Filters =0A= draft?

=0A=

In its consideration of new WG items, the RADEXT WG = seems to be =0A= asking the
wrong questions.  The right = question =0A= isn't "Are there any objections?"
but rather = "Is there =0A= WG consensus that this document is an appropriate solution =
to a real problem, and are there a significant base of vendors = who =0A= consider this
functionality necessary and who = will =0A= implement it?"

------_=_NextPart_001_01C5AB51.778F382C-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 11:27:09 +0000 Date: Sat, 27 Aug 2005 04:26:58 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RE: Capabilities negotiation problem statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 3GPP2 for example use advertisement for: > Prepaid - Before we push down a Prepaid policy we need to know whether > the NAS supports that policy. Otherwise the NAS will ignore the policy > and allow the session to continue. As you can see this is a serious > problem. This case sounds the same as the security issue with filter rules. That is, the RADIUS server needs to send an attribute that cannot be safely ignored by the NAS. > Dynamic Auth - we need to understand whether a NAS supports 3576 for > correct operation. RFC 3576 already specifies how a RADIUS server can determine if a NAS supports it. Where the RADIUS client does not support RFC 3576, the server will receive an ICMP port unreachable message in reply to a Disconnect or CoA-Request. If the proxy supports RFC 3576, but the NAS does not, then the proxy replies with an Error-Cause value of "Unsupported Extension": "Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS. > Sure for simple deployement scenarios like Dial up. But now we are > talking about more sophisticated usage for RADIUS. The existing RADIUS mechanisms work for all services. They are not just for "dialup". > But this is not efficient. Why send an attribute or a set of attributes > if they are not required by the Server? RADIUS is a request/response protocol. There is no way for a NAS to know what the RADIUS server requires before sending an Access-Request. > For one I need to be assured that the NAS supports the mandatory > semantics. That's relatively simple though -- a NAS can signal support for the extended format with a single attribute. > I may support NAS Filter Rule but only some of its options. To date, RADIUS documents have focused on a single subject and included clear guidelines about what is needed to be considered compliant. As an example, RFC 2868 is focused on tunnel attributes, so that a vendor can indicate that they are compliant with it, without being forced to implement attributes relating to a different capability. Similarly, existing RADIUS attributes are typically either implemented or not implemented. If an attribute covers divergent capabilities so that vendors are unlikely to fully implement it within a single device, I would argue that that attribute should be broken down into distinct attributes, each with a unitary purpose. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 10:56:43 +0000 Date: Sat, 27 Aug 2005 03:54:56 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org cc: Alan DeKok , geopriv@ietf.org Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > And blindly requesting for location information (as you propose) I run > the risk of having a rejection by getting to a NAS that does not support > Challenge in the first place. The only reason a RADIUS server will need to send an Access-Challenge is if it *requires* location and it is not present. In that case, the RADIUS server cannot allow access if location isn't provided. If the RADIUS server doesn't require location, then it can just request location in the Access-Accept. If it gets it, great. If not, it is willing to live with out it. In either case (mandatory or optional), capability advertisement by the NAS is irrelevant. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 07:25: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: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 27 Aug 2005 03:26:11 -0400 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWqzpd+lXe9f+03Sw60ZGDf/BpHNgACRN8A From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" Cc: , Hi Bernard, =20 Bernard wrote: > Based on this discussion, I think it is even simpler than I=20 > had thought -- Access-Challenge, Error-Cause and a "send=20 > location" attribute appear to solve the problem with no need=20 > for any capability advertisements.=20 I still think you are missing something. I still need to know whether the capability is supported. It may impact my policy decision. I may have a policy that allows certain services to be provided only if location is provided. Knowing that a NAS cant support location allows me to send an Accept with only those services that do not require location information to be provided.=20 And blindly requesting for location information (as you propose) I run the risk of having a rejection by getting to a NAS that does not support Challenge in the first place.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, August 27, 2005 2:13 AM > To: Alan DeKok > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt >=20 > > Can there be multiple Error-Causes? That would seem to=20 > be efficient. >=20 > Off the top of my head, I don't see why not. RFC 3576 allows=20 > 0+ Error-Cause attributes in a NAK, so I'd assume that it=20 > also would be allowed in an Access-Challenge or Access-Reject.=20 >=20 > > An Access-Request MAY be responded to with an Access-Challenge=20 > > containing Error-Cause, For authentication methods that normally=20 > > expect request/ack, receipt of an Access-Challenge would=20 > indicate that=20 > > they add the relevant data, and re-send the Access-Request without=20 > > prompting the user for more information. >=20 > Where an Access-Challenge is expected, this works. Where it=20 > is unexpected, RFC 2865 Section 4.4 requires that the NAS=20 > treat the Access-Challenge as an Access-Reject.=20 >=20 > > That requirement would make it clear that the NAS *does* have to=20 > > maintain state, but that it does not have to tell the user=20 > about the=20 > > re-authentication. >=20 > I think that it's possible to make this work without changing=20 > existing Access-Challenge behavior. If an Access-Challenge=20 > would be sent anyway, a "send location" attribute can be=20 > piggybacked on it. If it is unexpected, the Access-Challenge=20 > will be treated as an Access-Reject and re-authentication=20 > will be required.=20 >=20 > > > Am I missing something, or is the problem really this simple?=20 > >=20 > > It would appear so. >=20 =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: Sat, 27 Aug 2005 07:17:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 27 Aug 2005 03:17:58 -0400 Message-ID: Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWqyciZ/4YopNpuTLa7cvl5VK2vLQADPcaw From: "Avi Lior" To: "Alan DeKok" , "Bernard Aboba" Cc: , Hi Alan, Just one nit. You said: > For non-location-aware NASes, the RFC's already require=20 > implementations to treat unexpected Access-Challenges as=20 > Access-Rejects, so this idea would appear to be fail-safe there, too. It not unexpected Access-Challenges but rather unsupported Access-Challenge. Section 4.4 of RFC 2865 states: " If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead." There is a difference because unexptected seems to tie the Challenge to the authentication method which is not true. My understanding is a Challenge is an indication that the Server requires more information. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Saturday, August 27, 2005 1:40 AM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt >=20 > Bernard Aboba wrote: > > If the RADIUS authentication mechanism doesn't already utilize an=20 > > Access-Challenge, this will not work. >=20 > On the other hand, if the NAS is updated to include=20 > location information, it may be acceptable to add additional=20 > requirements such as this. Yes. The scenario in Geopriv would imply that a NAS stating suppot for Location is expected to receive a Challenge by a server requiring location information. But we can be more clear about 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: Sat, 27 Aug 2005 07:07: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: Capabilities negotiation problem statement Date: Sat, 27 Aug 2005 03:07:47 -0400 Message-ID: Thread-Topic: Capabilities negotiation problem statement Thread-Index: AcWqYxAmD1GxKO4mQBuK5KrbLSpaCAAbsupQ From: "Avi Lior" To: "Bernard Aboba" , Hi Bernard, Thank you for your review.=20 I presented a slide presentation at IETF 62 that describes the problem statement for Cap Exchange. > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, August 26, 2005 1:23 PM > To: radiusext@ops.ietf.org > Subject: Capabilities negotiation problem statement >=20 > In looking at the Capabilities Negotiation draft, I was=20 > struck by the vagueness of the problem statement.=20 >=20 > RADIUS has existed without capabilities negotiation for more=20 > than a decade now. As far as I know, there are not even any=20 > Vendor-Specific implementations. Given the level of=20 > experimentation on other areas (see RFC 2882) this is=20 > surprising. If this problem is so important and pervasive=20 > (as the draft argues) how come the industry seems to have=20 > ignored it for a decade, without creating huge problems?=20 In fact, CUI and other work has introduced a capability exchange. 3GPP2 for example use advertisement for: Prepaid - Before we push down a Prepaid policy we need to know whether the NAS supports that policy. Otherwise the NAS will ignore the policy and allow the session to continue. As you can see this is a serious problem. Dynamic Auth - we need to understand whether a NAS supports 3576 for correct operation. There maybe more the one way to kill a session. So we want to know what the NAS can do. This is laregely an efficiency problem but also=20 > The answer is that RADIUS already enables NASes and RADIUS=20 > servers with different capabilities to interoperate. For=20 > example, RFC 2865 allows a NAS to ignore attributes it does=20 > not understand, and this is how most existing RADIUS client=20 > implementations behave. This allows a RADIUS server to send=20 > attributes to a NAS without having to worry about whether it=20 > understands them, as long as those attributes can be safely ignored.=20 Sure for simple deployement scenarios like Dial up. But now we are talking about more sophisticated usage for RADIUS. > Similarly, a NAS does not need to know whether a RADIUS=20 > server understands an attribute in order to send it, as long=20 > as the attribute can be safely discarded by the RADIUS server. But this is not efficient. Why send an attribute or a set of attributes if the are not required by the Server? Also if you look at new drafts such as logoff. Why send a logoff message if the Server doesn't need it? =20 > As a result, the real issue is specification of mandatory=20 > attributes, not "capability-negotiation" per se. Note that a=20 > proposal for mandatory/optional marking has recently been put=20 > forward in the Design Guidelines document.=20 I don't think that that is all. =20 > Some of the cases where the mandatory/optional issue comes up=20 > include:=20 >=20 > a. Where the RADIUS server REQUIRES the NAS to understand an=20 > attribute in order for access to be provided. A classic case=20 > of this is use of security attributes (VLANs, Filters, etc.).=20 > A NAS cannot safely ignore a security attribute sent by the=20 > RADIUS server. =20 >=20 > This situation is the most common one; there are documented=20 > cases where existing behavior has resulted in substantial=20 > financial losses. =20 > At the same time, the behavior of existing implementations=20 > can't be changed retroactively.=20 >=20 > b. Where the NAS REQUIRES that the RADIUS server send an=20 > attribute in order for it to provide access.=20 >=20 > Other cases are already handled by the RADIUS protocol as it=20 > exists today:=20 >=20 > c. Where the RADIUS server requires an attribute that the NAS=20 > does not provide in an Access-Request, the server can send an=20 > Access-Reject, potentially including an Error-Cause (101)=20 > attribute. If the NAS understands the Error-Cause attribute,=20 > it can correct the problem.=20 >=20 > In looking at the proposal within the Design Guidelines=20 > document, it appears to me that the Mandatory/Optional=20 > functionality described there potentially handles both cases=20 > a) and b). In case a), a RADIUS server can send an attribute=20 > with the "M" bit set. In case b), a NAS can send an=20 > attribute with the "M" bit set.=20 >=20 > Given all of this -- what is the problem statement for=20 > Capabilities Negotiation, and how does it differ from the=20 > problem statement for Mandatory/Optional attributes?=20 For one I need to be assured that the NAS supports the mandatory semantics. So as a minimum we need that information. But there is more.... But mandatory is not enough. Since some Applications have different options or capabilities. We need to understand which ones are supported. For example, I may support volume based or time based prepaid but not support Prepaid Pools which are much more difficult to implement. I may support NAS Filter Rule but only some of its options. So knowing what the NAS supports allows me to send the appropriate attributes to the NAS invoking the modes that it supports for a given application. After all, the name of the game is not to have the NAS reject the session. Finally, A server may need to understand what features are supported as part of its authentication/authorization policy decision. If the NAS does not support prepaid then, in a mobile IPv4 scenario, the server will not rely on the NAS for prepaid but rather the HA. It will then force the NAS (acting as FA) to reverse traffic all the flows to the HA and not send any prepaid attributes to the NAS. > -- > 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: Sat, 27 Aug 2005 06:35:12 +0000 Date: Fri, 26 Aug 2005 23:34:56 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org cc: geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Am I missing something, or is the problem really this simple? > > > > It would appear so. The "server-driven" approach also provides a mechanism to address RADEXT Issue 27 (Who's Location). One of the major problems with the RADIUS-GEOPRIV document is that it does not support user location determination, only NAS location. This is a problem for vendors who are shipping APs with built-in location support that enables APs to pinpint the location of associated stations. At least one RADIUS server implementation now supports "location-based access control". Why can't the RADIUS-GEOPRIV specification be used to send user as well as NAS location? This basic problem with the document was pointed out in November 2004, but has still not been fixed in August 2005, 9 months later. However, using the "server-driven" approach, the problem would not be hard to address. In the "send location" attribute included by the server, the server can specify what type of location data it is looking for - user or NAS. Note that layer 2 standards such as IEEE 802.11k already enable this distinction. In IEEE 802.11k a station can ask either for its own location or the location of the AP. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 06:13:27 +0000 Date: Fri, 26 Aug 2005 23:13:17 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Can there be multiple Error-Causes? That would seem to be efficient. Off the top of my head, I don't see why not. RFC 3576 allows 0+ Error-Cause attributes in a NAK, so I'd assume that it also would be allowed in an Access-Challenge or Access-Reject. > An Access-Request MAY be responded to with an Access-Challenge > containing Error-Cause, For authentication methods that normally expect > request/ack, receipt of an Access-Challenge would indicate that they > add the relevant data, and re-send the Access-Request without > prompting the user for more information. Where an Access-Challenge is expected, this works. Where it is unexpected, RFC 2865 Section 4.4 requires that the NAS treat the Access-Challenge as an Access-Reject. > That requirement would make it clear that the NAS *does* have to > maintain state, but that it does not have to tell the user about the > re-authentication. I think that it's possible to make this work without changing existing Access-Challenge behavior. If an Access-Challenge would be sent anyway, a "send location" attribute can be piggybacked on it. If it is unexpected, the Access-Challenge will be treated as an Access-Reject and re-authentication will be required. > > Am I missing something, or is the problem really this simple? > > It would appear so. Based on this discussion, I think it is even simpler than I had thought -- Access-Challenge, Error-Cause and a "send location" attribute appear to solve the problem with no need for any capability advertisements. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 06:02:33 +0000 Date: Fri, 26 Aug 2005 23:02:13 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > would seem that this proposal may work for non-location-aware proxies. Yes, I think the problem is with the NAS, not proxies. > For non-location-aware NASes, the RFC's already require > implementations to treat unexpected Access-Challenges as > Access-Rejects, so this idea would appear to be fail-safe there, too. Yes, Section 4.4 of RFC 2865 states: " If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead." So a RADIUS server can always send a Challenge with an Error-Cause value as well as a "send location" attribute. Where the NAS does not expect a Challenge, it will treat it as an Access-Reject. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 05:39:03 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Cc: radiusext@ops.ietf.org, geopriv@ietf.org Date: Sat, 27 Aug 2005 01:40:13 -0400 Message-Id: <20050827054013.48FB116CCA@mail.nitros9.org> Bernard Aboba wrote: > If the RADIUS authentication mechanism doesn't already utilize an > Access-Challenge, this will not work. On the other hand, if the NAS is updated to include location information, it may be acceptable to add additional requirements such as this. For simple password-style authentication methods such as PAP or CHAP, adding another step would be relatively easy. For methods already involving Access-Challenge, your previous suggestion would apply. > But we can't impose that requirement retroactively. I agree. However, RADIUS proxies already pass Access-Challenge packets back and forth for protocols they don't understand. (e.g. EAP). So it would seem that this proposal may work for non-location-aware proxies. For non-location-aware NASes, the RFC's already require implementations to treat unexpected Access-Challenges as Access-Rejects, so this idea would appear to be fail-safe there, too. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 27 Aug 2005 05:26:04 +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: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Sat, 27 Aug 2005 01:26:00 -0400 Message-ID: Thread-Topic: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWqoIyis5NW2kUVTUSPXRU3lCnkcAAJiSig From: "Avi Lior" To: "Bernard Aboba" , , Hi Bernard, Please see inline. > -----Original Message----- > From: geopriv-bounces@ietf.org=20 > [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, August 26, 2005 8:43 PM > To: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: [Geopriv] Re: Review of draft-ietf-geopriv-radius-lo-04.txt >=20 > In thinking about the problem of capabilities negotiation=20 > within the RADIUS-GEOPRIV document, it is not clear to me=20 > that it is necessary for a NAS to advertise location support.=20 >=20 > Instead, the NAS can be set by default not to send location=20 > attributes unless the server asks for them. The problem then=20 > reduces to how the server communicates its needs to the NAS.=20 >=20 > There are several cases of interest:=20 >=20 > 1) The RADIUS server REQUIRES the NAS to provide location in=20 > the Access-Request (e.g. it implements location-based access control). > In this case the RADIUS server can send an Access-Reject with=20 > an Error-Cause attribute with a value of "Location Required".=20 > Alternatively if the authentication mechanism (e.g. EAP)=20 > supports Access-Challenges, the RADIUS server can place a=20 > "Send location" attribute in the Challenge. On receiving=20 > either of these indications, the NAS includes location=20 > attributes in the Access-Request.=20 > Note that the server's decision is not influenced by whether=20 > the client has advertised location support, only by the=20 > inclusion of location attributes in the Access-Request. Access Reject case is grossly inefficient requiring the re-authentication and is simply not acceptable in many deployement and in particular in mobile deployements where authentication is resouce intensive. The Challenge Option is better but we will benefit in efficiency if the home network knew whether or not the NAS supported the feature in the first place. After all, if you required location information, why would you challenge a NAS that couldn't deliver the information? > 2) The RADIUS server does not require location in the=20 > Access-Request, but would like location attributes to be=20 > included in Accounting packets, if available. In this case,=20 > the RADIUS server sends an Access-Accept including a "Send=20 > location" attribute, perhaps specifying more details on how=20 > location should be provided (e.g. Accounting-Stop only,=20 > interim records, civil/geographic, etc.). This would work but if the authentication is predicated on whether or not I could have location in the accounting stream, then your scheme would not work right? =20 > Since the RADIUS server does not require location attributes,=20 > a legacy NAS can ignore the "send location" attribute with no=20 > ill effects. This is how legacy NAS implementations behave,=20 > and the "Issues and Fixes" document indicates that this is in=20 > fact the correct behavior. > If the NAS does understand the "send location" attribute then=20 > it will send location in the Accounting packets as requested. >=20 > Am I missing something, or is the problem really this simple?=20 I think advertizement as described in the current Geopriv document is well thoughtout. I think the issue raised is whether or not to take care of it in the End-to-End capability or in the document itself. > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=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: Sat, 27 Aug 2005 05:14:03 +0000 Date: Fri, 26 Aug 2005 22:13:53 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Also, this use of Access-Reject is closer to the semantics for > Access-Challenge. I would prefer to use that, instead. i.e. An > Access-Request MAY be responded to with an Access-Challenge containing > Error-Cause, For authentication methods that normally expect > request/ack, receipt of an Access-Challenge would indicate that they > add the relevant data, and re-send the Access-Request without > prompting the user for more information. If the RADIUS authentication mechanism doesn't already utilize an Access-Challenge, this will not work. > That requirement would make it clear that the NAS *does* have to > maintain state, but that it does not have to tell the user about the > re-authentication. But we can't impose that requirement retroactively. > > Alternatively if the authentication mechanism (e.g. EAP) supports > > Access-Challenges, the RADIUS server can place a "Send > > location" attribute in the Challenge. On receiving either of these > > indications, the NAS includes location attributes in the Access-Request. > > Note that the server's decision is not influenced by whether the client > > has advertised location support, only by the inclusion of location > > attributes in the Access-Request. > > Yes. > > > 2) The RADIUS server does not require location in the Access-Request, > ... > > Yes. > > > Am I missing something, or is the problem really this simple? > > It would appear 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: Sat, 27 Aug 2005 05:00:52 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Cc: radiusext@ops.ietf.org, geopriv@ietf.org Date: Sat, 27 Aug 2005 01:01:40 -0400 Message-Id: <20050827050140.91A9016CCA@mail.nitros9.org> Bernard Aboba wrote: > 1) The RADIUS server REQUIRES the NAS to provide location > in the Access-Request (e.g. it implements location-based access control). > In this case the RADIUS server can send an Access-Reject with an > Error-Cause attribute with a value of "Location Required". Can there be multiple Error-Causes? That would seem to be efficient. Also, this use of Access-Reject is closer to the semantics for Access-Challenge. I would prefer to use that, instead. i.e. An Access-Request MAY be responded to with an Access-Challenge containing Error-Cause, For authentication methods that normally expect request/ack, receipt of an Access-Challenge would indicate that they add the relevant data, and re-send the Access-Request without prompting the user for more information. That requirement would make it clear that the NAS *does* have to maintain state, but that it does not have to tell the user about the re-authentication. > Alternatively if the authentication mechanism (e.g. EAP) supports > Access-Challenges, the RADIUS server can place a "Send > location" attribute in the Challenge. On receiving either of these > indications, the NAS includes location attributes in the Access-Request. > Note that the server's decision is not influenced by whether the client > has advertised location support, only by the inclusion of location > attributes in the Access-Request. Yes. > 2) The RADIUS server does not require location in the Access-Request, ... Yes. > Am I missing something, or is the problem really this simple? It would appear 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: Sat, 27 Aug 2005 00:43:38 +0000 Date: Fri, 26 Aug 2005 17:43:14 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In thinking about the problem of capabilities negotiation within the RADIUS-GEOPRIV document, it is not clear to me that it is necessary for a NAS to advertise location support. Instead, the NAS can be set by default not to send location attributes unless the server asks for them. The problem then reduces to how the server communicates its needs to the NAS. There are several cases of interest: 1) The RADIUS server REQUIRES the NAS to provide location in the Access-Request (e.g. it implements location-based access control). In this case the RADIUS server can send an Access-Reject with an Error-Cause attribute with a value of "Location Required". Alternatively if the authentication mechanism (e.g. EAP) supports Access-Challenges, the RADIUS server can place a "Send location" attribute in the Challenge. On receiving either of these indications, the NAS includes location attributes in the Access-Request. Note that the server's decision is not influenced by whether the client has advertised location support, only by the inclusion of location attributes in the Access-Request. 2) The RADIUS server does not require location in the Access-Request, but would like location attributes to be included in Accounting packets, if available. In this case, the RADIUS server sends an Access-Accept including a "Send location" attribute, perhaps specifying more details on how location should be provided (e.g. Accounting-Stop only, interim records, civil/geographic, etc.). Since the RADIUS server does not require location attributes, a legacy NAS can ignore the "send location" attribute with no ill effects. This is how legacy NAS implementations behave, and the "Issues and Fixes" document indicates that this is in fact the correct behavior. If the NAS does understand the "send location" attribute then it will send location in the Accounting packets as requested. Am I missing something, or is the problem really this simple? -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 23:28:34 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Capabilities negotiation problem statement Cc: radiusext@ops.ietf.org Date: Fri, 26 Aug 2005 19:29:33 -0400 Message-Id: <20050826232933.19F7216CCA@mail.nitros9.org> "Nelson, David" wrote: > What happens to the "extended" RADIUS attribute format including the > Mandatory bit when the RADIUS PDU passes through a proxy server that > hasn't implemented the "extended" attribute format? Ideally, it passes it through unchanged. > I suppose this is the same as what happens to any other unrecognized > attributes at proxy servers... which is what, exactly? "implementation dependent". So let's look at the error conditions: 1) proxy drops the attributes, and home server doesn't see them. It's likely then, that the home server will need those attributes, and the new type of session will fail to meet it's requirements, and will be rejected 2) The proxy passes them as-is, and the home server sees them. It's likely, then, that the new type of session will work. Looking at (1), if the home server has a way to tell that the new attributes have been dropped, then the design is fail-safe. Otherwise, the home server gets a request with missing information, and may reach the wrong conclusion. My initial thought is to extend the RADIUS packet header by mandating a new RADIUS attribute to be the first one in the packet. The existence, and placement, of that attribute would signal new capabilities. It's content could include things like information about the other "mandatory" attributes in the packet, such as a simple count. If that attribute was a simple integer, it's impact on RADIUS would be small, and the likelihood of making it through a proxy chain would be high. The other, complex, new attributes may not make it through a proxy chain, but by "bootstrapping" off of the first attribute, home servers could detect this fact, and deal with it. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Aug 2005 21:36: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: IETF-63 Proceedings Submission Date: Fri, 26 Aug 2005 17:35:43 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032547@MAANDMBX2.ets.enterasys.com> Thread-Topic: IETF-63 Proceedings Submission Thread-Index: AcWqhhzE9C4/w3w6TAe/AlhFJtnpqw== From: "Nelson, David" To: Cc: IETF-63 RADEXT WG Minutes Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson) No jabberer. (Later Hannes Tschofenig joined the jabber room.) Bluesheets started. No agenda changes requested. Presentations and agenda online at: http://www.drizzle.com/~aboba/IETF63/radext/ RADEXT Issues Tracker location: http://www.drizzle.com/~aboba/RADEXT Streaming audio archive location: =20 http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-we d.mp3.1 [start time index: 20:34] Brief status of WG work items: - 2684bis in AD follow-up - Dynauth MIBs completed WGLC, 9 issues - CUI in AD follow-up - Digest Auth completed WGLC, 5 issues - 802 Extensions in WGLC, 3 issues (so far) Presentations: - RFC2684 bis presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt Problem with internationalization found in IESG review. Added clarifying text for ABNF vs. document text requirements and the use of UTF-8 vs. IDN-unware ASCII for the realm part. Revision back to IESG for approval -- very soon, e.g. about a week. Realm strings will be IDN unaware (no "!"). - Chargeable User Identity presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id -03.txt All issues have been addressed in the current version of the document. Several SDOs are interested in this draft - WiMAX is one who will be submitting a liaison letter to IETF for this. Pasi Eronen clarifies that this document is in AD evaluation stage and not at the IESG. Bernard may need to update the web-site to indicate the appropriate document status. ID Tracker from IETF homepage is definitive on status. - Digest Authentication update by Wolfgang Beck. http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt Diameter compatibility is the current main issue with the document. There is also an issue regarding client-side nonce generation when interoperating with Diameter - additional text will be added to address this. We could move forward two ways; one it get client side nonce generation added to diameter, or simply drop this. The 3GPP2 liaison would like to see client side nonce generation remain because they currently use it. Avi Lior recommends that we operate in both modes of operation and when working with Diameter, and get Diameter to update to support client side nonce generation. The 3GPP2 people are waiting for an RFC number on this document so they can publish their spec. The security considerations need to be updated to discuss what to do when realm check fails. There were also some typos that will be corrected. Desire to get -04 version out shortly after IETF-63. - Dynamic Authorization MIBs - Greg Weber speaking for authors who could not attend. http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib -01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib -01.txt =20 These MIBs are companions to RFC 3576. They are expected to be completed by the end of the year. Issues 96/97 have been resolved and are simply editorial in nature. Issue 105 resolution relates to where the MIBs are to be located in the OID tree. It is believed that new MIBs should be rooted off of mib-2 and the authors are willing to make the change to support this. Issue 92 is the most controversial. A few new terms are defined by this document; DAC and DAS. It was suggested to match RFC 3576 and not introduce new terms in MIB, however the terms are embedded in all of the object names. It is still the belief of the WG that the terms should be consistent and it sounds as though the object names will be globally searched and replaced. Bernard Aboba: RFC 3576bis would be within WG charter, and we could address the terminology issues there. That would mean either delaying the MIBs or revising them later. - 802 Extensions draft presented by Paul Congdon. http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt Discussed recent changes, but not current issue status. Changes include removal of controversial (Diameter-like) extended attribute types, no new data-types or M-bit, fleshed out the NAS-Filter-Rule, can now specify L2 encapsulations, removed IP-redirection rule type in favor of tunneling. Among the interested parties are TNC of TCG, 3GPP, WiMAX (hot-lining). Glen Zorn questioned the chairs on why this document was so quickly moved to last call. The chairs believe that the previous issues in the individual submissions were sufficiently resolved and there being a number of SDOs waiting on this document see the need to expedite the review and closure of this document. WG last call closes on Aug 10th. There was a question regarding when the wireless attributes would be documented. There is a -00 draft on WLAN attributes to be discussed on this later in the meeting. - RADIUS IPv6 MIBs discussed by Dave Nelson. http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt New textual conventions for address objects have been included. Review comments from the MIB Doctors have been resolved in the -01 revisions. The drafts UPDATE their predecessor RFCs, deprecate old tables (not doing table augmenting anymore), added new tables to mirror old ones, added specific usage guidelines new IP address objects. The question of whether these should be WG work items was posed and no objections were heard. The RADEXT -00 drafts will be created and moved to WG last call. - Common Radius Implementation Issues and Fixes presented by Dave Nelson. http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt The document was created based upon a long laundry list of issues that have been discussed on the mailing list. This document identifies many of the problems identified in the field and makes suggestions to resolve the problems. Areas discussed include:=20 - Proper use of the state attribute=20 - Request ID supplementation alternative=20 - Re-transmit schemes=20 - How to handle overload conditions=20 - Clarification of accounting attribute updates=20 - Clarification of using multiple Filter-ID attributes=20 - Treating access-accept for unknown services as a reject=20 - Avoiding sending VSAs to a NAS that doesn't understand them =20 A question about this recommendation is how to reliably detect supported vs. unsupported VSAs. The capabilities attribute is a possible solution. Glen Zorn suggested the possibility of a version number. Since this is just -00, it was suggested to post issues against the document. It was noted that some issues were currently in the tracker but not yet included in the draft. - Corrections to RFC 2869, section 2.2 regarding miss-stated Access-Challenge.=20 - Handling multiple services=20 - Defining how to calculate Message-Authenticator for Disconnect, COA and others=20 - Authorize only discussion There were some questions of how this document should progress. The document is useful, but perhaps an RFC 3576bis additionally needs to be created. Also, some of the issues are against earlier RFCs as well. These are standards track and may be more difficult to update. This document is intended to address existing and past issues. Another forward looking document discusses future issues. Other issues not addressed were NASes with multiple IP addresses and accounting interval updates. These should be included and consensus on a solution for these needs to be proposed. - RADIUS Attribute Design Guidelines presented by Greg Weber. http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0 0.txt This is a forwarding looking document addressing design recommendations for new attributes. This document describes what is considered a good attribute design and reviews the current RADIUS data types, as well as the divergence in the Standard and Vendor Specific data models. A few have reviewed this document so far. The current document does include some recommendations, but these are straw-man recommendations. The motivation for this document is to get better alignment with data models in vendor attributes, address attribute space exhaustion and align better with diameter. The scope of the document includes consideration for backward compatibility, existing VSAs, supporting the existing transport, non-AAA applications and Diameter compatibility. The document straw-man proposes a single standards base format for VSAs as a recommendation. The document also includes recommendations on when particular formats should be used and when to use existing VSA format verse the new one. Lots to do on this draft. Avi Lior agrees this document is a good starting point and is willing to work on the draft. There was a question whether SDOs should be differentiated from Vendors, but the group doesn't believe so. There was a question whether IANA considerations are included, but the authors believe this is already spelled out elsewhere. Glen Zorn asks if it was considered to extend the size of RADIUS attributes rather than dealing with fragmentation. Greg Weber did not consider this because he felt it would be beyond the scope of the charter. - WLAN Attributes presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt The list of attributes that were removed from the 802 Extensions draft was presented. There is some overlap that needs to be discussed. [Technical difficulties with slides caused us to move forward to the next topic.] Upon return, some relationships to the EAP keying draft were described. A list of key management attributes were described and the issues. Privacy can be addressed similar to NAI and by omitting Peer-ID and Server-ID attributes. Key-wrap options were described as three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec. The later is not used in industry. The key-wrap options may be difficult to resolve. The questions on this document are whether this should be a WG item and how to solve the privacy and key-wrap problems. - RADIUS attributes for Cryptographic Keys presented by Glen Zorn. http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt The motivation for this draft was to allow RADIUS to be used in certain government environments. While RADIUS isn't a key provisioning protocol, there are keys that are passed around in RADIUS and perhaps aren't wrapped securely enough. Several editorial changes were made in the -07 revision, but also HMAC-MD5 was removed and other key transport attributes (e.g. MPPE-xxx) were outlawed if the same data is also transferred in the new attributes. Questions about how keys are transferred to the client - hop-by-hop or end-to-end? They are passed along the path in the way they are set-up - may be hop-by-hop. Glen plans to add AES-CMAC and some other technical changes in the -08 revision. - General WG discussion on key-wrap issues. Glen Zorn points out that the keying issue is not just an 802.11 or Wireless problem. Also, Glen believes that IPSec is inappropriate as a protection mechanism for an application level protocol. Glen believes that NIST is in agreement that IPSec is not appropriate for this use. Nancy Cam-Winget from Cisco summarized the NIST meeting that took place back at the end of June. She also agrees that it isn't just wireless that needs the keying solutions. They wanted to know if a new key-wrap attribute with a new algorithm would be sufficient or would IPSec work. Nancy believes that the latest draft of the Zorn document has all the changes included based upon the NIST discussion. Nancy believes that NIST's reaction to the use of IPSec to protect RADIUS key distribution was that it would require further review by NIST. Jari Arkko also believes the key work isn't just for wireless and would like to see it in a separate draft from other WLAN attributes. There was a question about the relationship to the Zorn document and the Aboba document? We do have keying attributes for WLAN as a charter item for this group, but can't introduce new security mechanisms. Bernard's document comes from the EAP key framework perspective. A question about a new message authenticator algorithm and attribute being described by Glen. It can be used in any RADIUS message because it is independent of the authenticator value in the RADIUS message. Message-Authenticator cannot be used in Accounting-Request or CoA messages. The new one is cryptographically stronger; the old one is not FIPS compliant (MD5). The new attribute can be used as a complete replacement of the old style message authenticator. Alternatively, the old message authenticator could still be used. Bernard's draft reuses the RADIUS shared secret, while Glen's draft assumes a cryptographically separate pre-shared key. Bill Burr cautions that NIST is not looking very closely at RADIUS usage and so there isn't a good view of what is being done here. He characterized the existing wireless key distribution mechanism (i.e. as used in 802.11i with RADIUS) as somewhat "Rube Goldberg". Bill described the process of obtaining a FIPS-140 certification and how painful it may be for vendors. Glen points out that there is a lot of interest in solving this problem and it has been solved, so why is there a new WLAN draft addressing the keying mechanisms? Dave Nelson (Chair) indicated that the keying problem seems to have a lot of interest. The WG might consider amending its charter (security mechanism restriction) to address this issue, if needed. [Ed. Note: Only the statements of Bill Burr should be considered as the position of NIST. Other statements are the opinion of the speaker.] - End-to-End capability exchange presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01 .txt The proposal describes an end-to-end, per-session mechanism to negotiate capabilities. The attribute contains a string of octets where each capability is encoded in 2 bits that define, not-supported, supported and required. Avi points out other documents need this work; location in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could all use this. Should it be a WG document? No one objects to making this a WG item, but we will confirm this on the list. This document should be in alignment with Greg's work on Design Guidelines if we are defining a new data type. - RADIUS Prepaid attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions -08.txt The document was re-organized for read-ability and updated. Flow based prepaid is becoming a requirement. Requested by 3GPP2 and WiMAX. The difference between RADIUS credit control (a.k.a. prepaid) and Diameter credit control was described. It is believed that some of the differences are regarding some features that may compromise the privacy of the client (e.g. balance check and cost inquiry). Other differences are not clear yet and need to be discussed. How can Diameter credit control and RADIUS prepaid be translated? The recommendation is that the server must do this itself. A recommendation from the audience was to have scenarios documented or analyzed - not necessarily included in the draft, but available. Different SDOs are using Diameter and RADIUS, and there will likely be some issues related to translation. Resolution of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as the RADEXT WG didn't anticipate supporting different "dialects" of the prepaid extensions. The authors believe the document is ready to become a WG item. Since the authors are not in complete alignment it was suggested that they hash out their problems before making it a WG document. The authors believe they have enough alignment, but being out of time, we will continue the discussion on the WG mailing list. - RADIUS Bandwidth attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili ty-01.txt Issues from Bernard Aboba's extensive review have all been addressed, except one which is related to the length of the attribute size. Should this be a WG document? Discuss on the WG mailing list. - RADIUS QoS attributes presented by Hannes Tschofenig. http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt Hannes describes a more general QoS environment. This work is related to the Diameter work. They are addressing a generic description described in NSIS QSPEC work. As compared to Avi Lior's bandwidth document, this is a more heavy weight description. Avi's document is viewed as a short term solution. There is the question of charter scope in RADEXT.=20 - General WG Discussion about QoS and Bandwidth. Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as a resource management protocol. She believes that RSVP and NSIS are the protocols to do resource allocation. There was an RSVP and Diameter document that is similar to proposed RADIUS document. John Loughney comments that the Diameter QoS document is an individual submission and not a current AAA WG document. John will post the link to the RADEXT WG mailing list for this document, so that we can review it. Allison mentions that we don't want to start extending the bandwidth draft to include a bunch of new things like latency and jitter, but they are happy with simple rates that are currently defined. Combining Avi's bandwidth draft and Hannes' QoS draft would certainly delay the simple bandwidth parameter attribute that has been requested by other SDOs. A comment from 3GPP is that they are depending upon the bandwidth draft to be complete for reference in their specification release 7, by mid-2006. The group doesn't believe they should be combined. Dave Nelson (Chair) asked what the overlap is between the documents. Avi points out that the QoS "blob" includes a bandwidth component and could be used, but John Loughney and the other authors believe there may be a solution on how cross reference the documents and avoid overlap. Dave (Chair) indicated he would work to facilitate the cross-WG and cross-Area coordination that will be required to move forward in this area. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 21:14:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-zorn-radius-keywrap-07 Date: Fri, 26 Aug 2005 17:14:10 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032545@MAANDMBX2.ets.enterasys.com> Thread-Topic: draft-zorn-radius-keywrap-07 Thread-Index: AcWqfkxRWvddbcWST6WwO9yA/fENFwAALDBQAAAvoUAAAMLHIA== From: "Nelson, David" To: Cc: "Pat Calhoun \(pacalhou\)" , "Nancy Winget \(ncamwing\)" > I would ask that all WG members review... Oh, yes... I should also have requested that comments use the RADEXT Issue format described on the Issue Tracker web page http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Aug 2005 21:05: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: draft-zorn-radius-keywrap-07 Date: Fri, 26 Aug 2005 17:05:04 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032544@MAANDMBX2.ets.enterasys.com> Thread-Topic: draft-zorn-radius-keywrap-07 Thread-Index: AcWqfkxRWvddbcWST6WwO9yA/fENFwAALDBQAAAvoUA= From: "Nelson, David" To: Cc: "Pat Calhoun \(pacalhou\)" , "Nancy Winget \(ncamwing\)" Pat Calhoun writes... > The chair has recently stated that the document above is in scope of the > working group, and I applaud this move given there is market need for > such a solution. Given that the draft is in its 7th version and includes > comments generated through various peer reviews, I would like to > recommend that the chair do a last call of the draft to move it forward > in the standards track. The co-chairs have stated that key-wrap attributes are within the scope of the RADEXT charter. However, we have two submissions that deal with this subject. The process we have been using in RADEXT is for individual submissions to be reviewed as pre-WG work items, with issues being tracked in the RADEXT Issues Tracker. Once the issues are resolved, and the drafts reasonably mature, we then ask for WG consensus to make the documents WG work items. In this case we also need to resolve which of the documents to adopt, or whether to merge them. This is basically an unfinished discussion from the RADEXT WG session at IETF-63, and it is appropriate that we continue the discussion on the mailing list. Some discussion has already occurred. I would ask that all WG members review=20 http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt and http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt=20 with respect to the key wrap attributes contained therein. Please review these documents with the Housley Criteria=20 http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt=20 in mind. Discussion of the key wrap issues in general, specific comments on either draft, and whether one or the other approach to RADIUS key wrap should become a WG work item, are welcome. Thanks! - Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Aug 2005 20:46:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: draft-zorn-radius-keywrap-07 Date: Fri, 26 Aug 2005 13:45:50 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D88E82E7@xmb-sjc-222.amer.cisco.com> Thread-Topic: draft-zorn-radius-keywrap-07 Thread-Index: AcWqfkxRWvddbcWST6WwO9yA/fENFwAALDBQ From: "Nancy Winget \(ncamwing\)" To: Cc: "Pat Calhoun \(pacalhou\)" , "Bernard Aboba" =20 Resending to the WG as it doesn't seem to be getting posted? =09 Nancy. -----Original Message----- From: Pat Calhoun (pacalhou)=20 Sent: Friday, August 26, 2005 1:40 PM To: Radius Ext Mailing List Cc: aboba@internaut.com; Nancy Winget (ncamwing) Subject: draft-zorn-radius-keywrap-07 All, The chair has recently stated that the document above is in scope of the working group, and I applaud this move given there is market need for such a solution. Given that the draft is in its 7th version and includes comments generated through various peer reviews, I would like to recommend that the chair do a last call of the draft to move it forward in the standards track. Thanks, Pat Calhoun CTO, Wireless Networking Business Unit -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 18:50: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: Capabilities negotiation problem statement Date: Fri, 26 Aug 2005 14:50:51 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032543@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities negotiation problem statement Thread-Index: AcWqboVY3v5/WyHySRigDpPstWuj7gAADfcQ From: "Nelson, David" To: "Bernard Aboba" Cc: Bernard Aboba writes... > In general, most proxies I've seen can be set either to pass along unknown > attributes, to only allow a defined set of attributes to pass, or to > completely replace some or all existing attributes with new ones. And that will be the behavior for either new mandatory attributes or a new capability advertisement attribute. There seems to be no requirement for capabilities advertisement over mandatory attributes based on proxy behavior. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 18:47:09 +0000 Date: Fri, 26 Aug 2005 11:46:48 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Capabilities negotiation problem statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Yes, but mandatory attributes were included in Diameter from day-one. > What happens to the "extended" RADIUS attribute format including the > Mandatory bit when the RADIUS PDU passes through a proxy server that > hasn't implemented the "extended" attribute format? > > I suppose this is the same as what happens to any other unrecognized > attributes at proxy servers... which is what, exactly? In general, most proxies I've seen can be set either to pass along unknown attributes, to only allow a defined set of attributes to pass, or to completely replace some or all existing attributes with new ones. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 26 Aug 2005 18:19: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: Capabilities negotiation problem statement Date: Fri, 26 Aug 2005 14:19:09 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032542@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities negotiation problem statement Thread-Index: AcWqaf0xJnrKSMhuSpiQ4MnjJDj78QAABZGw From: "Nelson, David" To: Bernard Aboba writes... > Mandatory attributes are end-to-end in Diameter, so I assume they would be > end-to-end in RADIUS too. It's only Diameter application negotiation that > is hop-by-hop. Yes, but mandatory attributes were included in Diameter from day-one. What happens to the "extended" RADIUS attribute format including the Mandatory bit when the RADIUS PDU passes through a proxy server that hasn't implemented the "extended" attribute format? I suppose this is the same as what happens to any other unrecognized attributes at proxy servers... which is what, exactly? -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 18:14:44 +0000 Date: Fri, 26 Aug 2005 11:14:21 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Capabilities negotiation problem statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think the only issues that may not be addressed by the Mandatory bit > (which, BTW, does not yet have WG consensus) that may require some > additional text would be proxy chain and roaming consortium scenarios. > If the Mandatory bit is hop-by-hop, then a Proxy Considerations section Mandatory attributes are end-to-end in Diameter, so I assume they would be end-to-end in RADIUS too. It's only Diameter application negotiation that is hop-by-hop. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 17:53:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Capabilities negotiation problem statement Date: Fri, 26 Aug 2005 13:52:47 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032540@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilities negotiation problem statement Thread-Index: AcWqYtfWn9za74uIQmCmBvErbFXJCQAA0pfg From: "Nelson, David" To: Bernard Aboba writes... > Given all of this -- what is the problem statement for Capabilities > Negotiation, and how does it differ from the problem statement for > Mandatory/Optional attributes? I think the only issues that may not be addressed by the Mandatory bit (which, BTW, does not yet have WG consensus) that may require some additional text would be proxy chain and roaming consortium scenarios. If the Mandatory bit is hop-by-hop, then a Proxy Considerations section will likely be required to describe behavior in those kinds of deployments. Avi's draft intends to cover end-to-end capabilities advertisement. If the Mandatory bit can be made end-to-end, or suitable behavior in roaming deployments can be described, then maybe we don't need capabilities advertisement. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Aug 2005 17:23:03 +0000 Date: Fri, 26 Aug 2005 10:22:31 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Capabilities negotiation problem statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In looking at the Capabilities Negotiation draft, I was struck by the vagueness of the problem statement. RADIUS has existed without capabilities negotiation for more than a decade now. As far as I know, there are not even any Vendor-Specific implementations. Given the level of experimentation on other areas (see RFC 2882) this is surprising. If this problem is so important and pervasive (as the draft argues) how come the industry seems to have ignored it for a decade, without creating huge problems? The answer is that RADIUS already enables NASes and RADIUS servers with different capabilities to interoperate. For example, RFC 2865 allows a NAS to ignore attributes it does not understand, and this is how most existing RADIUS client implementations behave. This allows a RADIUS server to send attributes to a NAS without having to worry about whether it understands them, as long as those attributes can be safely ignored. Similarly, a NAS does not need to know whether a RADIUS server understands an attribute in order to send it, as long as the attribute can be safely discarded by the RADIUS server. As a result, the real issue is specification of mandatory attributes, not "capability-negotiation" per se. Note that a proposal for mandatory/optional marking has recently been put forward in the Design Guidelines document. Some of the cases where the mandatory/optional issue comes up include: a. Where the RADIUS server REQUIRES the NAS to understand an attribute in order for access to be provided. A classic case of this is use of security attributes (VLANs, Filters, etc.). A NAS cannot safely ignore a security attribute sent by the RADIUS server. This situation is the most common one; there are documented cases where existing behavior has resulted in substantial financial losses. At the same time, the behavior of existing implementations can't be changed retroactively. b. Where the NAS REQUIRES that the RADIUS server send an attribute in order for it to provide access. Other cases are already handled by the RADIUS protocol as it exists today: c. Where the RADIUS server requires an attribute that the NAS does not provide in an Access-Request, the server can send an Access-Reject, potentially including an Error-Cause (101) attribute. If the NAS understands the Error-Cause attribute, it can correct the problem. In looking at the proposal within the Design Guidelines document, it appears to me that the Mandatory/Optional functionality described there potentially handles both cases a) and b). In case a), a RADIUS server can send an attribute with the "M" bit set. In case b), a NAS can send an attribute with the "M" bit set. Given all of this -- what is the problem statement for Capabilities Negotiation, and how does it differ from the problem statement for Mandatory/Optional attributes? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 14:43:58 +0000 Date: Thu, 25 Aug 2005 07:43:44 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Please post comments to the RADEXT WG in the format defined on the > RADEXT WG Issue list: > > http://www.drizzle.com/~aboba/RADEXT/ It would also be helpful if the authors of the RADIUS Location document would post the resolution of the 13 issues that have already been filed, so we can figure out which ones are now closed. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Aug 2005 14:25:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-geopriv-radius-lo-04.txt Date: Thu, 25 Aug 2005 10:22:09 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252E@MAANDMBX2.ets.enterasys.com> Thread-Topic: Review of draft-ietf-geopriv-radius-lo-04.txt Thread-Index: AcWo8Bgvi/9D23vxR76eWryLSEB6oAAj1ZiQ From: "Nelson, David" To: Bernard Aboba writes... > Review of draft-ietf-geopriv-radius-lo-04.txt Thanks, Bernard. I'd like to request that the entire WG take some time to review this document. I've been informed that it is getting ready for WGLC in the GEOPRIV WG, and it would be well for RADEXT WG comments to be received at this time. So... This is a request for cross-WG review of the document "Carrying Location Objects in RADIUS". The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt =20 Please post comments to the RADEXT WG in the format defined on the RADEXT WG Issue list: http://www.drizzle.com/~aboba/RADEXT/ Please send comments by Friday September 30, 2005. (But sooner is better.) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 14:12:22 +0000 Message-ID: <430DD1CD.6080102@piuha.net> Date: Thu, 25 Aug 2005 17:12:29 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, Russ Housley Subject: Re: RADIUS keywrap attributes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>o Do we expect to find a solution that can reasonably >>be expected to fit existing networks without a lot >>of additional effort from vendors/network managers? >>(I don't know, but this is crucial in order to make >>a real impact.) >> >> > >I don't think that it is required for the solution be deployed by >everyone, by the segment of people who want/need it. > > Yes, I meant to say that. Of course, for IETF to do work in this area I think we should expect the segment to be large enough to warrant the work. Maybe "everyone who sells to DoD" is sufficiently large :-) --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 14:07:51 +0000 Date: Thu, 25 Aug 2005 07:07:28 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org cc: Russ Housley Subject: Re: RADIUS keywrap attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > For instance, > I think the Diameter redirect scheme is pretty good, but its > very likely that most or even all usage is going to be through > proxies, just as we already do today. What was accomplished in RFC 4072 (Diameter EAP) was to provide a secure mode of operation. Not everyone will use this mode, but defining it means that users who want it will have it available. > o Do we expect to find a solution that can reasonably > be expected to fit existing networks without a lot > of additional effort from vendors/network managers? > (I don't know, but this is crucial in order to make > a real impact.) I don't think that it is required for the solution be deployed by everyone, by the segment of people who want/need it. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 12:56: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: Items from the IETF-63 meeting requiring confirmation. Date: Thu, 25 Aug 2005 15:56:08 +0300 Message-ID: Thread-Topic: Items from the IETF-63 meeting requiring confirmation. Thread-Index: AcWpBqD/a4GXL/q5QU6Z6azR/MCOEAAbU+MA From: "Romascanu, Dan \(Dan\)" To: "Murtaza Chiba" , "Nelson, David" Cc: =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Murtaza Chiba > Sent: Thursday, August 25, 2005 2:50 AM > To: Nelson, David > Cc: radiusext@ops.ietf.org > Subject: Re: Items from the IETF-63 meeting requiring confirmation. >=20 > David et al., >=20 >=20 > >=20 > > 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and=20 > > draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the=20 > > drafts will be revised to use terminology that is=20 > consistent with the=20 > > base document, RFC 3576. > >=20 >=20 > Would like to point out that the new terms introduced do use=20 > the terms as found in the RFC3576 as part of its definition. =20 > These new terms are necessary to make it unambiguous as to=20 > what the MIB objects are referring to. Else, we will have a=20 > strange situation where the dynauth-client-mib will have=20 > objects that are named radiusServer and dynauth-server-mib=20 > having objects name radiusClient at the top level, which IMO=20 > is most likely to be more confusing. >=20 > Further, the intent for the new terms has been misrepresented=20 > as being an attempt to clarify the RFC3576 rather than its=20 > original intent which was to have unambiguous less confusing=20 > object names and text. >=20 > If, however, the group at large feels that the terms MUST=20 > change then we > ask how to make the terms/text less confusing, bearing in=20 > mind that the roles of the RADIUS Server and Client are=20 > actually reversed in the case of the RFC3576. >=20 > Thanks, > Murtaza >=20 My personal opinion, as MIB reviewer is that the terminology and the naming convention used in the two MIB documents is not that confusing. As a manager I do expect that a client exposes information known to the client about the servers it registers with, and that a server exposes information it is aware about concerning the clients accessing the server.=20 Regards, Dan -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 08:22:02 +0000 Message-ID: <430D7FA4.8070704@piuha.net> Date: Thu, 25 Aug 2005 11:21:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: "Nelson, David" CC: "Glen Zorn (gwz)" , Bernard Aboba , radiusext@ops.ietf.org, "Zhang, Tiebing" , Russ Housley Subject: Re: RADIUS keywrap attributes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re: charter prohibition on new security mechanisms. I tend to agree with David on this. While we do not want to develop (say) RADIUS-over-TLS, addressing the security issues in specific attributes is within scope, if those attributes themselves on the charter. Re: draft-zorn vs. draft-aboba. I think that from a 10.000 ft perspective these are really the same thing, just different in details and have some different deployment impacts. Perhaps we can leave the choice between them until we've decided if we need this work to begin with. Re: IESG expectations, charter constraints, NIST requirements: I think its pretty obvious that we are dealing with several sets of different types of requirements, not all of which always match the real world out there. For instance, I think the Diameter redirect scheme is pretty good, but its very likely that most or even all usage is going to be through proxies, just as we already do today. But having this scheme at least made it possible to publish an IETF RFC, and even the non-redirect usage of Diameter EAP is much better than the vendor specific attributes that most people use today. I think it would be useful to ask ourselves if we can make a similar positive step, not necessarily reaching all goals but improving what we have today. At the end of the day, that's what matters. So, I have some questions: o Do we believe we have an issue in the existing usage? (I think we do) o Do we have a clear target for this work? (Yes we do, wireless LANs.) o Does it fit our overall plan for the system that we want to provide? (Yes, its the missing part in the network access authentication system.) o If we do something, will that actually be deployed by a significant number of users, or are we using it just as an checkbox item to pass through IESG/IEEE/ NIST/unsuspecting customer? (Here I think we need more input...) o Do we expect to find a solution that can reasonably be expected to fit existing networks without a lot of additional effort from vendors/network managers? (I don't know, but this is crucial in order to make a real impact.) o Do we have the manpower/expertise to do this? (You tell me.) --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 07:25:22 +0000 Message-ID: <430D7258.7050809@piuha.net> Date: Thu, 25 Aug 2005 10:25:12 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: Alper Yegin , radiusext@ops.ietf.org Subject: Re: RFC 2867/2868 question Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>I have a question though: It seems like we can use either RADIUS >>Access-Request/Answer, or RADIUS Accounting Request/Answer for setting >>up the compulsory tunnel. What is the rationale behind this >>"flexibility"? When would you recommend using one or the other? >> >> > >I am not sure what "flexibility" you are talking about. RADIUS Accounting >is not an authentication/authorization mechanism, it is an accounting >protocol. RFC 2867 attributes are used to account for tunnel usage after >they have been set up; the RFC 2868 attributes are used to authorize >compulsory tunnels. > > There's some flexibility in using the same attributes for incoming or outgoing tunnels, and for reporting capabilities vs. requesting a specific action. (I'm personally not too fond of this flexibility.) But all of this happens within the auth/authz part i.e. Access-Request/Challenge/Response, not within accounting. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 25 Aug 2005 05:46: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: Items from the IETF-63 meeting requiring confirmation. Date: Thu, 25 Aug 2005 11:15:16 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F80E6DEB@xmb-blr-416.apac.cisco.com> Thread-topic: Items from the IETF-63 meeting requiring confirmation. Thread-index: AcWpBqVNf05w1gRhTdKA2jajCNulfQAMCzyw From: "Nagi Reddy Jonnala \(njonnala\)" To: "Murtaza Chiba \(mchiba\)" , "Nelson, David" Cc: Please see inline with the tag -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Murtaza Chiba (mchiba) Sent: Thursday, August 25, 2005 5:20 AM To: Nelson, David Cc: radiusext@ops.ietf.org Subject: Re: Items from the IETF-63 meeting requiring confirmation. David et al., >=20 > 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and=20 > draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the=20 > drafts will be revised to use terminology that is consistent with the=20 > base document, RFC 3576. >=20 Would like to point out that the new terms introduced do use the terms as found in the RFC3576 as part of its definition. These new terms are necessary to make it unambiguous as to what the MIB objects are referring to. Else, we will have a strange situation where the dynauth-client-mib will have objects that are named radiusServer and dynauth-server-mib having objects name radiusClient at the top level, which IMO is most likely to be more confusing. Does it make sense to rename it as "radiusClient" while the other MIBs call "radiusAuthenticationClient". IMHO, it makes a lot of sense to call them as they are. i.e., "radiusDynAuthServer" and "radiusDynAuthClient". The only difference I see is that the DynAuth MIBs have the formal "Terminology" section and there is a justification why it is there as I mentioned in my other e-mail. Further, the intent for the new terms has been misrepresented as being an attempt to clarify the RFC3576 rather than its original intent which was to have unambiguous less confusing object names and text. As Murtaza correctly pointed it, the terminology is not needed to define in the RFC-3576. It is the same with RFC-2865 and RFC-2618. If, however, the group at large feels that the terms MUST change then we ask how to make the terms/text less confusing, bearing in mind that the roles of the RADIUS Server and Client are actually reversed in the case of the RFC3576. Would like to know WG opinion as to how the Dynauth MIBs deviated from the other MIBs and how better we can handle it. Thanks Nagi. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Aug 2005 05:34: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: Items from the IETF-63 meeting requiring confirmation. Date: Thu, 25 Aug 2005 11:03:56 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F80E6DEA@xmb-blr-416.apac.cisco.com> Thread-topic: Items from the IETF-63 meeting requiring confirmation. Thread-index: AcWo97/ihfHBR2eBQsOKWwdyK1FuPQANEhqg From: "Nagi Reddy Jonnala \(njonnala\)" To: "Nelson, David" , All, Please see below my view points on the Dynauth MIBs for issue 92. > 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, > that the drafts will be revised to use terminology that is consistent with the base document, RFC 3576. First I would like to request the group to focus on the below points and not getting distracted or drawing conclusions on the other previous discussions. - Take for instance, Radius Authentication Client MIB, RFC-2618(Same is true with the Radius Accounting MIB as well). You can observe that there is the term "Radius Authentication Client" everywhere but you may wonder where is this terminology coming from? If you refer to the RFC-2865, all you find is Radius client or server but not Radius *Authentication* client/server. =20 - However, if you read the "Overview" section of the RFC-2618, you find the below and I wonder if anybody has problems to understand what exactly "Radius Authentication Client" is and who is supposed to implement "Radius Authentication Client MIB". IMO, the term "Radius Authentication Client" in RFC-2618 makes a lot of sense though there was *no need* to introduce this term in the base RFC-2865. For your quick ref, snippet from RFC-2618, Overview section. =20 "The RADIUS authentication protocol, described in [16], distinguishes between the client function and the server function. In RADIUS authentication, clients send Access-Requests, and servers reply with Access-Accepts, Access-Rejects, and Access-Challenges. Typically NAS devices implement the client function, and thus would be expected to implement the RADIUS authentication client MIB, while RADIUS authentication servers implement the server function, and thus would be expected to implement the RADIUS authentication server MIB." - Now, if you see the Dynauth MIBs, no wonder, you observe the Dynamic Authorization Server/Client terms. Base protocol talks about the Dynamic Authorization Protocol(RFC-3576) though *no need* to introduce the Dynamic Authorization Client/Server. - The only extra section for Dynauth MIBs is to clarify "DAC" and "DAS" because that in this particular case (in contrast with Radius Authenticatio/Accounting Client/Server) the client and server functionality is reversed. Conclusion: Terminology is never defined in the base RFCs but introduced informally(not noted in the bold letters that says "Terminology") in the respective MIBs as and when appropriate. Like the other MIBs, Dynauth MIBs also have the overview section that clarifies the terminology. In the case of the Dynauth MIBs, since the client/server functionality is reversed, we highlighted/clarified in the Terminology section as per the WG suggestion. Had the Dynauth protocol operate on a regular "pull" model instead of "push" model(i.e., authentication and accounting requests are initiated by the NAS and acts as client. For the Dynauth, the Radius server initiates the requests and NAS acts as a server), then we would have observed *absolutely no difference* with the other MIBs. For instance, if I could have referred the NAS as a "Dynamic Authorization Client" then you wouldn't have even noticed the difference between the other MIBs and Dynauth MIBs. The terminology has always been introduced/defined in the MIBs. Hence I don't see a need to define this terminology in the RFC-3576bis/Issues and Fixes document.=20 Hope I can convince atleast some of you. We need your vote especially when you are in agreement :-) Thank you, Nagi. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Aug 2005 01:28:02 +0000 Message-ID: <430D1E82.6080909@cisco.com> Date: Wed, 24 Aug 2005 18:27:30 -0700 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Items from the IETF-63 meeting requiring confirmation. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Bernard Aboba wrote: >>If, however, the group at large feels that the terms MUST change then we ask >>how to make the terms/text less confusing, bearing in mind that the roles of >>the RADIUS Server and Client are actually reversed in the case of the RFC3576. > > > RFC 3576 uses the terms "NAS" and "RADIUS server" to refer to the > entities, although the term "RADIUS client" is used occasionally as well. > My overall impression on rereading RFC 3576 is that is fairly clear about > what entities are involved and what they do. I think that using the > term "NAS" instead of "RADIUS client" most of the time was helpful in that > regard. > > Maybe something like this might help here? Might it make sense to have a > "Dynamic Authorization NAS MIB" and a "Dynamic Authorization Server MIB"? The NAS IS the Dynamic Authorization "Server" as described in RFC3576. That is, the NAS actually services requests from a client (RADIUS server). Besides Dynamic Authorization Server is new term DAS that has been used in the MIBs. So your proposal is more confusing really. Murtaza > Reducing the usage of the term "client" might help the clarity. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Aug 2005 01:12:42 +0000 Date: Wed, 24 Aug 2005 18:12:19 -0700 (PDT) From: Bernard Aboba To: Murtaza Chiba cc: radiusext@ops.ietf.org Subject: Re: Items from the IETF-63 meeting requiring confirmation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If, however, the group at large feels that the terms MUST change then we ask > how to make the terms/text less confusing, bearing in mind that the roles of > the RADIUS Server and Client are actually reversed in the case of the RFC3576. RFC 3576 uses the terms "NAS" and "RADIUS server" to refer to the entities, although the term "RADIUS client" is used occasionally as well. My overall impression on rereading RFC 3576 is that is fairly clear about what entities are involved and what they do. I think that using the term "NAS" instead of "RADIUS client" most of the time was helpful in that regard. Maybe something like this might help here? Might it make sense to have a "Dynamic Authorization NAS MIB" and a "Dynamic Authorization Server MIB"? Reducing the usage of the term "client" might help the clarity. -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2005 23:50:13 +0000 Message-ID: <430D0792.2060309@cisco.com> Date: Wed, 24 Aug 2005 16:49:38 -0700 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720) MIME-Version: 1.0 To: "Nelson, David" CC: radiusext@ops.ietf.org Subject: Re: Items from the IETF-63 meeting requiring confirmation. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David et al., > > 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and > draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the > drafts will be revised to use terminology that is consistent with the > base document, RFC 3576. > Would like to point out that the new terms introduced do use the terms as found in the RFC3576 as part of its definition. These new terms are necessary to make it unambiguous as to what the MIB objects are referring to. Else, we will have a strange situation where the dynauth-client-mib will have objects that are named radiusServer and dynauth-server-mib having objects name radiusClient at the top level, which IMO is most likely to be more confusing. Further, the intent for the new terms has been misrepresented as being an attempt to clarify the RFC3576 rather than its original intent which was to have unambiguous less confusing object names and text. If, however, the group at large feels that the terms MUST change then we ask how to make the terms/text less confusing, bearing in mind that the roles of the RADIUS Server and Client are actually reversed in the case of the RFC3576. Thanks, Murtaza -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2005 22:05: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: Items from the IETF-63 meeting requiring confirmation. Date: Wed, 24 Aug 2005 18:04:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252D@MAANDMBX2.ets.enterasys.com> Thread-Topic: Items from the IETF-63 meeting requiring confirmation. Thread-Index: AcWo97/ihfHBR2eBQsOKWwdyK1FuPQ== From: "Nelson, David" To: The following is a list of items on which rough consensus was obtained at the RADEXT WG session at IETF-63, and upon which confirmation on the RADEXT WH mailing list is sought. 1.) With regard to draft-ietf-radext-digest-auth-03, RADEXT Issues 123, 124, that the draft will include support for both modes of operation, nonces from client and nonces from server, and that the companion Diameter draft will take the same approach (pending consensus in the AAA WG). 2.) With regard to draft-ietf-radext-dynauth-client-mib-01 and draft-ietf-radext-dynauth-server-mib-01, RADEXT Issue 92, that the drafts will be revised to use terminology that is consistent with the base document, RFC 3576. 3.) With regard to draft-nelson-rfc2618bis-01.txt, draft-nelson-rfc2619bis-01.txt, draft-nelson-rfc2620bis-01.txt and draft-nelson-rfc2621bis-01.txt that the drafts will be accepted as RADEXT WG work items and moved to WGLC soon after the -00 versions are posted. 4.) With regard to draft-lior-radext-end-to-end-caps-01, that the document will be accepted a WG work item. Please take a moment to review these items and reply to the list by Wednesday, August 31, 2005 if you do not concur with these WG decisions taken at the IETF-63 meeting. -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2005 21:35:12 +0000 Date: Wed, 24 Aug 2005 14:35:00 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Pre working-group work item review of RADIUS Bandwidth document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a request for review of the document "Network Bandwidth Parameters for RADIUS". The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capability-01.txt Please post comments to the RADEXT WG in the format defined on the RADEXT WG Issue list: http://www.drizzle.com/~aboba/RADEXT/ Please send comments by Friday September 23, 2005. -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2005 21:08:26 +0000 Date: Wed, 24 Aug 2005 14:08:01 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Review of draft-ietf-geopriv-radius-lo-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of draft-ietf-geopriv-radius-lo-04.txt The RADEXT WG Issues page discloses that 13 issues remain open against this document: http://www.drizzle.com/~aboba/RADEXT/ Based on a preliminary review of the -04 version, it appears that some of these open issues still have not been addressed. Some notes below: Section 2 " Furthermore, the authors believe that there is a relationship between the location of the network and the location of the entity that triggered the network access authentication. Knowing the location of a network (where the user or end host is attached to) might in many networks also reveal the location of the user or end host. In some networks it is even possible to provide a accurate location of the user or end host. A similar assumption is also made with regard to the location information obtained via DHCP (see for example [4]). This information might be used by applications in other protocols (such as SIP [12] with extensions [13]) to indicate the location of a particular user even though the location "only" refers to the location of the network or equipment within the network. The assumption here is also that the location of the network has some relationship to the location of the end host (and subsequently to a user). This assumption might not hold in all scenarios. Nevertheless, it seems to be reasonable." RADEXT Issue 27 points out that this assumption is not correct -- the location of the peer and the location of the NAS are not the same thing. There are APs today that are capable of providing the location of the user with a high degree of accuracy. Can those APs use this specification to provide the NAS and peer location information independently? Section 3.2 RADEXT Issue 74 points out problems with the way this document uses RFC 3576. The COA message may instruct the access network to generate an Authorize-Only Access-Request (Access- Request with Service-Type set to "Authorize-Only") in which case the NAS MUST include the location infromation in this Access-Request. This paragraph appears to retroactively update RFC 3576. Upon receiving the Authorize-Only message from the access network, the AAA server MUST respond with either an Access-Accept message or an Access-Reject message. This also sounds like an update of RFC 3576. Why should RFC 3576 behavior be different when location attributes are included? More fundamentally, why does RFC 3576 need to be used to obtain location information in mid-session when the same info is available in Accounting packets? Or is the issue that location data may not be included in Interim accounting information? I didn't notice a way that the RADIUS server can configure the way the NAS sends location info (e.g. don't send in interims, send at a given interval different from the interim interval, etc.) Section 4 How the network obtains the user's location information is out of the scope of this document. See RADEXT Issue 27. Obtaining the peer location is one of the fundamental usage scenarios for RADIUS-based location information. If this is out of scope for this specification, a different specification will be needed to address that issue. Why not handle both issues within the same document? Section 8 The capability attribute allows the RADIUS client to indicate whether civic and/or geospatial location information can be provided to the RADIUS server. This is useful to avoid sending location information with every request if no further out-of-band arrangements are made with regard to the transport of location information. The AAA server uses the capability attribute to indicate that the AAA client has to provide civic and/or geospatial location information as part of this particular protocol exchange. If the AAA server does not send a capability attribute then the AAA client MUST NOT return location information. The user's authorization policies MUST be consulted by the AAA server before requesting location information delivery from the AAA client. If the AAA server encounters that the AAA client does not support the desired location information it might respond with an Access-Reject with the corresponding error cause attribute (with the Location-Info-Required error code). The above paragraph seems vague about the nature of the capability negotiation. Terms like "might respond" imply a range of acceptable behaviors, which could result in interoperability problems. Since Access-Requests are initiated by the NAS, there is no way for the NAS to know beforehand whether a given RADIUS server requires location information or not. However, a NAS might default to not sending location information and then if the AAA server sends back an Access-Reject with a Location-Info-Required error code, then it could enable it. This seems to handle the case where the RADIUS server requires location (e.g. won't grant access without it). Based on the rest of Section 8, it appears that there are other scenarios in which the RADIUS server might like location information if available, but does not require it. In these cases, the RADIUS server could send back an Access-Accept with a request for location information, specifying what kind of location it is asking for (NAS or peer). If the NAS does not understand the attribute it will ignore it. Overall, it is not clear to me why the Capability attribute is needed, or if so, what the goal is. Section 11 Why is a capability attribute needed in an Access-Challenge? Why is "Location-Info-Required" a new attribute rather than a value of Error-Cause? Why are Basic-Policy-Rules, Extended-Policy-Rules, Capability and Location-Info-Required attributes allowed in an Access-Reject? -- to unsubscribe send a message to radiusext-request@ops.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, 24 Aug 2005 18:13:21 +0000 Date: Wed, 24 Aug 2005 11:13:04 -0700 (PDT) From: Bernard Aboba To: "Tschofenig, Hannes" cc: mankin@psg.com, rg+ietf@qualcomm.com, radiusext@ops.ietf.org, andy@hxr.us, dnelson@enterasys.com, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, farid.adrangi@intel.com Subject: Re: RADIUS-GEOPRIV and Capabilities Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > draft-lior-radext-end-to-end-caps-01.txt document) i would like to > confirm that > a) it is ok to define a registry in the radius-geopriv document and > b) to register two values (require for radius-geopriv) BTW, does the current GEOPRIV-RADIUS location document address the issues that were raised in RADEXT WG review? It is not clear to me that the kind of capability negotiation you are proposing makes sense in this application. RADIUS accounting servers can handle unknown attributes. Since a RADIUS server may be doing location-based authorization, a RADIUS client may need to send location or its Access-Request will be rejected. In that situation, the RADIUS client needs to send location before negotiation is possible. It seems like the issue could be handled without having the client announce capabilities at all. The client is set up by default to either send or not send location information. If the server has a problem with this, it rejects the request and indicates that location data is needed. Since Access-Reject messages cannot request a service, this probably needs to be accomplished via an error-message, rather than inclusion of a location attribute. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 24 Aug 2005 17:45:04 +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: [Isms] draft of ISMS charter Date: Wed, 24 Aug 2005 13:44:21 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032522@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWo0AQ9TNrJfZ1KRwiuAol9+Nfq5wAAfqfA From: "Nelson, David" To: "Juergen Quittek" , , Cc: , Juergen Quittek writes... (Cross posted to RADEXT and ISMS WG lists) > --On 8/22/2005 10:59 PM +0200 David B Harrington wrote: >=20 > > I think the definiton of RADIUS attributes for management belongs in > > RADEXT. >=20 > I also would prefer this option. > Do you think we should bring the issue to the RADEXT mailing list? Yes. As I have already indicated, we have an existing draft under consideration in RADEXT that contains this type of new attribute. It is fairly close to being ready for adoption as a WG work item. We could use this existing draft, or we could break it out as separate draft. I think the important things for ISMS to communicate to RADEXT are: (a) That ISMS has a requirement for standardization of a RADIUS attribute for the purpose of providing authorization of SNMPv3 access to the NAS (managed entity) via the ISMS mechanisms (i.e. SSH, etc.). (b) That the attribute will be used in the ISMS security method to map into one or more SNMP security parameters, such as securityName or groupName. (c) The desired milestone date for sending such an I-D to the IESG for approval, that aligns with the ISMS WG milestones. Since, I've already cross posted this message to RADEXT, we can use this as the starting point for discussions. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Aug 2005 21:33:23 +0000 Date: Mon, 22 Aug 2005 14:33:09 -0700 (PDT) From: Bernard Aboba To: Alper Yegin cc: radiusext@ops.ietf.org Subject: Re: RFC 2867/2868 question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I have a question though: It seems like we can use either RADIUS > Access-Request/Answer, or RADIUS Accounting Request/Answer for setting > up the compulsory tunnel. What is the rationale behind this > "flexibility"? When would you recommend using one or the other? I am not sure what "flexibility" you are talking about. RADIUS Accounting is not an authentication/authorization mechanism, it is an accounting protocol. RFC 2867 attributes are used to account for tunnel usage after they have been set up; the RFC 2868 attributes are used to authorize compulsory tunnels. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2005 20:51: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: Draft RADEXT WG Minutes from IETF-63 Date: Mon, 22 Aug 2005 16:50:25 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032511@MAANDMBX2.ets.enterasys.com> Thread-Topic: Draft RADEXT WG Minutes from IETF-63 Thread-Index: AcWnWx80e8lOWoGKRaal3JKn8a76Ew== From: "Nelson, David" To: Please review this draft of the minutes of the RADEXT WG session at = IETF-63. Kindly reply to the list with any errors or omissions you may = notice, by the end of this week (August 26). Thanks! -------------------------------------------------------------------------= --- IETF-63 RADEXT WG Minutes Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson) No jabberer. (Later Hannes Tschofenig joined the jabber room.) Bluesheets started. No agenda changes requested. Presentations and agenda online at: http://www.drizzle.com/~aboba/IETF63/radext/ RADEXT Issues Tracker location: http://www.drizzle.com/~aboba/RADEXT Streaming audio archive location: = http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-wed= .mp3.1 [start time index: 20:34] Brief status of WG work items: - 2684bis in AD follow-up - Dynauth MIBs completed WGLC, 9 issues - CUI in AD follow-up - Digest Auth completed WGLC xx issues - 802 Extensions in WGLC, 3 issues (so far) Presentations: - RFC2684 bis presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt Problem with internationalization found in IESG review. Added = clarifying text for ABNF vs. document text requirements and the use of = UTF-8 vs. IDN-unware ASCII for the realm part. Revision back to IESG = for approval -- very soon, e.g. about a week. Realm strings will be = IDN unaware (no "!"). - Chargeable User Identity presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-= 03.txt All issues have been addressed in the current version of the document. = Several SDOs are interested in this draft - WiMAX is one who will be = submitting a liaison letter to IETF for this. Pasi Eronen clarifies = that this document is in AD evaluation stage and not at the IESG. = Bernard may need to update the web-site to indicate the appropriate = document status. ID Tracker from IETF homepage is definitive on status. - Digest Authentication update by Wolfgang Beck. http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt Diameter compatibility is the current main issue with the document. = There is also an issue regarding client-side nonce generation when = interoperating with Diameter - additional text will be added to address = this. We could move forward two ways; one it get client side nonce = generation added to diameter, or simply drop this. The 3GPP2 liaison = would like to see client side nonce generation remain because they = currently use it. Avi Lior recommends that we operate in both modes of = operation and when working with Diameter, and get Diameter to update to = support client side nonce generation. The 3GPP2 people are waiting for = an RFC number on this document so they can publish their spec. The = security considerations need to be updated to discuss what to do when = realm check fails. There were also some typos that will be corrected. = Desire to get -04 version out shortly after IETF-63. - Dynamic Authorization MIBs - Greg Webber speaking for authors who = could not attend. http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-= 01.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-= 01.txt =20 These MIBs are companions to RFC 3576. They are expected to be = completed by the end of the year. Issues 96/97 have been resolved and = are simply editorial in nature. Issue 105 resolution relates to where = the MIBs are to be located in the OID tree. It is believed that new = MIBs should be rooted off of mib-2 and the authors are willing to make = the change to support this. Issue 92 is the most controversial. A few = new terms are defined by this document; DAC and DAS. It was suggested = to match RFC 3576 and not introduce new terms in MIB, however the terms = are embedded in all of the object names. It is still the belief of the = WG that the terms should be consistent and it sounds as though the = object names will be globally searched and replaced. Bernard Aboba: RFC = 3576bis would be within WG charter, and we could address the terminology = issues there. That would mean either delaying the MIBs or revising them = later. - 802 Extensions draft presented by Paul Congdon. http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt Discussed recent changes, but not current issue status. Changes include = removal of controversial (Diameter-like) extended attribute types, no = new data-types or M-bit, fleshed out the NAS-Filter-Rule, can now = specify L2 encapsulations, removed IP-redirection rule type in favor of = tunneling. Among the interested parties are TNC of TCG, 3GPP, WiMAX = (hot-lining). Glen Zorn questioned the chairs on why this document was = so quickly moved to last call. The chairs believe that the previous = issues in the individual submissions were sufficiently resolved and = there being a number of SDOs waiting on this document see the need to = expedite the review and closure of this document. WG last call closes = on Aug 10th. There was a question regarding when the wireless = attributes would be documented. There is a -00 draft on WLAN attributes = to be discussed on this later in the meeting. - RADIUS IPv6 MIBs discussed by Dave Nelson. http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt New textual conventions for address objects have been included. Review = comments from the MIB Doctors have been resolved in the -01 revisions. = The drafts UPDATE their predecessor RFCs, deprecate old tables (not = doing table augmenting anymore), added new tables to mirror old ones, = added specific usage guidelines new IP address objects. The question of = whether these should be WG work items was posed and no objections were = heard. The RADEXT -00 drafts will be created and moved to WG last call. - Common Radius Implementation Issues and Fixes presented by Dave = Nelson. http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt The document was created based upon a long laundry list of issues that = have been discussed on the mailing list. This document identifies many = of the problems identified in the field and makes suggestions to resolve = the problems. Areas discussed include:=20 - Proper use of the state attribute=20 - Request ID supplementation alternative=20 - Re-transmit schemes=20 - How to handle overload conditions=20 - Clarification of accounting attribute updates=20 - Clarification of using multiple Filter-ID attributes=20 - Treating access-accept for unknown services as a reject=20 - Avoiding sending VSAs to a NAS that doesn't understand them =20 A question about this recommendation is how to reliably detect supported = vs. unsupported VSAs. The capabilities attribute is a possible = solution. Glen Zorn suggested the possibility of a version number. = Since this is just -00, it was suggested to post issues against the = document. It was noted that some issues were currently in the tracker = but not yet included in the draft. - Corrections to RFC 2869, section 2.2 regarding miss-stated = Access-Challenge.=20 - Handling multiple services=20 - Defining how to calculate Message-Authenticator for Disconnect, COA = and others=20 - Authorize only discussion There were some questions of how this document should progress. The = document is useful, but perhaps an RFC 3576bis additionally needs to be = created. Also, some of the issues are against earlier RFCs as well. = These are standards track and may be more difficult to update. This = document is intended to address existing and past issues. Another = forward looking document discusses future issues. Other issues not = addressed were NASes with multiple IP addresses and accounting interval = updates. These should be included and consensus on a solution for these = needs to be proposed. - RADIUS Attribute Design Guidelines presented by Greg Weber. http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-00= .txt This is a forwarding looking document addressing design recommendations = for new attributes. This document describes what is considered a good = attribute design and reviews the current RADIUS data types, as well as = the divergence in the Standard and Vendor Specific data models. A few = have reviewed this document so far. The current document does include = some recommendations, but these are straw-man recommendations. The = motivation for this document is to get better alignment with data models = in vendor attributes, address attribute space exhaustion and align = better with diameter. The scope of the document includes consideration = for backward compatibility, existing VSAs, supporting the existing = transport, non-AAA applications and Diameter compatibility. The document = straw-man proposes a single standards base format for VSAs as a = recommendation. The document also includes recommendations on when = particular formats should be used and when to use existing VSA format = verse the new one. Lots to do on this draft. Avi Lior agrees this = document is a good starting point and is willing to work on the draft. = There was a question whether SDOs should be differentiated from Vendors, = but the group doesn't believe so. There was a question whether IANA = considerations are included, but the authors believe this is already = spelled out elsewhere. Glen Zorn asks if it was considered to extend = the size of RADIUS attributes rather than dealing with fragmentation. = Greg Weber did not consider this because he felt it would be beyond the = scope of the charter. - WLAN Attributes presented by Jari Arkko. http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt The list of attributes that were removed from the 802 Extensions draft = was presented. There is some overlap that needs to be discussed. = [Technical difficulties with slides caused us to move forward to the = next topic.] Upon return, some relationships to the EAP keying draft = were described. A list of key management attributes were described and = the issues. Privacy can be addressed similar to NAI and by omitting = Peer-ID and Server-ID attributes. Key-wrap options were described as = three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec. = The later is not used in industry. The key-wrap options may be = difficult to resolve. The questions on this document are whether this = should be a WG item and how to solve the privacy and key-wrap problems. - RADIUS attributes for Cryptographic Keys presented by Glen Zorn. http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt The motivation for this draft was to allow RADIUS to be used in certain = government environments. While RADIUS isn't a key provisioning = protocol, there are keys that are passed around in RADIUS and perhaps = aren't wrapped securely enough. Several editorial changes were made in = the -07 revision, but also HMAC-MD5 was removed and other key transport = attributes (e.g. MPPE-xxx) were outlawed if the same data is also = transferred in the new attributes. Questions about how keys are = transferred to the client - hop-by-hop or end-to-end? They are passed = along the path in the way they are set-up - may be hop-by-hop. Glen = plans to add AES-CMAC and some other technical changes in the -08 = revision. - General WG discussion on key-wrap issues. Glen Zorn points out that the keying issue is not just an 802.11 or = Wireless problem. Also, Glen points out that IPSec is inappropriate as = a protection mechanism for an application level protocol. Glen believes = NIST is in agreement that IPSec is not appropriate for this use. Nancy = Cam-Winget from Cisco summarized the NIST meeting that took place back = at the end of June. She also agrees that it isn't just wireless that = needs the keying solutions. They wanted to know if a new key-wrap = attribute with a new algorithm would be sufficient or would IPSec work. = The latest draft of the Zorn document has all the changes included based = upon the NIST discussion. Nancy indicated that NISTs reaction to IPSec = would require further review by NIST. Jari Arkko also believes the key = work isn't just for wireless and would like to see it in a separate = draft from other WLAN attributes. There was a question about the = relationship to the Zorn document and the Aboba document? We do have = attributes for WLAN as a charter item for this group, but can't = introduce new security mechanisms. Bernard's document comes from the = EAP key framework perspective. A question about a new message = authenticator algorithm and attribute being described by Glen. It can = be used in any RADIUS message because it is independent of the = authenticator value in the RADIUS message. Message-Authenticator cannot = be used in Accounting-Request or CoA messages. The new one is = cryptographically stronger; the old one is not FIPS compliant (MD5). = The new attribute can be used as a complete replacement of the old style = message authenticator. Alternatively, the old message authenticator = could still be used. Bernard's draft reuses the RADIUS shared secret, = while Glen's draft assumes a cryptographically separate pre-shared key. = Bill Burr cautions that NIST is not looking very closely at RADIUS usage = and so there isn't a good view of what is being done here. He = characterized the existing wireless key distribution mechanism (i.e. as = used in 802.11i with RADIUS) as somewhat "Rube Goldberg". Bill = described the process of obtaining a FIPS-140 certification and how = painful it may be for vendors. Glen points out that there is a lot of = interest in solving this problem and it has been solved, so why is there = a new WLAN draft addressing the keying mechanisms? Dave Nelson (Chair) = indicated that the keying problem seems to have a lot of interest. The = WG might consider amending its charter (security mechanism restriction) = to address this issue, if appropriate. - End-to-End capability exchange presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01.= txt The proposal describes an end-to-end, per-session mechanism to negotiate = capabilities. The attribute contains a string of octets where each = capability is encoded in 2 bits that define, not-supported, supported = and required. Avi points out other documents need this work; location = in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could = all use this. Should it be a WG document? No one objects to making = this a WG item, but we will confirm this on the list. This document = should be in alignment with Greg's work on Design Guidelines if we are = defining a new data type. - RADIUS Prepaid attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-= 08.txt The document was re-organized for read-ability and updated. Flow based = prepaid is becoming a requirement. Requested by 3GPP2 and WiMAX. The = difference between RADIUS credit control (a.k.a. prepaid) and Diameter = credit control was described. It is believed that some of the = differences are regarding some features that may compromise the privacy = of the client (e.g. balance check and cost inquiry). Other differences = are not clear yet and need to be discussed. How can Diameter credit = control and RADIUS prepaid be translated? The recommendation is that = the server must do this itself. A recommendation from the audience was = to have scenarios documented or analyzed - not necessarily included in = the draft, but available. Different SDOs are using Diameter and RADIUS, = and there will likely be some issues related to translation. Resolution = of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as = the RADEXT WG didn't anticipate supporting different "dialects" of the = prepaid extensions. The authors believe the document is ready to become = a WG item. Since the authors are not in complete alignment it was = suggested that they hash out their problems before making it a WG = document. The authors believe they have enough alignment, but being = out of time, we will continue the discussion on the WG mailing list. - RADIUS Bandwidth attributes presented by Avi Lior. http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabilit= y-01.txt Issues from Bernard Aboba's extensive review have all been addressed, = except one which is related to the length of the attribute size. Should = this be a WG document? Discuss on the WG mailing list. - RADIUS QoS attributes presented by Hannes Tschofenig. http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt Hannes describes a more general QoS environment. This work is related = to the Diameter work. They are addressing a generic description = described in NSIS QSPEC work. As compared to Avi Lior's bandwidth = document, this is a more heavy weight description. Avi's document is = viewed as a short term solution. There is the question of charter scope = in RADEXT.=20 - General WG Discussion about QoS and Bandwidth. Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as = a resource management protocol. She believes that RSVP and NSIS are the = protocols to do resource allocation. There was an RSVP and Diameter = document that is similar to proposed RADIUS document. John Loughney = comments that the Diameter QoS document is an individual submission and = not a current AAA WG document. John will post the link to the RADEXT WG = mailing list for this document, so that we can review it. Allison = mentions that we don't want to start extending the bandwidth draft to = include a bunch of new things like latency and jitter, but they are = happy with simple rates that are currently defined. Combining Avi's = bandwidth draft and Hannes' QoS draft would certainly delay the simple = bandwidth parameter attribute that has been requested by other SDOs. A = comment from 3GPP is that they are depending upon the bandwidth draft to = be complete for reference in their specification release 7, by mid-2006. = The group doesn't believe they should be combined. Dave Nelson (Chair) = asked what the overlap is between the documents. Avi points out that = the QoS "blob" includes a bandwidth component and could be used, but = John Loughney and the other authors believe there may be a solution on = how cross reference the documents and avoid overlap. Dave (Chair) = indicated he would work to facilitate the cross-WG and cross-Area = coordination that will be required to move forward in this area. =A0 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Aug 2005 18:45: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 keywrap attributes Date: Mon, 22 Aug 2005 14:44:54 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250D@MAANDMBX2.ets.enterasys.com> Thread-Topic: RADIUS keywrap attributes Thread-Index: AcWmIjK/+pHLcji3TQWpD03nsPmhVwAX7o7QACnxJYAAB2FDIAAAVInQ From: "Nelson, David" To: "Glen Zorn \(gwz\)" , "Bernard Aboba" , Cc: "Zhang, Tiebing" , "Russ Housley" Glen Zorn writes... > Hmm. Since RADIUS clients and servers are required to ignore unknown > packet types (by specification, not tradition), I don't really understand > why this same logic would not apply to the protocol in general. I would suggest that one level of forwards and backwards compatibility is obtained by ignoring individual attributes that are not understood, while a very different (IMHO much lower) level of compatibility might be obtained by ignoring entire protocol PDUs. This discussion side-steps the whole issue of whether new attributes (or indeed new commands) may safely be ignored by either clients or servers, if the subject matter of said protocol elements is important or "security sensitive". We have the Mandatory header bit in Diameter to address this issue. I don't see any good solution to this problem, short of adding a Mandatory bit in RADIUS attributes, which raises a whole other backwards compatibility issue.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 22 Aug 2005 18:36:38 +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: RADIUS keywrap attributes Date: Mon, 22 Aug 2005 11:35:57 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625952DF7@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADIUS keywrap attributes Thread-Index: AcWmIjK/+pHLcji3TQWpD03nsPmhVwAX7o7QACnxJYAAB2FDIA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" , "Bernard Aboba" , Cc: "Zhang, Tiebing" , "Russ Housley" Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >>> So yes, keying attributes are within the RADEXT WG charter. >>=20 >> I suppose that, as David mentioned, this is a matter that is open to >> interpretation. However, the current charter states that "No new >> security mechanisms will be defined for protecting RADIUS." Taking >> the position (which I think reasonable) that RADIUS includes >> attributes and their allowable contents, it would seem to me that an >> attribute that cryptographically protects its contents is, in fact, >> a new security mechanism. >=20 > The intent of the charter prohibition on "new security mechanisms" > was to preclude the specification of incompatible revisions to > RADIUS, that would mandate upgrades to existing RADIUS > implementations. Since RADIUS was designed without the benefit of a > security method negotiation or selection mechanism, it's likely quite > difficult to add new PDU-level security mechanisms in a backwards > compatible fashion. Since RADIUS implementations have traditionally > ignored new attributes, introduced after the implementation, adding > new security within the scope of a single attribute does not present > the same level of backwards compatibility issues. =20 Hmm. Since RADIUS clients and servers are required to ignore unknown = packet types (by specification, not tradition), I don't really = understand why this same logic would not apply to the protocol in = general.=20 =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: Mon, 22 Aug 2005 16:04: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: Issue: Radius Digest, both modes of operation should be mandatory Date: Mon, 22 Aug 2005 12:03:43 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250A@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Radius Digest, both modes of operation should be mandatory Thread-Index: AcWm4PwnyiQRrXYsRU2tuomY4r3S/AAUYgBQ From: "Nelson, David" To: "Miguel Garcia" , "Beck01, Wolfgang" Cc: Miguel Garcia writes... > I didn't take the same approach for the analysis. Instead, I thought > that if you are doing an interoperability test between two independently > developped implementations, one implementation might have implemented a > Radius client that supports only nonces generated in the Radius client > and the other implementation might have implemented a Radius server that > only supports nonces generated in the Radius server. >=20 > Both implementation will be compliant to your draft, but unable to > interoperate. And will not be able to recover from any error. >=20 > To me this is a severe design failure, and I am trying to avoid it. I > think that the burden of implementing support for both modes of > operation is almost negligible compared to the burden of not being able > to interoperate. So for the sake of interoperability I would suggest to > mandate the support for both modes of operation in both RADIUS clients > and servers. I tend to agree with Miguel. If we are standardizing Digest Authentication within RADIUS, the traditional multi-vendor interoperability considerations should apply. Suggesting that cross-vendor interoperability will not occur in practical deployments may be correct, at least in some cases. Still, having an RFC that documents inherently non-interoperable protocol options seems like a poor choice. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2005 15:09:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS keywrap attributes Date: Mon, 22 Aug 2005 11:09:15 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032506@MAANDMBX2.ets.enterasys.com> Thread-Topic: RADIUS keywrap attributes Thread-Index: AcWmIjK/+pHLcji3TQWpD03nsPmhVwAX7o7QACnxJYA= From: "Nelson, David" To: "Glen Zorn \(gwz\)" , "Bernard Aboba" , Cc: "Zhang, Tiebing" , "Russ Housley" Glen Zorn writes... > > So yes, keying attributes are within the RADEXT WG charter. >=20 > I suppose that, as David mentioned, this is a matter that is open to > interpretation. However, the current charter states that "No new security > mechanisms will be defined for protecting RADIUS." Taking the position > (which I think reasonable) that RADIUS includes attributes and their > allowable contents, it would seem to me that an attribute that > cryptographically protects its contents is, in fact, a new security > mechanism. The intent of the charter prohibition on "new security mechanisms" was to preclude the specification of incompatible revisions to RADIUS, that would mandate upgrades to existing RADIUS implementations. Since RADIUS was designed without the benefit of a security method negotiation or selection mechanism, it's likely quite difficult to add new PDU-level security mechanisms in a backwards compatible fashion. Since RADIUS implementations have traditionally ignored new attributes, introduced after the implementation, adding new security within the scope of a single attribute does not present the same level of backwards compatibility issues. I would further suggest that *if* the issues at hand, i.e. modifications to RADIUS to allow FIPS certification of systems that include RADIUS as a component, are of sufficient importance to the Internet Community, then we should consider amending the charter to allow that work in RADEXT, understanding that backwards compatibility is still an issue. It would, IMHO, be a Bad Idea (tm) for this work of this significance to be undertaken as individual submissions, when we have a WG working in this area. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2005 06:15:50 +0000 Message-ID: <43096D72.50105@nokia.com> Date: Mon, 22 Aug 2005 09:15:14 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: radiusext@ops.ietf.org Subject: Re: Issue: Radius Digest, both modes of operation should be mandatory Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wolfgang: I didn't take the same approach for the analysis. Instead, I thought that if you are doing an interoperability test between two independently developped implementations, one implementation might have implemented a Radius client that supports only nonces generated in the Radius client and the other implementation might have implemented a Radius server that only supports nonces generated in the Radius server. Both implementation will be compliant to your draft, but unable to interoperate. And will not be able to recover from any error. To me this is a severe design failure, and I am trying to avoid it. I think that the burden of implementing support for both modes of operation is almost negligible compared to the burden of not being able to interoperate. So for the sake of interoperability I would suggest to mandate the support for both modes of operation in both RADIUS clients and servers. /Miguel Beck01, Wolfgang wrote: > What scenarios do we have? > > 1) plain IETF SIP providers, web servers, using HTTP Digest > - client-side nonce generation is sufficient > > 2) plain IETF SIP providers, web servers, using AKA Digest > - server-side nonce generation is required > > 3) providers using Diameter servers > - server-side nonce generation is required, as Diameter does not (yet?) support > client-side nonce generation. > > 4) 3GPP2 IMS > - client-side nonce generation is required > > Will there be mixed environments? > > A) RADIUS clients connected to distinct service providers (RADIUS roaming using NAI) > - This is unlikely in SIP/HTTP environments, as RADIUS is not used for layer 2 > access authentication here. A user can access directly his SIP/HTTP server. > This is different from the classical RADIUS use. > > In IMS -- where there is a coupling between SIP and lower layers --, roaming > is done on the the SIP level. As far as I know, there is no RADIUS or Diameter > connection between different IMS providers. > > B) A provider changes its equipment gradually from plain HTTP digest to AKA digest. > > In the case of Digest Authentication, RADIUS clients are never talking to RADIUS > or Diameter servers of a different provider. > > My feeling is that there will be providers that will never bother about server-side > nonce generation. Others will never consider client-side nonce generation. Mandating > both modes will only complicate the initial configuration for them. > > What does the group think? > > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- to unsubscribe send a message to radiusext-request@ops.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, 22 Aug 2005 01:21: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: RE: RADIUS keywrap attributes Date: Sun, 21 Aug 2005 18:17:46 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625952C8E@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADIUS keywrap attributes Thread-Index: AcWmIjK/+pHLcji3TQWpD03nsPmhVwAX7o7Q From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" , Cc: "Zhang, Tiebing" , "Russ Housley" Bernard Aboba <> supposedly scribbled: >>> I was under the impression that this was outside the scope of the WG >>> charter. Has this changed recently? >=20 > The RADEXT WG charter was written based on liaison requests from SDOs > including IEEE 802.11. The IEEE 802 attribute draft, developed to > respond to those requests, included keying attributes from the > beginning. =20 The keying attribute you mention was such in name only; it provided no = security for the encapsulated key, since it was assumed that security = would be supplied by running RADIUS over IPsec. > So yes, keying attributes are within the RADEXT WG charter. I suppose that, as David mentioned, this is a matter that is open to = interpretation. However, the current charter states that "No new = security mechanisms will be defined for protecting RADIUS." Taking the = position (which I think reasonable) that RADIUS includes attributes and = their allowable contents, it would seem to me that an attribute that = cryptographically protects its contents is, in fact, a new security = mechanism. >=20 > While keying attributes are within the scope of the RADEXT WG > charter, I am not clear what the criteria are for IESG approval. > Satisfying the requirements in "AAA Key Management" (draft-housley) > could prove quite difficult. One of the requirements of > draft-housley is to avoid disclosure of keying material to > unauthorized parties. This hurdle was overcome in RFC 4072 using > Diameter redirect. =20 It's not at all clear that the redirect technique actually solves any = problem; for example, the keying problem is basically ignored, although = there are probably ways to solve it. =20 >=20 > However, it is not clear to me that it would be possible to retrofit > a redirect mechanism within RADIUS. Since CMS failed to gain > traction within Diameter, I see no reason why that would be viable > for RADIUS, either. The presentation at IETF 63 discussed a number > of other alternatives, some of which are subjects of current research > (the DNSSEC approach under development within Terena). =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: Sun, 21 Aug 2005 21:28:42 +0000 Date: Sun, 21 Aug 2005 14:28:24 -0700 (PDT) From: Bernard Aboba To: "Nancy Winget (ncamwing)" cc: radiusext@ops.ietf.org, "Zhang, Tiebing" , Russ Housley , "Pat Calhoun (pacalhou)" Subject: RE: RADIUS keywrap attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If we can agree that this is a work item for this group, then we can > discuss the merits of the different proposed approaches by either > draft-zorn-radius-keywrap-08.txt or your newly proposed > draft-aboba-radext-wlan-00.txt and make progress on this particular > requirement. I believe that the issue of keywrap is within the scope of the RADEXT WG charter, so that discussing it on the RADEXT WG mailing list is appropriate. > We can always determine the criteria for IESG approval as well but that > should not stall our progress in addressing this requirement. I agree that we should not wait to move forward, but past history shows that getting IESG input early on is likely to avoid a lot of pain down the road. The original RADIUS WG was not permitted to work on RADIUS keywrap attributes, and that is why the VSAs documented in RFC 2548 needed to be developed. Prior to the approval of RFC 4004 (Diameter MIP) and RFC 4072 (Diameter EAP), the IETF had not published any AAA key management documents developed by an IETF WG as RFCs; both of these documents took more than 5 years to go from an initial submission to publication as RFCs. In order to avoid the problems that have been experienced in the past, it would be nice to know that what criteria are believed to apply to the work beforehand, so that we don't go through a lot of effort only to find out that the document is unacceptable to the IESG, requiring years of rework. My understanding is that all AAA key management documents submitted for publication as RFCs need to meet the criteria established in: http://www.ietf.org/internet-drafts/draft-housley-aaa-key-mgmt-00.txt However, given that RADIUS is a mature, widely deployed protocol, there are practical limits on the scale of changes that can be made in order to meet these criteria. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2005 20:39:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS keywrap attributes Date: Sun, 21 Aug 2005 13:38:55 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D8867C0F@xmb-sjc-222.amer.cisco.com> Thread-Topic: RADIUS keywrap attributes Thread-Index: AcWmIjKs5ujPc4k/Rqmx5WUdGce4jgAbEpQg From: "Nancy Winget \(ncamwing\)" To: "Bernard Aboba" , Cc: "Zhang, Tiebing" , "Russ Housley" , "Pat Calhoun \(pacalhou\)" The proposed draft-zorn-radius-keywrap-08.txt focuses mainly on the keying attributes which we believe need to be protected and has been a requirement for quite some time now. Draft-zorn-radius-keywrap-08.txt does not attempt to introduce a full new security mechanism to RADIUS as is suggested by draft-aboba-radext-wlan-00.txt but merely addresses how the keying material should be protected. If we can agree that this is a work item for this group, then we can discuss the merits of the different proposed approaches by either draft-zorn-radius-keywrap-08.txt or your newly proposed draft-aboba-radext-wlan-00.txt and make progress on this particular requirement. We can always determine the criteria for IESG approval as well but that should not stall our progress in addressing this requirement. Nancy. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Sunday, August 21, 2005 12:29 AM To: radiusext@ops.ietf.org Cc: Zhang, Tiebing; Russ Housley Subject: RE: RADIUS keywrap attributes > > I was under the impression that this was outside the scope of the WG > > charter. Has this changed recently? The RADEXT WG charter was written based on liaison requests from SDOs including IEEE 802.11. The IEEE 802 attribute draft, developed to respond to those requests, included keying attributes from the beginning. =20 So yes, keying attributes are within the RADEXT WG charter. While keying attributes are within the scope of the RADEXT WG charter, I am not clear what the criteria are for IESG approval. Satisfying the requirements in "AAA Key Management" (draft-housley) could prove quite difficult. One of the requirements of draft-housley is to avoid disclosure of keying material to unauthorized parties. This hurdle was overcome in RFC 4072 using Diameter redirect. However, it is not clear to me that it would be possible to retrofit a redirect mechanism within RADIUS. Since CMS failed to gain traction within Diameter, I see no reason why that would be viable for RADIUS, either. The presentation at IETF 63 discussed a number of other alternatives, some of which are subjects of current research (the DNSSEC approach under development within Terena). =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: -- to unsubscribe send a message to radiusext-request@ops.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, 21 Aug 2005 07:30:09 +0000 Date: Sun, 21 Aug 2005 00:29:21 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org cc: "Zhang, Tiebing" , Russ Housley Subject: RE: RADIUS keywrap attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > I was under the impression that this was outside the scope of the WG > > charter. Has this changed recently? The RADEXT WG charter was written based on liaison requests from SDOs including IEEE 802.11. The IEEE 802 attribute draft, developed to respond to those requests, included keying attributes from the beginning. So yes, keying attributes are within the RADEXT WG charter. While keying attributes are within the scope of the RADEXT WG charter, I am not clear what the criteria are for IESG approval. Satisfying the requirements in "AAA Key Management" (draft-housley) could prove quite difficult. One of the requirements of draft-housley is to avoid disclosure of keying material to unauthorized parties. This hurdle was overcome in RFC 4072 using Diameter redirect. However, it is not clear to me that it would be possible to retrofit a redirect mechanism within RADIUS. Since CMS failed to gain traction within Diameter, I see no reason why that would be viable for RADIUS, either. The presentation at IETF 63 discussed a number of other alternatives, some of which are subjects of current research (the DNSSEC approach under development within Terena). -- to unsubscribe send a message to radiusext-request@ops.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, 19 Aug 2005 11:34:51 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121E4C@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: Miguel.An.Garcia@nokia.com Subject: Re: Issue: Radius Digest, both modes of operation should be manda tory Date: Fri, 19 Aug 2005 13:33:58 +0200 MIME-Version: 1.0 Content-Type: text/plain What scenarios do we have? 1) plain IETF SIP providers, web servers, using HTTP Digest - client-side nonce generation is sufficient 2) plain IETF SIP providers, web servers, using AKA Digest - server-side nonce generation is required 3) providers using Diameter servers - server-side nonce generation is required, as Diameter does not (yet?) support client-side nonce generation. 4) 3GPP2 IMS - client-side nonce generation is required Will there be mixed environments? A) RADIUS clients connected to distinct service providers (RADIUS roaming using NAI) - This is unlikely in SIP/HTTP environments, as RADIUS is not used for layer 2 access authentication here. A user can access directly his SIP/HTTP server. This is different from the classical RADIUS use. In IMS -- where there is a coupling between SIP and lower layers --, roaming is done on the the SIP level. As far as I know, there is no RADIUS or Diameter connection between different IMS providers. B) A provider changes its equipment gradually from plain HTTP digest to AKA digest. In the case of Digest Authentication, RADIUS clients are never talking to RADIUS or Diameter servers of a different provider. My feeling is that there will be providers that will never bother about server-side nonce generation. Others will never consider client-side nonce generation. Mandating both modes will only complicate the initial configuration for them. What does the group think? 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: Thu, 18 Aug 2005 18:00: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: Issue 121: Data Representation Date: Thu, 18 Aug 2005 13:59:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F9@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 121: Data Representation Thread-Index: AcWj7mjyip5C10j+QtySMfQMxlAJfwAL4ZnA From: "Nelson, David" To: "Beck01, Wolfgang" , Wolfgang Beck writes... > I've used the description in RfC 2617, Section 3.2.1 >=20 > "nonce > A server-specified data string which should be uniquely generated > each time a 401 response is made. It is recommended that this > string be base64 or hexadecimal data. " >=20 > As the nonce is only interpreted by the nonce generator, interopability > is not required. Perhaps adding that last sentence, of some variant, to the text of the draft would clarify that this is an opaque (to RADIUS) nonce, in which case its encoding is not required to be specified to obtain interoperability. In that case the attribute value should perhaps be String, with the advisory that robust implementations shout treat it as undistinguished octets. -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2005 14:03:26 +0000 Message-ID: <430494AF.5070405@nokia.com> Date: Thu, 18 Aug 2005 17:01:19 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: radiusext@ops.ietf.org CC: "Beck01, Wolfgang" Subject: Issue: Radius Digest requirement to clients Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Submitter name: Miguel Garcia Submitter email address: Miguel.An.Garcia@nokia.com Date first submitted: August 18, 2005 Reference: - Document: draft-ietf-radext-digest-auth-03.txt Comment type: T Priority: '1' Should fix Section: 1.2 Rationale/Explanation of issue: The text imposes a requirement for RADIUS client that is both unimplementable and untestable. The text reads: "If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. " The text seems to suggest that if a RADIUS server is generating a nonce then the RADIUS client must make sure that it does not generate a nonce. These seems to imply a sequence where first the RADIUS server does an action (generate or not a nonce), and then the RADIUS client does a consequent action (not generate or generate a nonce). However, the sequence of events (see the scenarios in Sections 1.3.1 and 1.3.2) is that it is the RADIUS client the first entity that has to decide whether to generate a nonce or not (I assume that based on configuration), and then the RADIUS server can operate consequently. Requested change: I see two possibilities here, please choose one. Possibility 1: ============== To describe that the RADIUS servers and clients do not verify whether a nonce has been previously generated by the correspondent node. However, this must be pre-agreed and pre-configured before operation. In this case, I suggest to delete the text above mentioned and add the following: "This specification assumes that both the RADIUS client and server are appropriately configured to generate the nonces in either the RADIUS client or the RADIUS server, but not in both at the same time. Implementations, though, do not have the means to verify this behaviour." Possibility 2: ============== To enforce that nonces are generated appropriately. I have my doubts whether this is achievable or not, espcially considering the case of HTTP Digest authentication using AKA (RFC 3310), because it requires to generate nonces always in the RADIUS server. In addition to this, we would need to consider the error cases and the recovery from them. If someone wants to pursue this track, please provide text for discussion. -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2005 13:44:30 +0000 Message-ID: <430490AD.2030102@nokia.com> Date: Thu, 18 Aug 2005 16:44:13 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: radiusext@ops.ietf.org CC: "Beck01, Wolfgang" Subject: Issue: Radius Digest, both modes of operation should be mandatory Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Submitter name: Miguel Garcia Submitter email address: Miguel.An.Garcia@nokia.com Date first submitted: August 18, 2005 Reference: - Document: draft-ietf-radext-digest-auth-03.txt Comment type: T Priority: '1' Should fix Section: 1.2 Rationale/Explanation of issue: The draft contains two modes of operation, in one the nonces are generated in the RADIUS client, in the other, nonces are generated in the RADIUS server. The text reads: "RADIUS clients and servers can support one, or both nonce generation modes." So how is interoperability going to be granted if a RADIUS client implements only one mode and the RADIUS server implements the other? In my opinion what has been pursued here is to not add additional complexity to the implementation. But the generation of a nonce does not add almost any complexity, so I would say that both modes have to be supported in the sake of interoperability. In addition to that, the text does not have a normative statement (only speaks about "can"). The text should be normative, and should be placed outside the Overview section, which is informative by nature. Requested change: Add the following text elsewhere (Section 2?): "RADIUS clients and servers MUST implement support for the two modes of operation: when nonces are generated in the RADIUS server and when nonces are generated in the RADIUS client." And delete the existing text in Section 1.3 "RADIUS clients and servers can support one, or both nonce generation modes." -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland -- to unsubscribe send a message to radiusext-request@ops.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, 18 Aug 2005 12:14:15 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121E43@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: aboba@internaut.com, radiusext@ops.ietf.org Subject: Re: Issue 121: Data Representation Date: Thu, 18 Aug 2005 14:13:46 +0200 MIME-Version: 1.0 Content-Type: text/plain Bernard wrote: > In Section 3.5, it says: > > " Text > It is recommended that this text be base64 or hexadecimal data." > > For interoperability, you need to choose the representation > or at least specify how it can be determined which > representation is to be used. > I've used the description in RfC 2617, Section 3.2.1 "nonce A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that this string be base64 or hexadecimal data. " As the nonce is only interpreted by the nonce generator, interopability is not required. Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 17 Aug 2005 17:34:12 +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 119: More NITs; table format Date: Wed, 17 Aug 2005 13:33:43 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F4@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 119: More NITs; table format Thread-Index: AcWjQvFMmptl8NH+T2auVH/XIaVr6wADlwDQ From: "Nelson, David" To: "Beck01, Wolfgang" , Wolfgang Beck writes... > - The xml2rfc tool adds borders to the table and I haven't found a=20 > way to disable this. Replacing the table with ASCII art is an option, > but it wouldn't look good in xml2rfc's html output (and I don't know > how the tool handles page breaks with large ascii art). I'm a reasonably new user of xlm2rfc, but I have chosen to use the artwork solution to preserve traditional ASCII RFC text formatting. I suspect that I have done this that the expense of the HTML version of the document. I haven't found another solution, however. -- to unsubscribe send a message to radiusext-request@ops.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, 17 Aug 2005 15:44:20 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121E3D@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: aboba@internaut.com, radiusext@ops.ietf.org Subject: AW: Issue 119: More NITs; table format Date: Wed, 17 Aug 2005 17:43:53 +0200 MIME-Version: 1.0 Content-Type: text/plain Bernard wrote: > Section 2.1 > > .. Change .. To: > Where an HTTP-style request traverses several proxies and each of the > proxies requests to authenticate the HTTP-style client the request at > the HTTP-style server may contain multiple credential sets. I've added a comma after "HTTP-style client": "Where an HTTP-style request traverses several proxies and each of the proxies requests to authenticate the HTTP-style client, the request at the HTTP-style server may contain multiple credential sets." > Section 5 > > Please reformat the attribute table in the format used in > other RADIUS RFCs, such as RFC 2865 Section 5.44: > > The following table provides a guide to which attributes may > be found in which kinds of packets, and in what quantity. > > Request Accept Reject Challenge # Attribute > 0-1 0-1 0 0 1 User-Name > 0-1 0 0 0 2 User-Password [Note 1] > Two remarks: - Placing the attribute name in the last column seems a bit strange to me - The xml2rfc tool adds borders to the table and I haven't found a way to disable this. Replacing the table with ASCII art is an option, but it wouldn't look good in xml2rfc's html output (and I don't know how the tool handles page breaks with large ascii art). 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, 16 Aug 2005 21:23: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: Issue: Editorial comments on draft-ietf-radext-digest-auth-03.txt Date: Tue, 16 Aug 2005 17:21:42 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F1@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-digest-auth-03.txt Thread-Index: AcWiqH75sGPZD/K+T4icXBNruSyZdw== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 16, 2005 Reference: Document: DIGEST-03 Comment type: 'E' Editorial Priority: '1' Should fix Section: 1.1, 1.3, 2.1, 4.1, 4.2. 4.3 (1) Rationale/Explanation of issue: 1.1 Terminology This document includes many instances of the normative keywords. It does not clarify that the usage applies only to RADIUS Clients and Server that implement the digest authentication feature described in the document. While this may be obvious to some, certain text would appear to be creating retroactive normative requirements on existing implementations. Requested changes: Add the following text at the end of Section 1.1: "The use of normative requirement key words in this document shall apply only to RADIUS Client and RADIUS Server implementations that include the features described in this document. This document creates no normative requirements for existing implementations." (2) Rationale/Explanation of issue: Typographical errors. Requested Changes: 1.3 Overview In the fourth paragraph: s/where Digest authentication is/where Digest Authentication is/ In the eighth paragraph: s/a configurable parameter/a configurable parameter./ 2.1 RADIUS Client Behavior In the second paragraph: s/are situation where/are situations where/ s/MUST send zero or exactly one/MUST send exactly zero or one/ (3) Rationale/Explanation of issue: Confusing text. The third paragraph contains the phrase "If the RADIUS client recognizes the nonce...". This could use some clarification. The definition of "nonce" in Section 1.1 is "An unpredictable value...". How is it possible for the RADIUS client to recognize an unpredictable value? Does this simply that the RADIUS client maintains a history of recently used nonce values? Or is there another meaning? Requested changes: Please add clarification. (4) Rationale/Explanation of issue: Move Diameter gateway considerations to the Diameter SIP Application draft. 4.1 RADIUS Client Diameter Server 4.1 Diameter Client, RADIUS Server 4.3 Limitations Requested Changes: Delete these sections and add a general reference to the Diameter SIP draft. This presumes, of course, that consensus is concurrently obtained in the AAA WG to make this change. -- to unsubscribe send a message to radiusext-request@ops.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, 16 Aug 2005 19:02:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RADIUS FIXES] Authorize Only / RADIUS layering Date: Tue, 16 Aug 2005 15:02:31 -0400 Message-ID: Thread-Topic: [RADIUS FIXES] Authorize Only / RADIUS layering Thread-Index: AcWSwvdNSjLkzkM/Ry2fZJWIrmOgpgADoqkQAB7tNoAC0rOWYA== From: "Avi Lior" To: , , Hi Pasi, Snip... > I think Avi's example of using "Authorize Only" for=20 > replenishing prepaid quota is a good example of this. The=20 > syntax of the attributes is defined in IETF specs, but actual=20 > interoperability requires some agreement of how the messages=20 > are acted upon that not's specified in any IETF document.=20 > (I'm not sure if it's specified in any document, in fact...) I agree with your points. But in the case of prepaid, I think the syntax and semantics is described in the RADIUS prepaid document. The same would be the case for Diameter Credit Control. However, in a case of the upcoming QoS Blob RADIUS work and even Mobile-IPv4 work and even PANA, the semantics are covered in other documents and therefore the RADIUS documents should reference the documents rather then repeat the information. > 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 -- to unsubscribe send a message to radiusext-request@ops.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, 14 Aug 2005 18:48:04 +0000 Date: Sun, 14 Aug 2005 11:47:24 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Last look at RFC 2486bis... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The current version of RFC 2486bis is believed to have addressed all outstanding issues. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt We are asking participants in the RADEXT WG to take one last look at the document. Please post your comments to the RADEXT WG mailing list by Friday, August 19, 2005. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 13 Aug 2005 00:36:21 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: ISSUE: Request Authenticator validation in RFC 2866 Date: Fri, 12 Aug 2005 20:35:24 -0400 Message-Id: <20050813003525.1702E16CCA@mail.nitros9.org> Description of issue: No requirement for Request Authenticator validation in RFC 286 Submitter name: Alan DeKok Submitter email address: aland@ox.org Date first submitted: August 12, 2005 Reference: URL to e-mail describing problem, if available Document: RFC 2866 Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: The text defining the Response Authenticator for Accounting-Response packets says that "invalid packets are silently discarded", but no such text exists for the Request Authenticator in Accounting-Request packets. Suggested fix: Add following text to "issues & fixes draft" RFC 2866, Section 4.1 says: Request Authenticator The Request Authenticator of an Accounting-Request contains a 16-octet MD5 hash value calculated according to the method described in "Request Authenticator" above. The text is incomplete, as it does not indicate any action to take when an Accounting-Request packet contains an invalid Request Authenticator. The following text should be considered to be part of the above description: The Request Authenticator field MUST contain the correct data, as given by the above calculation. Invalid packets are silently discarded. Note that some early implementations always set the Request Authenticator to all zeros. New implementations of RADIUS clients MUST use the above algorithm to calculate the Request Authenticator field. New implementations of RADIUS servers MUST silently discard invalid packets. We may also want to add a note to the Security Considerations section of the "Issues and fixes" draft. RADIUS server implementations which accept a Request Authenticator of all zeros are subject to various attack scenarios. 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, 12 Aug 2005 21:30:53 +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 Issue 81 Date: Fri, 12 Aug 2005 17:29:23 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E3@MAANDMBX2.ets.enterasys.com> Thread-Topic: RE: RADEXT Issue 81 Thread-Index: AcWfhOhBnHTYEs/aSuulBcuGhAKHtA== From: "Nelson, David" To: The authors believe that the -02 version of this draft addresses RADEXT = Issue 81.=20 ------------------ A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : RADIUS NAS-Management Authorization Author(s) : G. Weber, D. Nelson Filename : draft-nelson-radius-management-authorization-02.txt Pages : 18 Date : 2005-8-12 =09 This document describes RADIUS attributes for the authorization and =A0=A0 service provisioning of local and remote management of embedded =A0=A0 systems and other managed entities (NASes).=A0 Specific = provisions are =A0=A0 made for remote management via framed management protocols, and = for =A0=A0 more granular levels of security and command privilege level = beyond =A0=A0 those included in the base RADIUS specification.=A0 Provisions = are also =A0=A0 introduced for enhancing auditability of individual management =A0=A0 operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nelson-radius-management-author= ization-02.txt --------------- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 12 Aug 2005 03:07:26 +0000 Date: Thu, 11 Aug 2005 20:06:55 -0700 (PDT) From: Bernard Aboba To: Narayanan Vidya-CVN065 cc: "'Emile van Bergen'" , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The most recent IEEE 802.11r draft eliminates portions of the key hierarchy and also mandates that the Authenticator and AAA client reside on the same entity. There is still discussion on the interactions between NASes. RFC 3580 describes how Accounting-Start messages can be sent in handover situations. On Thu, 11 Aug 2005, Narayanan Vidya-CVN065 wrote: > Emile, Bernard, > Thanks for the clarification on the accounting issues. > > Does anyone know how this will work with 802.11r-like key hierarchy? As > per the key hierarchy, it seems like the station will have to establish > the MSK by contacting the R0 key holder. However, the PTK it shares is > with the R2 key holder. So, technically, the PMK-R0 is only used to > derive the PMK-R1 and the latter to derive PMK-R2. I would imagine the > RADIUS client would reside in the R0-KH - right? However, the station > may handoff to different R2-KHs within the same R0-KH - how and when > will accounting-start messages be sent in this case? Or, is it that the > accounting messages only need to be sent when the station first derives > the PMK-R0? > > About IAPP, I wasn't referring to the use of it here. I think mandating > use of IAPP for sake of authentication or accounting perhaps leads to > more complications. -- to unsubscribe send a message to radiusext-request@ops.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, 12 Aug 2005 02:12:05 +0000 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A72D5@il02exm13> From: Narayanan Vidya-CVN065 To: "'Emile van Bergen'" , Bernard Aboba Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Date: Thu, 11 Aug 2005 21:11:47 -0500 MIME-Version: 1.0 Content-Type: text/plain Emile, Bernard, Thanks for the clarification on the accounting issues. Does anyone know how this will work with 802.11r-like key hierarchy? As per the key hierarchy, it seems like the station will have to establish the MSK by contacting the R0 key holder. However, the PTK it shares is with the R2 key holder. So, technically, the PMK-R0 is only used to derive the PMK-R1 and the latter to derive PMK-R2. I would imagine the RADIUS client would reside in the R0-KH - right? However, the station may handoff to different R2-KHs within the same R0-KH - how and when will accounting-start messages be sent in this case? Or, is it that the accounting messages only need to be sent when the station first derives the PMK-R0? About IAPP, I wasn't referring to the use of it here. I think mandating use of IAPP for sake of authentication or accounting perhaps leads to more complications. Vidya > -----Original Message----- > From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] > Sent: Thursday, August 11, 2005 7:21 PM > To: Bernard Aboba > Cc: Narayanan Vidya-CVN065; radiusext@ops.ietf.org; > aaa-wg@merit.edu; Korus Mike-CMK013 > Subject: Re: AAA for Handovers > > > Hi, > > On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote: > > > > However, AAA servers can authenticate accounting messages by > > > including a Class attribute in its access accept message. > According > > > to RFC2865, the NAS SHOULD echo the given A/V pair, regardless of > > > value, in all its accounting messages that pertain to the > session, > > > including Accounting-Start. > > > > Yes, but Class was created to link the accounting message to a > > previous authentication on the same NAS. In pre-emptive keying the > > problem is linking an accounting message on one NAS to an > > authentication that occurred previously on another NAS. > > > > Specifically, with pre-emptive keying, getting an > Accounting message > > with an echo'd class attribute doesn't actually demonstrate > that the > > user authenticated to the NAS, since no evidence is provided to the > > AAA server. > > No, but it does demonstrate that the second NAS obtained it > from the first one, possibly with other context and > credentials, as part part of an IAPP. > > > This means that any NAS that received a Class attribute > along with the > > pushed key can subsequently send an Accounting-Start regardless of > > whether the user actually connected to the NAS and actually > used the > > key. > > I would say the sequence would be > > 0. user connects to NAS X > 1. AAA receives authentication request from NAS X > 2. AAA sends key + Class + other authorization parameters to > nas X 3. AAA sends key to nas Y, Z, etc. > > and nas Y and Z will only be able to use the key and send > accounting if they are trusted by nas X, because nas X > decided to give them Class. > > Or am I shifting the problem too easily to the NASes? Is the > underlying assumption for this work that there's no IAPP > operating at all? > > > > cannot fabricate sessions that never took place, because the home > > > AAA can test whether the unique value of Class corresponds to a > > > session autenticated by it earlier. > > > > If the AAA server sends pre-emptive notifications to several NAS > > devices, each one of them can pretend that the user > connected to it, > > and can generate Accounting records with the correct Class > attribute. > > Without user authentication there is no way for the AAA > server to know > > whether the Accounting-Start messages are valid. > > Not if those notifications don't include Class. Class would > then only be transported between NASes through an IAPP, at > the actual handoff time. > > > > And by tying the accounting record > > > to a specific authentication instance, the home AAA can verify if > > > the session duration given by Acct-Session-Time in > Accounting-Stop > > > messages doesn't exceed the time granted in its earlier > > > Access-Accept. > > > > The problem is that pre-emptive keying does not require a client to > > demonstrate possession of the key to the AAA server. The > AAA server > > just pushes the key out and assumes that it is either used > or expires > > on the NAS. As a result, there may be no corresponding > authentication > > instance for each accounting record sent by a NAS. That means that > > the AAA server cannot verify the Acct-Session-Time or even > whether the > > session started at all. > > I think if there is one Class per session, instead of one > Class per session per NAS, this problem does not occur. > > > > The secure tying of accounting to an earlier > authentication can be > > > done securely by the home AAA if the home AAA generates Class as > > > > > > nonce + locally-unique-session-id + HMAC(Class + local-secret) > > > > Unfortunately in pre-emptive keying there may be no "local-secret" > > between the NAS and the home AAA server. > > No, local as in only known on the AAA server. It's talking to > itself via the NAS, which only echos Class after all. > > > > Or, is the AAA server keeping track of the fact that the MN > > > authenticated through the target NAS and checks that when > receiving > > > the Accounting-Start? > > > > The AAA server doesn't need to check this in real-time but if a > > question arises it is helpful to have logs to be able to figure out > > what happened. > > > > > On the other hand, if it is the latter, doesn't this > cause concern > > > for the state build-up in the AAA server? > > > > For forensic purposes, it isn't necessary for the AAA > server to keep > > state on authentications and corresponding accounting > records; logging > > is sufficient. However, both pre-emptive keying and key-request > > require the AAA server to cache key state, which does represent a > > fundamental change. > > As long as such caching it can be done on a layer above the > core protocol as given in RFC2865, -6, -9, it needn't be any > worse than other schemes that use accounting information for > subsequent authentications. > > > > As illustrated above, the home AAA /can/ check that the MN was > > > authenticated by it before accepting an accounting start. > > > > In pre-emptive keying, there is no corresponding > authentication on the > > NAS that produces the accounting-start. > > > > > Other than that, I would like to second a preference > towards a key > > > request (as a form of lightweight authentication; of > course the home > > > AAA must see /some/ form of credentials or session cookie > before it > > > should hand out keying material) rather than the AAA pushing > > > material outwards. > > > > Key-Request does not bring up these concerns because there > can be an > > authentication corresponding to each accounting-start. This means > > that a log can verify that the client authenticated to the > AAA server > > via a particular NAS and this can be correlated with a subsequent > > accounting-start. > > Exactly. The model where a user session is a set of > lightweight RADIUS sessions, one session per NAS contact, is > probably easier to design and implement. > > I think we should only choose one of the extremes: either use > a full RADIUS authentication/start/interim/stop per NAS > contact, implying we must solve caching and reauthentication > speed issues at the EAP layer, or use one RADIUS > authentication/start/interim/stop per full user session, and > let handoff be done wholly outside RADIUS, through an IAPP. > > Cheers, > > > Emile. > > -- > E-Advies - Emile van Bergen emile@e-advies.nl > tel. +31 (0)70 3906153 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: Fri, 12 Aug 2005 02:04:29 +0000 Date: Thu, 11 Aug 2005 19:03:31 -0700 (PDT) From: Bernard Aboba To: Emile van Bergen cc: Narayanan Vidya-CVN065 , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: Re: AAA for Handovers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Specifically, with pre-emptive keying, getting an Accounting message with > > an echo'd class attribute doesn't actually demonstrate that the user > > authenticated to the NAS, since no evidence is provided to the AAA server. > > No, but it does demonstrate that the second NAS obtained it from the > first one, possibly with other context and credentials, as part part of > an IAPP. The IRTF pre-emptive keying proposal does not involve IAPP. See: http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt > 0. user connects to NAS X > 1. AAA receives authentication request from NAS X > 2. AAA sends key + Class + other authorization parameters to nas X > 3. AAA sends key to nas Y, Z, etc. > > and nas Y and Z will only be able to use the key and send accounting if > they are trusted by nas X, because nas X decided to give them Class. In pre-emptive keying, there is no transport of attributes between NASes, because the NAS obtains the attributes directly from the AAA server. > Or am I shifting the problem too easily to the NASes? Is the underlying > assumption for this work that there's no IAPP operating at all? I think you're confusing the IRTF pre-emptive keying proposal with another proposal. > > If the AAA server sends pre-emptive notifications to several NAS devices, > > each one of them can pretend that the user connected to it, and can generate > > Accounting records with the correct Class attribute. Without user > > authentication there is no way for the AAA server to know whether the > > Accounting-Start messages are valid. > > Not if those notifications don't include Class. Class would then only be > transported between NASes through an IAPP, at the actual handoff time. The IRTF pre-emptive keying proposal doesn't involve IAPP, so this not possible. > I think if there is one Class per session, instead of one Class per > session per NAS, this problem does not occur. It can occur either way because any NAS that obtains a pre-emptive key can issue an Accounting-Start with the same Class attribute. > Exactly. The model where a user session is a set of lightweight RADIUS > sessions, one session per NAS contact, is probably easier to design and > implement. That was the feedback provided by 802.11r participants. > I think we should only choose one of the extremes: either use a full > RADIUS authentication/start/interim/stop per NAS contact, implying we > must solve caching and reauthentication speed issues at the EAP layer, > or use one RADIUS authentication/start/interim/stop per full user > session, and let handoff be done wholly outside RADIUS, through an IAPP. As I understand it, IEEE 802.11r supports both of these modes as well as as "Key Request" mode. At the last meeting, the group was looking at features to cut, so if you have an opinion, bring your occam's razor with you :) BTW, if a specification supports multiple modes, it's worth considering whether *all* of them need to satisfy the Housley Criteria. As long as there is one mode that does satisfy the criteria, then operators who value security can deploy it. There is a distinction between making security "mandatory to implement" and "mandatory to use". As long as one mode is secure and its implementation is mandatory, then I think the "mandatory to implement" requirement is satisfied. -- to unsubscribe send a message to radiusext-request@ops.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, 12 Aug 2005 00:21:02 +0000 Date: Fri, 12 Aug 2005 02:20:49 +0200 From: Emile van Bergen To: Bernard Aboba Cc: Narayanan Vidya-CVN065 , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: Re: AAA for Handovers Message-ID: <20050812002049.GF14154@web1> Mail-Followup-To: Bernard Aboba , Narayanan Vidya-CVN065 , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Aug 11, 2005 at 04:52:51PM -0700, Bernard Aboba wrote: > > However, AAA servers can authenticate accounting messages by including a > > Class attribute in its access accept message. According to RFC2865, the > > NAS SHOULD echo the given A/V pair, regardless of value, in all its > > accounting messages that pertain to the session, including > > Accounting-Start. > > Yes, but Class was created to link the accounting message to a previous > authentication on the same NAS. In pre-emptive keying the problem > is linking an accounting message on one NAS to an authentication that > occurred previously on another NAS. > > Specifically, with pre-emptive keying, getting an Accounting message with > an echo'd class attribute doesn't actually demonstrate that the user > authenticated to the NAS, since no evidence is provided to the AAA server. No, but it does demonstrate that the second NAS obtained it from the first one, possibly with other context and credentials, as part part of an IAPP. > This means that any NAS that received a Class attribute along with the > pushed key can subsequently send an Accounting-Start regardless of > whether the user actually connected to the NAS and actually used the key. I would say the sequence would be 0. user connects to NAS X 1. AAA receives authentication request from NAS X 2. AAA sends key + Class + other authorization parameters to nas X 3. AAA sends key to nas Y, Z, etc. and nas Y and Z will only be able to use the key and send accounting if they are trusted by nas X, because nas X decided to give them Class. Or am I shifting the problem too easily to the NASes? Is the underlying assumption for this work that there's no IAPP operating at all? > > cannot fabricate sessions that never took place, because > > the home AAA can test whether the unique value of Class corresponds to a > > session autenticated by it earlier. > > If the AAA server sends pre-emptive notifications to several NAS devices, > each one of them can pretend that the user connected to it, and can generate > Accounting records with the correct Class attribute. Without user > authentication there is no way for the AAA server to know whether the > Accounting-Start messages are valid. Not if those notifications don't include Class. Class would then only be transported between NASes through an IAPP, at the actual handoff time. > > And by tying the accounting record > > to a specific authentication instance, the home AAA can verify if the > > session duration given by Acct-Session-Time in Accounting-Stop messages > > doesn't exceed the time granted in its earlier Access-Accept. > > The problem is that pre-emptive keying does not require a client to > demonstrate possession of the key to the AAA server. The AAA server > just pushes the key out and assumes that it is either used or expires > on the NAS. As a result, there may be no corresponding authentication > instance for each accounting record sent by a NAS. That means that > the AAA server cannot verify the Acct-Session-Time or even whether the > session started at all. I think if there is one Class per session, instead of one Class per session per NAS, this problem does not occur. > > The secure tying of accounting to an earlier authentication can be done > > securely by the home AAA if the home AAA generates Class as > > > > nonce + locally-unique-session-id + HMAC(Class + local-secret) > > Unfortunately in pre-emptive keying there may be no "local-secret" between > the NAS and the home AAA server. No, local as in only known on the AAA server. It's talking to itself via the NAS, which only echos Class after all. > > Or, is the AAA server keeping track of the fact that the MN > > authenticated through the target NAS and checks that when receiving > > the Accounting-Start? > > The AAA server doesn't need to check this in real-time but if a question > arises it is helpful to have logs to be able to figure out what happened. > > > On the other hand, if it is the latter, doesn't this cause > > concern for the state build-up in the AAA server? > > For forensic purposes, it isn't necessary for the AAA server to keep > state on authentications and corresponding accounting records; logging is > sufficient. However, both pre-emptive keying and key-request require > the AAA server to cache key state, which does represent a fundamental > change. As long as such caching it can be done on a layer above the core protocol as given in RFC2865, -6, -9, it needn't be any worse than other schemes that use accounting information for subsequent authentications. > > As illustrated above, the home AAA /can/ check that the MN was > > authenticated by it before accepting an accounting start. > > In pre-emptive keying, there is no corresponding authentication on the NAS > that produces the accounting-start. > > > Other than that, I would like to second a preference towards a key > > request (as a form of lightweight authentication; of course the home AAA > > must see /some/ form of credentials or session cookie before it should > > hand out keying material) rather than the AAA pushing material outwards. > > Key-Request does not bring up these concerns because there can be an > authentication corresponding to each accounting-start. This means that a > log can verify that the client authenticated to the AAA server via a > particular NAS and this can be correlated with a subsequent > accounting-start. Exactly. The model where a user session is a set of lightweight RADIUS sessions, one session per NAS contact, is probably easier to design and implement. I think we should only choose one of the extremes: either use a full RADIUS authentication/start/interim/stop per NAS contact, implying we must solve caching and reauthentication speed issues at the EAP layer, or use one RADIUS authentication/start/interim/stop per full user session, and let handoff be done wholly outside RADIUS, through an IAPP. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 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: Thu, 11 Aug 2005 23:53:01 +0000 Date: Thu, 11 Aug 2005 16:52:51 -0700 (PDT) From: Bernard Aboba To: Emile van Bergen cc: Narayanan Vidya-CVN065 , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: Re: AAA for Handovers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > However, AAA servers can authenticate accounting messages by including a > Class attribute in its access accept message. According to RFC2865, the > NAS SHOULD echo the given A/V pair, regardless of value, in all its > accounting messages that pertain to the session, including > Accounting-Start. Yes, but Class was created to link the accounting message to a previous authentication on the same NAS. In pre-emptive keying the problem is linking an accounting message on one NAS to an authentication that occurred previously on another NAS. Specifically, with pre-emptive keying, getting an Accounting message with an echo'd class attribute doesn't actually demonstrate that the user authenticated to the NAS, since no evidence is provided to the AAA server. This means that any NAS that received a Class attribute along with the pushed key can subsequently send an Accounting-Start regardless of whether the user actually connected to the NAS and actually used the key. > cannot fabricate sessions that never took place, because > the home AAA can test whether the unique value of Class corresponds to a > session autenticated by it earlier. If the AAA server sends pre-emptive notifications to several NAS devices, each one of them can pretend that the user connected to it, and can generate Accounting records with the correct Class attribute. Without user authentication there is no way for the AAA server to know whether the Accounting-Start messages are valid. > And by tying the accounting record > to a specific authentication instance, the home AAA can verify if the > session duration given by Acct-Session-Time in Accounting-Stop messages > doesn't exceed the time granted in its earlier Access-Accept. The problem is that pre-emptive keying does not require a client to demonstrate possession of the key to the AAA server. The AAA server just pushes the key out and assumes that it is either used or expires on the NAS. As a result, there may be no corresponding authentication instance for each accounting record sent by a NAS. That means that the AAA server cannot verify the Acct-Session-Time or even whether the session started at all. > The secure tying of accounting to an earlier authentication can be done > securely by the home AAA if the home AAA generates Class as > > nonce + locally-unique-session-id + HMAC(Class + local-secret) Unfortunately in pre-emptive keying there may be no "local-secret" between the NAS and the home AAA server. > Or, is the AAA server keeping track of the fact that the MN > authenticated through the target NAS and checks that when receiving > the Accounting-Start? The AAA server doesn't need to check this in real-time but if a question arises it is helpful to have logs to be able to figure out what happened. > On the other hand, if it is the latter, doesn't this cause > concern for the state build-up in the AAA server? For forensic purposes, it isn't necessary for the AAA server to keep state on authentications and corresponding accounting records; logging is sufficient. However, both pre-emptive keying and key-request require the AAA server to cache key state, which does represent a fundamental change. > As illustrated above, the home AAA /can/ check that the MN was > authenticated by it before accepting an accounting start. In pre-emptive keying, there is no corresponding authentication on the NAS that produces the accounting-start. > Other than that, I would like to second a preference towards a key > request (as a form of lightweight authentication; of course the home AAA > must see /some/ form of credentials or session cookie before it should > hand out keying material) rather than the AAA pushing material outwards. Key-Request does not bring up these concerns because there can be an authentication corresponding to each accounting-start. This means that a log can verify that the client authenticated to the AAA server via a particular NAS and this can be correlated with a subsequent accounting-start. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 23:51:12 +0000 Date: Fri, 12 Aug 2005 01:51:05 +0200 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt Message-ID: <20050811235105.GD14154@web1> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Aug 11, 2005 at 10:45:35AM -0400, Nelson, David wrote: > Submitter name: David Nelson > Submitter email address: dnelson@enterasys.com > Date first submitted: August 10, 2005 > Reference: (missing from the RADEXT archive ???) > Document: VLAN, Priority and Filtering Attributes > Comment type: 'T' Technical > Priority: '0' Must fix > Section: 3.1 > Rationale/Explanation of issue: > > Integer > > The Integer field is four octets in length. The format of the > Integer field consists of two parts, the first consuming high- > order octet and the second consuming the remaining three lower- > order octets. The high-order octet field indicates if the > VLANID is allowed for tagged or untagged packets. The second > part is the 12-bit 802.1Q VLAN VID value that has been padded > out to consume the remaining three lower-order octets. A > sample encoding follows: > > > This is not an Integer data type. It is a multi-field Octet String > (complex data type). > > Requested changes: > > Express a String data type (with sub-fields). Disagree. Integers are not monotonic counters only. If two integers need to be tied together, are of fixed length and together fit in 4 octets, I see no reason not to use RADIUS integers. What's next, sending IPv4 addresses as a complex type consisting of 4 decimal variable length strings? I know we've always used a dedicated label for IP addresses in RADIUS dicationaries, but they are encoded and can be handled exactly the same as integers everywhere in the server, up to the point where you reach the very end of the chain, in modules that deal with ASCII representations. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 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: Thu, 11 Aug 2005 23:39:17 +0000 Date: Fri, 12 Aug 2005 01:39:07 +0200 From: Emile van Bergen To: Alan DeKok Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: It's all in the timing... Message-ID: <20050811233907.GC14154@web1> Mail-Followup-To: Alan DeKok , "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Aug 10, 2005 at 06:11:45PM -0400, Alan DeKok wrote: > "Nelson, David" wrote: > > I have a general concern, or meta-issue, to raise regarding the WGLC of > > draft-ietf-radext-ieee802-00.txt. The VLAN, Priority and Filtering > > Attributes draft proposes new RADIUS attributes of base data type String > > (Octet String) that are, in fact, multi-field structures a.k.a. complex > > data types. > > Like ARAP-Features, Login-LAT-Group, Framed-Appletalk-Link, > Framed-Appletalk-Zone ... > > > My frustration is that I don't see a good solution. The Design > > Guidelines for RADIUS Attributes must be given time to mature and obtain > > consensus. It does not seem reasonable to delay the VLAN, Priority and > > Filtering Attributes draft until the design guidelines are ready. I > > guess the best I can hope for is that work on the design guidelines > > progresses rapidly, and that any substantial disconnects between the > > design guidelines and the VLAN, Priority and Filtering Attributes draft > > can be reconciled before it goes out for IETF Last Call. > > Sure. > > I also have no objection to publishing the VLAN... draft without the > benefit of the final Design Guidelines draft. There are already > complex data types in RADIUS attributes, so adding a few more > shouldn't be a serious problem. Seconded. I would also like to reiterate my plea for layering. Let's keep RADIUS to deal with big endian numeric and variable length octet strings (possibly interpreted as UTF-8 if they need to be displayed), and keep it at that. Interpretation of values, applying boundaries and so forth should always be done on a higher layer. I thing we should not try and invent an ASN.1 for RADIUS or another RFC2869 (creating a data structure by tying attributes together using a tag, where the syntax of the pair (tag-value or just value) is dependent of the value(!) of the potential tag (> 0x1f means no tag). Hackish seems a nice word for that solution). Let's keep the attribute field in the basic protocol a simple transport for simple ordinals and octet strings, and build on that to do the rest. The day that RADIUS requires some form of a DTD so that the protocol can do part of the application's work of verifying the syntax of its own input is the day that I quit my RADIUS work. If an application refuses to check its own input syntax /at all cost/, have it use XML, not RADIUS. All types are /not/ created equal. Complex types belong on a higher layer. It should be possible to parse a RADIUS packet using a simple dictionary containing only name, number and 4 types, before passing it onwards to an application, whether that's done through a database, XML-RPC, SOAP, BEEP, HTTP GET, or whatever. Of course, a recommendation for a field separator and escape method may be useful if application developers are really incapable of coming up with anything to use. I'd suggest something light weight, like HTTP's request URIs (field1&field2&ben%26jerry). If an application wants fields to carry names, they can be encoded as var=value&var=value, again as in HTTP. I favour independent, simple layers and the KISS principle, especially in security protocols. If a proposal is being done to merely prevent another tagged attribute invention for allowing simple sets, then I suggest either creating a container attribute type that is to be parsed as the RADIUS attribute field (ie. allowing it to contain a list of A/V pairs), or the HTTP request URI approach given above. But, please, keep it /simple/ and stay away from application specific types below the application. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 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: Thu, 11 Aug 2005 22:58:16 +0000 Date: Fri, 12 Aug 2005 00:57:39 +0200 From: Emile van Bergen To: Narayanan Vidya-CVN065 Cc: 'Bernard Aboba' , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: Re: AAA for Handovers Message-ID: <20050811225739.GB14154@web1> Mail-Followup-To: Narayanan Vidya-CVN065 , 'Bernard Aboba' , radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Aug 11, 2005 at 09:53:52AM -0500, Narayanan Vidya-CVN065 wrote: > > > Pre-emptive keying seeds the key cache at potential points of > > attachment, but the EAP peer only authenticates with the > > target NAS, the AAA server never confirms that the EAP peer > > used the key. The only indication the AAA server receives is > > an Accounting-Start from the target NAS, indicating that the > > EAP peer has connected. > > > > Because the AAA server can never confirm that the EAP peer > > was even considering the target NAS, it has no way to know > > whether the Accounting-Start it received is authentic. This > > enables a rogue operator to generate fraudulent accounting > > records that cannot be easily checked by the AAA server. > > > > I am not very familiar with how accounting works. Is the > Accounting-Start message not authenticated? If it is authenticated > using an SA shared between the NAS and the AAA server, I am wondering > why that isn't enough to trust the NAS. Accounting messages are signed using the Request Authenticator and possibly Message-Authenticator (required in case of EAP), by the RADIUS client (ie. NAS or proxy). There is generally no SA between NAS and AAA (the endpoints), only between individual RADIUS link partners. However, AAA servers can authenticate accounting messages by including a Class attribute in its access accept message. According to RFC2865, the NAS SHOULD echo the given A/V pair, regardless of value, in all its accounting messages that pertain to the session, including Accounting-Start. Indeed, many roaming agreements even require NASes to do so. Support also seems very widely implemented, perhaps because it's a trivial thing, and I would advocate to require the NAS to support it for new applications, just like Message-Authenticator support was required in RFC 2869 if EAP is used. If the home AAA chooses a new value of Class per session, A rogue proxy operator can change the value of all attributes in the accounting request, but cannot fabricate sessions that never took place, because the home AAA can test whether the unique value of Class corresponds to a session autenticated by it earlier. And by tying the accounting record to a specific authentication instance, the home AAA can verify if the session duration given by Acct-Session-Time in Accounting-Stop messages doesn't exceed the time granted in its earlier Access-Accept. The secure tying of accounting to an earlier authentication can be done securely by the home AAA if the home AAA generates Class as nonce + locally-unique-session-id + HMAC(Class + local-secret) The rogue proxy or NAS can replay Class values in forged accounting messages, but the home AAA can always be programmed to allow only one start and one stop record for each session. > > The requirement that the EAP peer demonstrate interest in the > > target NAS and prove its identity means that there is an > > authentication attempt to go along with the Accounting-Start. > > Is it that the AAA server relies on the successive timing of the > authentication via the target NAS and the Accounting-Start message? > Or, is the AAA server keeping track of the fact that the MN > authenticated through the target NAS and checks that when receiving > the Accounting-Start? If it is the former, isn't there a problem with > pre-authentication itself? The MN may have pre-authenticated via a > target NAS well before handoff, but an Accounting-Start may be sent > much later. On the other hand, if it is the latter, doesn't this cause > concern for the state build-up in the AAA server? As illustrated above, the home AAA /can/ check that the MN was authenticated by it before accepting an accounting start. There's currently nothing in RADIUS itself that requires tying accounting to authentication. Some home AAA policies will cause some connection between accounting and subsequent authentications to exist, eg. by subtracting time from a user's voucher or locking a session, but such a connection is always rather indirect and application specific. With respect to timing, a home AAA can only be certain that it has sent an accept before it can ever receive a valid accounting start. The rest is variable. Other than that, I would like to second a preference towards a key request (as a form of lightweight authentication; of course the home AAA must see /some/ form of credentials or session cookie before it should hand out keying material) rather than the AAA pushing material outwards. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 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: Thu, 11 Aug 2005 20:54:21 +0000 Date: Thu, 11 Aug 2005 13:54:13 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 119: More NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 119: More NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: General: RADIUS RFCs use the term "packet" to refer to RADIUS Access-Request, Challenge, Accept and Reject messages, not "message". Please change "message" to "packet" throughout the document. Section 3 The term 'HTTP-style' denotes any protocol that uses HTTP-like headers and uses HTTP digest authentication as described in [RFC2617]. Examples are HTTP and SIP. Why is this here? Shouldn't this be moved to the terminology section? Section 3.1 Change: " If this attribute is present in an Access-Request message, the RADIUS server MUST view the Access-Request as a Digest one." to: " If this attribute is present in an Access-Request message, a RADIUS server implementing this specification MUST treat the Access-Request as a request for Digest Authentication." Change: "The attribute proves the user knows the password and MUST only be used in Access-Requests." To: "This attribute (which enables the user to prove possession of the password) MUST only be used in Access-Requests" Change: " When using HTTP digest, the text field is 32 octets long and contains hexadecimal representation of 16 octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without quotes." To: " When using HTTP digest, the text field is 32 octets long and contains a hexadecimal representation of the 16 octet digest value as it was calculated by the authenticated client. Other digest algorithms MAY define different digest lengths. The text field MUST be copied from request-digest of digest-response ([RFC2617]) without quotes." Section 3.3 Change: " This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access-Challenge message. This attribute MUST only be used in Access-Request and Access-Challenge messages." to: " This attribute holds a nonce to be used in the HTTP Digest calculation. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access-Challenge message. This attribute MUST only be used in Access-Request and Access-Challenge messages." Section 3.4 Change: " This text proves the RADIUS server knows the password. If the previously received Digest-Qop attribute was 'auth-int' (without quotes), the RADIUS server MUST send a Digest-HA1 attribute instead of Digest-Response-Auth. The Digest- Response-Auth attribute MUST only be used in Access-Accept messages. The RADIUS client puts the attribute value without quotes into the rspauth directive of the Authentication-Info header." To: " This attribute enables the RADIUS server to prove possesion of the password. If the previously received Digest-Qop attribute was 'auth-int' (without quotes), the RADIUS server MUST send a Digest-HA1 attribute instead of a Digest-Response-Auth attribute. The Digest-Response-Auth attribute MUST only be used in Access-Accept messages. The RADIUS client puts the attribute value without quotes into the rspauth directive of the Authentication-Info header." Section 3.11 Change: " This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access- Request messages.u" To: " This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. It MUST only be used in Access- Request messages." Section 3.13 Change: " This attribute holds the user name parameter that is used in the HTTP digest calculation. The RADIUS server MUST NOT use this value for password finding, but only for digest calculation purpose. In order to find the user record containing the password, the RADIUS server MUST use the value of the ([RFC2865] -)User-Name attribute. This attribute MUST only be used in Access-Request packets." To: " This attribute holds the user name used in the HTTP digest calculation. The RADIUS server MUST use this attribute only for the purposes of calculating the digest. In order to determine the appropriate user credentials, the RADIUS server MUST use the User-Name (1) attribute, and MUST NOT use the Digest-Username attribute. This attribute MUST only be used in Access-Request packets." Section 3.15 Change: " If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute and each instance MUST contain one different unknown Digest parameter/ value combination. This attribute MUST ONLY be used in Access-Request, Access- Challenge, or Access-Accept messages." To: " If the Digest header contains several unknown parameters, then the RADIUS implementation MUST repeat this attribute and each instance MUST contain one different unknown Digest parameter/ value combination. This attribute MUST ONLY be used in Access-Request, Access-Challenge, or Access-Accept messages." In Section 3.20, change: "However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request messages." To: "However, the exact mapping of this attribute to SIP can change due to new developments in the protocol. This attribute MUST only be used in Access-Request messages, when the RADIUS client wants to authorize SIP users." Section 4 Please remove Section 4 (Migration Path to Diameter) as was discussed at IETF 63. Section 5 Please reformat the attribute table in the format used in other RADIUS RFCs, such as RFC 2865 Section 5.44: The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name 0-1 0 0 0 2 User-Password [Note 1] -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 20:52:54 +0000 Date: Thu, 11 Aug 2005 13:52:48 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 120: Message-Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 120: Message-Authenticator Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: T Priority: S Section: 8 Rationale/Explanation of issue: The document appears to mandate use of Message-Authenticator in all RADIUS usage. Section 8 Change: "8. Security Considerations The RADIUS extensions described in this document make RADIUS a transport protocol for the data that is required to perform a digest calculation. It adds the vulnerabilities of HTTP Digest (see [RFC2617], section 4) to those of RADIUS (see [RFC2865], Section 8 or Section 4 of [RFC3579]). If an attacker gains control over a RADIUS client or RADIUS proxy, he can perform man-in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec. The RADIUS server MUST check the Digest-Realm attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised. RADIUS clients implementing the extension described in this document authenticate layer 3 requests received from the Internet. This is in contrast to the original use of RADIUS, where layer 2 sessions are authenticated. In layer 2 access networks, attackers can usually tracked down more easily. An attacker could try to overload the RADIUS infrastructure by excessively sending HTTP-style requests. To make simple denial of service attacks more difficult, the nonce issuer (RADIUS client or server) MUST check if it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature of the RADIUS client, as described in [RFC2617], section 3.2.1. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack. In this case, the RADIUS client would use a weaker authentication scheme than intended. RfC 3579 [RFC3579], section 3.2 describes a Message- Authenticator attribute which MUST be used to improve the integrity protection of RADIUS messages. The RADIUS server can use this attribute to verify the identity of the RADIUS client. The Digest-HA1 attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary attacks easier and can be used for replay attacks. HTTP-style clients can use TLS with server side certificates together with HTTP-Digest authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded as one leg on the path between the HTTP-style client and the HTTP-style server. To prevent the RADIUS transaction from being the weakest hop on the path, a RADIUS client receiving an HTTP-style request via TLS or IPsec MUST use an equally secure connection to the RADIUS server. There are two ways to achieve this: o the RADIUS client rejects HTTP-style requests received over TLS or IPsec o the operator of the RADIUS client takes actions to ensure that RADIUS traffic is exclusively sent and received using IPsec. When using IPsec, it MUST be set up as described [RFC3579] section 4.2." To: "8. Security Considerations The RADIUS extensions described in this document enable RADIUS to transport the data that required to perform a digest calculation. As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see [RFC2617], section 4) in addition to RADIUS security vulnerabilities described in [RFC2865] Section 8 and [RFC3579] Section 4. An attacker compromising a RADIUS client or proxy can carry out man-in-the-middle attacks even if the paths between A, B and B, C (Figure 2) have been secured with TLS or IPsec. The RADIUS server MUST check the Digest-Realm attribute it has received from a client. If the RADIUS client is not authorized to serve HTTP-style clients of that realm, it might be compromised. RADIUS clients implementing the extension described in this document may authenticate HTTP-style requests received over the Internet. As compared with use of RADIUS to authenticate link layer network access, an attacker may find it easier to cover their tracks in such a scenario. An attacker can attempt a denial of service attack on one or more RADIUS servers by sending a large number of HTTP-style requests. To make simple denial of service attacks more difficult, the nonce issuer (RADIUS client or server) MUST check if it has generated the nonce received from an HTTP-style client. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature provided by the RADIUS client, as described in [RFC2617], section 3.2.1. RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm attributes in Access-Challenge messages. A man in the middle can modify or remove those attributes in a bidding down attack, causing the RADIUS client to use a weaker authentication scheme than intended. The Message-Authenticator attribute, described in [RFC3579] section 3.2 MUST be included in Access-Request, Access-Challenge, Access-Reject and Access-Accept messages that contain attributes described in this specificaiton. The Digest-HA1 attribute contains no random components if the algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary attacks easier and enables replay attacks. HTTP-style clients can use TLS with server side certificates together with HTTP-Digest authentication. Instead of TLS, IPsec can be used, too. TLS or IPsec secure the connection while Digest Authentication authenticates the user. The RADIUS transaction can be regarded as one leg on the path between the HTTP-style client and the HTTP-style server. To prevent RADIUS from representing the weak link, a RADIUS client receiving an HTTP-style request via TLS or IPsec MUST use an equally secure connection to the RADIUS server. There are two ways to achieve this: o the RADIUS client may reject HTTP-style requests received over TLS or IPsec o the RADIUS client require that traffic be sent and recieved over IPsec. RADIUS over IPsec, if used, MUST conform to the requirements described in [RFC3579] section 4.2." -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 20:52:10 +0000 Date: Thu, 11 Aug 2005 13:51:47 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 121: Data Representation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 121: Data Representation Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: T Priority: S Section: 3.5 Rationale/Explanation of issue: In Section 3.5, it says: " Text It is recommended that this text be base64 or hexadecimal data." For interoperability, you need to choose the representation or at least specify how it can be determined which representation is to be used. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 19:07:11 +0000 Date: Thu, 11 Aug 2005 12:07:02 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 118: Editorial NITs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 118: Editorial NITs Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Section 1.1 HTTP-style protocol a protocol using HTTP digest, like HTTP, SIP. Change "a protocol" to "A protocol" The combination of realm and digest URI the use of which is authorized by the RADIUS server. Change "URI the" to "URI, the" Please include definitions of NAS, UA and UAS in the terminology section. Section 1.3 "digest into the message" -> "digest within the message" Change: " Instead of maintaining a local user database, the server could use RADIUS. However, RADIUS does not support HTTP digest without an extension like the one described in this document. The RADIUS client can not send a User-Password attribute as it does not receive a password from the HTTP-style client. The RADIUS mechanism for CHAP resembles HTTP digest, but the digest algorithms are not compatible. This document extends RADIUS to support Digest Authentication, via addition as a native authentication mechanism. An implementation supporting this extension MUST include a Digest-Response attribute within an Access-Request packet where Digest authentication is desired. An Access-Request MUST NOT contain both a Digest-Response attribute and another authentication attribute, such as User- Password, CHAP-Password, or EAP-Message. This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617]." To: " Instead of maintaining a local user database, the server could use RADIUS. However, RADIUS [RFC2865] does not include support for HTTP digest authentication. The RADIUS client can not use the User-Password attribute, since it does not receive a password from the HTTP-style client. The CHAP-Challenge and CHAP-Password attributes are also not suitable since the CHAP algorithm is not compatible with HTTP digest. This document defines new attributes that enable the RADIUS server to perform the digest calculation defined in [RFC2617], providing support for Digest Authentication as a native authentication mechanism within RADIUS. An implementation supporting this extension MUST include a Digest-Response attribute within an Access-Request packet where Digest authentication is desired. An Access-Request MUST NOT contain both a Digest-Response attribute and another authentication attribute, such as User- Password, CHAP-Password, or EAP-Message." Change: " The nonces required by the digest algorithm are either generated by the RADIUS client or by the RADIUS server. A mix of nonce generation modes is not supported. RADIUS clients and servers can support one, or both nonce generation modes. If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. The nonce generation mode is a configurable parameter" To: " The nonces required by the digest algorithm are either generated by the RADIUS client or by the RADIUS server. A mix of nonce generation modes is not supported. RADIUS clients and servers can support one, or both nonce generation modes. If the RADIUS server generates nonces, its RADIUS clients MUST NOT try to generate nonces. If the RADIUS server does not generate nonces, its RADIUS clients MUST generate nonces locally. If at least one HTTP-style client requires AKA authentication [RFC3310], the RADIUS server MUST generate nonces and its RADIUS clients MUST NOT generate nonces locally. The nonce generation mode is a configurable parameter." Section 1.3.1 change "without authorization header" to "without an authorization header" in this section. "If credentials were accepted B" -> "If credentials were accepted, B" Section 1.3.2 change: " In most cases, the operation outlined in Section 1.3.1 is sufficient. It reduces the load on the RADIUS server to a minimum. However, when using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector. These authentication vectors are often stored centrally. Figure 3 depicts a scenario, where the RADIUS server chooses nonces. It shows a generic case where entities A and B communicate in the front-end using protocols such as HTTP/SIP, while entities B and C communicate in the back-end using RADIUS." To: " While the usage scenario described in Section 1.3.1 minimizes the load on the RADIUS server, alternatives are required in some situations. When using AKA [RFC3310] the nonce is partially derived from a precomputed authentication vector, which is often stored centrally. Figure 3 depicts a scenario in which the RADIUS server chooses nonces. In this case entities A and B communicate in the using HTTP or SIP, while entities B and C communicate using RADIUS." Change: " The relevant order of messages sent in this scenario is as follows:" to: " The following messages are sent in this scenario:" Section 2.1 The first paragraph seems a bit awkard. Does this really belong in Section 2.1, or might it belong in the Security Considerations Section? Change: " If the messages between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients (or else the HTTP-style clients would have a false sense of security)." To: " The attributes described in this document are sent in cleartext. Therefore were a RADIUS client to accept secured connections (https or sips) from HTTP-style clients, this could result in information intentionally protected by HTTP-style clients being sent in the clear during the RADIUS exchange. If the messages between RADIUS client and RADIUS server are not protected with IPsec, the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients, so that HTTP-style clients are not provided with a false sense of security." Change: " On reception of an HTTP-style request message, the RADIUS client checks whether it is responsible to authenticate the request. There are situation where an HTTP-style request traverses several proxies, and each of the proxies request to authenticate the HTTP-style client. In this situation, it is a valid scenario that a HTTP-style request received at a HTTP-style server contains several sets of credentials. The 'realm' directive in HTTP is the key that the RADIUS client can use to determine which credential is applicable. It may happen also that none of the realms are of interest to the RADIUS client, in which case the RADIUS client MUST consider that no credentials (of interest) were sent. In any case, a RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header where the realm directive matches its locally configured realm value. If such a header is present and contains HTTP digest information, the RADIUS client checks the 'nonce' parameter. If the RADIUS client generates nonces but did not issue the received nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to the HTTP-style client. In this error response, the RADIUS client sends a new nonce. If the RADIUS client recognizes the nonce or does not generate nonces, it takes the header directives and puts them into a RADIUS Access-Request message. It puts the 'response' directive into a Digest-Response attribute and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc / username / opaque directives into the respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- Username / Digest-Opaque attributes. The request method is put into the Digest-Method attribute. The RADIUS clients adds a Message- Authenticator (see [RFC3579]) attribute. Now, the RADIUS client sends the Access-Request message to the RADIUS server. The RADIUS server processes the message and responds with an Access- Accept or an Access-Reject message." To: "On reception of an HTTP-style request message, the RADIUS client checks whether it is authorized to authenticate the request. Where an HTTP-style request traverses several proxies and each of the proxies request to authenticate the HTTP-style client the request at the HTTP-style server may contain multiple credential sets. The RADIUS client can use the 'realm' directive in HTTP to determine which credentials are applicable. Where none of the realms are of interest, the RADIUS client MUST behave as though no relevant credentials were sent. In all situations the RADIUS client MUST send zero or exactly one credential to the RADIUS server. The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its locally configured realm. If such a (Proxy-)Authorization header is present and contains HTTP digest information, the RADIUS client checks the 'nonce' parameter. If the RADIUS client generates nonces but did not issue the received nonce, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to the HTTP-style client. In this error response, the RADIUS client sends a new nonce. If the RADIUS client recognizes the nonce or does not generate nonces, it takes the header directives and puts them into a RADIUS Access-Request message. It puts the 'response' directive into a Digest-Response attribute and the realm / nonce / digest-uri / qop / algorithm / cnonce / nc / username / opaque directives into the respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop / Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest- Username / Digest-Opaque attributes. The request method is put into the Digest-Method attribute. The RADIUS client adds a Message- Authenticator attribute, defined in [RFC3579] and sends the Access-Request message to the RADIUS server. The RADIUS server processes the message and responds with an Access- Accept or an Access-Reject." -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 19:02:34 +0000 Date: Thu, 11 Aug 2005 12:02:04 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 117: Transport Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 117: Transport Behavior Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 11, 2005 Reference: Document: DIGEST-03 Comment type: T Priority: S Section: 2.1, 2.2 Rationale/Explanation of issue: In at least two places, this document changes the basic transport behavior of RADIUS. If a RADIUS client does not receive a response from a RADIUS server, it retransmits the Request or fails over to another RADIUS server. A RADIUS client that automatically rejects user access without retransmission or failover is badly behaved. In general, a RADIUS server only silently discards a packet if it is invalid, such as a packet containing a Request Authenticator (Accounting) or Message-Authenticator attribute that does not verify. Unless there is a loading problem, silently discarding packets is a bad idea since the client will just retransmit or failover to another RADIUS server. If the Access-Request is valid but is requesting an unauthorized service, the correct response is an Access-Reject, not silent discard. In Section 2.1, Change: " The RADIUS server MAY have added a Digest-Nextnonce attribute into an Access-Accept message. If the RADIUS client discovers this, it puts the contents of this attribute into a 'nextnonce' directive. Now it can send an HTTP-style response. If the RADIUS client did receive an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header. If the RADIUS client receives an Access-Reject or no response from the RADIUS server, it sends an error response to the HTTP-style request it has received. 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 message, 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 message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- Realm, 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 receives an Access-Challenge message in response to an Access-Request containing a Digest-Nonce attribute, the RADIUS server did not accept the nonce. If a Digest-Stale attribute is present in the Access-Challenge and has a value of 'true' (without quotes), the RADIUS client sends an error (401 or 407) response containing WWW-/Proxy-Authenticate header with the directive 'stale' and the digest directives derived from the Digest-* attributes." To: " The RADIUS server MAY include a Digest-Nextnonce attribute within an Access-Accept message. A RADIUS client receiving a Digest-Nextnonce attribute places the contents of this attribute into a 'nextnonce' directive within a response sent to the HTTP-style client. If the RADIUS client receives an HTTP-style request without a (Proxy-)Authorization header matching its locally configured realm value, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header. If the RADIUS client receives an Access-Reject it sends an error response to the HTTP-style request it has received. If the RADIUS client does not receive a response, it retransmits or fails over to another RADIUS server as described in [RFC2865]. The RADIUS client has three ways to obtain nonces: it can generate them locally, it may receive a Digest-Nextnonce attribute within an Access-Accept message, or it may ask the RADIUS server to generate one. To do the latter, it sends an Access-Request containing Digest-Method and Digest-URI attributes, but without a Digest-Nonce attribute. The RADIUS client then adds a Message-Authenticator attribute to the Access-Request message. The RADIUS server chooses a nonce and responds with an Access-Challenge containing a Digest-Nonce attribute. The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- Realm, Digest-Domain and Digest-Opaque attributes in the Access-Challenge carrying the nonce. If these attributes are present, the RADIUS client MUST use them. If the RADIUS client sends an Access-Request containing a Digest-Nonce attribute and receives an Access-Challenge message in response, the RADIUS server did not accept the nonce. If a Digest-Stale attribute is present in the Access-Challenge and has a value of 'true' (without quotes), the RADIUS client sends an error (401 or 407) response containing WWW-/Proxy-Authenticate header with the directive 'stale' and the digest directives derived from the Digest-* attributes." In Section 2.2, Change: " If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Challenge message to the RADIUS client. The RADIUS server MUST add Digest-Realm, Message- Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes to the Access-Challenge message. If the server cannot choose a nonce, it replies with an Access-Reject message. If the RADIUS server receives an Access-Request message containing a Digest-Response attribute, it looks for the following attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] for details. If the Digest-Algorithm attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque attribute. If mandatory attributes are missing, it MUST respond with an Access- Reject message. If the attributes are present, the RADIUS server calculates the digest response as described in [RFC2617]. To look up the password, the RADIUS server uses the RADIUS User-Name attribute. The RADIUS server MUST check if the user identified by the User-Name attribute o is authorized to access the protection space defined by the Digest-URI and Digest-Realm attributes, o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present. If any of those checks fails, the RADIUS server MUST send an Access- Reject. Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register or misuse a SIP-AOR allocated to another user. A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server silently discards the Access-Request message. Other actions taken by the RADIUS server are out of scope of this document. However, the RADIUS server should notify the operator and may take additional action such as discarding all future requests from this client, until some management action tells it to do so again. All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response attribute, the authentication was successful. If not, the RADIUS server responds with an Access-Reject." to: " If the RADIUS server receives an Access-Request message with Digest-Method and Digest-URI attributes, but without a Digest-Nonce attribute, sends an Access-Challenge message to the RADIUS client containing a nonce within a Digest-Nonce atribute. The RADIUS server MUST include Digest-Realm and Message-Authenticator attributes within the Access-Challenge and SHOULD include Digest-Algorithm and one or more Digest-Qop attributes. The RADIUS server MAY include Digest-Domain and Digest-Opaque attributes in the Access-Challenge message. If the server cannot choose a nonce, it replies with an Access-Reject message. If the RADIUS server receives an Access-Request message containing a Digest-Response attribute, it looks for the following attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-Qop, Digest-Algorithm, Digest-Username. Depending on the content of Digest-Algorithm and Digest-Qop, it looks for Digest-Entity-Body- Hash, Digest-CNonce and Digest-AKA-Auts attributes; see [RFC2617] and [RFC3310] for details. If the Digest-Algorithm attribute is missing, 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque attribute along with the nonce, the Access-Request MUST have a matching Digest-Opaque attribute. If mandatory attributes are missing, the RADIUS server MUST respond with an Access-Reject. If the required attributes are present, the RADIUS server calculates the digest response as described in [RFC2617]. The RADIUS server determines the required credentials based on the contents of the User-Name attribute sent in the Access-Request. The RADIUS server MUST check if the user identified by the User-Name attribute: o is authorized to access the protection space defined by the Digest-URI and Digest-Realm attributes, o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present. If any of these checks fail, the RADIUS server MUST send an Access-Reject. Correlation between User-Name and SIP-AOR AVP values is required to prevent a user from registering or misusing a SIP-AOR allocated to another user. A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm provided in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server MUST send an Access-Reject. The RADIUS server SHOULD log the event so as to notify the operator, and MAY take additional action such as sending an Access-Reject in response to all future requests from this client, until this behavior is reset by management action. All values required for the digest calculation are taken from the Digest attributes described in this document. If the calculated digest response equals the value received in the Digest-Response attribute, the authentication was successful. If not, the RADIUS server responds with an Access-Reject." -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 15:00:02 +0000 Message-Id: <97A461F3EE5284469E41ED3728202F41121E32@S4DE9JSAAMW.ost.t-com.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: dnelson@enterasys.com, aboba@internaut.com Subject: AW: Do we have consensus on the Digest Auth draft issues? Date: Thu, 11 Aug 2005 16:59:53 +0200 MIME-Version: 1.0 Content-Type: text/plain Bernard wrote: > Dave wrote: > > The substantive issue with the draft-ietf-radext-diget-auth-03.txt > > seems to be how to deal with Diameter interoperability of the two > > different sources of nonce. The general sense of the room at IETF-63 > > seemed to be that the Digest Auth draft needed to support both modes, > > and that the companion Diameter draft would need to follow suit. This > > places the Diameter compatibility action item with the Diameter > > document. > > > > Does the WG at large agree? Please reply. > > Personally, I agree. But then again, I was the person who > first suggested moving the Diameter compatibility section to > the Diameter document :) > > > Assuming that we do agree, then what action item doe we have w.r.t. > > the Diameter document? > > I think the implication is that the Diameter document (which > has been in simulaneous WG last call with Digest) needs to > own the compatibility section. > I am preparing a -04 version of the draft correcting a few nits -- like the text/table mismatch discovered by Hideo Morishita -- and without the Diameter migration section. I have asked Miguel Garcia whether he could add the client-side nonce generation mode and the RADIUS/Diameter migration section into draft-ietf-diameter-sip-app. If there are no new issues with -03, I will submit -04 tomorrow. 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: Thu, 11 Aug 2005 14:57: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: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:57:40 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324CE@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWehQU1koqcKfFoSuKYAxq5ckInHw== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com=20 Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes=20 Comment type: 'E' Editorial Priority: '1' Should fix Section: 4.1 Rationale/Explanation of issue: 4.1. Acct-NAS-Filter-Rule The first eight octets of this string are used for a 64-bit=20 value of the rule counter. The remaining octets are used to=20 specify which filter rule the counter value is for. The rule=20 specification MUST conform to the syntax rules specified for=20 NAS-Filter-Rule[TODO]. [TODO] indicates an open action item. Requested changes: Provide the [TODO]. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:55: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: Editorial comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:54:16 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324CD@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWehIuzjFHyFplCRHqfqHliwGmD2A== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes=20 Comment type: 'E' Editorial Priority: '1' Should fix Section: 3.5 Rationale/Explanation of issue: Clarification of the text. Requested changes: Furthermore, the concatenated filter list=20 must abide to the following rules of precedence and ordering:=20 =20 1) A flush rule MUST appear before all other rule types.=20 Change "A flush rule" to "A flush rule, when present,". 2) Base encapsulation filter rules MUST appear after a=20 flush rule and before IP tunnel, HTTP redirect, IP=20 filter, and/or HTTP filter rules. Change "a flush rule" to "any flush rule". dir "in" is from the terminal, "out" is to the=20 terminal, "inout" is from and to the terminal. The term "terminal" is not defined in the draft. I suspect it identifies the network entity which contains the IEEE 802.1X Supplicant function, but this should perhaps be clarified. General comment: I'd much rather that we use ABNF to define the NAS-Filter-Rule formal syntax, however I'm not prepared to submit that text just now. :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 11 Aug 2005 14:54:12 +0000 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A72C6@il02exm13> From: Narayanan Vidya-CVN065 To: "'Bernard Aboba'" Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Date: Thu, 11 Aug 2005 09:53:52 -0500 MIME-Version: 1.0 Content-Type: text/plain > Pre-emptive keying seeds the key cache at potential points of > attachment, but the EAP peer only authenticates with the > target NAS, the AAA server never confirms that the EAP peer > used the key. The only indication the AAA server receives is > an Accounting-Start from the target NAS, indicating that the > EAP peer has connected. > > Because the AAA server can never confirm that the EAP peer > was even considering the target NAS, it has no way to know > whether the Accounting-Start it received is authentic. This > enables a rogue operator to generate fraudulent accounting > records that cannot be easily checked by the AAA server. > I am not very familiar with how accounting works. Is the Accounting-Start message not authenticated? If it is authenticated using an SA shared between the NAS and the AAA server, I am wondering why that isn't enough to trust the NAS. > > The requirement that the EAP peer demonstrate interest in the > target NAS and prove its identity means that there is an > authentication attempt to go along with the Accounting-Start. > > Is it that the AAA server relies on the successive timing of the authentication via the target NAS and the Accounting-Start message? Or, is the AAA server keeping track of the fact that the MN authenticated through the target NAS and checks that when receiving the Accounting-Start? If it is the former, isn't there a problem with pre-authentication itself? The MN may have pre-authenticated via a target NAS well before handoff, but an Accounting-Start may be sent much later. On the other hand, if it is the latter, doesn't this cause concern for the state build-up in the AAA server? > > From what I can tell, the security of the "Key Request" > scheme is equal to or better than pre-emptive keying, without > requiring server-initiated messages or changes to the lower > layer neighbor reporting mechanisms. > It seemed like there was concern about evolving key hierarhies - is that not true? For e.g., typically in EAP, the MSK is generated and using that MSK, the NAS and STA derive transient keys. In 802.11r, it seems like the R0, R1, R2 keys (I think they are called PMK-Rx) are derived successfully from one another, R0 being the MSK (in most cases). I noticed that there was no freshness added in generating these PMKs. Are such schemes as secure as regular EAP key derivation? > > One thing to keep in mind is that the total transaction time > is not the only factor determining whether a handoff can be > completed in time. A more important factor is the key cache > hit rate and the lead time. If knowledge of key state is > synchronized and the neighboring NASes can be determined well > ahead of time, then the introduction of one or more > roundtrips to the AAA server may not matter that much because > EAP authentication or "Key Request" may be a rare event. > > As an example, in a building where there are two WLAN > switches, an EAP peer with an awareness of the key cache > boundaries would only need to authenticate with each switch > once a key cache entry had expired. So if the key lifetime > is 24 hours, the peer might authenticate with each switch at > the beginning of the day, and then not do any other EAP > authentications until the next day. > > In such a situation the extra round-trips to the AAA server > of an EAP pre-authentication or "Key Request" do not affect > performance or AAA server loading that adversely. > Yes, to an extent this becomes dependent on topology and makes it somewhat difficult to generalize the requirements here. > > I think it would probably be worth bringing the issue up in > IEEE 802.11r, so as to clarify exactly what (if anything) > they want from the IETF. From my perspective, a very valuable > contribution would be to develop a requirements document that > states clearly what the problem is and what a good solution > would look like. For example, to date there are a lot of > different notions of what "fast" means, or what scenarios > need to be supported and why. Without consensus on what the > problem is or how we know when it is solved, it is difficult > to make much progress. > Okay. Thanks, Vidya -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:46:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:45:35 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324CC@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWeg1U+ixmcG+NxSiW1Xm0f+1MzSQ== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'T' Technical Priority: '0' Must fix Section: 3.1 Rationale/Explanation of issue: Integer=20 =20 The Integer field is four octets in length. The format of the=20 Integer field consists of two parts, the first consuming high- order octet and the second consuming the remaining three lower- order octets. The high-order octet field indicates if the=20 VLANID is allowed for tagged or untagged packets. The second=20 part is the 12-bit 802.1Q VLAN VID value that has been padded=20 out to consume the remaining three lower-order octets. A=20 sample encoding follows: =20 This is not an Integer data type. It is a multi-field Octet String (complex data type). Requested changes: Express a String data type (with sub-fields). -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:42:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:42:06 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324CB@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Technical comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWegtiUQjnO2uneSpi/0kloyfJpQA== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'T' Technical Priority: '0' Must fix Section: 2.2 Rationale/Explanation of issue: Text appears to create retroactive normative requirements on existing implementations. Requested changes: Change: Similarly, if a NAS conforming to this specification receives a=20 CoA message that contains an attribute from this document that it=20 does not recognize or cannot apply, it MUST NOT terminate the=20 session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)=20 set to "Unsupported Attribute"(401). =20 To: Similarly, if a NAS conforming to this specification and also conforming to RFC 3576 [RFC3576] receives a CoA message that=20 contains an attribute from this document that it does not=20 recognize or cannot apply, it MUST NOT terminate the session and MUST generate a CoA-NAK packet with Error-Cause (101) set to "Unsupported Attribute"(401). =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, 11 Aug 2005 14:36:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59E82.0076EB40" Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:36:04 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324CA@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWeggBucNQPZYPlTSqusY8gLqrUcQ== From: "Nelson, David" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C59E82.0076EB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'E' Editorial Priority: '1' Should fix Section: 2.1 Rationale/Explanation of issue: =20 This section seems out of place. =20 2.1 Capability Advertisement=20 =20 RADIUS does not currently define a method by which a NAS can=20 advertise its capabilities and in many instances, it would be=20 desirable for the home network to know what capabilities are=20 supported by the NAS to ensure proper operational behavior. The=20 attributes defined in this document are intended to be used to=20 enforce policy by the NAS. If a NAS does not recognize these=20 attributes it will most likely ignore them and the desired policy=20 will not be enforced. A method for the NAS advertising the=20 capability to support these attributes would help the RADIUS=20 server understand if the intended policies can be enforced. As a=20 result, the attributes in this document, in particular NAS-Filter- Rule(TBD), can benefit from capability advertisement, if=20 available. =20 =20 Requested changes: =20 Should this entire section perhaps be part of the Security Considerations? =20 ------_=_NextPart_001_01C59E82.0076EB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Submitter name: = David Nelson

Submitter email = address: dnelson@enterasys.com

Date first = submitted: August 10, 2005

Reference: (missing = from the RADEXT archive ???)

Document: VLAN, = Priority and Filtering Attributes

Comment type: 'E' = Editorial

Priority: '1' = Should fix

Section: = 2.1

Rationale/Explanation of issue:

 

This section seems = out of place.

 

2.1 Capability = Advertisement

      

      RADIUS does not currently define a method by which a NAS can =

      advertise its capabilities and in many instances, it would be =

      desirable for the home network to know what capabilities are

      supported by the NAS to ensure proper operational behavior. The

      attributes defined in this document are intended to be used to

      enforce policy by the NAS. If a NAS does not recognize these

      attributes it will most likely ignore them and the desired policy =

      will not be enforced. A method for the NAS advertising the

      capability to support these attributes would help the RADIUS

      server understand if the intended policies can be enforced. As a =

      result, the attributes in this document, in particular NAS-Filter-

      Rule(TBD), can benefit from capability advertisement, if

      available.  =

 

Requested = changes:

 

Should this entire = section perhaps be part of the Security = Considerations?

 

------_=_NextPart_001_01C59E82.0076EB40-- -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:33:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59E81.79D7F458" Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:32:18 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C9@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWegXnQ1JfMzl53Rq2jL9CFRudeGw== From: "Nelson, David" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C59E81.79D7F458 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'E' Editorial Priority: '1' Should fix Section: 2 Rationale/Explanation of issue: =20 Better phrasing. =20 Requested changes: =20 (1) =20 The first paragraph is awkwardly worded. Perhaps the following would be an improvement. =20 In this section we provide an elaboration of the requirements=20 briefly described in the Introduction. =20 (2) =20 For example, the user maybe on=20 a prepaid plan and all the resources have been used up. =20 Change "maybe" to "may be" and "resources have" to "credit balance has". =20 (3) =20 For example, the ability to block and=20 redirect traffic is required for TCP users, cell phone users, WiFi users. =20 Change "TCP users" to "IP users". =20 (4) =20 Change: =20 As pointed out by [NASREQ] the use Filter-Id is not roaming=20 friendly and it is recommended that instead one should use NAS- Filter-Rule(TBD) AVP. For this reason, this document introduces=20 NAS-Filter-Rule(TBD) to RADIUS. =20 To: =20 As pointed out by [NASREQ] the use Filter-Id is not roaming=20 friendly and it is recommended that instead one should adapt=20 the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD) attribute. =20 =20 ------_=_NextPart_001_01C59E81.79D7F458 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Submitter name: = David Nelson

Submitter email = address: dnelson@enterasys.com Date first submitted: August 10, = 2005

Reference: (missing = from the RADEXT archive ???)

Document: VLAN, = Priority and Filtering Attributes Comment type: 'E' = Editorial

Priority: '1' = Should fix

Section: = 2

Rationale/Explanation of issue:

 

Better = phrasing.

 

Requested = changes:

 

(1)

 

The first paragraph = is awkwardly worded.  Perhaps the following would be an = improvement.

 

      In this section we provide an elaboration of the requirements

      briefly described in the Introduction.

 

(2)

 

      For example, the user maybe on

      a prepaid plan and all the resources have been used up.

 

Change = "maybe" to "may be" and "resources have" to "credit = balance has".

 

(3)

 

      For example, the ability to block and

      redirect traffic is required for TCP users, cell phone users,

      WiFi = users.

 

Change "TCP = users" to "IP users".

 

(4)

 

Change:

 

      As pointed out by [NASREQ] the use Filter-Id is not roaming

      friendly and it is recommended that instead one should use = NAS-

      Filter-Rule(TBD) AVP.  For this reason, this document introduces

      NAS-Filter-Rule(TBD) to RADIUS.

 

To:

 

   =    As pointed out by [NASREQ] the use Filter-Id is not roaming

      friendly and it is recommended that instead one should adapt

      the Diameter NAS-Filter-Rule AVP as a RADIUS = NAS-Filter-Rule(TBD)

      = attribute.

 

 

------_=_NextPart_001_01C59E81.79D7F458-- -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:29:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59E81.0368A6E0" Subject: Issue: Editorial commets on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:28:59 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C8@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial commets on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWegQNiT+4y4J9RTlaUnPy4OP6XNA== From: "Nelson, David" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C59E81.0368A6E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'E' Editorial Priority: '1' Should fix Section: 1.1 Rationale/Explanation of issue: =20 The following definitions are not used in the draft: =20 Access Point Association Station =20 Requested change: =20 Please delete them. =20 =20 ------_=_NextPart_001_01C59E81.0368A6E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Submitter name: David Nelson

Submitter email address: = dnelson@enterasys.com

Date first submitted: August 10, = 2005

Reference: (missing from the RADEXT archive = ???)

Document: VLAN, Priority and Filtering = Attributes

Comment type: 'E' Editorial

Priority: '1' Should fix

Section: 1.1

Rationale/Explanation of issue:

 

The following = definitions are not used in the draft:

 

Access = Point

Association

Station

 

Requested = change:

 

Please delete = them.

 

 

------_=_NextPart_001_01C59E81.0368A6E0-- -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:27:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:26:12 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C7@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Editorial comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWFybZp/uP5ITr6TdOU6yD6mQRCHwX1uhSgAAzGbWAAKthEsA== From: "Nelson, David" To: Submitter name: David Nelson Submitter email address: dnelson@enterasys.com Date first submitted: August 10, 2005 Reference: (missing from the RADEXT archive ???) Document: VLAN, Priority and Filtering Attributes Comment type: 'E' Editorial Priority: '1' Should fix Section: 1 Rationale/Explanation of issue: Better phrasing. Requested changes: (1)=20 Within the confines of RADIUS authentication, authorization, and accounting (AAA) environments, there is a general dearth of standardized RADIUS attributes to limit user access using dynamic VLANs, filters or redirection. =20 =20 Could we change "a general dearth of" to "a requirement for"? It sounds more positive. (2) IEEE 802.1X-2004 [IEEE8021X] provides "network port=20 authentication" for IEEE 802 [IEEE802] media, including Ethernet=20 [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i]. Remove this sentence as it appears in the second paragraph as well. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 14:15: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: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Date: Thu, 11 Aug 2005 10:15:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C6@MAANDMBX2.ets.enterasys.com> Thread-Topic: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWFybZp/uP5ITr6TdOU6yD6mQRCHwX1uhSgAAzGbWAAKsLtAA== From: "Nelson, David" To: "Bernard Aboba" , > My WGLC comments on the subject draft are included herein. I wanted to send my comments by the close of WGLC, but I will now proceed to re-submit each of these items as RADEXT 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: Thu, 11 Aug 2005 06:37:40 +0000 Date: Wed, 10 Aug 2005 23:37:01 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 114: WGLC Review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 114: WGLC Review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: August 10, 2005 Reference: Document: IEEE802-00 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Accounting I do not understand the purpose of the accounting functionality in the draft. The focus of this document is VLAN attribute, priority and filtering. How does Acct-EAP-Auth-Method fit into that? I think this is a leftover WLAN attribute which should be removed. Acct-NAS-Filter-Rule attribute. The purpose of this attribute is to keep count of hits on filter rules. This duplicates functionality under development in other WGs such as IPFIX, and so I'd question whether this is appropriate functionality for RADIUS accounting. Overview I do not understand the purpose of Section 2, Overview. Most of it seems like it could be deleted without losing anything. " As described in the Introduction section, it may be desirable to a control user's access to network resources (e.g. the Internet) with greater standardized explicitness than what current RADIUS attributes provide. In this section we will examine these requirements in more detail. " What is "standardized explicitness?" The filtering functionality defined in this document is no more granular than what is already supported in the Filter-ID attribute. So this sentence seems inaccurate. " Besides IEEE 802.1X networks, there is a corollary need within Internet Service Provider (ISP) environments for standardized authorization attributes." What is an IEEE 802.1X network? Do you mean an IEEE 802 network? RADIUS has supported authorization attributes for a long time, this sentence makes it seem like this is the first time that authorization attributes have been defined in RADIUS. Also, mixing ISPs and IEEE 802 functionality in the same document is a symptom of a deeper problem which Greg Weber has brought up -- it is not clear what devices need to do in order to comply with the document, if compliance is even possible. " From time to time, an ISP requires to restrict a user's access to the Internet and redirect their traffic to an alternate location. For example, the user maybe on a prepaid plan and all the resources have been used up." Since this implies that the document is actually aimed at prepaid, I think you need a reference here. The ability to block user's traffic is required at service initiation and once service has been established. These capabilities must also be available across access technologies and various business scenarios. For example, the ability to block and redirect traffic is required for TCP users, cell phone users, WiFi users. As well, this capability must work whether the user is in their home network or roaming in a visited network which may or may not have a direct roaming relationship with the user's home network. This seems like a list of requirements that this document was supposed to satisfy. However, I would question whether in fact these requirements are legitimate. This documented started out focussed on IEEE 802 functionality -- how did it somehow morph into a document relating to prepaid, portals, etc.? " Blocking access refers to setting up access control rules at the NAS such that when the user initiates IP traffic, the NAS examines the set of rules associated with the service granted to the user. These rules determine what traffic is allowed to proceed through the NAS and what traffic will be blocked. Today this capability is supported in RADIUS and is configurable during service establishment and mid-service via the Filter-Id(11) attribute. To use Filter-Id to control access to network resources the rules need to be configured apriori at each NAS. Filter-Id(11) is used in an Access-Accept to specify the name of the filter rule(s) to apply to this session. To effect a change mid-service (dynamically), the Filter-Id(11) is included in a Change-of- Authorization (COA) packet as described in [RFC3676]. Upon receiving the Filter-Id(11) the NAS starts to apply the rules specified by the Filter-Id(11)." I'm not sure why this document needs to discuss Filter-ID, which is not defined here. " As pointed out by [NASREQ] the use Filter-Id is not roaming friendly and it is recommended that instead one should use NAS- Filter-Rule(TBD) AVP. For this reason, this document introduces NAS-Filter-Rule(TBD) to RADIUS." What does "roaming friendly" mean? Filter-ID has been used in roaming for many years by cooperating parties. Perhaps the issue is requiring pre-established filters to be set on the NAS? This paragraph appears to be deprecating an existing RADIUS attribute without a clear justification. -- to unsubscribe send a message to radiusext-request@ops.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, 11 Aug 2005 03:04: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: WGLC comments on draft-ietf-radext-ieee802-00.txt Date: Wed, 10 Aug 2005 23:02:56 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B66B586F@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Issue: WGLC comments on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWeISwr1QlR4ax5Teu9FPFmThN+Rw== From: "Greg Weber \(gdweber\)" To: Description of issue: WGLC comments on draft-ietf-radext-ieee802-00.txt Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: 8/10/05 Reference: N/A Document: draft-ietf-radext-ieee802-00.txt Comment type: T/E Priority: S Section: various Rationale/Explanation of issue: 1) Compliance vs. Functional Coherence Most of the RADIUS RFCs tend to address a single functional area, e.g. IPv6 attributes, EAP, tunneling, etc. This is good because RFCs tend to become checkmarks on RFPs or customer requirements. This documents seems to combine functionality that is only related to IEEE 802 (VLANs) and things that are independent of access type. For example, filtering and redirection can apply equally usefully to PPP-based L2 connections. If I'm a vendor of PPPoA-based DSL termination NASes, I can't claim compliance to this potential RFC unless I support all the VLAN oriented=20 attributes because the compliance language in section 1.2 requires an all or nothing approach to compliance. Can=20 the authors clarify why the NAS-Filter-Rule/QoS-Filter-Rule attributes are combined with the 802 specific attributes? I would think these should be addressed via separate documents. 2) Compliance vs. Optional Functionality I did not understand how the "options" in section 3.5 relate to the compliance language in section 1.2. If I do not=20 support the "Cnt" option for counting rule hits, can I still claim compliance with this document? Are these optionally specified or optionally supported? 3) Accounting The accounting requirements do not seem to be fully treated by the draft. Section A.3 has a MUST requirement related to accounting. I would think that MUST requirements should be treated by the text, not in an appendix. Why does redirection require a STOP/START pair? Can't this information be conveyed via an INTERIM record for the same session? If the Service- Type is not changing, I'd think that an INTERIM would suffice. 4) NAS-Filter-Rule proto specification I could not understand some parts of the specification; I=20 guess Pasi has already commented on this. In particular, the proto spec: proto > type[:val]|ipprot|ip|http> there are not an equal number of "<" and ">" and the=20 "type[:val]" part is not described. The "ipprot" does not provide for a value part. 5) Attribute concatenation I didn't understand how the language in section 3.6 about concatenating QoS-Filter-Rule(s) works. If these are simply concatenated, how does an implementation distinguish between multiple 'small' QoS-Filter-Rules and a single larger=20 attribute? What if I want to send one QoS-Filter-Rule which spans 253, followed by one which does not? 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: Wed, 10 Aug 2005 22:11:02 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: It's all in the timing... Cc: radiusext@ops.ietf.org Date: Wed, 10 Aug 2005 18:11:45 -0400 Message-Id: <20050810221145.D377216CCA@mail.nitros9.org> "Nelson, David" wrote: > I have a general concern, or meta-issue, to raise regarding the WGLC of > draft-ietf-radext-ieee802-00.txt. The VLAN, Priority and Filtering > Attributes draft proposes new RADIUS attributes of base data type String > (Octet String) that are, in fact, multi-field structures a.k.a. complex > data types. Like ARAP-Features, Login-LAT-Group, Framed-Appletalk-Link, Framed-Appletalk-Zone ... > My frustration is that I don't see a good solution. The Design > Guidelines for RADIUS Attributes must be given time to mature and obtain > consensus. It does not seem reasonable to delay the VLAN, Priority and > Filtering Attributes draft until the design guidelines are ready. I > guess the best I can hope for is that work on the design guidelines > progresses rapidly, and that any substantial disconnects between the > design guidelines and the VLAN, Priority and Filtering Attributes draft > can be reconciled before it goes out for IETF Last Call. Sure. I also have no objection to publishing the VLAN... draft without the benefit of the final Design Guidelines draft. There are already complex data types in RADIUS attributes, so adding a few more shouldn't be a serious problem. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 10 Aug 2005 22:08: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: Do we have consensus on the Digest Auth draft issues? Date: Wed, 10 Aug 2005 18:08:22 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C4@MAANDMBX2.ets.enterasys.com> Thread-Topic: Do we have consensus on the Digest Auth draft issues? Thread-Index: AcWd962OxmGwMqzmTFmNGVneh5BxCAAAAkEw From: "Nelson, David" To: "Alan DeKok" Cc: > Are minutes available? Not yet. I'm still waiting for the second note taker to send me his raw minutes, and then I will edit the two sets of notes into one document. The streaming audio archive is available, if you want to listen. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 22:06:12 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Do we have consensus on the Digest Auth draft issues? Cc: radiusext@ops.ietf.org Date: Wed, 10 Aug 2005 18:06:37 -0400 Message-Id: <20050810220637.BE77216CCA@mail.nitros9.org> "Nelson, David" wrote: > I'm starting a few threads on the RADEXT WG mailing list to follow up on > issues discussed at the IETF-63 RADEXT session. Are minutes available? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 10 Aug 2005 21:51:27 +0000 Date: Wed, 10 Aug 2005 14:51:16 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: Re: Do we have consensus on the Digest Auth draft issues? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The substantive issue with the draft-ietf-radext-diget-auth-03.txt seems > to be how to deal with Diameter interoperability of the two different > sources of nonce. The general sense of the room at IETF-63 seemed to be > that the Digest Auth draft needed to support both modes, and that the > companion Diameter draft would need to follow suit. This places the > Diameter compatibility action item with the Diameter document. > > Does the WG at large agree? Please reply. Personally, I agree. But then again, I was the person who first suggested moving the Diameter compatibility section to the Diameter document :) > Assuming that we do agree, then what action item doe we have w.r.t. the > Diameter document? I think the implication is that the Diameter document (which has been in simulaneous WG last call with Digest) needs to own the compatibility section. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 21:45:12 +0000 Date: Wed, 10 Aug 2005 14:44:56 -0700 (PDT) From: Bernard Aboba To: Narayanan Vidya-CVN065 cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs > from the current NAS through which the STA is authenticating? I agree > that it is unrealistic to expect the AAA server to have complete > knowledge of the topology. By allowing this information to be carried in > RADIUS to the server, the topology information can still come from the > STA - of course, this will require some support from EAP as well to get > this from the STA to the current NAS, but it still seems like it can be > done. So, in this model, the AAA server will only derive keys for the > requested target NAS devices - so, the station will know where the keys > are sent. Am I missing something? While technologies such as 802.11 allow a NAS to discover the L2 address of its neighbors (e.g. IEEE 802.11k Neighbor Report), there is currently no mechanism to allow discovery of L3 addresses or names. So today an AP has no way to learn the L3 address of a neighbor, let alone the neighbor NAS-Identifier. So before the AAA client could provide this information to the server it would need a mechanism to obtain it. In the case of 802.11, this would probably imply the addition of an L3 address or NAS-Identifier IE to the Beacon/Probe Response. I think that IEEE 802.11r does include support for the latter, but not the former. > Yes, true. I have wondered why RFC3576 wasn't made a bit more generic, > with "disconnect" being one type of message. But, why is this style bad? The issue is that RFC 3576 has not been widely implemented. There are a few devices that support it (e.g. Airespace WLAN switches) and a few servers. This makes it possible to deploy RFC 3576 in an intra-domain scenario, but in inter-domain scenarios you'd need to upgrade all the intervening proxies and there are some substantial security issues to deal. For example, you'd need to make sure one ISP couldn't disconnect or change authorization for another ISP's users. The end result of this is that building a proxy that supports RFC 3576 in a secure way is non-trivial. > > Finally, questions were also raised about whether the > > mechanism satisfied the criteria in draft-housley since the > > pre-emptive keying scheme does not authenticate the user > > through the NAS that it will connect to. > > Maybe I'm not remembering draft-housley properly - what threat does this introduce? > If the AAA server shares an SA with the target NAS, and the MN can be > properly authenticated, why is it important that the MN be authenticated > through that NAS? Pre-emptive keying seeds the key cache at potential points of attachment, but the EAP peer only authenticates with the target NAS, the AAA server never confirms that the EAP peer used the key. The only indication the AAA server receives is an Accounting-Start from the target NAS, indicating that the EAP peer has connected. Because the AAA server can never confirm that the EAP peer was even considering the target NAS, it has no way to know whether the Accounting-Start it received is authentic. This enables a rogue operator to generate fraudulent accounting records that cannot be easily checked by the AAA server. > > As a result, the focus of work on fast handoff has shifted > > away from pre-emptive keying schemes initiated by the server, > > toward "key request" schemes initiated by the peer. > > Advantages of "Key Request" include: > > > > a. The station can send an authenticated "Key Request" via > > the target NAS, sychronizing the key state between the peer, > > NAS and server and enabling integration between roaming and > > key management on the peer. > > > > Obviously, this is straightforward - but, are there security reasons why this is better? The requirement that the EAP peer demonstrate interest in the target NAS and prove its identity means that there is an authentication attempt to go along with the Accounting-Start. > > b. A conventional AAA Request/Response conversation is > > sufficient; server initiated messages are not required. > > I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs. >From what I can tell, the security of the "Key Request" scheme is equal to or better than pre-emptive keying, without requiring server-initiated messages or changes to the lower layer neighbor reporting mechanisms. > > c. "Key Request" relies on local information available to the > > station rather than a global map of the topology kept on the > > AAA server, so that it scales better in roaming scenarios. > > As I mentioned above, perhaps this model can still be preserved? The nice thing about "Key Request" is that the peer figures out who the neighbors are, so the AAA server or NAS doesn't have to. Note also that in inter-media handoffs, the peer's idea of a "neighbor" may not correspond to the AP's idea. > I was not aware that a proactive approach was considered by 802.11r - > any particular reason why it was rejected? Is it simply to avoid making > changes to AAA or due to other reasons? Since both "Key Request" and "pre-emptive keying" approaches require AAA changes, I don't think that this was the deciding factor. My understanding is that "Key Request" is more in tune with the station-initiated nature of 802.11 roaming than "pre-emptive keying", and that this coupled with the RFC 3576 deployment issues and potential security concerns lead to "Key Request" being preferred. > Yes, and therein lies the problem. At least for requirements we have on handoff > times for some of the applications we are seeing, it seems rather > unacceptable to have any need for conversation with the AAA server at > the time of handoff. This is leading to designs that include intermediate key > hierarchy branches off the MSK as Madjid pointed out. One thing to keep in mind is that the total transaction time is not the only factor determining whether a handoff can be completed in time. A more important factor is the key cache hit rate and the lead time. If knowledge of key state is synchronized and the neighboring NASes can be determined well ahead of time, then the introduction of one or more roundtrips to the AAA server may not matter that much because EAP authentication or "Key Request" may be a rare event. As an example, in a building where there are two WLAN switches, an EAP peer with an awareness of the key cache boundaries would only need to authenticate with each switch once a key cache entry had expired. So if the key lifetime is 24 hours, the peer might authenticate with each switch at the beginning of the day, and then not do any other EAP authentications until the next day. In such a situation the extra round-trips to the AAA server of an EAP pre-authentication or "Key Request" do not affect performance or AAA server loading that adversely. > This is true. However, is it because AAA lacks support for this or is > it the "key request" approach is technically a better one? AAA servers don't support either pre-emptive keying or key request, so that's probably not a factor. > I do realize that the pre-emptive handoff work as written in the IRTF > draft does not satisfy all requirements. Is it worth looking at whether > it will be more applicable with some changes, such as a method to send > multiple NAS-IDs to the AAA server? I think it would probably be worth bringing the issue up in IEEE 802.11r, so as to clarify exactly what (if anything) they want from the IETF. >From my perspective, a very valuable contribution would be to develop a requirements document that states clearly what the problem is and what a good solution would look like. For example, to date there are a lot of different notions of what "fast" means, or what scenarios need to be supported and why. Without consensus on what the problem is or how we know when it is solved, it is difficult to make much progress. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 21:04: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: Do we have consensus on the Digest Auth draft issues? Date: Wed, 10 Aug 2005 17:04:14 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324C1@MAANDMBX2.ets.enterasys.com> Thread-Topic: Do we have consensus on the Digest Auth draft issues? Thread-Index: AcWd7xBAJ6XL+tFZTXex5teyyLOA+Q== From: "Nelson, David" To: I'm starting a few threads on the RADEXT WG mailing list to follow up on issues discussed at the IETF-63 RADEXT session. The first is the status of the RADIUS Digest Authentication draft. The substantive issue with the draft-ietf-radext-diget-auth-03.txt seems to be how to deal with Diameter interoperability of the two different sources of nonce. The general sense of the room at IETF-63 seemed to be that the Digest Auth draft needed to support both modes, and that the companion Diameter draft would need to follow suit. This places the Diameter compatibility action item with the Diameter document. Does the WG at large agree? Please reply. Assuming that we do agree, then what action item doe we have w.r.t. the Diameter document? There is some substantial schedule pressure to get the Digest Auth draft (-04) to the IESG, as 3GPP2 has a normative dependency on its publication. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 20:02:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: It's all in the timing... Date: Wed, 10 Aug 2005 16:01:58 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324BF@MAANDMBX2.ets.enterasys.com> Thread-Topic: It's all in the timing... Thread-Index: AcWd5l00R6fHFsvYThuKRI4cllWSoA== From: "Nelson, David" To: I have a general concern, or meta-issue, to raise regarding the WGLC of draft-ietf-radext-ieee802-00.txt. The VLAN, Priority and Filtering Attributes draft proposes new RADIUS attributes of base data type String (Octet String) that are, in fact, multi-field structures a.k.a. complex data types. The prose of the draft describes the content and delimitation of the various fields. This seems clear enough. My concern is that RADEXT is prepared to send this draft to the IESG for approval and publication before another WG work item, Design Guidelines for RADIUS Attributes, has been completed. My sincere thanks go to Greg Weber for stepping up to work on this document. The new attributes specified in the VLAN, Priority and Filtering Attributes draft may very well fall within the design guidelines that are eventually set for complex data types in Design Guidelines for RADIUS Attributes. However, if they are not, then RADEXT will be in the position of publishing a Standards Track RFC that introduces attributes that do not follow its own design guidelines. IMHO, this would be a Very Bad Thing (tm). It would be at least inconsistent and at most down right embarrassing. My frustration is that I don't see a good solution. The Design Guidelines for RADIUS Attributes must be given time to mature and obtain consensus. It does not seem reasonable to delay the VLAN, Priority and Filtering Attributes draft until the design guidelines are ready. I guess the best I can hope for is that work on the design guidelines progresses rapidly, and that any substantial disconnects between the design guidelines and the VLAN, Priority and Filtering Attributes draft can be reconciled before it goes out for IETF Last Call. Other suggestions are more than welcome... The WG's initial schedule, as captured in the charter, was to complete the design guidelines work early on. Had that happened as planned, this sort of dependency problem would not have arisen. But we are where we are. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 10 Aug 2005 18:56: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: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Date: Wed, 10 Aug 2005 14:55:13 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324BE@MAANDMBX2.ets.enterasys.com> Thread-Topic: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWFybZp/uP5ITr6TdOU6yD6mQRCHwX1uhSgAAzGbWA= From: "Nelson, David" To: "Bernard Aboba" , My WGLC comments on the subject draft are included herein. -------------- 1. Introduction=20 =20 Within the confines of RADIUS authentication, authorization, and=20 accounting (AAA) environments, there is a general dearth of=20 standardized RADIUS attributes to limit user access using dynamic=20 VLANs, filters or redirection. Could we change "a general dearth of" to "a requirement for"? It sounds more positive. ------------- User traffic redirection is supported with or without tunneling.=20 Tunneling support is provided using the tunnel attributes defined=20 in [RFC2868]. Redirection of traffic in mid-session may break=20 applications. Remove "or without". I thought we had agreed to remove support for non-tunneled IP redirection. --------------- IEEE 802.1X-2004 [IEEE8021X] provides "network port=20 authentication" for IEEE 802 [IEEE802] media, including Ethernet=20 [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i]. Remove this sentence as it appears in the second paragraph as well. --------------- 1.1 Terminology The following definitions are not used in the draft: Access Point Association Station -------------- 2. Overview The first paragraph is awkwardly worded. Perhaps the following would be an improvement. In this section we provide an elaboration of the requirements=20 briefly described in the Introduction. ------------ For example, the user maybe on=20 a prepaid plan and all the resources have been used up. Change "maybe" to "may be" and "resources have" to "credit balance has". -------------- For example, the ability to block and=20 redirect traffic is required for TCP users, cell phone users, WiFi users. Change "TCP users" to "IP users". ------------- Change: As pointed out by [NASREQ] the use Filter-Id is not roaming=20 friendly and it is recommended that instead one should use NAS- Filter-Rule(TBD) AVP. For this reason, this document introduces=20 NAS-Filter-Rule(TBD) to RADIUS. To: As pointed out by [NASREQ] the use Filter-Id is not roaming=20 friendly and it is recommended that instead one should adapt=20 the Diameter NAS-Filter-Rule AVP as a RADIUS NAS-Filter-Rule(TBD) attribute. ----------- 2.1. Capability Advertisement=20 =20 RADIUS does not currently define a method by which a NAS can=20 advertise its capabilities and in many instances, it would be=20 desirable for the home network to know what capabilities are=20 supported by the NAS to ensure proper operational behavior. The=20 attributes defined in this document are intended to be used to=20 enforce policy by the NAS. If a NAS does not recognize these=20 attributes it will most likely ignore them and the desired policy=20 will not be enforced. A method for the NAS advertising the=20 capability to support these attributes would help the RADIUS=20 server understand if the intended policies can be enforced. As a=20 result, the attributes in this document, in particular NAS-Filter- Rule(TBD), can benefit from capability advertisement, if=20 available. =20 Should this entire section perhaps be part of the Security Considerations? ----------- Change: Similarly, if a NAS conforming to this specification receives a=20 CoA message that contains an attribute from this document that it=20 does not recognize or cannot apply, it MUST NOT terminate the=20 session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101)=20 set to "Unsupported Attribute"(401). =20 To: Similarly, if a NAS conforming to this specification and also conforming to RFC 3576 [RFC3576] receives a CoA message that=20 contains an attribute from this document that it does not=20 recognize or cannot apply, it MUST NOT terminate the session and MUST generate a CoA-NAK packet with Error-Cause (101) set to "Unsupported Attribute"(401). =20 ------------ 3.1. Egress-VLANID Integer=20 =20 The Integer field is four octets in length. The format of the=20 Integer field consists of two parts, the first consuming high- order octet and the second consuming the remaining three lower- order octets. The high-order octet field indicates if the=20 VLANID is allowed for tagged or untagged packets. The second=20 part is the 12-bit 802.1Q VLAN VID value that has been padded=20 out to consume the remaining three lower-order octets. A=20 sample encoding follows: =20 This is not an Integer data type. It is a multi-field Octet String (complex data type). ----------- 3.4. User-Priority-Table=20 =20 Description=20 =20 IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re- map) user priority on frames received at a port. Change "IEEE 802.1D" to "IEEE 802.1D [IEEE8021D]". ----------- 3.5. NAS-Filter-Rule Furthermore, the concatenated filter list=20 must abide to the following rules of precedence and ordering:=20 =20 1) A flush rule MUST appear before all other rule types.=20 Change "A flush rule" to "A flush rule, when present,". 2) Base encapsulation filter rules MUST appear after a=20 flush rule and before IP tunnel, HTTP redirect, IP=20 filter, and/or HTTP filter rules. Change "a flush rule" to "any flush rule". dir "in" is from the terminal, "out" is to the=20 terminal, "inout" is from and to the terminal. The term "terminal" is not defined in the draft. I suspect it identifies the network entity which contains the IEEE 802.1X Supplicant function, but this should perhaps be clarified. General comment: I'd much rather that we use ABNF to define the NAS-Filter-Rule formal syntax, however I'm not prepared to submit that text just now. :-) ------------ 4.1. Acct-NAS-Filter-Rule The first eight octets of this string are used for a 64-bit=20 value of the rule counter. The remaining octets are used to=20 specify which filter rule the counter value is for. The rule=20 specification MUST conform to the syntax rules specified for=20 NAS-Filter-Rule[TODO]. Provide the [TODO]. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 18:42:25 +0000 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A72B2@il02exm13> From: Narayanan Vidya-CVN065 To: "'Bernard Aboba'" Cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Date: Wed, 10 Aug 2005 13:42:02 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Bernard, Thanks for the detailed explanation. This was very helpful to me. Please see some questions/comments inline. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, August 10, 2005 11:38 AM > To: Narayanan Vidya-CVN065 > Cc: radiusext@ops.ietf.org; aaa-wg@merit.edu; Korus Mike-CMK013 > Subject: Re: AAA for Handovers > > > > A while ago, some work was done in the IRTF on RADIUS for > handovers in > > the aaaarch-handoff draft, but it seems to have rather died now. > > The extension specified in the draft was implemented, and > experimental measurements were made that showed that the > technique was effective in intra-domain use. > > However, in other scenarios there are potential efficiency > issues since in 802.11 handoff is station-initiated and yet > pre-emptive keying does not allow the station to know where > keys have been sent. As a result, the key state between the > peer, authenticator and server is not kept in sync and the > station may not be able to make effective roaming decisions. > For example, in roaming scenarios the server would be > unlikely to have a complete knowledge of the topology and > thus would be unable to determine where to send keying material. > Can this not be addressed by providing a mechanism in AAA to carry target NAS-IDs from the current NAS through which the STA is authenticating? I agree that it is unrealistic to expect the AAA server to have complete knowledge of the topology. By allowing this information to be carried in RADIUS to the server, the topology information can still come from the STA - of course, this will require some support from EAP as well to get this from the STA to the current NAS, but it still seems like it can be done. So, in this model, the AAA server will only derive keys for the requested target NAS devices - so, the station will know where the keys are sent. Am I missing something? > This causes pre-emptive keying to be ineffective in > inter-domain use. There are also concerns about intra-domain > deployments because pre-emptive keying requires RFC > 3576-style server-initiated messages. > Yes, true. I have wondered why RFC3576 wasn't made a bit more generic, with "disconnect" being one type of message. But, why is this style bad? > Finally, questions were also raised about whether the > mechanism satisfied the criteria in draft-housley since the > pre-emptive keying scheme does not authenticate the user > through the NAS that it will connect to. > Maybe I'm not remembering draft-housley properly - what threat does this introduce? If the AAA server shares an SA with the target NAS, and the MN can be properly authenticated, why is it important that the MN be authenticated through that NAS? > As a result, the focus of work on fast handoff has shifted > away from pre-emptive keying schemes initiated by the server, > toward "key request" schemes initiated by the peer. > Advantages of "Key Request" include: > > a. The station can send an authenticated "Key Request" via > the target NAS, sychronizing the key state between the peer, > NAS and server and enabling integration between roaming and > key management on the peer. > Obviously, this is straightforward - but, are there security reasons why this is better? > b. A conventional AAA Request/Response conversation is > sufficient; server initiated messages are not required. > I guess I am trying to see if by adding new AAA messages, we can achieve better security along with faster handoffs. > c. "Key Request" relies on local information available to the > station rather than a global map of the topology kept on the > AAA server, so that it scales better in roaming scenarios. > As I mentioned above, perhaps this model can still be preserved? > > Thinking about this a little further, it seems like such a > design is > >becoming popular due to the lack of a method in AAA to > pre-authenticate > >to multiple authenticators (NAS-es) and proactively > distribute keys to > >the NAS-es. > > As I understand it, IEEE 802.11r supports both conventional > pre-authentication as well as a "Key Request" mode. However, > it does not support pre-emptive keying. > > Note that the terms "pre-authentication" and "proactive" are > mutually exclusive. Pre-authentication schemes (such as Key > Request) are station initiated; "proactive" schemes are > server-initiated. Typically a given approach will do one or > the other, but not both. My understanding is that IEEE > 802.11r has rejected the "proactive" approach. Yes, since pre-authentication and proactive aren't the same thing, I included both terms in my statement above :) I was not aware that a proactive approach was considered by 802.11r - any particular reason why it was rejected? Is it simply to avoid making changes to AAA or due to other reasons? > > Note that "Key Request" schemes do not eliminate the need for > a conversation between the NAS and AAA server, they merely > shorten it. For example, a "fast resume" typically requires > 2.5 roundtrips, while a Key Request might be completed in a > single round-trip. > Yes, and therein lies the problem. At least for requirements we have on handoff times for some of the applications we are seeing, it seems rather unacceptable to have any need for conversation with the AAA server at the time of handoff. This is leading to designs that include intermediate key hierarchy branches off the MSK as Madjid pointed out. > >It seems to me that if the IETF worked on this and matured > it enough, > >people would be willing to use it to provide more secure faster > >handoffs. > > Dorothy Stanley the IEEE 802.11 liaison has mentioned that > IEEE 802.11r may make a liaison request for work on fast > handoff. However, based on the discussion that has occurred > so far, it seems unlikely that such a request will relate to > pre-emptive keying. "Key Request" approaches have a lot more > support at this point. > This is true. However, is it because AAA lacks support for this or is it the "key request" approach is technically a better one? > >Especially since some work was done in this space earlier > on, it seems > >like it might be worth looking into. The IRTF draft was ahead of its > >time when it was written - but, it seems like the timing for such a > >task would be perfect now. > > As mentioned earlier, the IRTF work on pre-emptive handoff is > not moving forward because it does not satisfy the problem > requirements as they are currently understood. I do realize that the pre-emptive handoff work as written in the IRTF draft does not satisfy all requirements. Is it worth looking at whether it will be more applicable with some changes, such as a method to send multiple NAS-IDs to the AAA server? Thanks, Vidya > Current work > is focused on "Key Request" approaches. However, some > fundamental questions remain about how "Key Request" would work: > > a. How are the keys to be named? Can the key naming scheme > used in the EAP key management framework be used? > > b. Can different media simultaneously use the key request > scheme? If so, does the AAA server need to maintain a > different cache for each media or can a single cache be supported? > > c. How is the key request authenticated? > > d. How does the peer direct the key request to the correct > AAA server? How does this work if the EAP method in question > does not provide a Server-ID so that the peer is unaware of > where its keys are being cached? > -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 18:34:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: HTTP NAS-Filter-Rules always assume port 80 Date: Wed, 10 Aug 2005 11:34:42 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA5548240336BC2B@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue: HTTP NAS-Filter-Rules always assume port 80 Thread-Index: AcWd2ix6C3+0EsYXTNWB9vBiijJJ8w== From: "Congdon, Paul T (ProCurve)" To: Cc: "Congdon, Paul T (ProCurve)" HTTP NAS-Filter-Rules always assume port 80 Submitter name: Paul Congdon=20 Submitter email address: paul.congdon@hp.com Date first submitted: 08-10-2005 Reference: N/A Document: draft-ietf-radext-ieee802-00.txt=20 Comment type: T Priority: S Section: 3.5 Rationale/Explanation of issue: There appears to be no way to augment the HTTP rules with a port number if we want to attempt to match HTTP traffic on something other than port 80. This is likely useful in enterprise environments where proxies may be used and browsers are configured to use something other than port 80. Seems like we should add the ports options seen in the IP filter to the HTTP rule. Requested change: Add the {port/port-port}[,ports[,...]] option that appears in the IP rule to the HTTP rule as well. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 18:27: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: Issue: redir_cnt not included as method of redirection removal Date: Wed, 10 Aug 2005 11:26:21 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA5548240336BC20@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue: redir_cnt not included as method of redirection removal Thread-Index: AcWd2QGr06YlvSCpSfG1K4PnRuULEA== From: "Congdon, Paul T (ProCurve)" To: Cc: "Congdon, Paul T (ProCurve)" redir_cnt not included as method of redirection removal Submitter name: Paul Congdon Submitter email address: paul.congdon@hp.com Date first submitted: 08-10-2005 Reference: N/A Document: draft-ietf-radext-ieee802-00.txt Comment type: T Priority: S Section: A.2.3, Pg 27, last paragraph Rationale/Explanation of issue: This section talks about how the redirection process can be disabled. Since we added the redir_cnt parameter to the rule we should include it as a mechanism for disabling redirection. Also it isn't clear if a new session is created when the redir_cnt value becomes zero. If a new session is created, then the accounting records should also be sent. I will propose that we insert a paragraph before the last paragraph in this clause so the accounting scheme will remain intact. Requested change: Insert a paragraph before the last paragraph that describes the redir_cnt scheme. Suggest something like the following words: "When HTTP redirection is established via a NAS-Filter-Rule (TBD) it also possible to have HTTP redirection automatically removed by including a redir_cnt parameter along with the rule. The rule will be removed from the active rule set when the rule matches redir_cnt number of times. When the rule is removed, HTTP redirection will also be removed." -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 16:38:19 +0000 Date: Wed, 10 Aug 2005 09:38:03 -0700 (PDT) From: Bernard Aboba To: Narayanan Vidya-CVN065 cc: radiusext@ops.ietf.org, aaa-wg@merit.edu, Korus Mike-CMK013 Subject: Re: AAA for Handovers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A while ago, some work was done in the IRTF on RADIUS for handovers in the > aaaarch-handoff draft, but it seems to have rather died now. The extension specified in the draft was implemented, and experimental measurements were made that showed that the technique was effective in intra-domain use. However, in other scenarios there are potential efficiency issues since in 802.11 handoff is station-initiated and yet pre-emptive keying does not allow the station to know where keys have been sent. As a result, the key state between the peer, authenticator and server is not kept in sync and the station may not be able to make effective roaming decisions. For example, in roaming scenarios the server would be unlikely to have a complete knowledge of the topology and thus would be unable to determine where to send keying material. This causes pre-emptive keying to be ineffective in inter-domain use. There are also concerns about intra-domain deployments because pre-emptive keying requires RFC 3576-style server-initiated messages. Finally, questions were also raised about whether the mechanism satisfied the criteria in draft-housley since the pre-emptive keying scheme does not authenticate the user through the NAS that it will connect to. As a result, the focus of work on fast handoff has shifted away from pre-emptive keying schemes initiated by the server, toward "key request" schemes initiated by the peer. Advantages of "Key Request" include: a. The station can send an authenticated "Key Request" via the target NAS, sychronizing the key state between the peer, NAS and server and enabling integration between roaming and key management on the peer. b. A conventional AAA Request/Response conversation is sufficient; server initiated messages are not required. c. "Key Request" relies on local information available to the station rather than a global map of the topology kept on the AAA server, so that it scales better in roaming scenarios. > Thinking about this a little further, it seems like such a design is becoming popular due to the lack >of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively >distribute keys to the NAS-es. As I understand it, IEEE 802.11r supports both conventional pre-authentication as well as a "Key Request" mode. However, it does not support pre-emptive keying. Note that the terms "pre-authentication" and "proactive" are mutually exclusive. Pre-authentication schemes (such as Key Request) are station initiated; "proactive" schemes are server-initiated. Typically a given approach will do one or the other, but not both. My understanding is that IEEE 802.11r has rejected the "proactive" approach. Note that "Key Request" schemes do not eliminate the need for a conversation between the NAS and AAA server, they merely shorten it. For example, a "fast resume" typically requires 2.5 roundtrips, while a Key Request might be completed in a single round-trip. >It seems to me that if the IETF worked on this and matured it enough, >people would be willing to use it to provide more secure faster handoffs. Dorothy Stanley the IEEE 802.11 liaison has mentioned that IEEE 802.11r may make a liaison request for work on fast handoff. However, based on the discussion that has occurred so far, it seems unlikely that such a request will relate to pre-emptive keying. "Key Request" approaches have a lot more support at this point. >Especially since some work was done in this space earlier on, it seems >like it might be worth looking into. The IRTF draft was ahead of its time >when it was written - but, it seems like the timing for such a task would >be perfect now. As mentioned earlier, the IRTF work on pre-emptive handoff is not moving forward because it does not satisfy the problem requirements as they are currently understood. Current work is focused on "Key Request" approaches. However, some fundamental questions remain about how "Key Request" would work: a. How are the keys to be named? Can the key naming scheme used in the EAP key management framework be used? b. Can different media simultaneously use the key request scheme? If so, does the AAA server need to maintain a different cache for each media or can a single cache be supported? c. How is the key request authenticated? d. How does the peer direct the key request to the correct AAA server? How does this work if the EAP method in question does not provide a Server-ID so that the peer is unaware of where its keys are being cached? -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 16:08:58 +0000 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A72AE@il02exm13> From: Narayanan Vidya-CVN065 To: Nakhjiri Madjid-MNAKHJI1 , "'radiusext@ops.ietf.org'" Cc: "'aaa-wg@merit.edu'" , Korus Mike-CMK013 Subject: RE: AAA for Handovers Date: Wed, 10 Aug 2005 11:08:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DC5.C0F957DC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59DC5.C0F957DC Content-Type: text/plain Hi Madjid, Thanks for a prompt response on the topic. While I agree with you that there are things that need to be synergized between AAA and EAP for complete support, I think that it would be useful for AAA to provide a framework to do this first. I have read the draft you posted on the EAP ML. It seems to me that if AAA can mature the handover operation a little further and provide a framework, it would help in solving the issue of EAP-AAA-handovers. So, in general, I don't want to get into the discussion of EAP particulars yet - I'd like to first understand the motivations and issues from the AAA side first. Since there are people in these WGs that have looked into this before, I am really interested in hearing their thoughts on reviving this work. In general, Jari seemed supportive of the idea when I talked to him. If there are others who also feel the same, perhaps it would make sense to take a look at doing this in the IETF. Thanks, Vidya -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 Sent: Wednesday, August 10, 2005 10:34 AM To: Narayanan Vidya-CVN065; radiusext@ops.ietf.org Cc: aaa-wg@merit.edu; Korus Mike-CMK013 Subject: RE: AAA for Handovers Hi Vidya, This is a topic that has been discussed over many mailing lists and not sure if a long thread on this topic is something people like to relive. However, unfortunately, I for one have not found a recipe from IETF yet (or at least a simply digestible for an amateur EAPer like myself). So non-IETF bodies are starting to do their own methods with varying degree of regard for Housely criteria, because the limited understanding of the specification and frankly in my believe limited IETF specifications. Issues that I see: 1) As you mentioned, the common understanding of RADIUS being incapable of doing server-initiated messaging. This seems to not be the case anymore with CoA RFC, but I am not sure if CoA messaging can be used to push keys to multiple NASes. 2) A related issues is EAP's limited capability in key transport (AAA key or MSKs are only sent to the authenticator and no other entities). Also key transport and encryption standards are generally not well understood. 3) Micro mobility in many systems forces people to have base stations or access points to work at a level below the NAS for a variety of reasons, from no need for RADIUS client in the BS, to not sharing the EAP master keys at a BS that can be easily hacked. This means people are inventing key hierarchies that feed off the EAP master keys and generated BS-specific keys to prevent "domino effects". so this can't even be solved by AAA server proactively pushing keys. and Going back to AAA server for each key generation is not desirable. 4) Lack of standardized authorization attributes and messaging to allow the EAP keys to bootstrap other mechanisms such as Mobile IP and so on. People invent bootstrapping mechanisms without regard to the initial EAP key lifetimes or authorizations or without the ability to cross check these life times. The AAA community needs to simply take control by providing authorization directives to the NAS on what it can and cannot do with the keys. 5) Channel binding is a very hard topic to understand and to provide a cure for. I tried to start a discussion on this topic in the EAP group by sending a draft talking about EAP and handover support, http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt but seeing your email and doing the short list above, I think both EAP and RADIUS need to be worked together. One of the major issues is that there are people on the list that do not think there are any problems with the existing specification, so I would say the more constructive thing to do (instead of engaging in intractable debates on the list) is to work on a draft that lists the issues (I tried both above and in my draft) and then solicit answers to see if the issues have convincing answers, if not try to solve it either in EAP or in RADext or find the right IETF venue to solve the problems, unless IETF does not want to deal with this and will rather have IEEE work on it. Madjid _____ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Narayanan Vidya-CVN065 Sent: Wednesday, August 10, 2005 9:57 AM To: radiusext@ops.ietf.org Cc: aaa-wg@merit.edu; Korus Mike-CMK013 Subject: AAA for Handovers All, I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. Some thoughts on why this work would be useful: It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. Any thoughts? Thanks, Vidya ------_=_NextPart_001_01C59DC5.C0F957DC Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE1MDUiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0wNzE1NDAyMTYtMTAwODIwMDU+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IaSANCk1hZGppZCw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0wNzE1NDAyMTYtMTAwODIwMDU+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGFua3MgDQpmb3IgYSBwcm9tcHQgcmVzcG9u c2Ugb24gdGhlIHRvcGljLiBXaGlsZSBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlcmUgYXJlIHRo aW5ncyANCnRoYXQgbmVlZCB0byBiZSBzeW5lcmdpemVkIGJldHdlZW4gQUFBIGFuZCBFQVAgZm9y IGNvbXBsZXRlIHN1cHBvcnQsIEkgdGhpbmsgDQp0aGF0IGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3Ig QUFBIHRvIHByb3ZpZGUgYSBmcmFtZXdvcmsgdG8gZG8gdGhpcyBmaXJzdC4gSSBoYXZlIA0KcmVh ZCB0aGUgZHJhZnQgeW91IHBvc3RlZCBvbiB0aGUgRUFQIE1MLiBJdCBzZWVtcyB0byBtZSB0aGF0 IGlmIEFBQSBjYW4gbWF0dXJlIA0KdGhlIGhhbmRvdmVyIG9wZXJhdGlvbiBhIGxpdHRsZSBmdXJ0 aGVyIGFuZCBwcm92aWRlIGEgZnJhbWV3b3JrLCBpdCB3b3VsZCBoZWxwIA0KaW4gc29sdmluZyB0 aGUgaXNzdWUgb2YgRUFQLUFBQS1oYW5kb3ZlcnMuIFNvLCBpbiBnZW5lcmFsLCBJIGRvbid0IHdh bnQgdG8gZ2V0IA0KaW50byB0aGUgZGlzY3Vzc2lvbiBvZiBFQVAgcGFydGljdWxhcnMgeWV0IC0g SSdkIGxpa2UgdG8gZmlyc3QgdW5kZXJzdGFuZCB0aGUgDQptb3RpdmF0aW9ucyBhbmQgaXNzdWVz IGZyb20gdGhlIEFBQSBzaWRlIGZpcnN0LiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BB TiBjbGFzcz0wNzE1NDAyMTYtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA3 MTU0MDIxNi0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlNp bmNlIA0KdGhlcmUgYXJlIHBlb3BsZSBpbiB0aGVzZSBXR3MgdGhhdCBoYXZlIGxvb2tlZCBpbnRv IHRoaXMgYmVmb3JlLCBJIGFtIHJlYWxseSANCmludGVyZXN0ZWQgaW4gaGVhcmluZyB0aGVpciB0 aG91Z2h0cyBvbiByZXZpdmluZyB0aGlzIHdvcmsuIEluIGdlbmVyYWwsIEphcmkgDQpzZWVtZWQg c3VwcG9ydGl2ZSBvZiB0aGUgaWRlYSB3aGVuIEkgdGFsa2VkIHRvIGhpbS4gSWYgdGhlcmUgYXJl IG90aGVycyB3aG8gYWxzbyANCmZlZWwgdGhlIHNhbWUsIHBlcmhhcHMgaXQgd291bGQgbWFrZSBz ZW5zZSB0byB0YWtlIGEgbG9vayBhdCBkb2luZyB0aGlzIGluIHRoZSANCklFVEYuIDwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTA3MTU0MDIxNi0xMDA4MjAwNT48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJ Vj4NCjxESVY+PFNQQU4gY2xhc3M9MDcxNTQwMjE2LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCnNpemU9Mj5UaGFua3MsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+ PFNQQU4gY2xhc3M9MDcxNTQwMjE2LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiANCnNpemU9Mj5WaWR5YTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9 bHRyIA0Kc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVIt TEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJVj48L0RJ Vj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIg YWxpZ249bGVmdD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBOYWtoamlyaSANCiAgTWFkamlkLU1OQUtISkkxIDxC Uj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMDUgMTA6MzQgDQogIEFNPEJS PjxCPlRvOjwvQj4gTmFyYXlhbmFuIFZpZHlhLUNWTjA2NTsgcmFkaXVzZXh0QG9wcy5pZXRmLm9y ZzxCUj48Qj5DYzo8L0I+IA0KICBhYWEtd2dAbWVyaXQuZWR1OyBLb3J1cyBNaWtlLUNNSzAxMzxC Uj48Qj5TdWJqZWN0OjwvQj4gUkU6IEFBQSBmb3IgDQogIEhhbmRvdmVyczxCUj48QlI+PC9GT05U PjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUt MTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+SGkgVmlk eWEsPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0K ICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGlzIGlzIGEgdG9waWMgdGhhdCBoYXMgYmVlbiBkaXNj dXNzZWQgb3ZlciBtYW55IG1haWxpbmcgDQogIGxpc3RzIGFuZCBub3Qgc3VyZSBpZiBhIGxvbmcg dGhyZWFkIG9uIHRoaXMgdG9waWMgaXMgc29tZXRoaW5nIHBlb3BsZSBsaWtlIHRvIA0KICByZWxp dmUuIDwvRk9OVD48L1NQQU4+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZh Y2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhvd2V2ZXIsIHVuZm9ydHVuYXRlbHks IEkgZm9yIG9uZSBoYXZlIG5vdCBmb3VuZCBhIHJlY2lwZSANCiAgZnJvbSBJRVRGIHlldCAob3Ig YXQgbGVhc3QgYSBzaW1wbHkgZGlnZXN0aWJsZSBmb3IgYW4gYW1hdGV1ciBFQVBlciBsaWtlIA0K ICBteXNlbGYpLiBTbyBub24tSUVURiBib2RpZXMgYXJlIHN0YXJ0aW5nIHRvIGRvIHRoZWlyIG93 biBtZXRob2RzIHdpdGggdmFyeWluZyANCiAgZGVncmVlIG9mIHJlZ2FyZCBmb3IgSG91c2VseSBj cml0ZXJpYSwgYmVjYXVzZSB0aGUgbGltaXRlZCB1bmRlcnN0YW5kaW5nIG9mIA0KICB0aGUgc3Bl Y2lmaWNhdGlvbiBhbmQgZnJhbmtseSBpbiBteSBiZWxpZXZlIGxpbWl0ZWQgSUVURiANCiAgc3Bl Y2lmaWNhdGlvbnMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAwNT48Rk9OVCBmYWNl PUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5Jc3N1ZXMgdGhhdCBJIHNlZTo8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0 ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+ PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjEpIEFzIHlvdSBtZW50aW9uZWQsIHRoZSBjb21tb24gdW5kZXJzdGFuZGlu ZyBvZiBSQURJVVMgDQogIGJlaW5nIGluY2FwYWJsZSBvZiBkb2luZyBzZXJ2ZXItaW5pdGlhdGVk IG1lc3NhZ2luZy4gVGhpcyBzZWVtcyB0byBub3QgYmUgdGhlIA0KICBjYXNlIGFueW1vcmUgd2l0 aCBDb0EgUkZDLCBidXQgSSBhbSBub3Qgc3VyZSBpZiBDb0EgbWVzc2FnaW5nIGNhbiBiZSB1c2Vk IHRvIA0KICBwdXNoIGtleXMgdG8gbXVsdGlwbGUgTkFTZXMuPC9GT05UPjwvU1BBTj48L0RJVj4N CiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1 PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4 MDYxNS0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4y KSBBIHJlbGF0ZWQgaXNzdWVzIGlzIEVBUCdzIGxpbWl0ZWQgY2FwYWJpbGl0eSBpbiBrZXkgDQog IHRyYW5zcG9ydCAoQUFBIGtleSBvciBNU0tzIGFyZSBvbmx5IHNlbnQgdG8gdGhlIGF1dGhlbnRp Y2F0b3IgYW5kIG5vIG90aGVyIA0KICBlbnRpdGllcykuIEFsc28ga2V5IHRyYW5zcG9ydCBhbmQg ZW5jcnlwdGlvbiBzdGFuZGFyZHMgYXJlIGdlbmVyYWxseSBub3Qgd2VsbCANCiAgdW5kZXJzdG9v ZC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBm ZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQog IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjMpIE1pY3JvIG1vYmlsaXR5IGluIG1hbnkgc3lzdGVtcyBm b3JjZXMgcGVvcGxlIHRvIGhhdmUgDQogIGJhc2Ugc3RhdGlvbnMgb3IgYWNjZXNzIHBvaW50cyB0 byB3b3JrIGF0IGEgbGV2ZWwgYmVsb3cgdGhlIE5BUyBmb3IgYSB2YXJpZXR5IA0KICBvZiByZWFz b25zLCBmcm9tIG5vIG5lZWQgZm9yIFJBRElVUyBjbGllbnQgaW4gdGhlIEJTLCB0byBub3Qgc2hh cmluZyB0aGUgRUFQIA0KICBtYXN0ZXIga2V5cyBhdCBhIEJTIHRoYXQgY2FuIGJlIGVhc2lseSBo YWNrZWQuIFRoaXMgbWVhbnMgcGVvcGxlIGFyZSBpbnZlbnRpbmcgDQogIGtleSBoaWVyYXJjaGll cyB0aGF0IGZlZWQgb2ZmIHRoZSBFQVAgbWFzdGVyIGtleXMgYW5kIGdlbmVyYXRlZCBCUy1zcGVj aWZpYyANCiAga2V5cyB0byBwcmV2ZW50ICJkb21pbm8gZWZmZWN0cyIuIHNvIHRoaXMgY2FuJ3Qg ZXZlbiBiZSBzb2x2ZWQgYnkgQUFBIHNlcnZlciANCiAgcHJvYWN0aXZlbHkgcHVzaGluZyBrZXlz LiBhbmQgPC9GT05UPjwvU1BBTj48U1BBTiANCiAgY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+R29pbmcgYmFjayB0byANCiAgQUFB IHNlcnZlciBmb3IgZWFjaCBrZXkgZ2VuZXJhdGlvbiBpcyBub3QgZGVzaXJhYmxlLjwvRk9OVD48 L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4 MDYxNS0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAw MDBmZiBzaXplPTI+NCkgTGFjayBvZiBzdGFuZGFyZGl6ZWQgYXV0aG9yaXphdGlvbiBhdHRyaWJ1 dGVzIGFuZCANCiAgbWVzc2FnaW5nIHRvIGFsbG93IHRoZSBFQVAga2V5cyB0byBib290c3RyYXAg b3RoZXIgbWVjaGFuaXNtcyBzdWNoIGFzIE1vYmlsZSANCiAgSVAgYW5kIHNvIG9uLiBQZW9wbGUg aW52ZW50IGJvb3RzdHJhcHBpbmcgbWVjaGFuaXNtcyB3aXRob3V0IHJlZ2FyZCB0byB0aGUgDQog IGluaXRpYWwgRUFQIGtleSBsaWZldGltZXMgb3IgYXV0aG9yaXphdGlvbnMgb3Igd2l0aG91dCB0 aGUgYWJpbGl0eSB0byBjcm9zcyANCiAgY2hlY2sgdGhlc2UgbGlmZSB0aW1lcy4gVGhlIEFBQSBj b21tdW5pdHkgbmVlZHMgdG8gc2ltcGx5IHRha2UgY29udHJvbCBieSANCiAgcHJvdmlkaW5nIGF1 dGhvcml6YXRpb24gZGlyZWN0aXZlcyB0byB0aGUgTkFTIG9uIHdoYXQgaXQgY2FuIGFuZCBjYW5u b3QgZG8gDQogIHdpdGggdGhlIGtleXMuPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAw NT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj41KSBDaGFubmVsIGJp bmRpbmcgaXMgYSB2ZXJ5IGhhcmQgdG9waWMgdG8gdW5kZXJzdGFuZCBhbmQgDQogIHRvIHByb3Zp ZGUgYSBjdXJlIGZvci48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAg Y29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZh Y2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkkgdHJpZWQgdG8gc3RhcnQgYSBkaXNj dXNzaW9uIG9uIHRoaXMgdG9waWMgaW4gdGhlIEVBUCANCiAgZ3JvdXAgYnkgc2VuZGluZyBhIGRy YWZ0IHRhbGtpbmcgYWJvdXQgRUFQIGFuZCBoYW5kb3ZlciANCiAgc3VwcG9ydCw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2 MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PEEg DQogIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW5ha2hq aXJpLWVhcC1oby0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LW5ha2hqaXJpLWVhcC1oby0wMC50eHQ8L0E+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjwvU1BB Tj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQz NDgwNjE1LTEwMDgyMDA1PjwvU1BBTj48U1BBTiANCiAgY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+YnV0IHNlZWluZyB5b3VyIA0K ICBlbWFpbCBhbmQgZG9pbmcgdGhlIHNob3J0IGxpc3QgYWJvdmUsIEkgdGhpbmsgYm90aCBFQVAg YW5kIFJBRElVUyBuZWVkIHRvIGJlIA0KICB3b3JrZWQgdG9nZXRoZXIuIDwvRk9OVD48L1NQQU4+ PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0x MDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz05NDM0ODA2MTUtMTAwODIwMDU+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1Bcmlh bCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+T25lIG9mIHRoZSBtYWpvciBpc3N1ZXMgaXMgdGhh dCB0aGVyZSBhcmUgcGVvcGxlIG9uIHRoZSANCiAgbGlzdCB0aGF0IGRvIG5vdCB0aGluayB0aGVy ZSBhcmUgYW55IHByb2JsZW1zIHdpdGggdGhlIGV4aXN0aW5nIHNwZWNpZmljYXRpb24sIA0KICBz byBJIHdvdWxkIHNheSB0aGUgbW9yZSBjb25zdHJ1Y3RpdmUgdGhpbmcgdG8gZG8gKGluc3RlYWQg b2YgZW5nYWdpbmcgaW4gDQogIGludHJhY3RhYmxlIGRlYmF0ZXMgb24gdGhlIGxpc3QpIGlzIHRv IHdvcmsgb24gYSBkcmFmdCB0aGF0IGxpc3RzIHRoZSBpc3N1ZXMgDQogIChJIHRyaWVkIGJvdGgg YWJvdmUgYW5kIGluIG15IGRyYWZ0KSBhbmQgdGhlbiBzb2xpY2l0IGFuc3dlcnMgdG8gc2VlIGlm IHRoZSANCiAgaXNzdWVzIGhhdmUgY29udmluY2luZyBhbnN3ZXJzLCBpZiBub3QgdHJ5IHRvIHNv bHZlIGl0IGVpdGhlciBpbiBFQVAgb3IgaW4gDQogIFJBRGV4dCBvciBmaW5kIHRoZSByaWdodCBJ RVRGIHZlbnVlIHRvIHNvbHZlIHRoZSBwcm9ibGVtcywgdW5sZXNzIElFVEYgZG9lcyANCiAgbm90 IHdhbnQgdG8gZGVhbCB3aXRoIHRoaXMgYW5kIHdpbGwgcmF0aGVyIGhhdmUgSUVFRSB3b3JrIG9u IA0KICBpdC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9 IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJp YWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPk1hZGppZDwvRk9OVD48L1NQQU4+PC9ESVY+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjxCUj4NCiAgPERJViBjbGFzcz1PdXRs b29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRh YkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IG93bmVy LXJhZGl1c2V4dEBvcHMuaWV0Zi5vcmcgDQogIFttYWlsdG86b3duZXItcmFkaXVzZXh0QG9wcy5p ZXRmLm9yZ10gPEI+T24gQmVoYWxmIE9mIDwvQj5OYXJheWFuYW4gDQogIFZpZHlhLUNWTjA2NTxC Uj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMDUgOTo1NyBBTTxCUj48Qj5U bzo8L0I+IA0KICByYWRpdXNleHRAb3BzLmlldGYub3JnPEJSPjxCPkNjOjwvQj4gYWFhLXdnQG1l cml0LmVkdTsgS29ydXMgDQogIE1pa2UtQ01LMDEzPEJSPjxCPlN1YmplY3Q6PC9CPiBBQUEgZm9y IEhhbmRvdmVyczxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0KICA8RElWPjwh LS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5BbGw8L1NQQU4+ LDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SSBo YWQgYSBicmllZiBjaGF0IHdpdGggSmFyaSZuYnNwOzxTUEFOIA0KICBjbGFzcz01MjMzNDI4MTQt MTAwODIwMDU+QXJra28gPC9TUEFOPm9uIHRoaXMgdG9waWMmbmJzcDs8U1BBTiANCiAgY2xhc3M9 NTIzMzQyODE0LTEwMDgyMDA1PmluIFBhcmlzIDwvU1BBTj5hbmQgaGUgc3VnZ2VzdGVkIEkgYnJp bmcgaXQgDQogIHVwJm5ic3A7PFNQQU4gY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1Pm9uIHRoZSA8 L1NQQU4+UkFERVhUPFNQQU4gDQogIGNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT4gbWFpbGluZyBs aXN0PC9TUEFOPi4gPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9 Mj5BIHdoaWxlIGFnbywgc29tZSB3b3JrIHdhcyBkb25lIGluIHRoZSBJUlRGIA0KICBvbiBSQURJ VVMgZm9yIGhhbmRvdmVycyBpbiB0aGUgYWFhYXJjaC1oYW5kb2ZmIGRyYWZ0LCBidXQgaXQgc2Vl bXMgdG8gaGF2ZSANCiAgcmF0aGVyIGRpZWQgbm93LiBDdXJyZW50bHksJm5ic3A7PFNQQU4gY2xh c3M9NTIzMzQyODE0LTEwMDgyMDA1PnRoZXJlIHNlZW1zIHRvIA0KICBiZSBubyBlZmZvcnRzIHRv IGFkdmFuY2Ugc3VjaCB3b3JrIGluIHRoZSBJRVRGIG9yIElSVEYuIEkgd2FzIHdvbmRlcmluZyBp ZiANCiAgcmV2aXZpbmcgc29tZSB3b3JrIGFsb25nIHRoZSBzYW1lIGxpbmVzIG1pZ2h0IGJlIGFu IG9wdGlvbiBwZW9wbGUgd291bGQgDQogIHN1cHBvcnQgb3IgZGVzaXJlLiA8L1NQQU4+PC9GT05U PjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BB TiANCiAgY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNw OzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTUyMzM0MjgxNC0xMDA4MjAwNT5Tb21lIA0KICB0aG91Z2h0cyBvbiB3aHkgdGhpcyB3b3JrIHdv dWxkIGJlIHVzZWZ1bDogPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUyMzM0MjgxNC0xMDA4MjAw NT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+SXQgaXMgcXVp dGUgDQogIGV2aWRlbnQgdGhhdCBwZXJmb3JtaW5nIGFuIGVudGlyZSBFQVAgbWV0aG9kIGV4Y2hh bmdlIHVwb24gaGFuZG9mZiBpbnRyb2R1Y2VzIA0KICBzaWduaWZpY2FudCBpbmNyZWFzZSBpbiBo YW5kb2ZmIHRpbWVzLiBJdCBzZWVtcyB0aGF0IHBlb3BsZSBhcmUgZ2V0dGluZyBhcm91bmQgDQog IGdvaW5nIHRvIHRoZSBBQUEgc2VydmVyIGV2ZXJ5IHRpbWUgYnkgZGVmaW5pbmcgZXZvbHZpbmcg a2V5cyBhbmQgaW50cm9kdWNpbmcgDQogIGxvY2FsIEtEQ3MuIEFuIGV4YW1wbGUgaXMgdGhlIHBh dGggODAyLjExciBpcyB0YWtpbmcuIDgwMi4xMXIgaGFzIGludHJvZHVjZWQgDQogIGFuIGV2b2x2 aW5nIGtleSBoaWVyYXJjaHkgdGhhdCBhbGxvd3MgdGhlIFNUQSB0byBoYW5kb2ZmIHdpdGhvdXQg aGF2aW5nIHRvIA0KICBwZXJmb3JtIGEgZnVsbCBFQVAgZXhjaGFuZ2UuIEl0IGlzIGdlbmVyYWxs eSBhY2NlcHRlZCAoYXQgbGVhc3Qgc2VlbXMgdG8gYmUpIA0KICB0aGF0IHRoaXMgaXMgaW5oZXJl bnRseSBsZXNzIHNlY3VyZSB0aGFuIHBlcmZvcm1pbmcgcmVndWxhciBFQVAgLSBob3dldmVyLCAN CiAgdGhpcyBpcyB2aWV3ZWQgYXMgaW1wb3J0YW50IHRvIGJlIGFibGUgdG8gaGF2ZSBhY2NlcHRh YmxlIGhhbmRvZmYgdGltZXMuIEJlaW5nIA0KICBvZiB0aGUgSUVURiBtZW50YWxpdHksIHRvIG1l LCB0aGVzZSBtZWNoYW5pc21zIGRvIG5vdCBzZWVtIHRvIHNhdGlzZnkgYWxsIHRoZSANCiAgSG91 c2xleSBjcml0ZXJpYSBhcyB0aGV5IHNob3VsZC4gSG93ZXZlciwgd2l0aG91dCBjaGFuZ2VzIGlu IEFBQSwgSSBkb24ndCBoYXZlIA0KICBhIGJldHRlciZuYnNwO2Fuc3dlciB0byByZWR1Y2luZyBo YW5kb2ZmIHRpbWVzLiA8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1 PjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJp YWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5UaGlua2luZyAN CiAgYWJvdXQgdGhpcyBhIGxpdHRsZSBmdXJ0aGVyLCBpdCBzZWVtcyBsaWtlIHN1Y2ggYSBkZXNp Z24gaXMgYmVjb21pbmcgcG9wdWxhciANCiAgZHVlIHRvIHRoZSBsYWNrIG9mIGEgbWV0aG9kIGlu IEFBQSB0byBwcmUtYXV0aGVudGljYXRlIHRvIG11bHRpcGxlIA0KICBhdXRoZW50aWNhdG9ycyAo TkFTLWVzKSBhbmQgcHJvYWN0aXZlbHkgZGlzdHJpYnV0ZSBrZXlzIHRvIHRoZSBOQVMtZXMuIElm IA0KICB0aGVyZSB3YXMgYSB3YXkgdG8gZG8gdGhpcywgaXQgd291bGQgYmUgcG9zc2libGUgdG8g ZGVyaXZlIG11bHRpcGxlIGtleXMgYXQgDQogIHRoZSBBQUEgc2VydmVyIGZvciBhIG1vYmlsZSBu b2RlIGNvcnJlc3BvbmRpbmcgdG8gdGFyZ2V0IE5BUyBkZXZpY2VzIGFuZCANCiAgcHJvYWN0aXZl bHkgcHVzaCB0aGUga2V5cyB0byB0aG9zZSBkZXZpY2VzIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGEg Y29tcGxldGUgDQogIGF1dGhlbnRpY2F0aW9uIGFuZCBrZXkgZGVyaXZhdGlvbiB1cG9uIGhhbmRv ZmYuIEl0IHdvdWxkIGFsbG93IHNpZ25pZmljYW50IA0KICByZWR1Y3Rpb24gaW4gdGhlIHNpZ25h bGluZyByZXF1aXJlZCB0byBlc3RhYmxpc2gga2V5cyBhdCBOQVMtZXMuIA0KICA8L1NQQU4+PC9G T05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48 U1BBTiANCiAgY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZu YnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNs YXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5JdCBzZWVtcyB0byANCiAgbWUgdGhhdCBpZiB0aGUgSUVU RiB3b3JrZWQgb24gdGhpcyBhbmQgbWF0dXJlZCBpdCBlbm91Z2gsIHBlb3BsZSB3b3VsZCBiZSAN CiAgd2lsbGluZyB0byB1c2UgaXQgdG8gcHJvdmlkZSBtb3JlIHNlY3VyZSBmYXN0ZXIgaGFuZG9m ZnMuIEVzcGVjaWFsbHkgc2luY2UgDQogIHNvbWUgd29yayB3YXMgZG9uZSBpbiB0aGlzIHNwYWNl IGVhcmxpZXIgb24sIGl0IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgd29ydGggDQogIGxvb2tpbmcg aW50by4gVGhlIElSVEYgZHJhZnQgd2FzIGFoZWFkIG9mIGl0cyB0aW1lIHdoZW4gaXQgd2FzIHdy aXR0ZW4gLSBidXQsIA0KICBpdCBzZWVtcyBsaWtlIHRoZSB0aW1pbmcgZm9yIHN1Y2ggYSB0YXNr IHdvdWxkIGJlIHBlcmZlY3Qgbm93LiANCiAgPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQog IDxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUyMzM0 MjgxNC0xMDA4MjAwNT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz01MjMzNDI4MTQtMTAwODIw MDU+QW55IA0KICB0aG91Z2h0cz8gPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUyMzM0MjgxNC0x MDA4MjAwNT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1 PlRoYW5rcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFy aWFsPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PlZpZHlh PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C59DC5.C0F957DC-- -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 15:33:52 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: Narayanan Vidya-CVN065 , radiusext@ops.ietf.org Cc: aaa-wg@merit.edu, Korus Mike-CMK013 Subject: RE: AAA for Handovers Date: Wed, 10 Aug 2005 10:33:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DC0.E1B45090" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59DC0.E1B45090 Content-Type: text/plain Hi Vidya, This is a topic that has been discussed over many mailing lists and not sure if a long thread on this topic is something people like to relive. However, unfortunately, I for one have not found a recipe from IETF yet (or at least a simply digestible for an amateur EAPer like myself). So non-IETF bodies are starting to do their own methods with varying degree of regard for Housely criteria, because the limited understanding of the specification and frankly in my believe limited IETF specifications. Issues that I see: 1) As you mentioned, the common understanding of RADIUS being incapable of doing server-initiated messaging. This seems to not be the case anymore with CoA RFC, but I am not sure if CoA messaging can be used to push keys to multiple NASes. 2) A related issues is EAP's limited capability in key transport (AAA key or MSKs are only sent to the authenticator and no other entities). Also key transport and encryption standards are generally not well understood. 3) Micro mobility in many systems forces people to have base stations or access points to work at a level below the NAS for a variety of reasons, from no need for RADIUS client in the BS, to not sharing the EAP master keys at a BS that can be easily hacked. This means people are inventing key hierarchies that feed off the EAP master keys and generated BS-specific keys to prevent "domino effects". so this can't even be solved by AAA server proactively pushing keys. and Going back to AAA server for each key generation is not desirable. 4) Lack of standardized authorization attributes and messaging to allow the EAP keys to bootstrap other mechanisms such as Mobile IP and so on. People invent bootstrapping mechanisms without regard to the initial EAP key lifetimes or authorizations or without the ability to cross check these life times. The AAA community needs to simply take control by providing authorization directives to the NAS on what it can and cannot do with the keys. 5) Channel binding is a very hard topic to understand and to provide a cure for. I tried to start a discussion on this topic in the EAP group by sending a draft talking about EAP and handover support, http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt but seeing your email and doing the short list above, I think both EAP and RADIUS need to be worked together. One of the major issues is that there are people on the list that do not think there are any problems with the existing specification, so I would say the more constructive thing to do (instead of engaging in intractable debates on the list) is to work on a draft that lists the issues (I tried both above and in my draft) and then solicit answers to see if the issues have convincing answers, if not try to solve it either in EAP or in RADext or find the right IETF venue to solve the problems, unless IETF does not want to deal with this and will rather have IEEE work on it. Madjid _____ From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Narayanan Vidya-CVN065 Sent: Wednesday, August 10, 2005 9:57 AM To: radiusext@ops.ietf.org Cc: aaa-wg@merit.edu; Korus Mike-CMK013 Subject: AAA for Handovers All, I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. Some thoughts on why this work would be useful: It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. Any thoughts? Thanks, Vidya ------_=_NextPart_001_01C59DC0.E1B45090 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE1MDUiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQz NDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5I aSBWaWR5YSw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQ QU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAw MGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpj b2xvcj0jMDAwMGZmIHNpemU9Mj5UaGlzIGlzIGEgdG9waWMgdGhhdCBoYXMgYmVlbiBkaXNjdXNz ZWQgb3ZlciBtYW55IG1haWxpbmcgDQpsaXN0cyBhbmQgbm90IHN1cmUgaWYgYSBsb25nIHRocmVh ZCBvbiB0aGlzIHRvcGljIGlzIHNvbWV0aGluZyBwZW9wbGUgbGlrZSB0byANCnJlbGl2ZS4gPC9G T05UPjwvU1BBTj48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1Bcmlh bCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhvd2V2ZXIsIHVuZm9ydHVuYXRlbHksIEkgZm9yIG9u ZSBoYXZlIG5vdCBmb3VuZCBhIHJlY2lwZSANCmZyb20gSUVURiB5ZXQgKG9yIGF0IGxlYXN0IGEg c2ltcGx5IGRpZ2VzdGlibGUgZm9yIGFuIGFtYXRldXIgRUFQZXIgbGlrZSANCm15c2VsZikuIFNv IG5vbi1JRVRGIGJvZGllcyBhcmUgc3RhcnRpbmcgdG8gZG8gdGhlaXIgb3duIG1ldGhvZHMgd2l0 aCB2YXJ5aW5nIA0KZGVncmVlIG9mIHJlZ2FyZCBmb3IgSG91c2VseSBjcml0ZXJpYSwgYmVjYXVz ZSB0aGUgbGltaXRlZCB1bmRlcnN0YW5kaW5nIG9mIHRoZSANCnNwZWNpZmljYXRpb24gYW5kIGZy YW5rbHkgaW4gbXkgYmVsaWV2ZSBsaW1pdGVkIElFVEYgDQpzcGVjaWZpY2F0aW9ucy48L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgw NjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNp emU9Mj5Jc3N1ZXMgdGhhdCBJIHNlZTo8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05U IGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj4xKSBBcyB5b3UgbWVudGlvbmVkLCB0 aGUgY29tbW9uIHVuZGVyc3RhbmRpbmcgb2YgUkFESVVTIA0KYmVpbmcgaW5jYXBhYmxlIG9mIGRv aW5nIHNlcnZlci1pbml0aWF0ZWQgbWVzc2FnaW5nLiBUaGlzIHNlZW1zIHRvIG5vdCBiZSB0aGUg DQpjYXNlIGFueW1vcmUgd2l0aCBDb0EgUkZDLCBidXQgSSBhbSBub3Qgc3VyZSBpZiBDb0EgbWVz c2FnaW5nIGNhbiBiZSB1c2VkIHRvIA0KcHVzaCBrZXlzIHRvIG11bHRpcGxlIE5BU2VzLjwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0 ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYg c2l6ZT0yPjIpIEEgcmVsYXRlZCBpc3N1ZXMgaXMgRUFQJ3MgbGltaXRlZCBjYXBhYmlsaXR5IGlu IGtleSANCnRyYW5zcG9ydCAoQUFBIGtleSBvciBNU0tzIGFyZSBvbmx5IHNlbnQgdG8gdGhlIGF1 dGhlbnRpY2F0b3IgYW5kIG5vIG90aGVyIA0KZW50aXRpZXMpLiBBbHNvIGtleSB0cmFuc3BvcnQg YW5kIGVuY3J5cHRpb24gc3RhbmRhcmRzIGFyZSBnZW5lcmFsbHkgbm90IHdlbGwgDQp1bmRlcnN0 b29kLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBj bGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9y PSMwMDAwZmYgc2l6ZT0yPjMpIE1pY3JvIG1vYmlsaXR5IGluIG1hbnkgc3lzdGVtcyBmb3JjZXMg cGVvcGxlIHRvIGhhdmUgDQpiYXNlIHN0YXRpb25zIG9yIGFjY2VzcyBwb2ludHMgdG8gd29yayBh dCBhIGxldmVsIGJlbG93IHRoZSBOQVMgZm9yIGEgdmFyaWV0eSBvZiANCnJlYXNvbnMsIGZyb20g bm8gbmVlZCBmb3IgUkFESVVTIGNsaWVudCBpbiB0aGUgQlMsIHRvIG5vdCBzaGFyaW5nIHRoZSBF QVAgbWFzdGVyIA0Ka2V5cyBhdCBhIEJTIHRoYXQgY2FuIGJlIGVhc2lseSBoYWNrZWQuIFRoaXMg bWVhbnMgcGVvcGxlIGFyZSBpbnZlbnRpbmcga2V5IA0KaGllcmFyY2hpZXMgdGhhdCBmZWVkIG9m ZiB0aGUgRUFQIG1hc3RlciBrZXlzIGFuZCBnZW5lcmF0ZWQgQlMtc3BlY2lmaWMga2V5cyB0byAN CnByZXZlbnQgImRvbWlubyBlZmZlY3RzIi4gc28gdGhpcyBjYW4ndCBldmVuIGJlIHNvbHZlZCBi eSBBQUEgc2VydmVyIHByb2FjdGl2ZWx5IA0KcHVzaGluZyBrZXlzLiBhbmQgPC9GT05UPjwvU1BB Tj48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9y PSMwMDAwZmYgc2l6ZT0yPkdvaW5nIGJhY2sgdG8gQUFBIHNlcnZlciBmb3IgZWFjaCBrZXkgZ2Vu ZXJhdGlvbiBpcyBub3QgDQpkZXNpcmFibGUuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAwNT48Rk9OVCBmYWNl PUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAwNT48 Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+NCkgTGFjayBvZiBzdGFuZGFy ZGl6ZWQgYXV0aG9yaXphdGlvbiBhdHRyaWJ1dGVzIGFuZCANCm1lc3NhZ2luZyB0byBhbGxvdyB0 aGUgRUFQIGtleXMgdG8gYm9vdHN0cmFwIG90aGVyIG1lY2hhbmlzbXMgc3VjaCBhcyBNb2JpbGUg SVAgDQphbmQgc28gb24uIFBlb3BsZSBpbnZlbnQgYm9vdHN0cmFwcGluZyBtZWNoYW5pc21zIHdp dGhvdXQgcmVnYXJkIHRvIHRoZSBpbml0aWFsIA0KRUFQIGtleSBsaWZldGltZXMgb3IgYXV0aG9y aXphdGlvbnMgb3Igd2l0aG91dCB0aGUgYWJpbGl0eSB0byBjcm9zcyBjaGVjayB0aGVzZSANCmxp ZmUgdGltZXMuIFRoZSBBQUEgY29tbXVuaXR5IG5lZWRzIHRvIHNpbXBseSB0YWtlIGNvbnRyb2wg YnkgcHJvdmlkaW5nIA0KYXV0aG9yaXphdGlvbiBkaXJlY3RpdmVzIHRvIHRoZSBOQVMgb24gd2hh dCBpdCBjYW4gYW5kIGNhbm5vdCBkbyB3aXRoIHRoZSANCmtleXMuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAw NT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYx NS0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+NSkgQ2hh bm5lbCBiaW5kaW5nIGlzIGEgdmVyeSBoYXJkIHRvcGljIHRvIHVuZGVyc3RhbmQgYW5kIA0KdG8g cHJvdmlkZSBhIGN1cmUgZm9yLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCAN CmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFj ZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkkgdHJpZWQgdG8gc3RhcnQgYSBkaXNjdXNz aW9uIG9uIHRoaXMgdG9waWMgaW4gdGhlIEVBUCANCmdyb3VwIGJ5IHNlbmRpbmcgYSBkcmFmdCB0 YWxraW5nIGFib3V0IEVBUCBhbmQgaGFuZG92ZXIgDQpzdXBwb3J0LDwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz05NDM0ODA2MTUtMTAwODIw MDU+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxBIA0KaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbmFraGppcmktZWFwLWhvLTAw LnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbmFraGppcmkt ZWFwLWhvLTAwLnR4dDwvQT48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWdu PWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjwvU1BBTj4mbmJzcDs8L0RJVj4N CjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYxNS0xMDA4MjAwNT48 L1NQQU4+PFNQQU4gDQpjbGFzcz05NDM0ODA2MTUtMTAwODIwMDU+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj5idXQgc2VlaW5nIHlvdXIgDQplbWFpbCBhbmQgZG9pbmcgdGhl IHNob3J0IGxpc3QgYWJvdmUsIEkgdGhpbmsgYm90aCBFQVAgYW5kIFJBRElVUyBuZWVkIHRvIGJl IA0Kd29ya2VkIHRvZ2V0aGVyLiA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFs aWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwg DQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjwvU1BBTj4m bmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk0MzQ4MDYx NS0xMDA4MjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+T25lIG9m IHRoZSBtYWpvciBpc3N1ZXMgaXMgdGhhdCB0aGVyZSBhcmUgcGVvcGxlIG9uIHRoZSANCmxpc3Qg dGhhdCBkbyBub3QgdGhpbmsgdGhlcmUgYXJlIGFueSBwcm9ibGVtcyB3aXRoIHRoZSBleGlzdGlu ZyBzcGVjaWZpY2F0aW9uLCANCnNvIEkgd291bGQgc2F5IHRoZSBtb3JlIGNvbnN0cnVjdGl2ZSB0 aGluZyB0byBkbyAoaW5zdGVhZCBvZiBlbmdhZ2luZyBpbiANCmludHJhY3RhYmxlIGRlYmF0ZXMg b24gdGhlIGxpc3QpIGlzIHRvIHdvcmsgb24gYSBkcmFmdCB0aGF0IGxpc3RzIHRoZSBpc3N1ZXMg KEkgDQp0cmllZCBib3RoIGFib3ZlIGFuZCBpbiBteSBkcmFmdCkgYW5kIHRoZW4gc29saWNpdCBh bnN3ZXJzIHRvIHNlZSBpZiB0aGUgaXNzdWVzIA0KaGF2ZSBjb252aW5jaW5nIGFuc3dlcnMsIGlm IG5vdCB0cnkgdG8gc29sdmUgaXQgZWl0aGVyIGluIEVBUCBvciBpbiBSQURleHQgb3IgDQpmaW5k IHRoZSByaWdodCBJRVRGIHZlbnVlIHRvIHNvbHZlIHRoZSBwcm9ibGVtcywgdW5sZXNzIElFVEYg ZG9lcyBub3Qgd2FudCB0byANCmRlYWwgd2l0aCB0aGlzIGFuZCB3aWxsIHJhdGhlciBoYXZlIElF RUUgd29yayBvbiBpdC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xv cj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9OTQzNDgwNjE1LTEwMDgyMDA1PjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5NYWRqaWQ8L0ZPTlQ+PC9TUEFOPjwvRElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEJSPg0KPERJViBjbGFzcz1PdXRsb29rTWVz c2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0YWJJbmRleD0t MT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gb3duZXItcmFkaXVzZXh0 QG9wcy5pZXRmLm9yZyANClttYWlsdG86b3duZXItcmFkaXVzZXh0QG9wcy5pZXRmLm9yZ10gPEI+ T24gQmVoYWxmIE9mIDwvQj5OYXJheWFuYW4gDQpWaWR5YS1DVk4wNjU8QlI+PEI+U2VudDo8L0I+ IFdlZG5lc2RheSwgQXVndXN0IDEwLCAyMDA1IDk6NTcgQU08QlI+PEI+VG86PC9CPiANCnJhZGl1 c2V4dEBvcHMuaWV0Zi5vcmc8QlI+PEI+Q2M6PC9CPiBhYWEtd2dAbWVyaXQuZWR1OyBLb3J1cyAN Ck1pa2UtQ01LMDEzPEJSPjxCPlN1YmplY3Q6PC9CPiBBQUEgZm9yIEhhbmRvdmVyczxCUj48L0ZP TlQ+PEJSPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+PCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0 L3BsYWluIGZvcm1hdCAtLT48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0Kc2l6ZT0yPjxTUEFOIGNs YXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5BbGw8L1NQQU4+LDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkkgaGFkIGEgYnJpZWYgY2hhdCB3aXRoIEphcmkm bmJzcDs8U1BBTiANCmNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5BcmtrbyA8L1NQQU4+b24gdGhp cyB0b3BpYyZuYnNwOzxTUEFOIA0KY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PmluIFBhcmlzIDwv U1BBTj5hbmQgaGUgc3VnZ2VzdGVkIEkgYnJpbmcgaXQgDQp1cCZuYnNwOzxTUEFOIGNsYXNzPTUy MzM0MjgxNC0xMDA4MjAwNT5vbiB0aGUgPC9TUEFOPlJBREVYVDxTUEFOIA0KY2xhc3M9NTIzMzQy ODE0LTEwMDgyMDA1PiBtYWlsaW5nIGxpc3Q8L1NQQU4+LiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD48Rk9OVCBzaXplPTI+QSB3aGlsZSBhZ28sIHNvbWUgd29yayB3YXMgZG9uZSBpbiB0 aGUgSVJURiANCm9uIFJBRElVUyBmb3IgaGFuZG92ZXJzIGluIHRoZSBhYWFhcmNoLWhhbmRvZmYg ZHJhZnQsIGJ1dCBpdCBzZWVtcyB0byBoYXZlIA0KcmF0aGVyIGRpZWQgbm93LiBDdXJyZW50bHks Jm5ic3A7PFNQQU4gY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PnRoZXJlIHNlZW1zIHRvIA0KYmUg bm8gZWZmb3J0cyB0byBhZHZhbmNlIHN1Y2ggd29yayBpbiB0aGUgSUVURiBvciBJUlRGLiBJIHdh cyB3b25kZXJpbmcgaWYgDQpyZXZpdmluZyBzb21lIHdvcmsgYWxvbmcgdGhlIHNhbWUgbGluZXMg bWlnaHQgYmUgYW4gb3B0aW9uIHBlb3BsZSB3b3VsZCBzdXBwb3J0IA0Kb3IgZGVzaXJlLiA8L1NQ QU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXpl PTI+PFNQQU4gDQpjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNs YXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5Tb21lIHRob3VnaHRzIA0Kb24gd2h5IHRoaXMgd29yayB3 b3VsZCBiZSB1c2VmdWw6IDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT48 L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1Pkl0IGlzIHF1aXRlIA0K ZXZpZGVudCB0aGF0IHBlcmZvcm1pbmcgYW4gZW50aXJlIEVBUCBtZXRob2QgZXhjaGFuZ2UgdXBv biBoYW5kb2ZmIGludHJvZHVjZXMgDQpzaWduaWZpY2FudCBpbmNyZWFzZSBpbiBoYW5kb2ZmIHRp bWVzLiBJdCBzZWVtcyB0aGF0IHBlb3BsZSBhcmUgZ2V0dGluZyBhcm91bmQgDQpnb2luZyB0byB0 aGUgQUFBIHNlcnZlciBldmVyeSB0aW1lIGJ5IGRlZmluaW5nIGV2b2x2aW5nIGtleXMgYW5kIGlu dHJvZHVjaW5nIA0KbG9jYWwgS0RDcy4gQW4gZXhhbXBsZSBpcyB0aGUgcGF0aCA4MDIuMTFyIGlz IHRha2luZy4gODAyLjExciBoYXMgaW50cm9kdWNlZCBhbiANCmV2b2x2aW5nIGtleSBoaWVyYXJj aHkgdGhhdCBhbGxvd3MgdGhlIFNUQSB0byBoYW5kb2ZmIHdpdGhvdXQgaGF2aW5nIHRvIHBlcmZv cm0gDQphIGZ1bGwgRUFQIGV4Y2hhbmdlLiBJdCBpcyBnZW5lcmFsbHkgYWNjZXB0ZWQgKGF0IGxl YXN0IHNlZW1zIHRvIGJlKSB0aGF0IHRoaXMgDQppcyBpbmhlcmVudGx5IGxlc3Mgc2VjdXJlIHRo YW4gcGVyZm9ybWluZyByZWd1bGFyIEVBUCAtIGhvd2V2ZXIsIHRoaXMgaXMgdmlld2VkIA0KYXMg aW1wb3J0YW50IHRvIGJlIGFibGUgdG8gaGF2ZSBhY2NlcHRhYmxlIGhhbmRvZmYgdGltZXMuIEJl aW5nIG9mIHRoZSBJRVRGIA0KbWVudGFsaXR5LCB0byBtZSwgdGhlc2UgbWVjaGFuaXNtcyBkbyBu b3Qgc2VlbSB0byBzYXRpc2Z5IGFsbCB0aGUgSG91c2xleSANCmNyaXRlcmlhIGFzIHRoZXkgc2hv dWxkLiBIb3dldmVyLCB3aXRob3V0IGNoYW5nZXMgaW4gQUFBLCBJIGRvbid0IGhhdmUgYSANCmJl dHRlciZuYnNwO2Fuc3dlciB0byByZWR1Y2luZyBoYW5kb2ZmIHRpbWVzLiA8L1NQQU4+PC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4g DQpjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTUyMzM0 MjgxNC0xMDA4MjAwNT5UaGlua2luZyBhYm91dCANCnRoaXMgYSBsaXR0bGUgZnVydGhlciwgaXQg c2VlbXMgbGlrZSBzdWNoIGEgZGVzaWduIGlzIGJlY29taW5nIHBvcHVsYXIgZHVlIHRvIA0KdGhl IGxhY2sgb2YgYSBtZXRob2QgaW4gQUFBIHRvIHByZS1hdXRoZW50aWNhdGUgdG8gbXVsdGlwbGUg YXV0aGVudGljYXRvcnMgDQooTkFTLWVzKSBhbmQgcHJvYWN0aXZlbHkgZGlzdHJpYnV0ZSBrZXlz IHRvIHRoZSBOQVMtZXMuIElmIHRoZXJlIHdhcyBhIHdheSB0byBkbyANCnRoaXMsIGl0IHdvdWxk IGJlIHBvc3NpYmxlIHRvIGRlcml2ZSBtdWx0aXBsZSBrZXlzIGF0IHRoZSBBQUEgc2VydmVyIGZv ciBhIA0KbW9iaWxlIG5vZGUgY29ycmVzcG9uZGluZyB0byB0YXJnZXQgTkFTIGRldmljZXMgYW5k IHByb2FjdGl2ZWx5IHB1c2ggdGhlIGtleXMgdG8gDQp0aG9zZSBkZXZpY2VzIHdpdGhvdXQgdGhl IG5lZWQgZm9yIGEgY29tcGxldGUgYXV0aGVudGljYXRpb24gYW5kIGtleSBkZXJpdmF0aW9uIA0K dXBvbiBoYW5kb2ZmLiBJdCB3b3VsZCBhbGxvdyBzaWduaWZpY2FudCByZWR1Y3Rpb24gaW4gdGhl IHNpZ25hbGluZyByZXF1aXJlZCB0byANCmVzdGFibGlzaCBrZXlzIGF0IE5BUy1lcy4gPC9TUEFO PjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBjbGFz cz01MjMzNDI4MTQtMTAwODIwMDU+SXQgc2VlbXMgdG8gbWUgDQp0aGF0IGlmIHRoZSBJRVRGIHdv cmtlZCBvbiB0aGlzIGFuZCBtYXR1cmVkIGl0IGVub3VnaCwgcGVvcGxlIHdvdWxkIGJlIHdpbGxp bmcgDQp0byB1c2UgaXQgdG8gcHJvdmlkZSBtb3JlIHNlY3VyZSBmYXN0ZXIgaGFuZG9mZnMuIEVz cGVjaWFsbHkgc2luY2Ugc29tZSB3b3JrIHdhcyANCmRvbmUgaW4gdGhpcyBzcGFjZSBlYXJsaWVy IG9uLCBpdCBzZWVtcyBsaWtlIGl0IG1pZ2h0IGJlIHdvcnRoIGxvb2tpbmcgaW50by4gVGhlIA0K SVJURiBkcmFmdCB3YXMgYWhlYWQgb2YgaXRzIHRpbWUgd2hlbiBpdCB3YXMgd3JpdHRlbiAtIGJ1 dCwgaXQgc2VlbXMgbGlrZSB0aGUgDQp0aW1pbmcgZm9yIHN1Y2ggYSB0YXNrIHdvdWxkIGJlIHBl cmZlY3Qgbm93LiA8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+PC9TUEFO PjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQg c2l6ZT0yPjxTUEFOIGNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5BbnkgdGhvdWdodHM/IA0KPC9T UEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6 ZT0yPjxTUEFOIA0KY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PjwvU1BBTj48L0ZPTlQ+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiAN CmNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT5UaGFua3MsPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTIz MzQyODE0LTEwMDgyMDA1PlZpZHlhPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== ------_=_NextPart_001_01C59DC0.E1B45090-- -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 14:57:34 +0000 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A72AC@il02exm13> From: Narayanan Vidya-CVN065 To: radiusext@ops.ietf.org Cc: aaa-wg@merit.edu, Korus Mike-CMK013 Subject: AAA for Handovers Date: Wed, 10 Aug 2005 09:56:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59DBB.BFD17B78" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59DBB.BFD17B78 Content-Type: text/plain All, I had a brief chat with Jari Arkko on this topic in Paris and he suggested I bring it up on the RADEXT mailing list. A while ago, some work was done in the IRTF on RADIUS for handovers in the aaaarch-handoff draft, but it seems to have rather died now. Currently, there seems to be no efforts to advance such work in the IETF or IRTF. I was wondering if reviving some work along the same lines might be an option people would support or desire. Some thoughts on why this work would be useful: It is quite evident that performing an entire EAP method exchange upon handoff introduces significant increase in handoff times. It seems that people are getting around going to the AAA server every time by defining evolving keys and introducing local KDCs. An example is the path 802.11r is taking. 802.11r has introduced an evolving key hierarchy that allows the STA to handoff without having to perform a full EAP exchange. It is generally accepted (at least seems to be) that this is inherently less secure than performing regular EAP - however, this is viewed as important to be able to have acceptable handoff times. Being of the IETF mentality, to me, these mechanisms do not seem to satisfy all the Housley criteria as they should. However, without changes in AAA, I don't have a better answer to reducing handoff times. Thinking about this a little further, it seems like such a design is becoming popular due to the lack of a method in AAA to pre-authenticate to multiple authenticators (NAS-es) and proactively distribute keys to the NAS-es. If there was a way to do this, it would be possible to derive multiple keys at the AAA server for a mobile node corresponding to target NAS devices and proactively push the keys to those devices without the need for a complete authentication and key derivation upon handoff. It would allow significant reduction in the signaling required to establish keys at NAS-es. It seems to me that if the IETF worked on this and matured it enough, people would be willing to use it to provide more secure faster handoffs. Especially since some work was done in this space earlier on, it seems like it might be worth looking into. The IRTF draft was ahead of its time when it was written - but, it seems like the timing for such a task would be perfect now. Any thoughts? Thanks, Vidya ------_=_NextPart_001_01C59DBB.BFD17B78 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE1MDUiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9y bWF0IC0tPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQpzaXplPTI+PFNQQU4gY2xhc3M9NTIzMzQy ODE0LTEwMDgyMDA1PkFsbDwvU1BBTj4sPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+SSBoYWQgYSBicmllZiBjaGF0IHdpdGggSmFyaSZuYnNwOzxTUEFO IA0KY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PkFya2tvIDwvU1BBTj5vbiB0aGlzIHRvcGljJm5i c3A7PFNQQU4gDQpjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+aW4gUGFyaXMgPC9TUEFOPmFuZCBo ZSBzdWdnZXN0ZWQgSSBicmluZyBpdCANCnVwJm5ic3A7PFNQQU4gY2xhc3M9NTIzMzQyODE0LTEw MDgyMDA1Pm9uIHRoZSA8L1NQQU4+UkFERVhUPFNQQU4gDQpjbGFzcz01MjMzNDI4MTQtMTAwODIw MDU+IG1haWxpbmcgbGlzdDwvU1BBTj4uIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxG T05UIHNpemU9Mj5BIHdoaWxlIGFnbywgc29tZSB3b3JrIHdhcyBkb25lIGluIHRoZSBJUlRGIA0K b24gUkFESVVTIGZvciBoYW5kb3ZlcnMgaW4gdGhlIGFhYWFyY2gtaGFuZG9mZiBkcmFmdCwgYnV0 IGl0IHNlZW1zIHRvIGhhdmUgDQpyYXRoZXIgZGllZCBub3cuIEN1cnJlbnRseSwmbmJzcDs8U1BB TiBjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+dGhlcmUgc2VlbXMgdG8gDQpiZSBubyBlZmZvcnRz IHRvIGFkdmFuY2Ugc3VjaCB3b3JrIGluIHRoZSBJRVRGIG9yIElSVEYuIEkgd2FzIHdvbmRlcmlu ZyBpZiANCnJldml2aW5nIHNvbWUgd29yayBhbG9uZyB0aGUgc2FtZSBsaW5lcyBtaWdodCBiZSBh biBvcHRpb24gcGVvcGxlIHdvdWxkIHN1cHBvcnQgDQpvciBkZXNpcmUuIDwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiAN CmNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NTIzMzQy ODE0LTEwMDgyMDA1PlNvbWUgdGhvdWdodHMgDQpvbiB3aHkgdGhpcyB3b3JrIHdvdWxkIGJlIHVz ZWZ1bDogPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PjwvU1BBTj48L0ZP TlQ+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9 Mj48U1BBTiBjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+SXQgaXMgcXVpdGUgDQpldmlkZW50IHRo YXQgcGVyZm9ybWluZyBhbiBlbnRpcmUgRUFQIG1ldGhvZCBleGNoYW5nZSB1cG9uIGhhbmRvZmYg aW50cm9kdWNlcyANCnNpZ25pZmljYW50IGluY3JlYXNlIGluIGhhbmRvZmYgdGltZXMuIEl0IHNl ZW1zIHRoYXQgcGVvcGxlIGFyZSBnZXR0aW5nIGFyb3VuZCANCmdvaW5nIHRvIHRoZSBBQUEgc2Vy dmVyIGV2ZXJ5IHRpbWUgYnkgZGVmaW5pbmcgZXZvbHZpbmcga2V5cyBhbmQgaW50cm9kdWNpbmcg DQpsb2NhbCBLRENzLiBBbiBleGFtcGxlIGlzIHRoZSBwYXRoIDgwMi4xMXIgaXMgdGFraW5nLiA4 MDIuMTFyIGhhcyBpbnRyb2R1Y2VkIGFuIA0KZXZvbHZpbmcga2V5IGhpZXJhcmNoeSB0aGF0IGFs bG93cyB0aGUgU1RBIHRvIGhhbmRvZmYgd2l0aG91dCBoYXZpbmcgdG8gcGVyZm9ybSANCmEgZnVs bCBFQVAgZXhjaGFuZ2UuIEl0IGlzIGdlbmVyYWxseSBhY2NlcHRlZCAoYXQgbGVhc3Qgc2VlbXMg dG8gYmUpIHRoYXQgdGhpcyANCmlzIGluaGVyZW50bHkgbGVzcyBzZWN1cmUgdGhhbiBwZXJmb3Jt aW5nIHJlZ3VsYXIgRUFQIC0gaG93ZXZlciwgdGhpcyBpcyB2aWV3ZWQgDQphcyBpbXBvcnRhbnQg dG8gYmUgYWJsZSB0byBoYXZlIGFjY2VwdGFibGUgaGFuZG9mZiB0aW1lcy4gQmVpbmcgb2YgdGhl IElFVEYgDQptZW50YWxpdHksIHRvIG1lLCB0aGVzZSBtZWNoYW5pc21zIGRvIG5vdCBzZWVtIHRv IHNhdGlzZnkgYWxsIHRoZSBIb3VzbGV5IA0KY3JpdGVyaWEgYXMgdGhleSBzaG91bGQuIEhvd2V2 ZXIsIHdpdGhvdXQgY2hhbmdlcyBpbiBBQUEsIEkgZG9uJ3QgaGF2ZSBhIA0KYmV0dGVyJm5ic3A7 YW5zd2VyIHRvIHJlZHVjaW5nIGhhbmRvZmYgdGltZXMuIDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNzPTUy MzM0MjgxNC0xMDA4MjAwNT48L1NQQU4+PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NTIzMzQyODE0LTEwMDgy MDA1PlRoaW5raW5nIGFib3V0IA0KdGhpcyBhIGxpdHRsZSBmdXJ0aGVyLCBpdCBzZWVtcyBsaWtl IHN1Y2ggYSBkZXNpZ24gaXMgYmVjb21pbmcgcG9wdWxhciBkdWUgdG8gDQp0aGUgbGFjayBvZiBh IG1ldGhvZCBpbiBBQUEgdG8gcHJlLWF1dGhlbnRpY2F0ZSB0byBtdWx0aXBsZSBhdXRoZW50aWNh dG9ycyANCihOQVMtZXMpIGFuZCBwcm9hY3RpdmVseSBkaXN0cmlidXRlIGtleXMgdG8gdGhlIE5B Uy1lcy4gSWYgdGhlcmUgd2FzIGEgd2F5IHRvIGRvIA0KdGhpcywgaXQgd291bGQgYmUgcG9zc2li bGUgdG8gZGVyaXZlIG11bHRpcGxlIGtleXMgYXQgdGhlIEFBQSBzZXJ2ZXIgZm9yIGEgDQptb2Jp bGUgbm9kZSBjb3JyZXNwb25kaW5nIHRvIHRhcmdldCBOQVMgZGV2aWNlcyBhbmQgcHJvYWN0aXZl bHkgcHVzaCB0aGUga2V5cyB0byANCnRob3NlIGRldmljZXMgd2l0aG91dCB0aGUgbmVlZCBmb3Ig YSBjb21wbGV0ZSBhdXRoZW50aWNhdGlvbiBhbmQga2V5IGRlcml2YXRpb24gDQp1cG9uIGhhbmRv ZmYuIEl0IHdvdWxkIGFsbG93IHNpZ25pZmljYW50IHJlZHVjdGlvbiBpbiB0aGUgc2lnbmFsaW5n IHJlcXVpcmVkIHRvIA0KZXN0YWJsaXNoIGtleXMgYXQgTkFTLWVzLiA8L1NQQU4+PC9GT05UPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQpj bGFzcz01MjMzNDI4MTQtMTAwODIwMDU+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNzPTUyMzM0Mjgx NC0xMDA4MjAwNT5JdCBzZWVtcyB0byBtZSANCnRoYXQgaWYgdGhlIElFVEYgd29ya2VkIG9uIHRo aXMgYW5kIG1hdHVyZWQgaXQgZW5vdWdoLCBwZW9wbGUgd291bGQgYmUgd2lsbGluZyANCnRvIHVz ZSBpdCB0byBwcm92aWRlIG1vcmUgc2VjdXJlIGZhc3RlciBoYW5kb2Zmcy4gRXNwZWNpYWxseSBz aW5jZSBzb21lIHdvcmsgd2FzIA0KZG9uZSBpbiB0aGlzIHNwYWNlIGVhcmxpZXIgb24sIGl0IHNl ZW1zIGxpa2UgaXQgbWlnaHQgYmUgd29ydGggbG9va2luZyBpbnRvLiBUaGUgDQpJUlRGIGRyYWZ0 IHdhcyBhaGVhZCBvZiBpdHMgdGltZSB3aGVuIGl0IHdhcyB3cml0dGVuIC0gYnV0LCBpdCBzZWVt cyBsaWtlIHRoZSANCnRpbWluZyBmb3Igc3VjaCBhIHRhc2sgd291bGQgYmUgcGVyZmVjdCBub3cu IDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxGT05U IHNpemU9Mj48U1BBTiANCmNsYXNzPTUyMzM0MjgxNC0xMDA4MjAwNT48L1NQQU4+PC9GT05UPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQ QU4gY2xhc3M9NTIzMzQyODE0LTEwMDgyMDA1PkFueSB0aG91Z2h0cz8gDQo8L1NQQU4+PC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4g DQpjbGFzcz01MjMzNDI4MTQtMTAwODIwMDU+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTIz MzQyODE0LTEwMDgyMDA1PlRoYW5rcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz01MjMzNDI4MTQtMTAw ODIwMDU+VmlkeWE8L1NQQU4+PC9GT05UPjwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C59DBB.BFD17B78-- -- to unsubscribe send a message to radiusext-request@ops.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, 10 Aug 2005 13:39: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: RE: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Date: Wed, 10 Aug 2005 16:37:05 +0300 Message-ID: Thread-Topic: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt Thread-Index: AcWFybZp/uP5ITr6TdOU6yD6mQRCHwX1uhSg From: "Romascanu, Dan \(Dan\)" To: "Bernard Aboba" , Here are my comments: 1. The second paragraph in the introduction reads: For example, in IEEE 802.1X [IEEE8021X] environments, which=20 provides "network port authentication" for IEEE 802 [IEEE802]=20 media, including Ethernet [IEEE8023], Token Ring and 802.11=20 [IEEE80211i] wireless LANS, there exists a strong desire to=20 control authorization beyond just the untagged VLAN parameter=20 based on tunnel attributes in [RFC2868].=20 - The syntax of this phrase sounds broken. Replacing 'provides' by 'provide' would help - No reference for Token Ring - 802.11i defines the security of the wireless LAN, and not the wireless LAN 2. It would be good to add abbreviations to section 1.1 - for example NAS, etc.=20 3. The term WiFi user in Section 2 is not explained 4. The diagrams in 3.1, 4.1, 4.2 have missing delimiters 5. Section 3.4: There are eight=20 possible user priorities, according to the IEEE 802 standard.=20 Should be IEEE 802.1Q standard 6. Section 7 - I believe that some text should be added about the threat resulting from intentional or accidental mis-configuration of filtering capabilities in IEEE 802.1 bridges which can result in blocking or degradation of service of traffic related to specific ports, users, or applications.=20 Regards, Dan =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, July 11, 2005 6:35 AM > To: radiusext@ops.ietf.org > Subject: RADEXT WG last call on draft-ietf-radext-ieee802-00.txt >=20 > This is an announcement of RADEXT WG last call on "VLAN,=20 > Priority, and Filtering Attributes" prior to sending this=20 > document to the IESG for consideration as a Proposed=20 > Standard. The document will be available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt >=20 > Until it arrives on the archive, it will be available at: > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-ieee802-00.txt >=20 > RADEXT WG last call will last until August 10, 2005. Please=20 > send comments to the RADEXT WG mailing list in the format=20 > described on the RADEXT Issues > list: > http://www.drizzle.com/~aboba/RADEXT/ >=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, 04 Aug 2005 04:57:57 +0000 Message-Id: <6.2.3.4.2.20050804005641.04fc2170@getmail.mitton.com> Date: Thu, 04 Aug 2005 00:57:04 -0400 To: From: David Mitton Subject: RE: Issue: Vendor Specifc Attribute Values Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed On 7/26/2005 03:57 PM, Nelson, David wrote: >Alan DeKok writes... > > > 2882 uses Vendor-Specific Enumerations (VSE's). We should use that > > here. > >RFC 2882 is certainly a fact-based document. It reports existing >deployment behaviors. Its abstract reads: > >Abstract > > This document describes current practices implemented in NAS products > that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The > purpose of this effort is to give examples that show the need for > addressing and standardizing these types of ad-hoc functions. Since > many of these features require a matching server support component, > the ability to deploy and manage interoperable NAS and AAA server > products is severely hindered. > > These practices are documented here to show functions that are > obviously desired in developing future AAA protocols for NAS > deployment. > >IMHO, we should be careful about inferring any desired or implied level >of standardization of any of the practices reported in 2882. If there >is no good reason to the contrary, then following existing convention >may be a good thing. OTOH, the fact that one or more vendors chose to >implement a needed (or desired) function in a particular fashion should >not set a binding precedent on the RADEXT WG. These extensions, in all >likelihood, received no IETF review, or even third party review, prior >to their implementation and deployment. We should look at these "ad >hoc" extensions with a critical eye. Indeed, one of my working titles for RFC 2882, was "RADIUS Worse Practices" Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 03 Aug 2005 18:22:13 +0000 Message-Id: <200508031821.j73ILKax001768@cliff.eng.ascend.com> Date: Wed, 03 Aug 2005 11:17:22 -0700 To: "Alan DeKok" From: Ignacio Goyret Subject: Re: Issue: Vendor Specifc Attribute Values Cc: radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 00:46 8/3/2005 -0400, Alan DeKok wrote: >Ignacio Goyret wrote: >> The method described in RFC2882 was used by one vendor and it works so long >> as the bottom 16-bits of the vendor-id is not repeated, something that was >> true then but it hasn't been for a long time. > > I'm not sure why you think 2^16 was passed a long time ago. You are correct. Sorry for the confusion. Please, ignore that part of my comments. >> My impression is that if assignment of new values was easier, the need for >> VSEs would tend to disappear. As it stands, it is a process that takes a >> good year at least. > > There will *always* be a need for people to define site-local VSA's >and VSE's. Without a standard method of doing so, they will choose >methods that destroy protocol interoperability. Yes, of course, there must be a well defined method to the madness. I'm not arguing against VSAs or VSEs. My point was that the main reason d'etre for VSAs and VSEs is the very long process to get new numbers. If that process could be sped up somehow (without detrimental of the protocol, of course), I'm positive it would reduce the current massive need for VSAs and VSEs. -- to unsubscribe send a message to radiusext-request@ops.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, 03 Aug 2005 04:46:29 +0000 From: "Alan DeKok" To: Ignacio Goyret Subject: Re: Issue: Vendor Specifc Attribute Values Cc: "Nelson, David" , radiusext@ops.ietf.org Date: Wed, 03 Aug 2005 00:46:34 -0400 Message-Id: <20050803044634.CB2CF16CCA@mail.nitros9.org> Ignacio Goyret wrote: > The method described in RFC2882 was used by one vendor and it works so long > as the bottom 16-bits of the vendor-id is not repeated, something that was > true then but it hasn't been for a long time. http://www.iana.org/assignments/enterprise-numbers Goes up to 23642 as of today. At the current rate, it will be a number of years before the assignments hit 2^16. I'm not sure why you think 2^16 was passed a long time ago. > My impression is that if assignment of new values was easier, the need for > VSEs would tend to disappear. As it stands, it is a process that takes a > good year at least. There will *always* be a need for people to define site-local VSA's and VSE's. Without a standard method of doing so, they will choose methods that destroy protocol interoperability. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 03 Aug 2005 02:55:13 +0000 Message-Id: <200508030254.j732s7NE015816@cliff.eng.ascend.com> Date: Tue, 02 Aug 2005 19:51:20 -0700 To: "Nelson, David" From: Ignacio Goyret Subject: RE: Issue: Vendor Specifc Attribute Values Cc: "Alan DeKok" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >> 2882 uses Vendor-Specific Enumerations (VSE's). We should use that >> here. > >RFC 2882 is certainly a fact-based document. It reports existing >deployment behaviors. Its abstract reads: ... > >IMHO, we should be careful about inferring any desired or implied level >of standardization of any of the practices reported in 2882. If there >is no good reason to the contrary, then following existing convention >may be a good thing. >OTOH, the fact that one or more vendors chose to >implement a needed (or desired) function in a particular fashion should >not set a binding precedent on the RADEXT WG. These extensions, in all >likelihood, received no IETF review, or even third party review, prior >to their implementation and deployment. We should look at these "ad >hoc" extensions with a critical eye. May be we should note here that some of this vendor behavior was caused by the attitude in the original RADIUS WG where any idea not implemented by certain vendor (now defunct) were systematically rejected. This (probably only apparent) inflexibility of the WG forced many vendors to find their own way to solve attribute and value assignments, in many cases, without much thought for multi-vendor interoperability. That was then, this is now. The method described in RFC2882 was used by one vendor and it works so long as the bottom 16-bits of the vendor-id is not repeated, something that was true then but it hasn't been for a long time. Ignoring this very serious limitation means that multi-vendor interoperability cannot be guaranteed nor implied. Please, let's not make that the rule. My impression is that if assignment of new values was easier, the need for VSEs would tend to disappear. As it stands, it is a process that takes a good year at least. Sorry, I somehow got derailed out of topic. -- to unsubscribe send a message to radiusext-request@ops.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, 03 Aug 2005 01:49:02 +0000 Date: Tue, 2 Aug 2005 18:48:21 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Presentations online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've updated the presentations for today's meeting. If your presentation isn't online yet, or if we don't have the right version, let me know: http://www.drizzle.com/~aboba/IETF63/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, 02 Aug 2005 13:23:37 +0000 Date: Tue, 2 Aug 2005 06:22:48 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: IETF 63 Presentations Online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RADEXT WG presentations for IETF 63 are online at: http://www.drizzle.com/~aboba/IETF63/radext/ If you haven't sent your presentation to Dave or myself, please do so ASAP. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: