From owner-radiusext@ops.ietf.org Sat Dec 01 14:27:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyXza-0001Kb-MX for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 01 Dec 2007 14:27:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyXza-0003G4-8a for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 01 Dec 2007 14:27:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IyXuX-0000mM-2B for radiusext-data@psg.com; Sat, 01 Dec 2007 19:21:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.171] (helo=bay0-omc2-s35.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IyXuM-0000ku-K5 for radiusext@ops.ietf.org; Sat, 01 Dec 2007 19:21:51 +0000 Received: from BAY117-W18 ([207.46.8.53]) by bay0-omc2-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 1 Dec 2007 11:21:46 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c2a0ec02-549c-4ff9-833b-ea517d635af3_" X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Subject: Please send slides Date: Sat, 1 Dec 2007 11:21:45 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Dec 2007 19:21:46.0208 (UTC) FILETIME=[69CBBE00:01C8344F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --_c2a0ec02-549c-4ff9-833b-ea517d635af3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a last call for agenda items for IETF 70. If you are not on the ag= enda and would like to present, please send email.=20 If you are on the agenda please confirm your availability and send slides A= SAP. --_c2a0ec02-549c-4ff9-833b-ea517d635af3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a last call for agenda items for IETF 70.  If you are not on t= he agenda and would like to present, please send email.

If you are = on the agenda please confirm your availability and send slides ASAP.
= --_c2a0ec02-549c-4ff9-833b-ea517d635af3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 02 19:39:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyzLf-0003MN-F1 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 02 Dec 2007 19:39:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyzLd-0000Jg-PW for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 02 Dec 2007 19:39:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IyzGS-000OeL-On for radiusext-data@psg.com; Mon, 03 Dec 2007 00:34:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.156] (helo=bay0-omc2-s20.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IyzFt-000OcS-JZ for radiusext@ops.ietf.org; Mon, 03 Dec 2007 00:34:07 +0000 Received: from BAY117-W23 ([207.46.8.58]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Dec 2007 16:33:48 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_" X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Subject: Updated agenda for IETF 70 Date: Sun, 2 Dec 2007 16:33:48 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2007 00:33:48.0905 (UTC) FILETIME=[2BCE5590:01C83544] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG AgendaWednesday December 5, 20079 AM - 11:30 AM, Cypress = Room 9 AM - 9:10 AM Preliminaries Blue Sheets Note Takers Jabber Scri= be Agenda bashing Document status Documents completing RADEXT WG last c= all (10 minutes) 9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKokhttp:/= /www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt 9:30 - 9:40 A= M RADIUS Authorization for NAS Management, David Nelsonhttp://www.ietf.or= g/internet-drafts/draft-ietf-radext-management-authorization-01.txt =20 WG Work items 9:40 - 9:50 Extended RADIUS Attributes, Glen Zornhttp://www.i= etf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt Pre-= WG Work Item Review 9:50- 10:00 IEEE 802 Attributes, Bernard Abobahttp://ww= w.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt =20 10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkarhttp://ww= w.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01.txt RADIUS Crypto-Agility (50 minutes) 10:10 - 10:25 RADEXT Crypto-agility Requ= irements and Selection Process, David Nelson 10:25 - 10:35 RADIUS + DTLS (A= lan DeKok)http://www.watersprings.org/pub/id/draft-dekok-radext-dtls-00.txt= 10:35 - 10:50 RADIUS Crypto-agility (Joe Salowey)http://www.watersprings.o= rg/pub/id/draft-zorn-radius-keywrap-13.txthttp://www.watersprings.org/pub/i= d/draft-zorn-radius-encattr-06.txt 10:50 - 11:10 Discussion Miscellaneous (= 10 minutes) 11:10 - 11:20 RADSEC (Stig Venaas)http://www.watersprings.org/p= ub/id/draft-winter-radsec-00.txt Discussion & Wrapup (10 minutes)= --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG Agenda
Wednesday December 5, 2007
9 AM - 11:30 AM, = Cypress Room
 
9 AM - 9:10 AM Preliminaries
   Blue= Sheets
   Note Takers
   Jabber Scribe
 =   Agenda bashing
   Document status
 
Document= s completing RADEXT WG last call (10 minutes)
 
9:20 - 9:30 AM&n= bsp; RADIUS Design Guidelines, Alan DeKok
http://www.ietf.org/inter= net-drafts/draft-ietf-radext-design-01.txt
 
9:30 - 9:40 AM&= nbsp;  RADIUS Authorization for NAS Management, David Nelson
http://www.ietf.org/internet-drafts/draft-ietf-radext-mana= gement-authorization-01.txt
 
WG Work items
 
9:40 - 9:50 Extended RADIUS Attributes, Glen Zor= n
http://www.ietf.org/internet-drafts/draft-ietf-radex= t-extended-attributes-00.txt
  
Pre-WG Work Item Revie= w
 
9:50- 10:00 IEEE 802 Attributes, Bernard Aboba
http://= www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
 
10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkar
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01= .txt
RADIUS Crypto-Agility (50 minutes)
 
10:10 - 10:25 RADEXT Crypto= -agility Requirements and Selection Process, David Nelson
 
10:2= 5 - 10:35 RADIUS + DTLS (Alan DeKok)
http://www.watersprings.org/pub/= id/draft-dekok-radext-dtls-00.txt
 
10:35 - 10:50 RADIUS Cry= pto-agility (Joe Salowey)
http://www.watersprings.org/pub/id/draft-= zorn-radius-keywrap-13.txt
http://www.watersprings.org/pub/id/d= raft-zorn-radius-encattr-06.txt
 
10:50 - 11:10 Discussion 
Miscellaneous (10 minutes)
 
11:10 - 11:20 RADSEC (S= tig Venaas)
http://www.watersprings.org/pub/id/draft-winter-radsec-00.txt=
 
Discussion & Wrapup (10 minutes)
= --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 02 20:48:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0Q5-0002pP-UT for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 02 Dec 2007 20:48:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz0Q4-00086M-0n for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 02 Dec 2007 20:48:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iz0Jw-0003w4-Mp for radiusext-data@psg.com; Mon, 03 Dec 2007 01:42:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.155] (helo=bay0-omc2-s19.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iz0JM-0003st-8U for radiusext@ops.ietf.org; Mon, 03 Dec 2007 01:41:48 +0000 Received: from BAY117-W13 ([207.46.8.48]) by bay0-omc2-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 2 Dec 2007 17:41:27 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_" X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Subject: Review of draft-ietf-radext-design-01.txt Date: Sun, 2 Dec 2007 17:41:27 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2007 01:41:27.0969 (UTC) FILETIME=[9F325910:01C8354D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-radext-design-01.txt =20 Designation =20 I thought that this document was a BCP, no? -01 states thatit is "Standard= s Track".=20 =20 Sections 1 and 1.1 =20 There is some overlap in coverage. My recommendation is to reorganizethe d= iscussion as follows: =20 "1. Introduction This document provides guidelines for the design of RADIUS attributes = both within the IETF as well as within other Standards Development Organi= zations (SDOs). By articulating RADIUS design guidelines, it is hoped t= hat this document will encourage the development and publication of high = quality RADIUS attribute specifications. The advice in this document will not be helpful unless it is put to use.= As with "Guidelines for Authors and Reviewers of MIB Documents" [RFC= 4181], it is expected that this document will enable authors to check the= ir document against the guidelines prior to requesting a review (such an = "Expert Review" described in [RFC3575]). Similarly, it is hoped that thi= s document will be of use to reviewers (such as WG participants or the AA= A Doctors) in improving the consistency of reviews. =20 In order to meet these objectives, this document needs to cover not on= ly the science of attribute design, but also the art. As a result, in ad= dition to covering the most frequently encountered issues, this document = attempts to provide some of the considerations motivating the guidelines. =20 In order to characterize current attribute usage, both the basic and c= omplex data types defined in the existing RADIUS RFCs are reviewed, toget= her with the ad-hoc extensions to that data model that have been used in = Vendor-Specific Attributes. =20 1.1. Applicability As RADIUS has become more widely accepted as a management protocol, it= s usage has become more prevalent, both within the IETF as well as within= other SDOs. Given the expanded utilization of RADIUS, it has become app= arent that requiring SDOs to accomplish all their RADIUS work within the= IETF is inherently inefficient and unscalable. By articulating guidelines for RADIUS attribute design, this document = enables SDOs to design their own RADIUS attributes within the Vendor-Sp= ecific Attribute (VSA) space, seeking review from the IETF. In order enab= le IETF review of SDO RADIUS attribute specifications, the authors recomm= end: =20 * Development of a program to encourage SDOs to make their RADIUS = attribute specifications publicly available; * Review of IETF and SDO specifications according to the guideli= nes proposed in this document; =20 The advice in this document applies to attributes used to encode data.= RADIUS protocol changes, or specification of attributes that can be use= d to provide new RADIUS commands (such as Service-Type) are out of scope.= Since protocol changes require greater expertise and deeper review, suc= h changes should not be undertaken outside the IETF and when handled with= in the IETF require "IETF Consensus" for adoption, as noted in [RFC3575] = Section 2.1. =20 As with protocol changes, this document does not provide guidance to d= ocument authors seeking to change the RADIUS operational model. While RAD= IUS server implementations may keep state, the RADIUS protocol is statele= ss, although information may be passed from one protocol transaction to a= nother via the State Attribute. As a result, documents which require sta= teful protocol behavior without use of the State Attribute are inherently= incompatible with RADIUS as defined in [RFC2865], and need to be redesig= ned. See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use = of the State Attribute." =20 BTW, I would also suggest a statement that this document does not applyto n= ew uses of RADIUS (e.g. uses of RADIUS that go beyond conversationsbetween = a RADIUS client and server).=20 Section 2.1.1 IPv6 address 128 bit value, most significant octet first. IPv6 prefi= x 8 bits of reserved, 8 bits of prefix length, up to 12= 8 bits of value, most significant octet first. Judging by some recent specifications, there appears to be some confusionbe= tween these two types. Should an IPv6 address type always be used torepres= ent an address (as opposed to the prefix type). If so, you mightstate this= explicitly using some normative language.=20 =20 integer64 64 bit unsigned value, most significant octet first. =20 I believe that this type has also been used to express an IPv6 Identifierva= lue, no?=20 =20 Section 2.1.2 =20 " New attributes SHOULD NOT use this tagging method because of the limit= atations described above." =20 limitatations -> limitations =20 Section 2.1.3 =20 The only other exception to the recommendation against complex types i= s for types that can be treated as opaque data by the RADIUS server. For = example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 cont= ains a complex data type that is an EAP packet. Since these complex type= s do not need to be parsed by the RADIUS server, the issues arising from = policy language limitations do not arise. Similarly, since attributes of = these complex types can be configured on the server using a data type of = String, dictionary limitations are also not encountered. Section A.1 bel= ow includes a series of checklists that may be used to analyze a design f= or RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types. =20 I think it may be worth expanding this discussion of opaque data typessomew= hat and covering additional implications, security related onesin particula= r. In general, RADIUS servers are highly valued targets sothat the introdu= ction of complex data types brings withit the potential for introduction of= security vulnerabilities such asbuffer overflows. An extreme outcome woul= d be a vulnerability thatwould allow an attacker to take over the RADIUS se= rver. =20 The use of attributes representing opaque data does not reduce thisthreat, = it merely moves it from the RADIUS server to an applicationthat consumes RA= DIUS attributes. Should this application not beproperly isolated, or run w= ith extended privileges, then the introduction of new opaque data types (or= changes in the formatof existing opaque types) may introduce serious new s= ecurity vulnerabilities.=20 =20 Section 3.1.3 =20 This change control can be obtained by requesting a PEC from the Inter= net Assigned Number Authority (IANA), for use as a Vendor-Id within a Ven= dor-Specific attribute. =20 =20 Can you expand "PEC" on first use?=20 =20 Rehosting may also require changes to the RADIUS data model which will af= fect implementations that do not intend to support the SDO specifications Period needed at the end of the sentence.=20 =20 IDNITs check------------- The tool found a few warnings: =20 idnits 2.05.02=20 tmp/draft-ietf-radext-design-01.txt: - Failure fetching the file, proceedin= g without it.) Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: = ---------------------------------------------------------------------------= - No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ------= ---------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ------------------------------------------------= ---------------------------- =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not an acc= epted usage according to RFC 2119. Please use 'MUST NOT' (if that is w= hat you mean). Found 'MUST not' in this paragraph: Th= is Attribute is available to allow vendors to support their own extende= d Attributes not suitable for general usage. It MUST not affect the op= eration of the RADIUS protocol. Checking references for intended status: Proposed Standard -------------= --------------------------------------------------------------- (See RFC 3967 for information about using normative references to = lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 1191 'The = Text field consists of UTF-8 encoded 10646 [8] characters....' =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no explici= t reference was found in the text '[RFC4005] Calhoun, P., Zorn, G.,= Spence, D., and D. Mitton, "Diamete...' -- No information found for draft-ietf-radext-extended-attributes - is th= e name correct? Summary: 0 errors (**), 2 warnings (=3D=3D), 2 comments (--).---------= -----------------------------------------------------------------------= --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-radext-design-01.txt
 
Designation
 
I thought that this document was a BCP, no?  -01 states that
it is = "Standards Track". 
 
Sections 1 and 1.1
 
There is some overlap in coverage.  My recommendation is to reorganize=
the discussion as follows:
 
"1.  Introduction
   This document provides guidelines for the design of RADIUS att= ributes
   both within the IETF as well as within other Standa= rds Development
   Organizations (SDOs).  By articulating= RADIUS design guidelines, it
   is hoped that this document = will encourage the development and
   publication of high qual= ity RADIUS attribute specifications.
   The advice in this document will not be helpful unless it is p= ut to use. 
   As with "Guidelines for Authors and Revie= wers of MIB Documents"
   [RFC4181], it is expected that this = document will enable authors to
   check their document agains= t the guidelines prior to requesting a
   review (such an "Exp= ert Review" described in [RFC3575]).  Similarly,
   it is= hoped that this document will be of use to reviewers (such as
 &nb= sp; WG participants or the AAA Doctors) in improving the consistency of
=    reviews.
 
   In order to meet these objectives, this document needs to cove= r not
   only the science of attribute design, but also the ar= t.  As a result,
   in addition to covering the most freq= uently encountered issues, this
   document attempts to provid= e some of the considerations motivating
   the guidelines.
 
   In order to characterize current attribute usage, both the bas= ic and
   complex data types defined in the existing RADIUS RF= Cs are reviewed,
   together with the ad-hoc extensions to tha= t data model that have been
   used in Vendor-Specific Attribu= tes.
 
1.1.  Applicability
   As RADIUS has become more widely accepted as a management prot= ocol,
   its usage has become more prevalent, both within the = IETF as well as
   within other SDOs.  Given the expanded= utilization of RADIUS,
   it has become apparent that requiri= ng SDOs to accomplish all their
   RADIUS work within the IET= F is inherently inefficient and unscalable.
   By articulating guidelines for RADIUS attribute design, this d= ocument
   enables SDOs to design their own RADIUS attributes= within the
   Vendor-Specific Attribute (VSA) space, seeking= review from the IETF.
   In order enable IETF review of SDO R= ADIUS attribute specifications,
   the authors recommend:
 
      * Development of a program to encourage SDOs= to make their RADIUS
      attribute specifica= tions publicly available;
      * Review of IETF and SDO specifications acco= rding to the
      guidelines proposed in this = document;
 
   The advice in this document applies to attributes used to enco= de
   data.  RADIUS protocol changes, or specification of= attributes that
   can be used to provide new RADIUS commands= (such as Service-Type) are
   out of scope.  Since proto= col changes require greater expertise and
   deeper review, su= ch changes should not be undertaken outside the IETF
   and wh= en handled within the IETF require "IETF Consensus" for
   ado= ption, as noted in [RFC3575] Section 2.1.
 
   As with protocol changes, this document does not provide guida= nce to
   document authors seeking to change the RADIUS operat= ional model.
   While RADIUS server implementations may keep s= tate, the RADIUS
   protocol is stateless, although informatio= n may be passed from one
   protocol transaction to another vi= a the State Attribute.  As a
   result, documents which r= equire stateful protocol behavior without
   use of the State = Attribute are inherently incompatible with RADIUS as
   define= d in [RFC2865], and need to be redesigned.
   See [RFC5080] Section 2.1.1 for a more in-depth discussion of = the use
   of the State Attribute."
 
BTW, I would also suggest a statement that this document does not apply
= to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations
= between a RADIUS client and server).
Section 2.1.1

   IPv6 address   128 bit value, most significant o= ctet first.
   IPv6 prefix    8 bits of reserve= d, 8 bits of prefix length, up to
      &n= bsp;           128 bits o= f value, most significant octet first.

Judging by some recent specifications, there appears to be some confusi= on
between these two types.  Should an IPv6 address type always be = used to
represent an address (as opposed to the prefix type).  If s= o, you might
state this explicitly using some normative language.
 
   integer64      64 bit unsigned value,= most significant octet first.
 
I believe that this type has also been used to express an IPv6 Identifiervalue, no?
 
Section 2.1.2
 
"  New attributes SHOULD NOT use this tagging method because of the   limitatations described above."
 
limitatations -> limitations
 
Section 2.1.3
 
   The only other exception to the recommendation against complex= types
   is for types that can be treated as opaque data by t= he RADIUS server.
   For example, the EAP-Message attribute, d= efined in [RFC3579] Section
   3.1 contains a complex data typ= e that is an EAP packet.  Since these
   complex types do= not need to be parsed by the RADIUS server, the
   issues ari= sing from policy language limitations do not arise.
   Similar= ly, since attributes of these complex types can be configured
 &nbs= p; on the server using a data type of String, dictionary limitations are   also not encountered.  Section A.1 below includes a seri= es of
   checklists that may be used to analyze a design for R= ECOMMENDED and
   NOT RECOMMENDED behavior in relation to comp= lex types.
 
I think it may be worth expanding this discussion of opaque data types
s= omewhat and covering additional implications, security related ones
in p= articular.  In general, RADIUS servers are highly valued targets sothat the introduction of complex data types brings with
it the potentia= l for introduction of security vulnerabilities such as
buffer overflows.=   An extreme outcome would be a vulnerability that
would allow an a= ttacker to take over the RADIUS server.
 
The use of attributes representing opaque data does not reduce this
thre= at, it merely moves it from the RADIUS server to an application
that con= sumes RADIUS attributes.  Should this application not be
properly i= solated, or run with extended privileges, then the
introduction of new = opaque data types (or changes in the format
of existing opaque types) ma= y introduce serious new security
vulnerabilities.
 
Section 3.1.3
 
   This change control can be obtained by requesting a PEC from t= he
   Internet Assigned Number Authority (IANA), for use as a = Vendor-Id
   within a Vendor-Specific attribute. 
 
Can you expand "PEC" on first use?
 
Rehosting may also require changes to the RADIUS data model
  = which will affect implementations that do not intend to support the
&nb= sp;  SDO specifications

Period needed at the end of the sentence.
 

IDNITs check
-------------
The tool found a few warnings:
 
idnits 2.05.02
tmp/draft-ietf-radext-design-01.txt:
 - Failure fetching the file, = proceeding without it.)
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4= 748:
  ------------------------------------------------------------= ----------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  -= ---------------------------------------------------------------------------=
     No issues found here.
  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  -------------= ---------------------------------------------------------------
     No issues found here.
  Miscellaneous warnings:
  ----------------------------------= ------------------------------------------
  =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not a= n accepted
     usage according to RFC 2119.  P= lease use 'MUST NOT' (if that is what you
     mean)= .
    
     Found 'MUST not'= in this paragraph:
    
    = ; This Attribute is available to allow vendors to support their own
&nbs= p;    extended Attributes not suitable for general usage.&nb= sp; It MUST not affect
     the operation of the RAD= IUS protocol.

  Checking references for intended status: Proposed Standard
&n= bsp; ----------------------------------------------------------------------= ------
     (See RFC 3967 for information about using normativ= e references to
     lower-maturity documents in RFC= s)
  -- Looks like a reference, but probably isn't: '8' on line 1191
&= nbsp;    'The Text field consists of UTF-8 encoded 10646 [8]= characters....'
  =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no ex= plicit
     reference was found in the text
 = ;    '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mi= tton, "Diamete...'
  -- No information found for draft-ietf-radext-extended-attributes - = is the
     name correct?

     Summary: 0 errors (**), 2 warnings (=3D=3D), 2= comments (--).
--------------------------------------------------------= ------------------------
= --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 03 07:33:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzAUF-00075P-8x for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 07:33:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzAUD-0000dm-GU for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 07:33:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzANF-000LNn-UR for radiusext-data@psg.com; Mon, 03 Dec 2007 12:26:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzAN2-000LKj-Ix for radiusext@ops.ietf.org; Mon, 03 Dec 2007 12:26:04 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id DF27AA704E for ; Mon, 3 Dec 2007 04:25:16 -0800 (PST) Message-ID: <4753F571.4000003@deployingradius.com> Date: Mon, 03 Dec 2007 13:24:17 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Bernard Aboba wrote: > Designation > > I thought that this document was a BCP, no? -01 states that > it is "Standards Track". -00 was Standards Track, too. The next version can be changed to a BCP. > Sections 1 and 1.1 > > There is some overlap in coverage. My recommendation is to reorganize > the discussion as follows: ... OK. > BTW, I would also suggest a statement that this document does not apply > to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations > between a RADIUS client and server). > Section 2.1.1 OK. > IPv6 address 128 bit value, most significant octet first. > IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to > 128 bits of value, most significant octet first. > > Judging by some recent specifications, there appears to be some confusion > between these two types. Should an IPv6 address type always be used to > represent an address (as opposed to the prefix type). If so, you might > state this explicitly using some normative language. Hmm... suggestions? > integer64 64 bit unsigned value, most significant octet first. > > I believe that this type has also been used to express an IPv6 Identifier > value, no? Yes. That is mentioned in the following paragraph. I'll add a line here saying the same thing. > limitatations -> limitations Fixed, thanks. > Section 2.1.3 .. > I think it may be worth expanding this discussion of opaque data types > somewhat and covering additional implications, security related ones > in particular. Section 2.1.3 is already over two pages long. I suggest adding a new section immediately following it, "Complex attributes and Security": 2.1.4. Complex Attributes and Security The introduction of complex data types brings the potential for the introduction of new security vulnerabilities. Experience shows that the common data types have few security vulnerabilities, or else that all known issues have been found and fixed. New data types require new code, which may introduce new bugs, and therefore new attack vectors. RADIUS servers are highly valued targets, as they control network access and interact with databases that store usernames and passwords. An extreme outcome of a vulnerability due to a new, complex type would be that an attacker is capable of taking complete control over the RADIUS server. The use of attributes representing opaque data does not reduce this threat. The threat merely moves from the RADIUS server to the application that consumes that opaque data. Any such application SHOULD be properly isolated from the RADIUS server, and SHOULD run with minimal privileges. Any potential vulnerabilities in that application will then have minimal impact on the security of the system as a whole. I've also added text in the security section referencing 2.1.4. > Section 3.1.3 ... > Can you expand "PEC" on first use? Done in Section 2.2. > Rehosting may also require changes to the RADIUS data model > which will affect implementations that do not intend to support the > SDO specifications > > Period needed at the end of the sentence. Fixed, thanks. > > IDNITs check ... > ---------------------------------------------------------------------------- > == Using lowercase 'not' together with uppercase 'MUST' is not an accepted > usage according to RFC 2119. Please use 'MUST NOT' (if that is > what you > mean). Text changed to MUST NOT. > -- Looks like a reference, but probably isn't: '8' on line 1191 It's in a quote from another document. > == Unused Reference: 'RFC4005' is defined on line 795, but no explicit > reference was found in the text > '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, > "Diamete...' That reference can be deleted. > -- No information found for draft-ietf-radext-extended-attributes - is the > name correct? Yes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 03 10:48:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDXV-0001f9-RF for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 10:48:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDXU-0007J5-7V for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 10:48:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzDRB-000BfW-JG for radiusext-data@psg.com; Mon, 03 Dec 2007 15:42:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.111] (helo=bay0-omc1-s39.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzDR0-000Ber-Vo for radiusext@ops.ietf.org; Mon, 03 Dec 2007 15:42:20 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc1-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Dec 2007 07:42:14 -0800 X-Originating-IP: [130.129.67.90] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <4753F571.4000003@deployingradius.com> To: "Alan DeKok" , References: <4753F571.4000003@deployingradius.com> Subject: Re: Review of draft-ietf-radext-design-01.txt Date: Mon, 3 Dec 2007 07:42:18 -0800 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 03 Dec 2007 15:42:14.0783 (UTC) FILETIME=[13D748F0:01C835C3] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 >> IPv6 address 128 bit value, most significant octet first. >> IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to >> 128 bits of value, most significant octet first. >> >> Judging by some recent specifications, there appears to be some confusion >> between these two types. Should an IPv6 address type always be used to >> represent an address (as opposed to the prefix type). If so, you might >> state this explicitly using some normative language. > > Hmm... suggestions? How about this? "Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to utilize the IPv6 Prefix type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED." > 2.1.4. Complex Attributes and Security > > The introduction of complex data types brings the potential for the > introduction of new security vulnerabilities. Experience shows that > the common data types have few security vulnerabilities, or else that > all known issues have been found and fixed. New data types require > new code, which may introduce new bugs, and therefore new attack > vectors. > > RADIUS servers are highly valued targets, as they control network > access and interact with databases that store usernames and > passwords. An extreme outcome of a vulnerability due to a new, > complex type would be that an attacker is capable of taking complete > control over the RADIUS server. > > The use of attributes representing opaque data does not reduce this > threat. The threat merely moves from the RADIUS server to the > application that consumes that opaque data. Suggest adding: "The threat is particularly severe when the opaque data is not originated or checked by the NAS, so that the RADIUS server is potentially exposed to attack by malware residing on a host. Applications consuming opaque data that reside on the RADIUS server > SHOULD be properly isolated from the RADIUS server, and SHOULD run > with minimal privileges. Any potential vulnerabilities in that > application will then have minimal impact on the security of the > system as a whole. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 03 12:09:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzEna-0000hH-Ld for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 12:09:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzEnZ-0008RM-TZ for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 12:09:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzEic-000JIz-Dn for radiusext-data@psg.com; Mon, 03 Dec 2007 17:04:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzEhc-000JCg-PJ for radiusext@ops.ietf.org; Mon, 03 Dec 2007 17:03:47 +0000 Received: (qmail 9659 invoked from network); 3 Dec 2007 12:05:12 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Dec 2007 12:05:12 -0500 From: "David B. Nelson" To: "'Bernard Aboba'" , References: Subject: RE: Review of draft-ietf-radext-design-01.txt Date: Mon, 3 Dec 2007 12:01:57 -0500 Organization: Elbrys Networks, Inc. Message-ID: <012c01c835ce$3694b6b0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acg1TsKun+30oRoxQeyMJulnd/ZZQQAfepkQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Bernard Aboba writes... There is some overlap in coverage.=A0 My recommendation is to reorganize the discussion as follows: =A0 "1.=A0 Introduction =A0=A0 This document provides guidelines for the design of RADIUS = attributes =A0=A0 both within the IETF as well as within other Standards = Development =A0=A0 Organizations (SDOs).=A0 By articulating RADIUS design = guidelines, it=20 =A0=A0 is hoped that this document will encourage the development and =A0=A0 publication of high quality RADIUS attribute specifications. =A0=A0 The advice in this document will not be helpful unless it is put = to use.=A0 =A0=A0 As with "Guidelines for Authors and Reviewers of MIB Documents" =A0=A0 [RFC4181], it is expected that this document will enable authors = to =A0=A0 check their document against the guidelines prior to requesting a =A0=A0 review (such an "Expert Review" described in [RFC3575]).=A0 = Similarly, =A0=A0 it is hoped that this document will be of use to reviewers (such = as =A0=A0 WG participants or the AAA Doctors) in improving the consistency = of =A0=A0 reviews. =A0 =A0=A0 In order to meet these objectives, this document needs to cover = not =A0=A0 only the science of attribute design, but also the art.=A0 As a = result, =A0=A0 in addition to covering the most frequently encountered issues, = this =A0=A0 document attempts to provide some of the considerations = motivating =A0=A0 the guidelines. =A0 =A0=A0 In order to characterize current attribute usage, both the basic = and =A0=A0 complex data types defined in the existing RADIUS RFCs are = reviewed, =A0=A0 together with the ad-hoc extensions to that data model that have = been =A0=A0 used in Vendor-Specific Attributes. DBN: I think this text is very good. 1.1.=A0 Applicability =A0=A0 As RADIUS has become more widely accepted as a management = protocol, =A0=A0 its usage has become more prevalent, both within the IETF as well = as =A0=A0 within other SDOs.=A0 Given the expanded utilization of RADIUS, =A0=A0 it has become apparent that requiring SDOs to accomplish all = their=20 =A0=A0 RADIUS work within the IETF is inherently inefficient and = unscalable. =A0=A0 By articulating guidelines for RADIUS attribute design, this = document=20 =A0=A0 enables SDOs to design their own RADIUS attributes within the=20 =A0=A0 Vendor-Specific Attribute (VSA) space, seeking review from the = IETF. =A0=A0 In order enable IETF review of SDO RADIUS attribute = specifications, =A0=A0 the authors recommend: =A0 =A0=A0=A0=A0=A0 * Development of a program to encourage SDOs to make = their RADIUS =A0=A0=A0=A0=A0 attribute specifications publicly available; =A0=A0=A0=A0=A0 * Review of IETF and SDO specifications according to the =A0=A0=A0=A0=A0 guidelines proposed in this document; =A0 =A0=A0 The advice in this document applies to attributes used to encode =A0=A0 data. DBN: I think this last sentence could be a bit more specific. All attributes encode data. The question is what kind of data. I think = what you want to say is: The advice in this document applies to attributes used to encode service-provisioning or authentication data. =A0 RADIUS protocol changes, or specification of attributes that =A0=A0 can be used to provide new RADIUS commands (such as Service-Type) = are =A0=A0 out of scope. DBN: I recommend clarifying this last sentence just a bit by: s/can be used to provide new RADIUS commands/can be used to, in effect, provide new RADIUS commands/ =A0 Since protocol changes require greater expertise and =A0=A0 deeper review, such changes should not be undertaken outside the = IETF =A0=A0 and when handled within the IETF require "IETF Consensus" for =A0=A0 adoption, as noted in [RFC3575] Section 2.1. =A0 =A0=A0 As with protocol changes, this document does not provide guidance = to =A0=A0 document authors seeking to change the RADIUS operational model. =A0=A0 While RADIUS server implementations may keep state, the RADIUS =A0=A0 protocol is stateless, although information may be passed from = one =A0=A0 protocol transaction to another via the State Attribute.=A0 As a =A0=A0 result, documents which require stateful protocol behavior = without =A0=A0 use of the State Attribute are inherently incompatible with = RADIUS as =A0=A0 defined in [RFC2865], and need to be redesigned. =A0=A0 See [RFC5080] Section 2.1.1 for a more in-depth discussion of the = use =A0=A0 of the State Attribute." =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: From owner-radiusext@ops.ietf.org Mon Dec 03 15:03:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHVV-0003r6-0B for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 15:03:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzHVT-0001pP-EK for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 15:03:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzHQy-0009gZ-Fa for radiusext-data@psg.com; Mon, 03 Dec 2007 19:58:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzHQn-0009fa-S6 for radiusext@ops.ietf.org; Mon, 03 Dec 2007 19:58:23 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 0B759A704E; Mon, 3 Dec 2007 11:58:12 -0800 (PST) Message-ID: <47545F93.30908@deployingradius.com> Date: Mon, 03 Dec 2007 20:57:07 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt References: <4753F571.4000003@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Bernard_Aboba@hotmail.com wrote: > How about this? > > "Where the intent is to represent a specific IPv6 address, the IPv6 ... Done. > Suggest adding: "The threat is particularly severe when the opaque data Word-smithing: The threat is particularly severe when the opaque data does not originate from, or is checked by the NAS. In those cases, the RADIUS server is potentially exposed to attack by malware residing on an unauthenticated host. Applications consuming opaque data that reside on the RADIUS server SHOULD be properly isolated from the RADIUS server, and SHOULD run with minimal privileges. Any potential vulnerabilities in that application will then have minimal impact on the security of the system as a whole. (chopping long sentences, etc.) 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: From owner-radiusext@ops.ietf.org Mon Dec 03 15:10:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzHcy-0002vj-KC for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 15:10:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzHcy-00029e-Am for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 03 Dec 2007 15:10:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzHY4-000AP7-Hw for radiusext-data@psg.com; Mon, 03 Dec 2007 20:05:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzHXs-000AMW-Kf for radiusext@ops.ietf.org; Mon, 03 Dec 2007 20:05:41 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id B751BA704E; Mon, 3 Dec 2007 12:05:31 -0800 (PST) Message-ID: <47546148.4090708@deployingradius.com> Date: Mon, 03 Dec 2007 21:04:24 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt References: <012c01c835ce$3694b6b0$5d1216ac@xpsuperdvd2> In-Reply-To: <012c01c835ce$3694b6b0$5d1216ac@xpsuperdvd2> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 David B. Nelson wrote: > Bernard Aboba writes... > > There is some overlap in coverage. My recommendation is to reorganize > the discussion as follows: ... > DBN: I think this text is very good. Updated as recommended. ... > DBN: I think this last sentence could be a bit more specific. All > attributes encode data. The question is what kind of data. I think what > you want to say is: Updated > DBN: I recommend clarifying this last sentence just a bit by: Updated. I'll post a new version before the meeting. 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: From owner-radiusext@ops.ietf.org Tue Dec 04 14:11:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzdBD-00035n-1N for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 04 Dec 2007 14:11:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzdBC-00025g-My for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 04 Dec 2007 14:11:39 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Izd2Z-0001BV-WF for radiusext-data@psg.com; Tue, 04 Dec 2007 19:02:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.148] (helo=bay0-omc2-s12.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Izd0V-000105-5e for radiusext@ops.ietf.org; Tue, 04 Dec 2007 19:01:40 +0000 Received: from BAY117-DS3 ([207.46.8.30]) by bay0-omc2-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 11:00:34 -0800 X-Originating-IP: [130.129.20.161] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: IETF 70 slides available Date: Tue, 4 Dec 2007 11:00:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016E_01C83664.E6334B90" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 04 Dec 2007 19:00:34.0679 (UTC) FILETIME=[F3251070:01C836A7] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_016E_01C83664.E6334B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Slides for the IETF 70 meeting of the RADEXT WG are being posted online = as they arrive: https://datatracker.ietf.org/meeting/70/materials.html If you have not sent in your slides, please do so ASAP. ------=_NextPart_000_016E_01C83664.E6334B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Slides for the IETF 70 meeting of the = RADEXT WG are=20 being posted online as they arrive:
https://d= atatracker.ietf.org/meeting/70/materials.html
 
If you have not sent in your slides, = please do so=20 ASAP.
------=_NextPart_000_016E_01C83664.E6334B90-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 04 22:53:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzlJq-0001PR-7D for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 04 Dec 2007 22:53:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzlJp-0004WJ-Js for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 04 Dec 2007 22:53:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzlFA-000067-Dq for radiusext-data@psg.com; Wed, 05 Dec 2007 03:48:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [161.114.21.104] (helo=ccerelbas01.cce.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzlEh-00004M-6G for radiusext@ops.ietf.org; Wed, 05 Dec 2007 03:48:01 +0000 Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 0822834C26 for ; Tue, 4 Dec 2007 21:47:46 -0600 (CST) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.0.700.0; Wed, 5 Dec 2007 03:45:21 +0000 Received: from G6W0269.americas.hpqcorp.net ([16.230.32.78]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 5 Dec 2007 03:45:20 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "radiusext@ops.ietf.org" Date: Wed, 5 Dec 2007 03:47:51 +0000 Subject: Request for review of RADIUS Attributes for IEEE 802 Networks Thread-Topic: Request for review of RADIUS Attributes for IEEE 802 Networks Thread-Index: AcgmODLyeeG1TRSFS16Yc4EGw4p4CgQuU01gAAAEyGA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0305_01C836AE.8E327520" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 ------=_NextPart_000_0305_01C836AE.8E327520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support this document as a RADEXT WG item. Cheers, MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner- > radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Tuesday, November 13, 2007 1:00 PM > To: radiusext@ops.ietf.org > Subject: Request for review of RADIUS Attributes for IEEE 802 Networks > > The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was > revised on > July 30, 2007, after incorporating review from the IEEE 802.11 WG. > This > document appears on the RADEXT WG charter as a June 2006 milestone > "WLAN > Attributes draft submitted as a Proposed Standard RFC". It would be > good to > make additional progress on this document. It appears that all the > required > external (i.e. IEEE) review has been completed. > > Please review this draft to determine if it is ready to be taken on as > a > RADEXT WG work item. The draft is to be found at: > > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt > > In light of the upcoming IETF-70 meeting, this request for review will > last > until December 7, 2007, i.e. approximately four weeks, including the > IETF > week. > > Please indicate whether you would like this document to be taken on as > a WG > work item. Please respond even if you have no issues with the document. > If > you have comments, please send the issues to the RADEXT WG mailing list > in > the format provided here: > > http://www.drizzle.com/~aboba/RADEXT/ > > Thanks! > > Regards, > > Dave Nelson > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_0305_01C836AE.8E327520 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh2K9TSN0bRHs7 wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAIC20 InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLSzZW6NF4K3fkq NjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cYB0G8dY+vGp77 WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTIwNTAzNDc1MVowIwYJ KoZIhvcNAQkEMRYEFHWgoDTA9YF1d5RhZ8S3Wqfi5pFdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgAbXdDsXk3m7b/H6i6qDFLVTi0fXZReyJ5kS82jdDJonRh68XRaPKlGeV+iWHHDX XfVEvkcpWIVoov5CdS4DBrpm7h1kYmCB86Z5aA049d0MoeP1/LbpTkMlDkOTX9Yoc7WpgIc2/fYr U0rbN8ZtMxu58H0/dUON0/MIp/RXddvrAAAAAAAA ------=_NextPart_000_0305_01C836AE.8E327520-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 05 04:10:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzqGz-0002xH-L2 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 05 Dec 2007 04:10:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzqGz-0005bC-75 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 05 Dec 2007 04:10:29 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzqBg-000OfN-NQ for radiusext-data@psg.com; Wed, 05 Dec 2007 09:05:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzqBC-000Ocs-5B for radiusext@ops.ietf.org; Wed, 05 Dec 2007 09:04:45 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 44AA611A60A for ; Wed, 5 Dec 2007 01:04:22 -0800 (PST) Message-ID: <47566959.7000709@deployingradius.com> Date: Wed, 05 Dec 2007 10:03:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: 'radext mailing list' Subject: Drafts for the meeting X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad I have put the drafts up on my web site: http://deployingradius.com/ietf/ I've included the DTLS draft, which has expired. I've also included the -02 draft, which I have just submitted. 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: From owner-radiusext@ops.ietf.org Wed Dec 05 05:14:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzrH3-0005ZS-0D for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 05 Dec 2007 05:14:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzrH2-0007n2-F9 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 05 Dec 2007 05:14:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzrD3-0003PE-GT for radiusext-data@psg.com; Wed, 05 Dec 2007 10:10:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.138] (helo=ns3.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IzrCd-0003LR-HJ for radiusext@ops.ietf.org; Wed, 05 Dec 2007 10:10:10 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 71A121758F; Wed, 5 Dec 2007 10:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzrCc-0006bo-0H; Wed, 05 Dec 2007 05:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-design-02.txt Message-Id: Date: Wed, 05 Dec 2007 05:10:02 -0500 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-02.txt Pages : 31 Date : 2007-12-05 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-design-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-design-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-05050411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-design-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-design-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-05050411.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 06 13:39:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LdM-0003Px-4a for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 13:39:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LdL-0006aH-I3 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 13:39:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0LXL-000D16-8J for radiusext-data@psg.com; Thu, 06 Dec 2007 18:33:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.167] (helo=bay0-omc2-s31.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0LXA-000CxJ-3m for radiusext@ops.ietf.org; Thu, 06 Dec 2007 18:33:21 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 10:33:15 -0800 X-Originating-IP: [130.129.20.161] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Thu, 6 Dec 2007 10:33:17 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C837F3.6A2D3F70" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 06 Dec 2007 18:33:15.0596 (UTC) FILETIME=[770058C0:01C83836] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C837F3.6A2D3F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 70, we discussed the applicability of RFC 4107 to RADIUS = Crypto-agility requirements.=20 The consensus within the room was that Automated Key Management should = not be added to the list of Crypto-agility requirements.=20 This is a call for RADEXT WG mailing list consensus on this issue. = Does the mailing list agree that Automated Key Management is not a requirement for a RADIUS = Crypto-agility solution?=20 Some of the arguments made include: 1. While automated key management may prove convenient in some = circumstances (e.g. EDUROAM), the demand is by no means universal, nor is the pain of the current = manual keying environment considered acute by most customers.=20 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: a. RADIUS client-server communication is not an N^2 problem (except = perhaps in the roaming situation where end-to-end protection is being provided). =20 b. One of the goals of RADIUS crypto-agility is to remove the use of = stream ciphers. c. RADIUS traffic is generally light enough that a credible = ciphersuite would not require rekey for a long time.=20 So, does the WG agree with these arguments? Please respond to the list = even if you have no new arguments to add, if only to say that you agree (or disagree) with the consensus = in the room at IETF 70. ------=_NextPart_000_0051_01C837F3.6A2D3F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 70, we discussed the = applicability of RFC=20 4107 to RADIUS Crypto-agility requirements.
 
The consensus within the room was that = Automated=20 Key Management should not be added to the list
of Crypto-agility requirements. =
 
This is a call for RADEXT WG mailing = list consensus=20 on this issue.   Does the mailing list agree
that Automated Key Management is not a = requirement=20 for a RADIUS Crypto-agility solution?
 
Some of the arguments made = include:
 
1. While automated key management = may prove=20 convenient in some circumstances (e.g. EDUROAM),
the demand is by no means universal, = nor is the=20 pain of the current manual keying environment considered
acute by most customers.
 
2. RFC 4107 criteria do not apply to a = RADIUS=20 crypto-agile solution:
  a. RADIUS=20 client-server communication is not an N^2 problem (except perhaps in the = roaming
situation where end-to-end protection = is being=20 provided). 
  b. One of the goals of RADIUS = crypto-agility=20 is to remove the use of stream=20 ciphers.
  c.  RADIUS traffic is = generally=20 light enough that a credible ciphersuite would=20 not require rekey for a long time.
 
So, does the WG agree with these = arguments? =20 Please respond to the list even if you have no new = arguments
to add, if only to say that you agree = (or disagree)=20 with the consensus in the room at IETF 70.
------=_NextPart_000_0051_01C837F3.6A2D3F70-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 06 18:56:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0QZm-0001uS-99 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 18:56:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0QZl-0006VN-MX for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 18:56:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0QVe-000P6F-3q for radiusext-data@psg.com; Thu, 06 Dec 2007 23:52:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.16] (helo=QMTA01.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0QVT-000P5j-8d for radiusext@ops.ietf.org; Thu, 06 Dec 2007 23:51:56 +0000 Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id MZi51Y0060FhH240A0JD00; Thu, 06 Dec 2007 23:51:55 +0000 Received: from smailcenter43.comcast.net ([204.127.205.143]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id Mbrt1Y00D369VJ40800000; Thu, 06 Dec 2007 23:51:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=pt-L-_U6iX0A:10 a=NCtGln71K7Al4g82tLc9rg==:17 a=HFoS7zRMqmM93o3gj5UA:9 a=nlI1-psgwkA_UZuH0p4A:7 a=4oE2NyYft5kE8JFs271YJq8Ws4gA:4 a=EfJqPEOeqlMA:10 a=gi0PWCVxevcA:10 a=dbhUFImg162ZpT2Q6LgA:7 a=nxkZDdwTNXzQiRSulu5urT2jizIA:4 a=37WNUvjkh6kA:10 Received: from [130.129.18.125] by smailcenter43.comcast.net; Thu, 06 Dec 2007 23:51:47 +0000 From: glenzorn@comcast.net To: , Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Thu, 06 Dec 2007 23:51:47 +0000 Message-Id: <120620072351.15546.47588B1300003D9B00003CBA2200763704029D0196020A0409@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 30 2007) X-Authenticated-Sender: Z2xlbnpvcm5AY29tY2FzdC5uZXQ= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_15546_1196985107_0" Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --NextPart_Webmail_9m3u9jl4l_15546_1196985107_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I agree. -------------- Original message -------------- From: At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements. The consensus within the room was that Automated Key Management should not be added to the list of Crypto-agility requirements. This is a call for RADEXT WG mailing list consensus on this issue. Does the mailing list agree that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution? Some of the arguments made include: 1. While automated key management may prove convenient in some circumstances (e.g. EDUROAM), the demand is by no means universal, nor is the pain of the current manual keying environment considered acute by most customers. 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: a. RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming situation where end-to-end protection is being provided). b. One of the goals of RADIUS crypto-agility is to remove the use of stream ciphers. c. RADIUS traffic is generally light enough that a credible ciphersuite would not require rekey for a long time. So, does the WG agree with these arguments? Please respond to the list even if you have no new arguments to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70. --NextPart_Webmail_9m3u9jl4l_15546_1196985107_0 Content-Type: text/html Content-Transfer-Encoding: 8bit
I agree.
 
-------------- Original message --------------
From: <Bernard_Aboba@hotmail.com>
At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements.
 
The consensus within the room was that Automated Key Management should not be added to the list
of Crypto-agility requirements.
 
This is a call for RADEXT WG mailing list consensus on this issue.   Does the mailing list agree
that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution?
 
Some of the arguments made include:
 
1. While automated key management may prove convenient in some circumstances (e.g. EDUROAM),
the demand is by no means universal, nor is the pain of the current manual keying environment considered
acute by most customers.
 
2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
  a. RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming
situation where end-to-end protection is being provided). 
  b. One of the goals of RADIUS crypto-agility is to remove the use of stream ciphers.
  c.  RADIUS traffic is generally light enough that a credible ciphersuite would not require rekey for a long time.
 
So, does the WG agree with these arguments?  Please respond to the list even if you have no new arguments
to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70.
--NextPart_Webmail_9m3u9jl4l_15546_1196985107_0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 06 19:22:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Qyw-0003AK-NL for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 19:22:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Qyv-00086Q-6Z for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 06 Dec 2007 19:22:18 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0Qu4-0001uR-0J for radiusext-data@psg.com; Fri, 07 Dec 2007 00:17:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0QoO-0001Nb-Cg for radiusext@ops.ietf.org; Fri, 07 Dec 2007 00:15:23 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 1D2F3A7068 for ; Thu, 6 Dec 2007 16:11:18 -0800 (PST) Message-ID: <47588F60.9000100@nitros9.org> Date: Fri, 07 Dec 2007 01:10:08 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Bernard_Aboba@hotmail.com wrote: > This is a call for RADEXT WG mailing list consensus on this issue. > Does the mailing list agree > that Automated Key Management is not a requirement for a RADIUS > Crypto-agility solution? I agree Pointing to my response: http://psg.com/lists/radiusext/2007/msg00911.html > Some of the arguments made include: > > 1. While automated key management may prove convenient in some > circumstances (e.g. EDUROAM), > the demand is by no means universal, nor is the pain of the current > manual keying environment considered > acute by most customers. Most commercial deployments of RADIUS interconnects are either ( N x N ) - where N is small, < 5 (N x 1 + 1 x M) - where N and M may each be > 30 i.e. full interconnects are usually small. Otherwise, intermediary proxies are used to simplify the problem. I think Eduroam is the only (N x N) deployment I've seen where N > 10. Since Eduroam is using RadSec, I suspect that the N^2 issue could be solved by leveraging a central Eduroam Certificate Authority. It would issue, and sign, certificates for each participating institution or country. Each particpant would then be responsible for using those certs, and for validating the certs of Eduroam partners. > 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: > a. RADIUS client-server communication is not an N^2 problem (except > perhaps in the roaming > situation where end-to-end protection is being provided). Yes. > b. One of the goals of RADIUS crypto-agility is to remove the use of > stream ciphers. > c. RADIUS traffic is generally light enough that a credible > ciphersuite would not require rekey for a long time. Yes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 07 02:29:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Xei-0001IM-Rw for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 07 Dec 2007 02:29:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Xeh-00064b-3h for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 07 Dec 2007 02:29:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0XYy-0001Ja-6A for radiusext-data@psg.com; Fri, 07 Dec 2007 07:23:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [158.64.1.62] (helo=smtprelay.restena.lu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0XYR-0001Er-Er for radiusext@ops.ietf.org; Fri, 07 Dec 2007 07:23:39 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D263076F44; Fri, 7 Dec 2007 08:23:21 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTP id BBBC876F43; Fri, 7 Dec 2007 08:23:21 +0100 (CET) From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Fri, 7 Dec 2007 08:23:15 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <47588F60.9000100@nitros9.org> In-Reply-To: <47588F60.9000100@nitros9.org> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?iso-8859-1?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3A?= =?iso-8859-1?q?t=7EVv=7D?=(exS~'/q+xqA =?iso-8859-1?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?iso-8859-1?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?iso-8859-1?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4311849.K2hZFybWMa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712070823.21198.stefan.winter@restena.lu> X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --nextPart4311849.K2hZFybWMa Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, > I think Eduroam is the only (N x N) deployment I've seen where N > 10. And even we are avoiding N^2 complexity at the moment with a tree structure= :=20 star topology with central proxy from institutions within a country, star=20 topology of country proxies to root. If you care enough: even with RadSec and peer resolution, we might still ha= ve=20 proxies in between, for entirely non-technical reasons. Some countries want= =20 to reserve the right to filter attributes at a national level, so any=20 resolution technique would be configured on their side to end up at the=20 national TLD proxy, and be distributed onwards from there. > Since Eduroam is using RadSec, I suspect that the N^2 issue could be > solved by leveraging a central Eduroam Certificate Authority. It would > issue, and sign, certificates for each participating institution or > country. Each particpant would then be responsible for using those > certs, and for validating the certs of Eduroam partners. That is exactly the plan. We are not quite there yet with full deployment, = but=20 on our way. > > 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: > > a. RADIUS client-server communication is not an N^2 problem (except > > perhaps in the roaming > > situation where end-to-end protection is being provided). > > Yes. We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end= =20 security, which is where my wish to have auto key mgmt came from. The=20 concrete use case we have is that some countries need the age of a user to= =20 determine if he's legally allowed to get unfiltered internet access. This means we would need to transfer either birthday or at least age via=20 RADIUS. This kind of user attribute can be easily tied to a concrete=20 User-Name in most cases and is thus subject to law regulations regarding=20 transmission and storage of personal data. =46or the moment our only solution is to keep eduroam to higher ed and rese= arch=20 only, where all eligible users can be expected to be over eighteen. We are= =20 currently working on a quite sophisticated out-of-band handshaking for such= =20 data (there are more examples than just age), but would be a lot happier if= =20 there was an easy in-band solution. I agree though that our woes in that regard are pretty much unique. Greetings, Stefan =2D-=20 Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale= et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224= 73 --nextPart4311849.K2hZFybWMa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHWPTp+jm90f8eFWYRAvvYAJ40CyLReN3dKpfNEXsbv7TzNN5CgQCfbZ9H WeaiOMqV8OdnDJ6RrqObrDA= =hpmQ -----END PGP SIGNATURE----- --nextPart4311849.K2hZFybWMa-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 07 03:08:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0YG6-0007gM-Vp for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 07 Dec 2007 03:08:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0YG6-0007Yq-Ga for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 07 Dec 2007 03:08:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0YBF-00056Z-KF for radiusext-data@psg.com; Fri, 07 Dec 2007 08:03:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J0YBE-00056L-As for radiusext@ops.ietf.org; Fri, 07 Dec 2007 08:03:28 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 198D8A7068; Fri, 7 Dec 2007 00:03:18 -0800 (PST) Message-ID: <4758FE03.5000201@nitros9.org> Date: Fri, 07 Dec 2007 09:02:11 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements References: <47588F60.9000100@nitros9.org> <200712070823.21198.stefan.winter@restena.lu> In-Reply-To: <200712070823.21198.stefan.winter@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Stefan Winter wrote: >> [ certs ] > That is exactly the plan. We are not quite there yet with full deployment, but > on our way. That addresses some of my concerns about scalability. > We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end > security, which is where my wish to have auto key mgmt came from. I think end-to-end security is outside of the scope of RADIUS. If hop-by-hop security is sufficient, then the requirements and assertions can go into a vendor-specific dictionary. 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: From owner-radiusext@ops.ietf.org Sun Dec 09 13:46:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1RAU-0004gm-Vd for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 09 Dec 2007 13:46:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1RAU-0006Lw-IZ for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 09 Dec 2007 13:46:22 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1R6X-000OgP-TX for radiusext-data@psg.com; Sun, 09 Dec 2007 18:42:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.48] (helo=QMTA05.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J1R6V-000Og2-74 for radiusext@ops.ietf.org; Sun, 09 Dec 2007 18:42:16 +0000 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id NfFh1Y0010cQ2SL0A0Fs00; Sun, 09 Dec 2007 18:42:14 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id Nii81Y00F53lGY30800000; Sun, 09 Dec 2007 18:42:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=R5QPQKeKIMEA:10 a=wn9DHnzW4yfxGeVL6AYA:9 a=3zTGOKq84NGdzCxk2SvbcW3r5T8A:4 a=Vdgex2DK8hkA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=BxzV8RIG9AH48rYYyYAA:9 a=SgFFcdT1HvRygBGYS7avECBczDUA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: Cc: "'Glen Zorn'" Subject: Questions on modified Extended Attribute format? Date: Sun, 9 Dec 2007 10:39:33 -0800 Message-ID: <003401c83a92$db6ed850$924c88f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C83A4F.CD4B9850" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg6ktaKf9XFXvNvSVSLUNVxuO19Jw== Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multipart message in MIME format. ------=_NextPart_000_0035_01C83A4F.CD4B9850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit During the meeting last week, I thought that there were a couple of questions/comments on Jabber regarding the changes that I proposed to the extended attribute format (adding a bit to distinguish between new TLVs and legacy RADIUS attributes in extended attributes) but I didn't quite catch them. Would those who presented those remarks mind repeating them in email? TIA. ------=_NextPart_000_0035_01C83A4F.CD4B9850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the meeting last week, I thought that there = were a couple of questions/comments on Jabber regarding the changes that I = proposed to the extended attribute format (adding a bit to distinguish between new = TLVs and legacy RADIUS attributes in extended attributes) but I didn't quite = catch them.  Would those who presented those remarks mind repeating them = in email?  TIA.

------=_NextPart_000_0035_01C83A4F.CD4B9850-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 17 14:13:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LPZ-0005UU-6E for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 14:13:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4LPX-0005Yp-NI for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 14:13:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4LGa-0008HW-Gy for radiusext-data@psg.com; Mon, 17 Dec 2007 19:04:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [207.47.15.6] (helo=mail2.azairenet.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4LGX-0008Gh-EA for radiusext@ops.ietf.org; Mon, 17 Dec 2007 19:04:38 +0000 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 11:04:28 -0800 Message-ID: <4766C83C.8030606@azairenet.com> Date: Mon, 17 Dec 2007 11:04:28 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Question on the Class attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 19:04:28.0581 (UTC) FILETIME=[A5EE6D50:01C840DF] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hello, I had a question on the Class attribute [RFC 2865]. What should the RADIUS server do if the Class in the Access Accept message that it sent does not match with the Accounting Request message that comes later? RFC 2865 does say this attribute should never be modified by the client. But I think the server behavior should still be specified in case there is a mismatch. Is there any document that talks about this? Thanks in advance Vijay -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 17 20:10:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Qy7-0006lG-Vk for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 20:09:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Qy7-0007Hc-Cs for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 20:09:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4QsL-000Hwo-3c for radiusext-data@psg.com; Tue, 18 Dec 2007 01:04:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-102.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO autolearn=no version=3.2.3 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4QrB-000HnU-Mo for radiusext@ops.ietf.org; Tue, 18 Dec 2007 01:02:59 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id 6BEAF10032C; Mon, 17 Dec 2007 17:02:49 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5080 on Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20071218010249.6BEAF10032C@bosco.isi.edu> Date: Mon, 17 Dec 2007 17:02:49 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 A new Request for Comments is now available in online RFC libraries. RFC 5080 Title: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes Author: D. Nelson, A. DeKok Status: Standards Track Date: December 2007 Mailbox: dnelson@elbrysnetworks.com, aland@freeradius.org Pages: 28 Characters: 64138 Updates: RFC2865, RFC2866, RFC2869, RFC3579 See-Also: I-D Tag: draft-ietf-radext-fixes-08.txt URL: http://www.rfc-editor.org/rfc/rfc5080.txt This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 17 22:13:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4StO-0008LU-Lk for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 22:13:14 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4StO-0001KJ-Ar for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 17 Dec 2007 22:13:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4Soc-0003U9-Sk for radiusext-data@psg.com; Tue, 18 Dec 2007 03:08:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4Soa-0003To-6U for radiusext@ops.ietf.org; Tue, 18 Dec 2007 03:08:17 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT800DYL61QMW@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Tue, 18 Dec 2007 11:08:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT800GO061NTW@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Tue, 18 Dec 2007 11:08:14 +0800 (CST) Received: from l67563 ([10.111.12.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT800JJS61I5A@szxml04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 18 Dec 2007 11:08:11 +0800 (CST) Date: Tue, 18 Dec 2007 11:08:06 +0800 From: li chunxiu Subject: a question about Management Authorization -01 document In-reply-to: <129a01c82b26$e5b030a0$6401a8c0@NEWTON603> To: "'David B. Nelson'" Cc: radiusext@ops.ietf.org Message-id: <007e01c84123$38dda610$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8A= Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hello, David In the RADIUS NAS Management Authorization Draft=A3=ACthe added = attribute Management-Privilege-Level is an integer-valued attribute for use with = CLI access methods, I have a question about it, does it apply to the Framed-Management-Protocol? For example, in access control of SNMP protocol or Netconf protocol, is = it necessary to use the Management-Privilege-Level attribute? Thanks, Chunxiu li -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 09:16:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4dFG-0005TG-HA for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 09:16:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4dFE-0007Th-Sh for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 09:16:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4d8H-000CN3-DR for radiusext-data@psg.com; Tue, 18 Dec 2007 14:09:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4d8E-000CMc-0T for radiusext@ops.ietf.org; Tue, 18 Dec 2007 14:09:15 +0000 Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id SD9J1Y0020QkzPw0A05u00; Tue, 18 Dec 2007 14:09:17 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id SE9A1Y00K24Kx1C8N00000; Tue, 18 Dec 2007 14:09:17 +0000 X-Authority-Analysis: v=1.0 c=1 a=knlbeGU9GrsA:10 a=07BeACQPc7hFIM_fTCoA:9 a=v-VXDfYnJEW7uOM074V3Al43piUA:4 a=DLWQtoLnVnAA:10 From: "David B. Nelson" To: Cc: References: <129a01c82b26$e5b030a0$6401a8c0@NEWTON603> <007e01c84123$38dda610$500c6f0a@china.huawei.com> Subject: RE: a question about Management Authorization -01 document Date: Tue, 18 Dec 2007 09:09:13 -0500 Message-ID: <055501c8417f$9270fef0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <007e01c84123$38dda610$500c6f0a@china.huawei.com> Thread-Index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Li Chunxiu writes... > In the RADIUS NAS Management Authorization Draft$B!$(Bthe added attribute > Management-Privilege-Level is an integer-valued attribute for use with > CLI access methods, I have a question about it, does it apply to the > Framed-Management-Protocol? The Management-Privilege-Level attribute was added to address a review comment and a long standing use case. In the -01 draft, we made it clear that the Management-Policy-Id attribute was to be a flat, simple name of local scope, and that the field was not to be overloaded with other kinds of elements, all in the name of good interoperability. To address a need that might have tempted vendors to overload the Management-Policy-Id attribute and to provide a way to provision a long standing CLI management parameter, we added the new attribute. The use case is that of integer valued-privilege level for CLI usages, as exemplified by the "enable' levels in Cisco's IOS. This use is common in other vendor's products, as well. I don't see any reason that the Management-Privilege-Level attribute could not be made applicable to Framed-Management sessions, but I don't see any compelling reason for doing so. Having it available as a matter of protocol symmetry might be nice, but is there actually a use case that it would support? > For example, in access control of SNMP protocol or Netconf protocol, is > it necessary to use the Management-Privilege-Level attribute? It seems to me that the named policy of Management-Policy-Id would be sufficient for uses such as SNMP or Netconf. Can you suggest a situation where it would be desirable to have an integer-valued parameter for provisioning access control via either of these methods? Regards, 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: From owner-radiusext@ops.ietf.org Tue Dec 18 09:54:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4dpr-00063Y-Ht for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 09:54:19 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4dpr-0000Ug-0K for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 09:54:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4dgZ-000Ffk-Pg for radiusext-data@psg.com; Tue, 18 Dec 2007 14:44:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4dgW-000FfP-NI for radiusext@ops.ietf.org; Tue, 18 Dec 2007 14:44:42 +0000 Received: (qmail 6931 invoked from network); 18 Dec 2007 09:44:30 -0500 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.3) by gumby.elbrysnetworks.com with SMTP; 18 Dec 2007 09:44:30 -0500 Message-ID: <4767DCD5.2070305@elbrysnetworks.com> Date: Tue, 18 Dec 2007 09:44:37 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli CC: radiusext@ops.ietf.org Subject: Re: Question on the Class attribute References: <4766C83C.8030606@azairenet.com> In-Reply-To: <4766C83C.8030606@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Vijay Devarapalli wrote: > I had a question on the Class attribute [RFC 2865]. What should > the RADIUS server do if the Class in the Access Accept message > that it sent does not match with the Accounting Request message > that comes later? Given that the RADIUS Accounting Server may be completely independent of the RADIUS Server, how would a RADIUS Accounting Server, in the most general case, be able to tell that the content of the Class attribute had been modified? What session identifier information from other RADIUS attributes would it use to make that determination? In the special case where the RADIUS Accounting Server is tightly coupled with the RADIUS Server and has a priori knowledge of sessions that the RADIUS Server has authorized, and therefore the intended value of the Class attribute, it might be possible to take some action. In these special cases it is not entirely clear what value exists in the Class attribute. Could you elaborate on a particular use case that exemplifies your concerns? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 13:33:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hG6-0008Kh-GU for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 13:33:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4hG4-0007bo-UV for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 13:33:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4h9P-000CHQ-TN for radiusext-data@psg.com; Tue, 18 Dec 2007 18:26:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [207.47.15.6] (helo=mail2.azairenet.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4h9M-000CGR-Kc for radiusext@ops.ietf.org; Tue, 18 Dec 2007 18:26:41 +0000 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 10:25:23 -0800 Message-ID: <47681092.8010706@azairenet.com> Date: Tue, 18 Dec 2007 10:25:22 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Question on the Class attribute References: <4766C83C.8030606@azairenet.com> <4767DCD5.2070305@elbrysnetworks.com> In-Reply-To: <4767DCD5.2070305@elbrysnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 18:25:23.0618 (UTC) FILETIME=[5AA33820:01C841A3] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi David, David B. Nelson wrote: > Vijay Devarapalli wrote: > >> I had a question on the Class attribute [RFC 2865]. What should >> the RADIUS server do if the Class in the Access Accept message >> that it sent does not match with the Accounting Request message >> that comes later? > > Given that the RADIUS Accounting Server may be completely independent of > the RADIUS Server, how would a RADIUS Accounting Server, in the most > general case, be able to tell that the content of the Class attribute > had been modified? What session identifier information from other > RADIUS attributes would it use to make that determination? It appears to me that RFC 2865 requires the class attribute, if used, to be the same in the Access Accept and the Accounting Request. I agree with you that if the Accounting Request goes to a different server from the one that sent the Access Accept message, this matching does not make sense. The use of this attribute also may not make sense. > In the special case where the RADIUS Accounting Server is tightly > coupled with the RADIUS Server and has a priori knowledge of sessions > that the RADIUS Server has authorized, and therefore the intended value > of the Class attribute, it might be possible to take some action. In > these special cases it is not entirely clear what value exists in the > Class attribute. I have no idea either. > Could you elaborate on a particular use case that exemplifies your > concerns? Our AAA server does not implement this attribute right now. We were asked to. I am trying to figure out what this attribute is about, where it is commonly used, etc... However, it looks like the RADIUS AAA server behavior when the value in the Class attribute in the Access Accept and Accounting Request does not match is unspecified. Vijay -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 13:47:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4hTj-00036z-BE for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 13:47:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4hTi-0007xO-VH for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 13:47:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4hNU-000DzO-JD for radiusext-data@psg.com; Tue, 18 Dec 2007 18:41:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4hNM-000Dy9-Kz for radiusext@ops.ietf.org; Tue, 18 Dec 2007 18:41:11 +0000 Received: (qmail 11316 invoked from network); 18 Dec 2007 13:41:07 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 18 Dec 2007 13:41:07 -0500 From: "David B. Nelson" To: "'Vijay Devarapalli'" Cc: References: <4766C83C.8030606@azairenet.com> <4767DCD5.2070305@elbrysnetworks.com> <47681092.8010706@azairenet.com> Subject: RE: Question on the Class attribute Date: Tue, 18 Dec 2007 13:39:02 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015d01c841a5$43152e50$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47681092.8010706@azairenet.com> Thread-Index: AchBo1t2nUFxp5o4TXWbk3cuyF0T4gAAGnoQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Vijay Devarapalli writes... > It appears to me that RFC 2865 requires the class attribute, if > used, to be the same in the Access Accept and the Accounting > Request. It requires that the RADIUS client (NAS or proxy) not change the content of Class, and that it be passed intact in the Accounting-Request messages. Class is a "cookie" between the RADIUS Server and the RADIUS Accounting server, much as State is a "cookie" between the RADIUS Server (e.g. Access-Challenge message) and the RADIUS Server (e.g. Access-Request message). > Our AAA server does not implement this attribute right now. We > were asked to. I am trying to figure out what this attribute is > about, where it is commonly used, etc... It is used to "bind" sessions, as authorized by a RADIUS Server, to accounting records, as logged on a RADIUS Accounting Server. > However, it looks like the RADIUS AAA server behavior when the > value in the Class attribute in the Access Accept and Accounting > Request does not match is unspecified. That is correct, primarily because in the most general case there is no way for the RADIUS Accounting Server to perform the "does it match" check. It takes the correct handling of the Class attribute by the NAS and by proxies on faith, as that behavior is specified in RFC 2865. There may be ways to detect broken behavior around the handling of Class attributes by means of manual inspection of the server records. There may be ways to automate the Class checking in the special case of a tightly bound RADIUS Server and RADIUS Accounting Server, but that is beyond the scope of RFC 2865 or RFC 2866. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 15:05:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4igq-0002Xk-0B for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 15:05:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4igp-0002ME-Ip for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 15:05:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4ia7-000MLj-9I for radiusext-data@psg.com; Tue, 18 Dec 2007 19:58:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.88] (helo=bay0-omc1-s16.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4iZl-000MKC-Gf for radiusext@ops.ietf.org; Tue, 18 Dec 2007 19:58:08 +0000 Received: from BAY117-W21 ([207.46.8.56]) by bay0-omc1-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 11:58:01 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_" X-Originating-IP: [131.107.0.102] From: Bernard Aboba To: Vijay Devarapalli , "David B. Nelson" CC: Subject: RE: Question on the Class attribute Date: Tue, 18 Dec 2007 11:58:00 -0800 Importance: Normal In-Reply-To: <47681092.8010706@azairenet.com> References: <4766C83C.8030606@azairenet.com> <4767DCD5.2070305@elbrysnetworks.com> <47681092.8010706@azairenet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Dec 2007 19:58:01.0244 (UTC) FILETIME=[4B3DA5C0:01C841B0] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It appears to me that RFC 2865 requires the class attribute, if> used, to= be the same in the Access Accept and the Accounting> Request. I agree with= you that if the Accounting Request goes to> a different server from the on= e that sent the Access Accept> message, this matching does not make sense. = The use of this> attribute also may not make sense. The Class attribute is designed to allow the RADIUS authentication server to provide information to be placed within accounting records. This is=20 typically most useful in situations where the accounting server may not have access to all the information which the authentication server has access to -- because if it did, why would the Class attribute be needed at = all?=20 =20 Accounting records need not even be handled by the same administrative doma= in=20 (let alone the same RADIUS authentication server). So the Class attribute = does not assume that the RADIUS authentication server and accounting server are the same entity. = --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It appears to me that RFC 2865 requires the class attribute, if
>= ; used, to be the same in the Access Accept and the Accounting
> Requ= est. I agree with you that if the Accounting Request goes to
> a diff= erent server from the one that sent the Access Accept
> message, this= matching does not make sense. The use of this
> attribute also may n= ot make sense.

The Class attribute is designed to allow the RADIUS authentication server to provide information to be placed within accounting records.  This i= s
typically most useful in situations where the accounting server may not
have access to all the information which the authentication server has
access to -- because if it did, why would the Class attribute be needed at = all?
 
Accounting records need not even be handled by the same administrative doma= in
(let alone the same RADIUS authentication server).  So the Class attri= bute does not
assume that the RADIUS authentication server and accounting server are the<= BR> same entity. 
= --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 18:21:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ll7-0007kb-QE for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 18:21:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ll6-0002cx-05 for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 18:21:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4ldp-000JxV-7S for radiusext-data@psg.com; Tue, 18 Dec 2007 23:14:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [207.47.15.6] (helo=mail2.azairenet.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4ldm-000Jwx-JQ for radiusext@ops.ietf.org; Tue, 18 Dec 2007 23:14:23 +0000 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Dec 2007 15:14:17 -0800 Message-ID: <47685448.70402@azairenet.com> Date: Tue, 18 Dec 2007 15:14:16 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Question on the Class attribute References: <4766C83C.8030606@azairenet.com> <4767DCD5.2070305@elbrysnetworks.com> <47681092.8010706@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2007 23:14:17.0882 (UTC) FILETIME=[B6A9FFA0:01C841CB] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Got it. Thanks for the responses. Vijay Bernard Aboba wrote: > > It appears to me that RFC 2865 requires the class attribute, if > > used, to be the same in the Access Accept and the Accounting > > Request. I agree with you that if the Accounting Request goes to > > a different server from the one that sent the Access Accept > > message, this matching does not make sense. The use of this > > attribute also may not make sense. > > The Class attribute is designed to allow the RADIUS authentication server > to provide information to be placed within accounting records. This is > typically most useful in situations where the accounting server may not > have access to all the information which the authentication server has > access to -- because if it did, why would the Class attribute be needed > at all? > > Accounting records need not even be handled by the same administrative > domain > (let alone the same RADIUS authentication server). So the Class > attribute does not > assume that the RADIUS authentication server and accounting server are the > same entity. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Dec 18 21:52:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4p2T-0004Fz-Le for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 21:52:05 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4p2S-0006HV-1F for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 18 Dec 2007 21:52:05 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4oxI-000HtV-RN for radiusext-data@psg.com; Wed, 19 Dec 2007 02:46:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4oxE-000Hqt-DS for radiusext@ops.ietf.org; Wed, 19 Dec 2007 02:46:42 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT9004EIZPQRC@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Wed, 19 Dec 2007 10:46:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JT9008TUZPP4Y@szxga03-in.huawei.com> for radiusext@ops.ietf.org; Wed, 19 Dec 2007 10:46:38 +0800 (CST) Received: from l67563 ([10.111.12.80]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JT9006EDZPOAI@szxml03-in.huawei.com> for radiusext@ops.ietf.org; Wed, 19 Dec 2007 10:46:37 +0800 (CST) Date: Wed, 19 Dec 2007 10:46:36 +0800 From: li chunxiu Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?= In-reply-to: <055501c8417f$9270fef0$031716ac@NEWTON603> To: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzw Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.7 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 > Li Chunxiu writes... > > In the RADIUS NAS Management Authorization Draft=A3=ACthe added = attribute > > Management-Privilege-Level is an integer-valued attribute for use = with > > CLI access methods, I have a question about it, does it apply to the > > Framed-Management-Protocol? > The Management-Privilege-Level attribute was added to address a review > comment and a long standing use case. > In the -01 draft, we made it clear that the Management-Policy-Id = attribute > was to be a flat, simple name of local scope, and that the field was = not to > be overloaded with other kinds of elements, all in the name of good > interoperability. To address a need that might have tempted vendors = to > overload the Management-Policy-Id attribute and to provide a way to > provision a long standing CLI management parameter, we added the new > attribute. > The use case is that of integer valued-privilege level for CLI usages, = as > exemplified by the "enable' levels in Cisco's IOS. This use is common = in > other vendor's products, as well. > I don't see any reason that the Management-Privilege-Level attribute = could > not be made applicable to Framed-Management sessions, but I don't see = any > compelling reason for doing so. Having it available as a matter of protocol > symmetry might be nice, but is there actually a use case that it would > support? >=20 > > For example, in access control of SNMP protocol or Netconf protocol, = is > > it necessary to use the Management-Privilege-Level attribute? >=20 > It seems to me that the named policy of Management-Policy-Id would be > sufficient for uses such as SNMP or Netconf. Can you suggest a = situation > where it would be desirable to have an integer-valued parameter for > provisioning access control via either of these methods? >=20 Here is a situation: 1.NETCONF access, defined by a policy: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D " Read-only group1" 2. NETCONF access, defined by a policy: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D "group1 Read-only" 3. NETCONF access, defined by a policy, with the = Management-Privilege-Level attribute: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D "group1 " * Management-Privilege-Level (xx) =3D 15=20 Comment:15 denotes Read-only=20 16 denotes create ... ... I think the 3rd example using the Management-Privilege-Level attribute clarifies the use methods of Management-Privilege-Level attribute.=20 What is your opinion? Regards,=20 Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 19 02:46:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4tdf-0000qI-0R for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 02:46:47 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4tdd-00052u-7P for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 02:46:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4tZQ-000H6U-0R for radiusext-data@psg.com; Wed, 19 Dec 2007 07:42:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4tZ2-000Gx9-SU for radiusext@ops.ietf.org; Wed, 19 Dec 2007 07:42:12 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AD508A1CF; Wed, 19 Dec 2007 08:41:59 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25591-03; Wed, 19 Dec 2007 08:41:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63A218A1CA; Wed, 19 Dec 2007 08:41:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 39E1742D1AD; Wed, 19 Dec 2007 08:41:53 +0100 (CET) Date: Wed, 19 Dec 2007 08:41:53 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: ????: a question about Management Authorization -01 document Message-ID: <20071219074153.GA4146@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org References: <055501c8417f$9270fef0$031716ac@NEWTON603> <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Wed, Dec 19, 2007 at 10:46:36AM +0800, li chunxiu wrote: > Here is a situation: > 1.NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = " Read-only group1" > 2. NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 Read-only" > 3. NETCONF access, defined by a policy, with the Management-Privilege-Level > attribute: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 " > * Management-Privilege-Level (xx) = 15 > Comment:15 denotes Read-only > 16 denotes create ... ... > I think the 3rd example using the Management-Privilege-Level attribute > clarifies the use methods of Management-Privilege-Level attribute. > What is your opinion? Since NETCONF right now does not have a defined access control system, the discussion is kind of pointless since implementations can do whatever they like. That said, let me say that I personally find a combination of Management-Policy-Id and Management-Privilege-Level somewhat strange. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 19 09:05:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zYN-0001W0-PA for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 09:05:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zYL-0006FP-Up for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 09:05:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4zQ8-000Kgv-UQ for radiusext-data@psg.com; Wed, 19 Dec 2007 13:57:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J4zQ5-000KgV-Aw for radiusext@ops.ietf.org; Wed, 19 Dec 2007 13:57:10 +0000 Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id SdsG1Y0070vp7WL0A00S00; Wed, 19 Dec 2007 13:57:14 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id Sdx71Y00124Kx1C8R00000; Wed, 19 Dec 2007 13:57:14 +0000 X-Authority-Analysis: v=1.0 c=1 a=knlbeGU9GrsA:10 a=ohe3yhbBh23Zk4xHBbAA:9 a=pxxV0blu0wRMVBCgsj9z9bKL_o8A:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: "'li chunxiu'" , References: <055501c8417f$9270fef0$031716ac@NEWTON603> <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> Subject: RE: a question about Management Authorization -01 document Date: Wed, 19 Dec 2007 08:57:01 -0500 Message-ID: <06e901c84247$086977a0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> Thread-Index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzwABbisZA= Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 > Li Chunxiu writes... > Here is a situation: > 1.NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = " Read-only group1" I take it that in this example the Management-Policy-Id is composed of two separate elements, "Read-only" which provides an over-riding access control policy of read only, and "group1", which provides some other access control policy, perhaps based on access to certain branches of the management tree. This is exactly the type of implementation that we discourage in the -01 text. The content of Management-Policy-Id should be exactly one name of a policy of local scope to the NAS. It should not be composed of sub-strings, each of which separately names a different policy element. You could certainly have a local policy named "read-only-group1" and another named "read-write-group1". That might accomplish your objective. > 3. NETCONF access, defined by a policy, with the Management-Privilege- > Level > attribute: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 " > * Management-Privilege-Level (xx) = 15 > Comment:15 denotes Read-only > 16 denotes create ... ... This could be workable, in that the Management-Policy-Id is restricted to a single, flat name of local scope (no sub-fields). It is possible to define a scenario in which two access control provisioning attributes are used in the same Access-Accept, but... It would be necessary to define the precedence relationship between them, should there be any conflicts in the underlying access control rules that would result from application of the polices in the NAS. That is also feasible to do. > I think the 3rd example using the Management-Privilege-Level attribute > clarifies the use methods of Management-Privilege-Level attribute. > What is your opinion? My question is whether it is necessary to support the application of two (or more) separately defined (and named) access control policies in the NAS at one time? In any case where multiple, separate policies are applied, it is also possible to create a single name for the combined policy. Of course, if there are a large number of such sub-policies that can be combined, the number of unique, flat names to represent them becomes combinatorially large. However, I think it is a true statement that organizations using a form of role-based access control policy will typically only define a hand-full of really distinct roles. For that reason, I think that the "mix-and-match" capability of provisioning multiple local policies via RADIUS, either in separate attributes or as sub-elements of a single attribute, creates added complexity disproportionate to the practical value. But that's just my opinion. The only use case that I can come up with in which it might be beneficial to apply disparate, separately named management policies in a single Access-Accept is the proxy RADIUS case, in which the operator of NAS and the first hop proxy RADIUS server may wish to overlay restrictions on the access control provisioned by the operator of the home RADIUS server. Unless these policies are well coordinated, and the precedence relationships well specified, the result may be unpredictable. I tend to agree with Juergen Schoenwaelder's comments on whether this kind of approach will ever be required by NETCONF. However, if the WG members think that addressing the proxy RADIUS server (e.g. the access outsourcing) use case is important, we could do that, in a couple of different ways. Comments on this? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 19 22:13:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5BqT-0001E1-RP for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 22:13:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5BqS-0006Qt-4i for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 19 Dec 2007 22:13:13 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5Blh-0007c2-BS for radiusext-data@psg.com; Thu, 20 Dec 2007 03:08:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5BlX-0007b8-Mh for radiusext@ops.ietf.org; Thu, 20 Dec 2007 03:08:16 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTB005N9VDGEI@szxga01-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 11:08:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTB009NTVDGM7@szxga01-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 11:08:04 +0800 (CST) Received: from l67563 ([10.111.12.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JTB003KEVDF1X@szxml04-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 11:08:04 +0800 (CST) Date: Thu, 20 Dec 2007 11:08:03 +0800 From: li chunxiu Subject: RE: a question about Management Authorization -01 document In-reply-to: <06e901c84247$086977a0$031716ac@NEWTON603> To: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000001c842b5$89489bd0$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzwABbisZAAGy1/IA== Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 > Dave writes... > I take it that in this example the Management-Policy-Id is composed of two > separate elements, "Read-only" which provides an over-riding access control > policy of read only, and "group1", which provides some other access control > policy, perhaps based on access to certain branches of the management tree. > This is exactly the type of implementation that we discourage in the -01 > text. The content of Management-Policy-Id should be exactly one name of a > policy of local scope to the NAS. It should not be composed of sub-strings, > each of which separately names a different policy element. You could > certainly have a local policy named "read-only-group1" and another named > "read-write-group1". That might accomplish your objective. I agree with the point of view of a local policy named "read-only-group1" and another named "read-write-group1". If the Access Control is mainly done in NAS, the Access Control policy in Radius may be very simple, and the pattern of "read-only-group1" is ok. If the Radius needs to participate in the Access Control, there may be some complicate policies. If the policies are too complicated to be expressed in one Management-Policy-Id, which expression is better? Will the policies be separated to several parts in each Management-Policy-Id within each Access-Accept? And these parts will be composed to be whole policies in the NAS to accomplish the Access Control, right? > This could be workable, in that the Management-Policy-Id is restricted to a > single, flat name of local scope (no sub-fields). It is possible to define > a scenario in which two access control provisioning attributes are used in > the same Access-Accept, but... It would be necessary to define the > precedence relationship between them, should there be any conflicts in the > underlying access control rules that would result from application of the > polices in the NAS. That is also feasible to do. This needs to be researched. > The only use case that I can come up with in which it might be beneficial to > apply disparate, separately named management policies in a single > Access-Accept is the proxy RADIUS case, in which the operator of NAS and the > first hop proxy RADIUS server may wish to overlay restrictions on the access > control provisioned by the operator of the home RADIUS server. Unless these > policies are well coordinated, and the precedence relationships well > specified, the result may be unpredictable. I agree. Comments on this? Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 20 02:40:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5G0u-00021H-Cx for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 02:40:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5G0s-0001kf-LJ for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 02:40:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5FtQ-000L8t-4l for radiusext-data@psg.com; Thu, 20 Dec 2007 07:32:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5FsQ-000L59-Qo for radiusext@ops.ietf.org; Thu, 20 Dec 2007 07:31:42 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A79E8A1CA; Thu, 20 Dec 2007 08:31:29 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17237-06; Thu, 20 Dec 2007 08:31:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FA658A1D3; Thu, 20 Dec 2007 08:31:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4825D42E17F; Thu, 20 Dec 2007 08:31:21 +0100 (CET) Date: Thu, 20 Dec 2007 08:31:21 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: a question about Management Authorization -01 document Message-ID: <20071220073121.GA5258@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org References: <06e901c84247$086977a0$031716ac@NEWTON603> <000001c842b5$89489bd0$500c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c842b5$89489bd0$500c6f0a@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Thu, Dec 20, 2007 at 11:08:03AM +0800, li chunxiu wrote: > I agree with the point of view of a local policy named "read-only-group1" > and another named "read-write-group1". > If the Access Control is mainly done in NAS, the Access Control policy in > Radius may be very simple, and the pattern of "read-only-group1" is ok. > If the Radius needs to participate in the Access Control, there may be some > complicate policies. If the policies are too complicated to be expressed in > one Management-Policy-Id, which expression is better? Will the policies be > separated to several parts in each Management-Policy-Id within each > Access-Accept? And these parts will be composed to be whole policies in the > NAS to accomplish the Access Control, right? Section 4 defines the purpose and scope of the access control policy attributes. In particular, note that the Management-Policy-Id and Management-Privilege-Level attributes are not meant to carry accress control rules; they merely identify which locally known access control rules to apply. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 20 03:27:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Gl5-0002lg-Nq for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 03:27:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5Gl4-0002QO-AR for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 03:27:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5Gf3-000OEP-CB for radiusext-data@psg.com; Thu, 20 Dec 2007 08:21:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5Geq-000OCr-Lt for radiusext@ops.ietf.org; Thu, 20 Dec 2007 08:21:44 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC008I69VV5P@szxga01-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 16:21:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC00IGY9VQI7@szxga01-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 16:21:31 +0800 (CST) Received: from l67563 ([10.111.12.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JTC0009S9VQPC@szxml04-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 16:21:26 +0800 (CST) Date: Thu, 20 Dec 2007 16:21:26 +0800 From: li chunxiu Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?= In-reply-to: <20071220073121.GA5258@elstar.local> To: j.schoenwaelder@jacobs-university.de Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000001c842e1$50892860$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Thread-index: AchC2lz2O38NQyeLSwaHW+9eNJ29bwABYp0g Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.7 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 > > I agree with the point of view of a local policy named "read-only-group1" > > and another named "read-write-group1". > > If the Access Control is mainly done in NAS, the Access Control policy in > > Radius may be very simple, and the pattern of "read-only-group1" is ok. > > If the Radius needs to participate in the Access Control, there may be some > > complicate policies. If the policies are too complicated to be expressed in > > one Management-Policy-Id, which expression is better? Will the policies be > > separated to several parts in each Management-Policy-Id within each > > Access-Accept? And these parts will be composed to be whole policies in the > > NAS to accomplish the Access Control, right? > > Section 4 defines the purpose and scope of the access control policy > attributes. In particular, note that the Management-Policy-Id and > Management-Privilege-Level attributes are not meant to carry accress > control rules; they merely identify which locally known access control > rules to apply. Thank you for clarify this two concepts. But in the SNMP/Netconf Access Control process, there are 3 entities, agent, NAS and Radius server. Could you please explain how to define the "local scope" concept? Thanks, Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 20 03:36:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Gsu-0008NR-1x for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 03:36:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5Gst-0002Zn-Km for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 03:36:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5GmR-000OdW-Ld for radiusext-data@psg.com; Thu, 20 Dec 2007 08:29:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5Gm4-000Obz-1p for radiusext@ops.ietf.org; Thu, 20 Dec 2007 08:29:12 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 301468A20E; Thu, 20 Dec 2007 09:28:59 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21703-04-49; Thu, 20 Dec 2007 09:28:54 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0158A211; Thu, 20 Dec 2007 09:28:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC80442E2D5; Thu, 20 Dec 2007 09:28:25 +0100 (CET) Date: Thu, 20 Dec 2007 09:28:25 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: ????: a question about Management Authorization -01 document Message-ID: <20071220082825.GA5307@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org References: <20071220073121.GA5258@elstar.local> <000001c842e1$50892860$500c6f0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c842e1$50892860$500c6f0a@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Thu, Dec 20, 2007 at 04:21:26PM +0800, li chunxiu wrote: > But in the SNMP/Netconf Access Control process, there are 3 entities, agent, > NAS and Radius server. Could you please explain how to define the "local > scope" concept? For me, the agent and the NAS are effectively the same thing. From the SNMP perspective, a manager talks to an agent. From a RADIUS perspective, the agent acts as a NAS to the RADIUS server. See also draft-ietf-isms-radius-usage-01.txt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 20 05:09:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5IL6-0008Dl-Ex for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 05:09:16 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5IL5-0004ys-R8 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 05:09:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5IDO-0004H8-Mc for radiusext-data@psg.com; Thu, 20 Dec 2007 10:01:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5IDH-0004Ga-P7 for radiusext@ops.ietf.org; Thu, 20 Dec 2007 10:01:17 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC00D9WEHUPA@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 18:01:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC00EIKEHUWJ@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 18:01:06 +0800 (CST) Received: from l67563 ([10.111.12.80]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JTC006ISEHSEN@szxml04-in.huawei.com> for radiusext@ops.ietf.org; Thu, 20 Dec 2007 18:01:06 +0800 (CST) Date: Thu, 20 Dec 2007 18:01:04 +0800 From: li chunxiu Subject: Re:a question about Management Authorization -01 document In-reply-to: <20071220082825.GA5307@elstar.local> To: j.schoenwaelder@jacobs-university.de Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000a01c842ef$3c27aff0$500c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchC4lvIjVECTnqvSLS588WEMxtk7QAA/liw Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > j/s wrote: > > But in the SNMP/Netconf Access Control process, there are 3 entities, agent, > > NAS and Radius server. Could you please explain how to define the "local > > scope" concept? > > For me, the agent and the NAS are effectively the same thing. From the > SNMP perspective, a manager talks to an agent. From a RADIUS > perspective, the agent acts as a NAS to the RADIUS server. See also > draft-ietf-isms-radius-usage-01.txt. Maybe there is need to define the "local scope" concept in the draft-ietf-radext-management-authorization-01. Regards Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 20 08:24:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5LOA-0006Zl-Hl for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 08:24:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5LOA-0008UL-3G for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 20 Dec 2007 08:24:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5LHF-000G6c-IH for radiusext-data@psg.com; Thu, 20 Dec 2007 13:17:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.64] (helo=QMTA07.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J5LGk-000G5M-7x for radiusext@ops.ietf.org; Thu, 20 Dec 2007 13:17:13 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id T0DV1Y0060QuhwU0505N00; Thu, 20 Dec 2007 13:16:57 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.westchester.pa.mail.comcast.net with comcast id T1Gt1Y00624Kx1C3N00000; Thu, 20 Dec 2007 13:16:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=knlbeGU9GrsA:10 a=M0EIhFcGWMOsd4FfCdgA:9 a=0FfgLq2VS6eNO-1ZTEDMYBMJYDsA:4 a=DLWQtoLnVnAA:10 From: "David B. Nelson" To: Cc: "'li chunxiu'" References: <20071220082825.GA5307@elstar.local> <000a01c842ef$3c27aff0$500c6f0a@china.huawei.com> Subject: RE: a question about Management Authorization -01 document Date: Thu, 20 Dec 2007 08:16:56 -0500 Message-ID: <002701c8430a$98e46ce0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000a01c842ef$3c27aff0$500c6f0a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AchC4lvIjVECTnqvSLS588WEMxtk7QAA/liwAAijE0A= Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Li Chunxiu writes... > Maybe there is need to define the "local scope" concept in the > draft-ietf-radext-management-authorization-01. We could certainly do that. I'll add that to the issues list. It works exactly like the Filter-Id attribute, which also relies on rules of local scope. Therefore, it's a well understood RADIUS operational paradigm. The rules are provisioned on all that NASes that are likely to need to know and apply them by some out of band means, such as via a MIB using SNMP, via the CLI or via FTP. Note that there is work in RADEXT to define attributes that supplement Filter-Id by provisioning and defining the rules at the same time. That is to say, defining a RADIUS filter rule attribute that actually contains the rules. This work leverages work done previously for Diameter. See RFC 4849. So far, there has been no effort to define similar self-contained management policy rules. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Dec 22 12:44:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J68P1-0006vA-Ns for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 22 Dec 2007 12:44:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J68Ov-0003Ut-FM for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 22 Dec 2007 12:44:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J68IF-000Mt7-2v for radiusext-data@psg.com; Sat, 22 Dec 2007 17:37:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.157] (helo=bay0-omc2-s21.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J68Hl-000MqO-OJ for radiusext@ops.ietf.org; Sat, 22 Dec 2007 17:37:32 +0000 Received: from BAY117-W20 ([207.46.8.55]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Dec 2007 09:37:13 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_850a5faa-11aa-4c9f-9f82-831ac36344fd_" X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Subject: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sat, 22 Dec 2007 09:37:13 -0800 Importance: Normal In-Reply-To: <20071221231446.GB5266@isi.edu> References: <20071107005849.GC28431@isi.edu> <20071117011304.GD9206@isi.edu> <20071121203436.GC17076@isi.edu> <1DDB0D3CC4E7F14FAE946361C0A6065504773089@isr-jlm-mail.Kayote.com> <20071126224034.GB21472@isi.edu> <1DDB0D3CC4E7F14FAE946361C0A606550477353E@isr-jlm-mail.Kayote.com> <20071210182633.GC2054@isi.edu> <1DDB0D3CC4E7F14FAE946361C0A606550483EA8B@isr-jlm-mail.Kayote.com> <20071214225110.GE21923@isi.edu> <20071221231446.GB5266@isi.edu> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2007 17:37:13.0365 (UTC) FILETIME=[49909C50:01C844C1] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 91a4853b4617d3c1ce94290cc3eeb886 --_850a5faa-11aa-4c9f-9f82-831ac36344fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 4590bis is now being held in AUTH48, pending final verification.=20 What started as a "simple" IANA-problem fix has turned into a longer odysse= y due to the=20 discovery of additional errors/omissions. =20 In attempt to bring this story to a close, we need to make very sure that w= e have looked over this document carefully so that we don't have to go through this again with= RFC 4590ter.=20 So if you have ever had any interest in RADIUS Digest Authentication, now w= ould be the time to look over the AUTH48 version of the document, and speak up if there is a= problem. =20 > Date: Fri, 21 Dec 2007 15:14:46 -0800 > From: rfc-editor@rfc-editor.org > To: beckw@t-systems.com > CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; dscreat@dscre= at.com; dwilli@cisco.com; dromasca@avaya.com; rbonica@juniper.net; d.b.nels= on@comcast.net; bernard_aboba@hotmail.com; rfc-editor@rfc-editor.org > Subject: Re: AUTH48 [SG]: RFC 5090 = NOW AVAILABLE >=20 > Greeings Wolfgang, >=20 > Just a reminder that we are waiting to hear from you before continuing > on with the publication process. >=20 > Please see the email below for document information. >=20 > Thank you. >=20 > RFC Editor >=20 > On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > > Hi Wolfgang, > >=20 > > Just a friendly reminder that we are waiting to hear from you before > > continuing on with the publication process for RFC 5090 > > . =20 > >=20 > > Please review the files located at: > >=20 > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > >=20 > > Note that this diff file highlights only the differences between the > > last posted version of the document and the current text file. The > > previously posted versions (during AUTH48) are available as: > >=20 > > The originally posted AUTH48 files: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > >=20 > > Version 2 (includes author updates) of AUTH48 files: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > > Note that this file highlights only the differences between the > > version 1 and 2 text files. > >=20 > > We will wait to hear from you before continuing on with the > > publication process. > >=20 > > Thank you. > >=20 > > RFC Editor/sg > >=20 > >=20 > > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > > >=20 > > > I also talked to Wolfgang at IETF 70. He wanted to check the documen= t over carefully to make sure there > > > were no further issues. > Subject: RE: AUTH48 [SG]: RFC 5090 NOW AVAILABLE> Date: Mon, 10 Dec 2007 20:30= :51 +0200> From: Baruch.Sterman@Kayote.com> To: rfc-editor@rfc-editor.org; = beckw@t-systems.com> CC: david.schwartz@xconnect.net; dscreat@dscreat.com; = dwilli@cisco.com; dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@ho= tmail.com; d.b.nelson@comcast.net> > Yes,> > David Schwartz saw him at the = ietf meeting and worked through the draft> with him. I think we should be h= earing from him soon.> > Baruch> > > -----Original Message-----> From: RFC = Editor [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, December 10, 2007= 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> Cc: David Schwartz; RFC = Editor; dscreat@dscreat.com; dwilli@cisco.com;> Dan Romascanu; Ronald Bonic= a; Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: AUTH48 = [SG]: RFC 5090 > NOW AVAILABLE> > All,= > > Just checking to see if you have had any luck contacting Wolfgang?> > T= hanks!> > RFC Editor/sg> > On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch= Sterman wrote:> > David Schwartz will be at the IETF meetings next week. M= aybe Wolfgang> > will be there and he can nudge him to answer. Lets hold of= f until we> see> > if that way forward works. If not, we can go with option= 3.> > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > F= rom: RFC Editor [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, Novem= ber 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> > Subject: R= e: AUTH48 [SG]: RFC 5090> > > NOW AVAI= LABLE> > > > Hi Baruch,> > > > We have a couple of ways to move forward.> >= > > 1. The author can be removed as an author, and moved to the> > Acknowl= edgements section.> > > > 2. We can create a Contributor's section and have= him listed there.> > > > 3. We can request that the AD approve the documen= t in place of the> > unavailabe author. > > > > Option 3 has been done befo= re in instances where the missing author> > made sizeable contributions to = the document, so the other authors> > did not feel comfortable removing the= individuals name as an> > author. > > > > It sounds as though 3 may be the= proper way forward. If this is the> > case, we will send an email to the A= Ds requesting their approval in> > place of Wolfgang (the message will be c= c'ed to all relevant> > parties, including Wolfgang). > > > > If the above = suggestions are unacceptable and you have an alternative> > solution, pleas= e let us know. > > > > Thank you.> > > > RFC Editor> > > > On Mon, Nov 26, = 2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I wrote to Wolfgang as= well, but got no response. What is the> > procedure> > > in this case? I a= m sure that Wolfgang would be ok with the changes.> > The> > > last email I= received was on October 19 where he said that he had> made> > > the one co= rrection (suggested by Ellermann) in the cnonce value. > > > > > > Baruch> = > > > > > > > > -----Original Message-----> > > From: RFC Editor [mailto:rf= c-editor@rfc-editor.org] > > > Sent: Wednesday, November 21, 2007 10:35 PM>= > > To: David Williams; Baruch Sterman; dscreat@dscreat.com; David> > Schw= artz;> > > beckw@t-systems.com> > > Cc: radext-ads@tools.ietf.org; radext-c= hairs@tools.ietf.org; RFC> > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090= > > > > > NOW AVAILABLE> > > > > > Gre= etings Wolfgang,> > > > > > We do not believe we have received your respons= e regarding this> > > document's readiness for publication as an RFC. Pleas= e review the> > > text and let us know if you are content with the document= as it now> > > appears at:> > > > > > ftp://ftp.rfc-editor.org/in-notes/au= thors/rfc5090.txt> > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-di= ff.html> > > Note that this diff file highlights only the changes between t= he> last > > > posted version of the document and the current text file.> >= > > > > > > > The last versions of the document are available as:> > > > >= > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > > ftp://ftp.r= fc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > > > > ftp://ftp.rfc= -editor.org/in-notes/authors/rfc5090v2.txt> > > ftp://ftp.rfc-editor.org/in= -notes/authors/rfc5090v2-diff.html> > > Note that this diff file highlights= only the changes between v1 and> > > the v2.> > > > > > We will wait to he= ar from you before continuing on with the> > > publication process.> > > > = > > Thank you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at 05:= 13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We have cor= rected the text as indicated below and posted the> revised> > > > version o= f the document at:> > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors= /rfc5090.txt> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.= html> > > > Note that this diff file highlights only the changes betwee the= > last> > > > > > posted version of the document and the current text file.= > > > > > > > > Please review the document and let us know if you approve t= his> > > > text for publication.> > > > > > > > We believe we are waiting f= or the following approvals:> > > > > > > > Baruch Sterman - done > > > > Da= niel Sadolevsky - done> > > > David Schwartz - done> > > > David Williams> = > > > Wolfgang Beck> > > > > > > > Bernard Aboba - done> > > > > > > > > > = > > Thank you.> > > > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov= 06, 2007 at 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > >= > > > > > Please confer and let us know how the text should/should not use= > > the> > > > > quote marks. It sounds as though this email was for discus= sion.> > If> > > > > the changes below are acceptable, we will make the cha= nges and> > post> > > a> > > > > revised version of the document.> > > > > = > > > > > Also, please note the following status of document approvals:> > = > > > > > > > > Baruch Sterman - done (although we would like to know if yo= u> agree> > > > > with the changes described below)> > > > > Daniel Sadolev= sky - done> > > > > David Schwartz> > > > > David Williams> > > > > Wolfgan= g Beck> > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will w= ait to hear further before continuing on with the> > > publication> > > > >= process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor> > > = > > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Wil= liams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > > These look good, = and I agree with your consistency comment. I> > > have a few > > > > > > mo= re specific changes to suggest that I would like you and> > others> > > to = > > > > > > review as well. But first a couple of general style comments> >= that> > > require > > > > > > no changes to the document.> > > > > > > > >= > > > General comment #1: I tried to find a definitive style guide> to> > = > use of > > > > > > single quotes versus double quotes and found there is = no hard> > > guidelines, > > > > > > that consistency is most important:> >= > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > > http://foru= m.wordreference.com/showthread.php?t=3D120946> > > > > > Though I tend to t= hink that double quotes are more commonly> used> > > and match > > > > > > = the syntax of more popular programming languages, but there> are> > so> > >= many > > > > > > quoted items in the document and it has been this way for= a> long> > > time, so > > > > > > best to leave as is.> > > > > > > > > > = > > General comment #2: When refering to responses from the radius> > > ser= ver > > > > > > there are a lot of instances of a comment similiar to "with= out> > > surrounding > > > > > > quotes" that potentially could be removed = for readability.> > > Especially if > > > > > > there were a more concise d= efinition up-front about the> general> > > form of > > > > > > values retur= ned from the radius server. But I am a little> > > hesitant to > > > > > > = just strip them out now.> > > > > > > > > > > > Specific comments, to build= on top of your list:> > > > > > > > > > > > In section 2.1.2, 1st paragrap= h should not have quotes around> > > nonce. > > > > > > Paragraph should re= ad:> > > > > > > > > > > > If a matching (Proxy-)Authorization header is pr= esent and> > > contains> > > > > > HTTP Digest information, the RADIUS clie= nt checks the nonce> > > > > > parameter.> > > > > > > > > > > > In next pa= ragraph, do not need quotes around response.> > Paragraph> > > should > > >= > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the non= ce, it takes the> > header> > > > > > directives and puts them into a RADIU= S Access-Request> packet.> > > It> > > > > > puts the response directive in= to a Digest-Response> attribute> > > and> > > > > > the realm, nonce, diges= t-uri, qop, algorithm, cnonce, nc,> > > username,> > > > > > and opaque dir= ectives into the respective Digest-Realm,> > > Digest-Nonce,> > > > > > Dig= est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > >= > Nonce-Count, Digest-Username, and Digest-Opaque attributes.> > > The> > = > > > > RADIUS client puts the request method into the> Digest-Method> > > = > > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to the= items you point out, in> the> > > last > > > > > > paragraph, nextnounce d= oes not need quoting. Paragraph> should> > > read:> > > > > > > > > > > > W= hen the RADIUS server provides a Digest-Nextnonce> attribute> > in> > > the= > > > > > > Access-Accept packet, the RADIUS client puts the contents> of> = > > this> > > > > > attribute into a nextnonce directive. Now it can send a= n> > HTTP-> > > > > > style response.> > > > > > > > > > > > In section 2.1= .4, 2nd paragraph, the stale directive should> not> > > need > > > > > > qu= oting. Paragraph should read:> > > > > > > > > > > > If the RADIUS client r= eceives an Access-Challenge packet in> > > response> > > > > > to an Access= -Request containing a Digest-Nonce attribute,> the> > > RADIUS> > > > > > s= erver did not accept the nonce. If a Digest-Stale> attribute> > > is> > > >= > > present in the Access-Challenge and has a value of 'true'> > > (withou= t> > > > > > surrounding quotes), the RADIUS client sends an error> > respo= nse> > > (401> > > > > > or 407) containing a WWW-/Proxy-Authenticate heade= r with> the> > > > > > directive stale and the digest directives derived fr= om the> > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I= think the wording of the last sentence in this same> > > paragraph > > > >= > > could be improved. So that the paragraph reads more like:> > > > > > >= > > > > > If the RADIUS client receives an Access-Challenge packet in> > >= response> > > > > > to an Access-Request containing a Digest-Nonce attribu= te,> the> > > RADIUS> > > > > > server did not accept the nonce. If a Diges= t-Stale> attribute> > > is> > > > > > present in the Access-Challenge and h= as a value of 'true'> > > (without> > > > > > surrounding quotes), the RADI= US client sends an error> > response> > > (401> > > > > > or 407) containin= g a WWW-/Proxy-Authenticate header with> the> > > > > > stale directive set= to 'true' and the digest directives> > derived> > > from> > > > > > the Di= gest-* attributes.> > > > > > > > > > > > In section 3.10, 1st paragraph, I= believe the term "qop-level"> > is> > > ill > > > > > > defined and should= not be used, that qop directive or> qop-value> > > would be > > > > > > be= tter. In other words the paragraph should read:> > > > > > > > > > > > When= using the qop-value 'auth-int', a hash of the> > > HTTP-style> > > > > > m= essage body's contents is required for digest> > > calculation.> > > > > > = Instead of sending the complete body of the message,> > only> > > its> > > = > > > hash value is sent. This hash value can be used> > directly> > > in> = > > > > > the digest calculation.> > > > > > > > > > > > In section 3.15, a= uth-param doesn't need quoting. So that the> > > paragraph > > > > > > beco= mes:> > > > > > > > > > > > This attribute is a placeholder for future exte= nsions> > and> > > > > > corresponds to the auth-param parameter defined in= > > > Section> > > > > > 3.2.1 of [RFC2617]. The Digest-Auth-Param is the> = > > mechanism> > > > > > whereby the RADIUS client and RADIUS server can> >= exchange> > > auth-> > > > > > param extension parameters contained within= Digest> > > headers that> > > > > > are not understood by the RADIUS clien= t and for which> > > there are> > > > > > no corresponding stand-alone attr= ibutes.> > > > > > > > > > > > In section 3.17, domain doesn't need quoting= . So that the> > > paragraph > > > > > > becomes:> > > > > > > > > > > > Wh= en a RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > > = > MAY send one or more Digest-Domain attributes in its> > > Access-> > > > = > > Challenge packet. The RADIUS client puts them into> the> > > quoted,> >= > > > > space-separated list of URIs of the domain directive> of> > a> > >= > > > WWW-Authenticate header. Together with Digest-Realm,> > the> > > URI= s> > > > > > in the list define the protection space (see> [RFC2617],> > > = Section> > > > > > 3.2.1) for some HTTP-style protocols. This attribute> > = > MUST only> > > > > > be used in Access-Challenge and Accounting-Request> = > > packets.> > > > > > > > > > > > In section 3.19, 1st paragraph, in addt= ion to no quotes around> > > rspauth as > > > > > > you pointed out, I beli= eve there should be no quotes around> qop.> > > So that > > > > > > the par= agraph reads:> > > > > > > > > > > > This attribute is used to allow the ge= neration of an> > > > > > Authentication-Info header, even if the HTTP-styl= e> > > response's> > > > > > body is required for the calculation of the rs= pauth> > > value.> > > > > > It SHOULD be used in Access-Accept packets if = the> > > required> > > > > > quality of protection (qop) is 'auth-int'.> > = > > > > > > > > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri= , 19 Oct 2007, 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After = lengthy discussions with my father-in-law who is a> > > professor of> > > >= > > >English, I agree with Dave's method of using quotes only in> the> > >= value of> > > > > > >an attribute/directive, but not in referencing the> >= > attribute/directive> > > > > > >by name. As such, I have some changes.> = > > > > > >> > > > > > >In section 2.1.3 3rd paragraph should not have quot= es around> > the> > > word> > > > > > >rspauth. Sentence should read:> > > = > > > >> > > > > > > * If the Digest-Qop attribute's value is 'auth' or not= > > > specified,> > > > > > > the RADIUS client puts the Digest-Response-Au= th> > > attribute's> > > > > > > content into the Authentication-Info heade= r's rspauth> > > > > > > directive of the HTTP-style response.> > > > > > >= > > > > > > >Same section 5th paragraph - no quotes around qop and> > algor= ithm:> > > > > > >> > > > > > > o If the Access-Accept packet contains a Di= gest-HA1> > attribute,> > > the> > > > > > > RADIUS client checks the qop a= nd algorithm directives in> > the> > > > > > > Authorization header of the = HTTP-style request it wants> to> > > > > > > authorize:> > > > > > >> > > >= > > >Next paragraph - no quotes around qop> > > > > > >> > > > > > > * If = the qop directive is missing or its value is> 'auth',> > > the> > > > > > >= RADIUS client ignores the Digest-HA1 attribute. It> > does> > > not> > > >= > > > include an Authentication-Info header in its> HTTP-style> > > > > > = > response.> > > > > > >> > > > > > >Next paragraph - no quotes around qop = or rspauth.> > > > > > >> > > > > > > * If the qop directive's value is 'au= th-int' and at> least> > > one> > > > > > > of the following conditions is = true, the RADIUS> client> > > > > > > calculates the contents of the HTTP-s= tyle response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > > = > >> > > > > > >2 paragraphs later - no quotes around rspauth> > > > > > >>= > > > > > > The RADIUS client creates the HTTP-style response> > message> = > > and> > > > > > > calculates the hash of this message's body. It uses> >= the> > > result> > > > > > > and the Digest-URI attribute's value of the> = > corresponding> > > > > > > Access-Request packet to perform the H(A2)> ca= lculation.> > > It> > > > > > > takes the Digest-Nonce, Digest-Nonce-Count,= > > > Digest-CNonce, and> > > > > > > Digest-Qop values of the correspondin= g Access-Request> > and> > > the> > > > > > > Digest-HA1 attribute's value = to finish the> computation> > of> > > the> > > > > > > rspauth value.> > > = > > > >> > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no = quotes around rspauth> > > > > > >> > > > > > > This attribute enables the = RADIUS server to prove> > > possession of> > > > > > > the password. If the= previously received Digest-Qop> > > attribute> > > > > > > was 'auth-int' = (without surrounding quotes), the> RADIUS> > > server> > > > > > > MUST sen= d a Digest-HA1 attribute instead of a> > > Digest-Response-> > > > > > > Au= th attribute. The Digest-Response-Auth attribute> > MUST> > > only> > > > >= > > be used in Access-Accept packets. The RADIUS client> > puts> > > the> = > > > > > > attribute value without surrounding quotes into the> > > rspaut= h> > > > > > > directive of the Authentication-Info header.> > > > > > >> >= > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes around nextnon= ce> > > > > > >> > > > > > > The RADIUS server MAY put a Digest-Nextnonce> = attribute> > > into an> > > > > > > Access-Accept packet. If this attribute= is present,> > the> > > RADIUS> > > > > > > client MUST put the contents o= f this attribute into> the> > > > > > > nextnonce directive of an Authentic= ation-Info header> in> > > its> > > > > > > HTTP-style response. This attri= bute MUST only be> used> > in> > > > > > > Access-Accept packets.> > > > > = > >> > > > > > >> > > > > > >Section 3.7, 4th paragraph - no quotes around = uri> > > > > > >> > > > > > > If the HTTP-style request has an Authorizatio= n> header,> > > the> > > > > > > RADIUS client puts the value of the uri di= rective> found> > > in> > > > > > > the HTTP-style request Authorization he= ader (known as> > > "digest-> > > > > > > uri-value" in Section 3.2.2 of [R= FC2617]) without> > > surrounding> > > > > > > quotes into this attribute. = If there is no> > Authorization> > > > > > > header, the RADIUS client take= s the value of the> > request> > > URI> > > > > > > from the HTTP-style req= uest it wants to authenticate.> > > > > > >> > > > > > >> > > > > > >Sectio= n 3.8, 4th paragraph - no quotes around qop> > > > > > >> > > > > > > In Ac= cess-Requests, the RADIUS client takes the value> > of> > > the> > > > > > = > qop directive (qop-value as described in [RFC2617])> > from> > > the> > >= > > > > HTTP-style request it wants to authenticate. In> > Access-> > > > = > > > Challenge packets, the RADIUS server puts a desired> > > qop-value> >= > > > > > into this attribute. If the RADIUS server supports> > more> > > = than> > > > > > > one "quality of protection" value, it puts each> > qop-va= lue> > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> >= > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > > >>= > > > > > > This attribute is sent by a RADIUS server in order to> > > not= ify> > > > > > > the RADIUS client whether it has accepted a nonce.> If> > = > the> > > > > > > nonce presented by the RADIUS client was stale, the> > v= alue> > > is> > > > > > > 'true' and is 'false' otherwise. The RADIUS clien= t> > puts> > > the> > > > > > > content of this attribute into a stale dire= ctive of> the> > > WWW-> > > > > > > Authenticate header in the HTTP-style = response to the> > > request> > > > > > > it wants to authenticate. The att= ribute MUST only be> > > used in> > > > > > > Access-Challenge packets.> > = > > > > >> > > > > > >3.19 1st paragraph - no quotes around rspauth> > > > = > > >> > > > > > > This attribute is used to allow the generation of an> > = > > > > > Authentication-Info header, even if the HTTP-style> > > response'= s> > > > > > > body is required for the calculation of the rspauth> > > val= ue.> > > > > > > It SHOULD be used in Access-Accept packets if the> > > req= uired> > > > > > > quality of protection ('qop') is 'auth-int'.> > > > > > = >> > > > > > >> > > > > > >> > > > > > >> > > > > > >I think that does it. = Even if this is not right, at least it> > > should now> > > > > > >be consi= stent.> > > > > > >> > > > > > >Comments?> > > > > > >> > > > > > >Baruch> = > > > > > >> > > > > > >> > > > > > >> > > > > > >-----Original Message----= -> > > > > > >From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> > > > > = > >Sent: Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> >= > > > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;> > > > >= > >beckw@t-systems.com; radext-ads@tools.ietf.org;> > > > > > >radext-chai= rs@tools.ietf.org; RFC Editor> > > > > > >Subject: Re: AUTH48 [SG]: RFC 509= 0> > > > > > > > > >NOW AVAILABLE> > >= > > > >> > > > > > >Greeting all,> > > > > > >> > > > > > >We have not hea= rd further regarding the issues below or other> > > changes> > > > > > >tha= t may be required before publishing this document as an> RFC.> > > > > > >P= lease review the document and let us know if there are any> > > > > > >corr= ections required.> > > > > > >> > > > > > > ftp://ftp.rfc-editor.org/in-not= es/authors/rfc5090.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/autho= rs/rfc5090-diff.html> > > > > > >> > > > > > >We will wait to hear from you= before continuing on with the> > > > > > >publication process.> > > > > > = >> > > > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> = > > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:= > > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > > >>> = > > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While reviewing > during> > > AUTH48,> > > > > > >>>please con= sider the following.> > > > > > >>>> > > > > > >>>In previous dialog, we ha= d the following exchange:> > > > > > >>>> > > > > > >>>>>2. Please explain = the usage of the single quote marks (')> > in> > > > > > >>>>>this document= . There seems to be inconsistency, but we> are> > > > > > >>>>>unable to de= termine which values/attributes/parameters> you> > > > > > >>>>>wanted to a= ppear in quote marks. For example, we see> > > > > > >>>>>> > > > > > >>>>>= 'auth-int'/"auth-int"> > > > > > >>>>>'rspauth' directive/rspauth directive= > > > > > > >>>>>'rspauth' value/rspauth value> > > > > > >>>>>> > > > > > = >>>>As RfC 2617 always uses ", replacing all 's in question> with> > "> > >= seems> > > > > > >>>>the right thing to do.> > > > > > >>>> > > > > > >>>P= lease note that we did not replace all 's with "s because> > > > > > >>>RFC= 4590 uses 's. However, if you feel that the document> > > should be> > > >= > > >>>more alignmed with RFC 2617, please let us know and we will> > > ma= ke> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are taking a= vote, I would prefer using " instead of '> > > around> > > > > > >the> > >= > > > >>value strings. I think it is better to stay aligned with> 2617> > = > rather> > > > > > >than> > > > > > >>4590. Also I believe the " usage is = more commonly used in> > other> > > > > > >>specifications.> > > > > > >>> = > > > > > >>>> > > > > > >>>Also, we had a difficult time understanding the= use of 's.> > We> > > > > > >>>inserted 's around auth-int, auth, qop, and= rspauth when> they> > > were> > > > > > >>>used as values or directives. H= owever, we did not attempt> to> > > include> > > > > > >>>'s for *all* dire= ctives and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let = us know if this is not correct.> > > > > > >>> > > > > > >>I agree it is co= nfusing. Looking at 2617 I don't think it> is> > > entirely> > > > > > >> >= > > > > >>consistent either, as I see references to ["qop" directive]> as>= > > well as> > > > > > >the> > > > > > >>unquoted form [qop directive].> >= > > > > >>> > > > > > >>I am no authority on style but my initial thought = is to> > suggest> > > > > > >removing '> > > > > > >>and " from keywords wh= en refering to a directive name rather> > > than its> > > > > > >>literal v= alue, and then use "" when refering to a value.> For> > > example,> > > > >= > >the> > > > > > >>existing 5090 text would then become:> > > > > > >>> >= > > > > >>> > > > > > >> o If the Access-Accept packet contains a Di= gest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the qop and= algorithm directives> in> > > the> > > > > > >> Authorization header of th= e HTTP-style request it> wants> > to> > > > > > >> authorize:> > > > > > >>= > > > > > > >> * If the qop directive is missing or its value is> > "auth",= > > > the> > > > > > >> RADIUS client ignores the Digest-HA1 attribute. It>= > > does not> > > > > > >> include an Authentication-Info header in its> >= HTTP-style> > > > > > >> response.> > > > > > >>> > > > > > >>> > >= > > > >>However when examing 2617 in more detail, using " around the> > > = directive> > > > > > >> > > > > > >>names would be more consistent with tha= t draft. For example> > > this> > > > > > >would> > > > > > >>become:> > > = > > > >>> > > > > > >>> > > > > > >> o If the Acce= ss-Accept packet contains a Digest-HA1> > > attribute, the> > > > > > >> RA= DIUS client checks the "qop" and "algorithm"> > directives> > > in the> > >= > > > >> Authorization header of the HTTP-style request it> wants> > to> >= > > > > >> authorize:> > > > > > >>> > > > > > >> * If the "qop" directive= is missing or its value is> > > "auth", the> > > > > > >> RADIUS client ig= nores the Digest-HA1 attribute. It> > > does not> > > > > > >> include an A= uthentication-Info header in its> > HTTP-style> > > > > > >> response.> > >= > > > >>> > > > > > >>> > > > > > >>Prehaps othe= rs can weigh in one which they believe is most> > > > > > >appropriate.> > = > > > > >>I believe either would be a slight improvement on the> existing> = > > text> > > > > > >which> > > > > > >>uses single quotes around the strin= g values.> > > > > > >>> > > > > > >>thanks,> > > > > > >>-david> > > > > >= >>> > > > > > >>>> > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RF= C Editor> > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 a= t 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org> > > > > > >wrote:> > > = > > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > > > > > >>>= >Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC AUTHOR(S):> > > > > = > >>>>--------------> > > > > > >>>>> > > > > > >>>>This is your LAST CHANC= E to make changes to your RFC to> be:> > > > > > >>>>draft-ietf-radext-rfc4= 590bis-02.txt, once the document is> > > published> > > > > > >as> > > > > = > >>>>an RFC we *WILL NOT* make any changes.> > > > > > >>>>> > > > > > >>>= >Please check your document at:> > > > > > >>>>> > > > > > >>>>ftp://ftp.rf= c-editor.org/in-notes/authors/rfc5090.txt> > > > > > >>>>> > > > > > >>>>AT= TENTION: The editing process occasionally introduces> > errors> > > that> >= > > > > >>>>were not in the Internet Draft. Although the RFC Editor> > tri= es> > > very> > > > > > >>>>hard to catch all errors, proofreading the text= at least> > > twice,> > > > > > >typos> > > > > > >>>>can slip through. Yo= u, as an author of the RFC, are> taking> > > > > > >>>>responsibility for t= he correctness of the final product> when> > > you OK> > > > > > >>>>public= ation. You should therefore proofread the entire> RFC> > > > > > >carefully= > > > > > > >>>>and without assumptions. Errors in RFCs last forever.> > > = > > > >>>>> > > > > > >>>>NOTE: We have run a diff tool that compares the a= pproved> > > > > > >internet-draft> > > > > > >>>>against our edited RFC ve= rsion of the document. Please> > review> > > this> > > > > > >>>>file at:> = > > > > > >>>>> > > > > >> >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rf= c5090-diff.html> > > > > > >>>>> > > > > > >>>>Please note that we used a s= lightly altered version of the> > > > > > >originally> > > > > > >>>>submit= ted ID to create the diff file above. To make the> > file> > > more> > > > = > > >>>>useful, we moved the terminology section to to appear> after> > > t= he> > > > > > >>>>introduction, but we did not alter the text.> > > > > > >= >>>> > > > > > >>>>The document will NOT BE PUBLISHED until ALL of the> aut= hors> > > listed> > > > > > >in> > > > > > >>>>the RFC have affirmed that t= he document is ready to be> > > > > > >>>>published, as ALL of the authors = are equally responsible> for> > > > > > >verifying> > > > > > >>>>the docum= ents readiness for publication.> > > > > > >>>>> > > > > > >>>>** Please se= nd us a list of suitable keywords for this> > > document,> > > > > > >over>= > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> = > > > > > >>>> Frequently INCORRECT information includes> > > > > > >>>>> >= > > > > >>>> - Contact Information> > > > > > >>>> - References (are they = up to date)> > > > > > >>>> - Section Numbers> > > > > > >>>> (especially i= f you originally put the copyright> > > > > > >somewhere> > > > > > >>>> ot= her than the VERY end of the document, or if> > you> > > > > > >>>> numbere= d the 'Status of the Memo' field)> > > > > > >>>>> > > > > > >>>>Please sen= d us the changes, *DO NOT* send a new document> > with> > > the> > > > > > = >>>>changes made. (If we think that the changes might be more> > > than> > = > > > > >>>>editorial we will contact the AD or the IESG to confirm> that> = > > the> > > > > > >>>>changes do not require review.)> > > > > > >>>>> > >= > > > >>>>Send us the changes in THIS format.> > > > > > >>>>> > > > > > >= >>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > > paragraph]> > > > > > >>= >> 2) the text you want changed,> > > > > > >>>> 3) the new correct text an= d> > > > > > >>>> 4) if the changes are spacing or indentation> than> > > p= lease> > > > > > >note> > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>= >FOR EXAMPLE:> > > > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> >= > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jump= ed over the lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> = The quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> > >= > > > >>>>If you have a whole paragraph to replace you do not need> to> > = > use> > > > > > >>>>the arrow to point out the differences> > > > > > >>>>= > > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > > >>>>> > > > > > >>>= > Replace OLD:> > > > > > >>>>> > > > > > >>>> alsdfja;sldjf;lajsd;fljas;dl= fj;> > > > > > >>>>> > > > > > >>>> With NEW:> > > > > > >>>>> > > > > > >>= >> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > >>>>> > > > > > >>>>Spacing o= r indentation problems...> > > > > > >>>>> > > > > > >>>> Section 10, 1st p= aragraph (remove spaces> between> > > bit> > > > > > >>>> and of, add space= after butter)> > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > = > > >>>> Better botter bought a bit> > > > > > >>>> of bitter butterMary ma= ry quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>> > >= > > > >>>> Better botter bought a bit of bitter butter> > > > > > >>>>> > = > > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > > > > >>>>This d= ocument will NOT be published until we receive> > > agreement, from> > > > = > > >>>>ALL listed authors, that the document is ready for> > > publication= .> > > > > > >>>>> > > > > > >>>>Thanks for your cooperation,> > > > > > >>= >>> > > > > > >>>>-RFC Editor> > > > > > >>>>> > > > > > >>>>> > > > > > >>= >>Title : RADIUS Extension for Digest> > > > > > >>>> Authentication> > > >= > > >>>>Author(s) : B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz= , D. Williams,> > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s= ) : Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan Romas= canu, Ronald Bonica> > > > > > >>>> > > > > > > --_850a5faa-11aa-4c9f-9f82-831ac36344fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 4590bis is now being held in AUTH48, pending final verification.
What started as a "simple" IANA-problem fix has turned into a longer odys= sey due to the
discovery of additional errors/omissions. 

= In attempt to bring this story to a close, we need to make very sure that w= e have looked over
this document carefully so that we don't have to go t= hrough this again with RFC 4590ter.

So if you have ever had any int= erest in RADIUS Digest Authentication, now would be the time
to look ove= r the AUTH48 version of the document, and speak up if there is a problem.&n= bsp;

> Date: Fri, 21 Dec 2007 15:14:46 -0800
> From: rfc-e= ditor@rfc-editor.org
> To: beckw@t-systems.com
> CC: baruch.ste= rman@kayote.com; david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@c= isco.com; dromasca@avaya.com; rbonica@juniper.net; d.b.nelson@comcast.net; = bernard_aboba@hotmail.com; rfc-editor@rfc-editor.org
> Subject: Re: A= UTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAIL= ABLE
>
> Greeings Wolfgang,
>
> Just a reminder t= hat we are waiting to hear from you before continuing
> on with the p= ublication process.
>
> Please see the email below for documen= t information.
>
> Thank you.
>
> RFC Editor
&= gt;
> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:> > Hi Wolfgang,
> >
> > Just a friendly reminder= that we are waiting to hear from you before
> > continuing on wit= h the publication process for RFC 5090
> > <draft-ietf-radext-r= fc4590bis-09.txt>.
> >
> > Please review the files = located at:
> >
> > ftp://ftp.rfc-editor.org/in-notes= /authors/rfc5090.txt
> > ftp://ftp.rfc-editor.org/in-notes/auth= ors/rfc5090-diff.html
> >
> > Note that this diff file h= ighlights only the differences between the
> > last posted version= of the document and the current text file. The
> > previously po= sted versions (during AUTH48) are available as:
> >
> > = The originally posted AUTH48 files:
> > ftp://ftp.rfc-editor.or= g/in-notes/authors/rfc5090v1.txt
> > ftp://ftp.rfc-editor.org/i= n-notes/authors/rfc5090v1-diff.html
> >
> > Version 2 (i= ncludes author updates) of AUTH48 files:
> > ftp://ftp.rfc-edit= or.org/in-notes/authors/rfc5090v2.txt
> > ftp://ftp.rfc-editor.= org/in-notes/authors/rfc5090v2-diff.html
> > Note that this file h= ighlights only the differences between the
> > version 1 and 2 tex= t files.
> >
> > We will wait to hear from you before co= ntinuing on with the
> > publication process.
> >
>= ; > Thank you.
> >
> > RFC Editor/sg
> > > >
> > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard = Aboba wrote:
> > >
> > > I also talked to Wolfgang= at IETF 70. He wanted to check the document over carefully to make sure t= here
> > > were no further issues. > Subject: RE: AUTH48 [= SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE>= Date: Mon, 10 Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com&= gt; To: rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: david.schwar= tz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com;= rbonica@juniper.net; Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net>= > Yes,> > David Schwartz saw him at the ietf meeting and worked t= hrough the draft> with him. I think we should be hearing from him soon.&= gt; > Baruch> > > -----Original Message-----> From: RFC Edit= or [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, December 10, 2007 = 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> Cc: David Schwartz;= RFC Editor; dscreat@dscreat.com; dwilli@cisco.com;> Dan Romascanu; Rona= ld Bonica; Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subjec= t: Re: AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt>>= ; NOW AVAILABLE> > All,> > Just checking to see if you have had= any luck contacting Wolfgang?> > Thanks!> > RFC Editor/sg> = > On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch Sterman wrote:> &g= t; David Schwartz will be at the IETF meetings next week. Maybe Wolfgang>= ; > will be there and he can nudge him to answer. Lets hold off until we= > see> > if that way forward works. If not, we can go with option = 3.> > > > Thanks,> > > > Baruch> > > > = > > -----Original Message-----> > From: RFC Editor [mailto:rfc-= editor@rfc-editor.org] > > Sent: Tuesday, November 27, 2007 12:41 AM&= gt; > To: Baruch Sterman> > Cc: RFC Editor> > Subject: Re: A= UTH48 [SG]: RFC 5090> <draft-ietf-radext-rfc4590bis-02.txt>> &g= t; NOW AVAILABLE> > > > Hi Baruch,> > > > We have a= couple of ways to move forward.> > > > 1. The author can be re= moved as an author, and moved to the> > Acknowledgements section.>= > > > 2. We can create a Contributor's section and have him liste= d there.> > > > 3. We can request that the AD approve the docum= ent in place of the> > unavailabe author. > > > > Option = 3 has been done before in instances where the missing author> > made = sizeable contributions to the document, so the other authors> > did n= ot feel comfortable removing the individuals name as an> > author. &g= t; > > > It sounds as though 3 may be the proper way forward. If t= his is the> > case, we will send an email to the ADs requesting their= approval in> > place of Wolfgang (the message will be cc'ed to all r= elevant> > parties, including Wolfgang). > > > > If the a= bove suggestions are unacceptable and you have an alternative> > solu= tion, please let us know. > > > > Thank you.> > > >= RFC Editor> > > > On Mon, Nov 26, 2007 at 09:39:09AM +0200, Ba= ruch Sterman wrote:> > > I wrote to Wolfgang as well, but got no r= esponse. What is the> > procedure> > > in this case? I am su= re that Wolfgang would be ok with the changes.> > The> > > l= ast email I received was on October 19 where he said that he had> made&g= t; > > the one correction (suggested by Ellermann) in the cnonce valu= e. > > > > > > Baruch> > > > > > > &= gt; > -----Original Message-----> > > From: RFC Editor [mailto:= rfc-editor@rfc-editor.org] > > > Sent: Wednesday, November 21, 200= 7 10:35 PM> > > To: David Williams; Baruch Sterman; dscreat@dscrea= t.com; David> > Schwartz;> > > beckw@t-systems.com> > = > Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC> &= gt; Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090> > <dr= aft-ietf-radext-rfc4590bis-02.txt>> > > NOW AVAILABLE> > = > > > > Greetings Wolfgang,> > > > > > We do = not believe we have received your response regarding this> > > doc= ument's readiness for publication as an RFC. Please review the> > >= ; text and let us know if you are content with the document as it now> &= gt; > appears at:> > > > > > ftp://ftp.rfc-editor.org/= in-notes/authors/rfc5090.txt> > > ftp://ftp.rfc-editor.org/in-note= s/authors/rfc5090-diff.html> > > Note that this diff file highligh= ts only the changes between the> last > > > posted version of t= he document and the current text file.> > > > > > > &g= t; > The last versions of the document are available as:> > > &= gt; > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> &= gt; > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html> = > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v= 2.txt> > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-dif= f.html> > > Note that this diff file highlights only the changes b= etween v1 and> > > the v2.> > > > > > We will wa= it to hear from you before continuing on with the> > > publication= process.> > > > > > Thank you.> > > > > &= gt; RFC Editor> > > > > > On Fri, Nov 16, 2007 at 05:13:0= 4PM -0800, RFC Editor wrote:> > > > Authors,> > > >= > > > > We have corrected the text as indicated below and post= ed the> revised> > > > version of the document at:> > = > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc= 5090.txt> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc50= 90-diff.html> > > > Note that this diff file highlights only th= e changes betwee the> last> > > > > > posted version o= f the document and the current text file.> > > > > > >= > Please review the document and let us know if you approve this> &g= t; > > text for publication.> > > > > > > > W= e believe we are waiting for the following approvals:> > > > &g= t; > > > Baruch Sterman - done > > > > Daniel Sadolevs= ky - done> > > > David Schwartz - done> > > > David= Williams> > > > Wolfgang Beck> > > > > > >= ; > Bernard Aboba - done> > > > > > > > > >= ; > > Thank you.> > > > > > > > RFC Editor>= ; > > > > > > > > > > > On Tue, Nov 06, 20= 07 at 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,&= gt; > > > > > > > > > Please confer and let us k= now how the text should/should not use> > the> > > > >= quote marks. It sounds as though this email was for discussion.> > I= f> > > > > the changes below are acceptable, we will make th= e changes and> > post> > > a> > > > > revised= version of the document.> > > > > > > > > > = Also, please note the following status of document approvals:> > >= > > > > > > > Baruch Sterman - done (although we woul= d like to know if you> agree> > > > > with the changes de= scribed below)> > > > > Daniel Sadolevsky - done> > &g= t; > > David Schwartz> > > > > David Williams> >= > > > Wolfgang Beck> > > > > > > > > &= gt; Bernard Aboba - done> > > > > > > > > > W= e will wait to hear further before continuing on with the> > > pub= lication> > > > > process.> > > > > > >= > > > Thank you.> > > > > > > > > >= RFC Editor> > > > > > > > > > > > >= > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Williams wrote:&= gt; > > > > > Hi Baruch,> > > > > > > &= gt; > > > > These look good, and I agree with your consistency = comment. I> > > have a few > > > > > > more spec= ific changes to suggest that I would like you and> > others> > = > to > > > > > > review as well. But first a couple of= general style comments> > that> > > require > > > = > > > no changes to the document.> > > > > > >= ; > > > > > General comment #1: I tried to find a definitive= style guide> to> > > use of > > > > > > sing= le quotes versus double quotes and found there is no hard> > > gui= delines, > > > > > > that consistency is most important:&= gt; > > > > > http://en.wikipedia.org/wiki/Quotation_mark>= ; > > > > > http://forum.wordreference.com/showthread.php?t= =3D120946> > > > > > Though I tend to think that double q= uotes are more commonly> used> > > and match > > > >= ; > > the syntax of more popular programming languages, but there>= are> > so> > > many > > > > > > quoted it= ems in the document and it has been this way for a> long> > > t= ime, so > > > > > > best to leave as is.> > > &g= t; > > > > > > > > General comment #2: When referin= g to responses from the radius> > > server > > > > >= ; > there are a lot of instances of a comment similiar to "without> &= gt; > surrounding > > > > > > quotes" that potentially= could be removed for readability.> > > Especially if > > &g= t; > > > there were a more concise definition up-front about the&g= t; general> > > form of > > > > > > values retur= ned from the radius server. But I am a little> > > hesitant to >= ; > > > > > just strip them out now.> > > > >= > > > > > > > Specific comments, to build on top of y= our list:> > > > > > > > > > > > In sec= tion 2.1.2, 1st paragraph should not have quotes around> > > nonce= . > > > > > > Paragraph should read:> > > > &= gt; > > > > > > > If a matching (Proxy-)Authorization = header is present and> > > contains> > > > > > H= TTP Digest information, the RADIUS client checks the nonce> > > &g= t; > > parameter.> > > > > > > > > > &g= t; > In next paragraph, do not need quotes around response.> > Par= agraph> > > should > > > > > > read:> > &g= t; > > > > > > > > > If the RADIUS client recogn= izes the nonce, it takes the> > header> > > > > > d= irectives and puts them into a RADIUS Access-Request> packet.> > &= gt; It> > > > > > puts the response directive into a Dige= st-Response> attribute> > > and> > > > > > th= e realm, nonce, digest-uri, qop, algorithm, cnonce, nc,> > > usern= ame,> > > > > > and opaque directives into the respective= Digest-Realm,> > > Digest-Nonce,> > > > > > Dig= est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,> > > Digest-= > > > > > > Nonce-Count, Digest-Username, and Digest-Opaq= ue attributes.> > > The> > > > > > RADIUS client= puts the request method into the> Digest-Method> > > > >= > attribute.> > > > > > > > > > > >= In section 2.1.3, in addtion to the items you point out, in> the> &g= t; > last > > > > > > paragraph, nextnounce does not n= eed quoting. Paragraph> should> > > read:> > > > &g= t; > > > > > > > When the RADIUS server provides a Dig= est-Nextnonce> attribute> > in> > > the> > > >= ; > > Access-Accept packet, the RADIUS client puts the contents> o= f> > > this> > > > > > attribute into a nextnonc= e directive. Now it can send an> > HTTP-> > > > > >= style response.> > > > > > > > > > > >= In section 2.1.4, 2nd paragraph, the stale directive should> not> &g= t; > need > > > > > > quoting. Paragraph should read:&= gt; > > > > > > > > > > > If the RADIUS cl= ient receives an Access-Challenge packet in> > > response> >= > > > > to an Access-Request containing a Digest-Nonce attribu= te,> the> > > RADIUS> > > > > > server did no= t accept the nonce. If a Digest-Stale> attribute> > > is> &g= t; > > > > present in the Access-Challenge and has a value of '= true'> > > (without> > > > > > surrounding quote= s), the RADIUS client sends an error> > response> > > (401&g= t; > > > > > or 407) containing a WWW-/Proxy-Authenticate he= ader with> the> > > > > > directive stale and the dige= st directives derived from the> > > Digest-*> > > > &g= t; > attributes.> > > > > > > > > > > &= gt; Except I think the wording of the last sentence in this same> > &= gt; paragraph > > > > > > could be improved. So that the = paragraph reads more like:> > > > > > > > > >= > > If the RADIUS client receives an Access-Challenge packet in> = > > response> > > > > > to an Access-Request contai= ning a Digest-Nonce attribute,> the> > > RADIUS> > > &= gt; > > server did not accept the nonce. If a Digest-Stale> attrib= ute> > > is> > > > > > present in the Access-Cha= llenge and has a value of 'true'> > > (without> > > > = > > surrounding quotes), the RADIUS client sends an error> > re= sponse> > > (401> > > > > > or 407) containing a= WWW-/Proxy-Authenticate header with> the> > > > > > s= tale directive set to 'true' and the digest directives> > derived>= > > from> > > > > > the Digest-* attributes.> &= gt; > > > > > > > > > > In section 3.10, 1st = paragraph, I believe the term "qop-level"> > is> > > ill >= ; > > > > > defined and should not be used, that qop directi= ve or> qop-value> > > would be > > > > > > be= tter. In other words the paragraph should read:> > > > > >= ; > > > > > > When using the qop-value 'auth-int', a hash= of the> > > HTTP-style> > > > > > message body'= s contents is required for digest> > > calculation.> > > = > > > Instead of sending the complete body of the message,> >= ; only> > > its> > > > > > hash value is sent. T= his hash value can be used> > directly> > > in> > >= > > > the digest calculation.> > > > > > > &= gt; > > > > In section 3.15, auth-param doesn't need quoting. S= o that the> > > paragraph > > > > > > becomes:&g= t; > > > > > > > > > > > This attribute is= a placeholder for future extensions> > and> > > > > &= gt; corresponds to the auth-param parameter defined in> > > Sectio= n> > > > > > 3.2.1 of [RFC2617]. The Digest-Auth-Param is= the> > > mechanism> > > > > > whereby the RADIU= S client and RADIUS server can> > exchange> > > auth-> &g= t; > > > > param extension parameters contained within Digest&g= t; > > headers that> > > > > > are not understood b= y the RADIUS client and for which> > > there are> > > >= ; > > no corresponding stand-alone attributes.> > > > >= ; > > > > > > > In section 3.17, domain doesn't need q= uoting. So that the> > > paragraph > > > > > > b= ecomes:> > > > > > > > > > > > When a R= ADIUS client has asked for a nonce, the> RADIUS> > > server>= > > > > > MAY send one or more Digest-Domain attributes in = its> > > Access-> > > > > > Challenge packet. Th= e RADIUS client puts them into> the> > > quoted,> > > = > > > space-separated list of URIs of the domain directive> of&= gt; > a> > > > > > WWW-Authenticate header. Together w= ith Digest-Realm,> > the> > > URIs> > > > > &= gt; in the list define the protection space (see> [RFC2617],> > &g= t; Section> > > > > > 3.2.1) for some HTTP-style protocol= s. This attribute> > > MUST only> > > > > > be u= sed in Access-Challenge and Accounting-Request> > > packets.> &= gt; > > > > > > > > > > In section 3.19, 1st = paragraph, in addtion to no quotes around> > > rspauth as > >= ; > > > > you pointed out, I believe there should be no quotes = around> qop.> > > So that > > > > > > the par= agraph reads:> > > > > > > > > > > > Th= is attribute is used to allow the generation of an> > > > > = > Authentication-Info header, even if the HTTP-style> > > respo= nse's> > > > > > body is required for the calculation of = the rspauth> > > value.> > > > > > It SHOULD be = used in Access-Accept packets if the> > > required> > > &= gt; > > quality of protection (qop) is 'auth-int'.> > > >= > > > > > > > > thanks,> > > > > &g= t; -david> > > > > > > > > > > > On Fri= , 19 Oct 2007, 1:43pm, Baruch Sterman wRote:> > > > > > &= gt; > > > > > >After lengthy discussions with my father-i= n-law who is a> > > professor of> > > > > > >= English, I agree with Dave's method of using quotes only in> the> >= ; > value of> > > > > > >an attribute/directive, bu= t not in referencing the> > > attribute/directive> > > &g= t; > > >by name. As such, I have some changes.> > > > = > > >> > > > > > >In section 2.1.3 3rd paragr= aph should not have quotes around> > the> > > word> > = > > > > >rspauth. Sentence should read:> > > > &= gt; > >> > > > > > > * If the Digest-Qop attribu= te's value is 'auth' or not> > > specified,> > > > >= ; > > the RADIUS client puts the Digest-Response-Auth> > > a= ttribute's> > > > > > > content into the Authenticatio= n-Info header's rspauth> > > > > > > directive of the = HTTP-style response.> > > > > > >> > > > &= gt; > >Same section 5th paragraph - no quotes around qop and> >= algorithm:> > > > > > >> > > > > > = > o If the Access-Accept packet contains a Digest-HA1> > attribute= ,> > > the> > > > > > > RADIUS client checks = the qop and algorithm directives in> > the> > > > > &g= t; > Authorization header of the HTTP-style request it wants> to> = > > > > > > authorize:> > > > > > >&= gt; > > > > > >Next paragraph - no quotes around qop> = > > > > > >> > > > > > > * If the qo= p directive is missing or its value is> 'auth',> > > the> &g= t; > > > > > RADIUS client ignores the Digest-HA1 attribute.= It> > does> > > not> > > > > > > inclu= de an Authentication-Info header in its> HTTP-style> > > > &= gt; > > response.> > > > > > >> > > >= ; > > >Next paragraph - no quotes around qop or rspauth.> > = > > > > >> > > > > > > * If the qop dir= ective's value is 'auth-int' and at> least> > > one> > &g= t; > > > > of the following conditions is true, the RADIUS> = client> > > > > > > calculates the contents of the HTT= P-style response's> > > rspauth> > > > > > > = directive:> > > > > > >> > > > > > &= gt;> > > > > > >2 paragraphs later - no quotes around = rspauth> > > > > > >> > > > > > >= The RADIUS client creates the HTTP-style response> > message> >= ; > and> > > > > > > calculates the hash of this me= ssage's body. It uses> > the> > > result> > > > = > > > and the Digest-URI attribute's value of the> > corresp= onding> > > > > > > Access-Request packet to perform t= he H(A2)> calculation.> > > It> > > > > > >= ; takes the Digest-Nonce, Digest-Nonce-Count,> > > Digest-CNonce, = and> > > > > > > Digest-Qop values of the correspondin= g Access-Request> > and> > > the> > > > > >= ; > Digest-HA1 attribute's value to finish the> computation> > = of> > > the> > > > > > > rspauth value.> &= gt; > > > > >> > > > > > >> > >= ; > > > >> > > > > > >Section 3.4 paragrap= h 1 - no quotes around rspauth> > > > > > >> > &= gt; > > > > This attribute enables the RADIUS server to prove&g= t; > > possession of> > > > > > > the password. = If the previously received Digest-Qop> > > attribute> > >= > > > > was 'auth-int' (without surrounding quotes), the> R= ADIUS> > > server> > > > > > > MUST send a Di= gest-HA1 attribute instead of a> > > Digest-Response-> > >= ; > > > > Auth attribute. The Digest-Response-Auth attribute>= ; > MUST> > > only> > > > > > > be used in= Access-Accept packets. The RADIUS client> > puts> > > the&g= t; > > > > > > attribute value without surrounding quotes= into the> > > rspauth> > > > > > > directive= of the Authentication-Info header.> > > > > > >> &= gt; > > > > >> > > > > > >Section 3.5 2= nd paragraph - no quotes around nextnonce> > > > > > >= > > > > > > > The RADIUS server MAY put a Digest-Nextn= once> attribute> > > into an> > > > > > > = Access-Accept packet. If this attribute is present,> > the> > &= gt; RADIUS> > > > > > > client MUST put the contents o= f this attribute into> the> > > > > > > nextnonce d= irective of an Authentication-Info header> in> > > its> >= > > > > > HTTP-style response. This attribute MUST only be&= gt; used> > in> > > > > > > Access-Accept packet= s.> > > > > > >> > > > > > >> = > > > > > >Section 3.7, 4th paragraph - no quotes around = uri> > > > > > >> > > > > > > If = the HTTP-style request has an Authorization> header,> > > the&g= t; > > > > > > RADIUS client puts the value of the uri di= rective> found> > > in> > > > > > > the HT= TP-style request Authorization header (known as> > > "digest-> = > > > > > > uri-value" in Section 3.2.2 of [RFC2617]) wit= hout> > > surrounding> > > > > > > quotes int= o this attribute. If there is no> > Authorization> > > > = > > > header, the RADIUS client takes the value of the> > re= quest> > > URI> > > > > > > from the HTTP-sty= le request it wants to authenticate.> > > > > > >> = > > > > > >> > > > > > >Section 3.8,= 4th paragraph - no quotes around qop> > > > > > >>= > > > > > > In Access-Requests, the RADIUS client takes = the value> > of> > > the> > > > > > > q= op directive (qop-value as described in [RFC2617])> > from> > &= gt; the> > > > > > > HTTP-style request it wants to au= thenticate. In> > Access-> > > > > > > Challenge= packets, the RADIUS server puts a desired> > > qop-value> >= > > > > > into this attribute. If the RADIUS server support= s> > more> > > than> > > > > > > one "q= uality of protection" value, it puts each> > qop-value> > > = into> > > > > > > a separate Digest-Qop attribute.>= > > > > > >> > > > > > >Section 3.1= 8 1st paragraph - no quotes around stale> > > > > > >&= gt; > > > > > > This attribute is sent by a RADIUS server= in order to> > > notify> > > > > > > the RAD= IUS client whether it has accepted a nonce.> If> > > the> &g= t; > > > > > nonce presented by the RADIUS client was stale,= the> > value> > > is> > > > > > > 'tru= e' and is 'false' otherwise. The RADIUS client> > puts> > > = the> > > > > > > content of this attribute into a stal= e directive of> the> > > WWW-> > > > > > >= Authenticate header in the HTTP-style response to the> > > reques= t> > > > > > > it wants to authenticate. The attribute= MUST only be> > > used in> > > > > > > Acces= s-Challenge packets.> > > > > > >> > > > &= gt; > >3.19 1st paragraph - no quotes around rspauth> > > &g= t; > > >> > > > > > > This attribute is used = to allow the generation of an> > > > > > > Authenticat= ion-Info header, even if the HTTP-style> > > response's> > &= gt; > > > > body is required for the calculation of the rspauth= > > > value.> > > > > > > It SHOULD be used i= n Access-Accept packets if the> > > required> > > > &g= t; > > quality of protection ('qop') is 'auth-int'.> > > >= ; > > >> > > > > > >> > > > > = > >> > > > > > >> > > > > > &g= t;I think that does it. Even if this is not right, at least it> > >= ; should now> > > > > > >be consistent.> > > = > > > >> > > > > > >Comments?> > >= ; > > > >> > > > > > >Baruch> > >= > > > >> > > > > > >> > > > &= gt; > >> > > > > > >-----Original Message-----&g= t; > > > > > >From: RFC Editor [mailto:rfc-editor@rfc-edi= tor.org]> > > > > > >Sent: Monday, October 15, 2007 8:= 45 PM> > > > > > >To: David Williams> > > >= ; > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>= ; > > > > > >beckw@t-systems.com; radext-ads@tools.ietf.o= rg;> > > > > > >radext-chairs@tools.ietf.org; RFC Edit= or> > > > > > >Subject: Re: AUTH48 [SG]: RFC 5090> = > > <draft-ietf-radext-rfc4590bis-02.txt>> > > > &g= t; > >NOW AVAILABLE> > > > > > >> > > &= gt; > > >Greeting all,> > > > > > >> > = > > > > >We have not heard further regarding the issues belo= w or other> > > changes> > > > > > >that may = be required before publishing this document as an> RFC.> > > &g= t; > > >Please review the document and let us know if there are an= y> > > > > > >corrections required.> > > >= > > >> > > > > > > ftp://ftp.rfc-editor.org/= in-notes/authors/rfc5090.txt> > > > > > > ftp://ftp.rf= c-editor.org/in-notes/authors/rfc5090-diff.html> > > > > >= ; >> > > > > > >We will wait to hear from you befor= e continuing on with the> > > > > > >publication proce= ss.> > > > > > >> > > > > > >Than= k you.> > > > > > >> > > > > > >R= FC Editor> > > > > > >> > > > > > &g= t;On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> &= gt; > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRot= e:> > > > > > >>> > > > > > >&= gt;>Authors,> > > > > > >>>> > > >= ; > > >>>While reviewing <draft-ietf-radext-rfc4590bis-02= .txt>> during> > > AUTH48,> > > > > > >= >>please consider the following.> > > > > > >>= ;>> > > > > > >>>In previous dialog, we had t= he following exchange:> > > > > > >>>> > &= gt; > > > >>>>>2. Please explain the usage of the s= ingle quote marks (')> > in> > > > > > >>>= >>this document. There seems to be inconsistency, but we> are> = > > > > > >>>>>unable to determine which valu= es/attributes/parameters> you> > > > > > >>>&= gt;>wanted to appear in quote marks. For example, we see> > > &= gt; > > >>>>>> > > > > > >>>= ;>>'auth-int'/"auth-int"> > > > > > >>>>= ;>'rspauth' directive/rspauth directive> > > > > > >= ;>>>>'rspauth' value/rspauth value> > > > > >= >>>>>> > > > > > >>>>As RfC 2= 617 always uses ", replacing all 's in question> with> > "> >= ; > seems> > > > > > >>>>the right thing t= o do.> > > > > > >>>> > > > > >= ; >>>Please note that we did not replace all 's with "s because>= ; > > > > > >>>RFC 4590 uses 's. However, if you fe= el that the document> > > should be> > > > > > &= gt;>>more alignmed with RFC 2617, please let us know and we will> = > > make> > > > > > >>>this change.> &g= t; > > > > >>> > > > > > >>If we = are taking a vote, I would prefer using " instead of '> > > around= > > > > > > >the> > > > > > >>= value strings. I think it is better to stay aligned with> 2617> > = > rather> > > > > > >than> > > > > &= gt; >>4590. Also I believe the " usage is more commonly used in> &= gt; other> > > > > > >>specifications.> > >= ; > > > >>> > > > > > >>>> >= ; > > > > >>>Also, we had a difficult time understandi= ng the use of 's.> > We> > > > > > >>>inse= rted 's around auth-int, auth, qop, and rspauth when> they> > >= were> > > > > > >>>used as values or directives= . However, we did not attempt> to> > > include> > > &g= t; > > >>>'s for *all* directives and values (e.g., realm an= d> opaque).> > > Please> > > > > > >>&g= t;let us know if this is not correct.> > > > > > >>= > > > > > > >>I agree it is confusing. Looking at 2= 617 I don't think it> is> > > entirely> > > > > = > >> > > > > > >>consistent either, as I see = references to ["qop" directive]> as> > > well as> > > = > > > >the> > > > > > >>unquoted form [= qop directive].> > > > > > >>> > > > &g= t; > >>I am no authority on style but my initial thought is to>= > suggest> > > > > > >removing '> > > >= ; > > >>and " from keywords when refering to a directive name r= ather> > > than its> > > > > > >>literal v= alue, and then use "" when refering to a value.> For> > > examp= le,> > > > > > >the> > > > > > >&= gt;existing 5090 text would then become:> > > > > > >&= gt;> > > > > > >><snip>> > > > &g= t; > >> o If the Access-Accept packet contains a Digest-HA1> &g= t; > attribute, the> > > > > > >> RADIUS client = checks the qop and algorithm directives> in> > > the> > &= gt; > > > >> Authorization header of the HTTP-style request = it> wants> > to> > > > > > >> authorize:&g= t; > > > > > >>> > > > > > >> = * If the qop directive is missing or its value is> > "auth",> >= > the> > > > > > >> RADIUS client ignores the D= igest-HA1 attribute. It> > > does not> > > > > >= >> include an Authentication-Info header in its> > HTTP-style&= gt; > > > > > >> response.> > > > > >= ; >></snip>> > > > > > >>> > >= > > > >>However when examing 2617 in more detail, using " a= round the> > > directive> > > > > > >> >= ; > > > > >>names would be more consistent with that draf= t. For example> > > this> > > > > > >would>= ; > > > > > >>become:> > > > > > >= ;>> > > > > > >><snip more like RFC 2617>&= gt; > > > > > >> o If the Access-Accept packet contain= s a Digest-HA1> > > attribute, the> > > > > > &g= t;> RADIUS client checks the "qop" and "algorithm"> > directives&g= t; > > in the> > > > > > >> Authorization hea= der of the HTTP-style request it> wants> > to> > > > &= gt; > >> authorize:> > > > > > >>> >= > > > > >> * If the "qop" directive is missing or its va= lue is> > > "auth", the> > > > > > >> RADI= US client ignores the Digest-HA1 attribute. It> > > does not> &= gt; > > > > >> include an Authentication-Info header in i= ts> > HTTP-style> > > > > > >> response.> = > > > > > >></snip more like RFC 2617>> > = > > > > >>> > > > > > >>Prehaps o= thers can weigh in one which they believe is most> > > > > &= gt; >appropriate.> > > > > > >>I believe either = would be a slight improvement on the> existing> > > text> &g= t; > > > > >which> > > > > > >>uses = single quotes around the string values.> > > > > > >&g= t;> > > > > > >>thanks,> > > > > >= ; >>-david> > > > > > >>> > > > &= gt; > >>>> > > > > > >>>Thank you.&g= t; > > > > > >>>> > > > > > >&= gt;>RFC Editor> > > > > > >>>> > > &= gt; > > >>>> > > > > > >>>On Thu,= Oct 04, 2007 at 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org&= gt; > > > > > >wrote:> > > > > > >&g= t;>>> > > > > > >>>>****IMPORTANT*****&= gt; > > > > > >>>>> > > > > > = >>>>Updated 2007/10/04> > > > > > >>>= ;>> > > > > > >>>>RFC AUTHOR(S):> > = > > > > >>>>--------------> > > > > = > >>>>> > > > > > >>>>This is = your LAST CHANCE to make changes to your RFC to> be:> > > > = > > >>>>draft-ietf-radext-rfc4590bis-02.txt, once the doc= ument is> > > published> > > > > > >as> &g= t; > > > > >>>>an RFC we *WILL NOT* make any change= s.> > > > > > >>>>> > > > > &g= t; >>>>Please check your document at:> > > > > &= gt; >>>>> > > > > > >>>>ftp://ftp= .rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > &= gt;>>>> > > > > > >>>>ATTENTION: The= editing process occasionally introduces> > errors> > > that= > > > > > > >>>>were not in the Internet Draf= t. Although the RFC Editor> > tries> > > very> > > = > > > >>>>hard to catch all errors, proofreading the t= ext at least> > > twice,> > > > > > >typos>= ; > > > > > >>>>can slip through. You, as an aut= hor of the RFC, are> taking> > > > > > >>>>= ;responsibility for the correctness of the final product> when> > = > you OK> > > > > > >>>>publication. You s= hould therefore proofread the entire> RFC> > > > > > &= gt;carefully> > > > > > >>>>and without assum= ptions. Errors in RFCs last forever.> > > > > > >>&= gt;>> > > > > > >>>>NOTE: We have run a di= ff tool that compares the approved> > > > > > >interne= t-draft> > > > > > >>>>against our edited RFC= version of the document. Please> > review> > > this> >= ; > > > > >>>>file at:> > > > > >= >>>>> > > > > >> >>>>ftp://ft= p.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > >= > >>>>> > > > > > >>>>Please = note that we used a slightly altered version of the> > > > >= > >originally> > > > > > >>>>submitted= ID to create the diff file above. To make the> > file> > > = more> > > > > > >>>>useful, we moved the term= inology section to to appear> after> > > the> > > >= > > >>>>introduction, but we did not alter the text.>= > > > > > >>>>> > > > > > >= ;>>>The document will NOT BE PUBLISHED until ALL of the> author= s> > > listed> > > > > > >in> > > &g= t; > > >>>>the RFC have affirmed that the document is rea= dy to be> > > > > > >>>>published, as ALL of = the authors are equally responsible> for> > > > > > &g= t;verifying> > > > > > >>>>the documents read= iness for publication.> > > > > > >>>>> &g= t; > > > > >>>>** Please send us a list of suitable= keywords for this> > > document,> > > > > > >= ;over> > > > > > >>>>and above those which ap= pear in the title.> > > > > > >>>>> > &= gt; > > > >>>> Frequently INCORRECT information includ= es> > > > > > >>>>> > > > > &g= t; >>>> - Contact Information> > > > > > >= >>> - References (are they up to date)> > > > > >= ; >>>> - Section Numbers> > > > > > >>&= gt;> (especially if you originally put the copyright> > > > = > > >somewhere> > > > > > >>>> other= than the VERY end of the document, or if> > you> > > > &= gt; > >>>> numbered the 'Status of the Memo' field)> >= > > > > >>>>> > > > > > >>= >>Please send us the changes, *DO NOT* send a new document> > w= ith> > > the> > > > > > >>>>changes = made. (If we think that the changes might be more> > > than> &g= t; > > > > >>>>editorial we will contact the AD or = the IESG to confirm> that> > > the> > > > > >= >>>>changes do not require review.)> > > > > &g= t; >>>>> > > > > > >>>>Send us th= e changes in THIS format.> > > > > > >>>>>= > > > > > >>>> 1)*** SECTION #'s*** [i.e. Secti= on 5, 2nd> > > paragraph]> > > > > > >>>= ;> 2) the text you want changed,> > > > > > >>&g= t;> 3) the new correct text and> > > > > > >>>= ;> 4) if the changes are spacing or indentation> than> > > p= lease> > > > > > >note> > > > > > &g= t;>>> that.> > > > > > >>>>> >= > > > > >>>>FOR EXAMPLE:> > > > > &= gt; >>>>> > > > > > >>>> Section = 5.6, 3rd paragraph> > > > > > >>>>> > &= gt; > > > >>>> OLD:> > > > > > >&= gt;>> The quick brown fox jumped over the lazy dog.> > > >= ; > > >>>>> > > > > > >>>> = NEW:> > > > > > >>>> The quick brown dog jump= s over the lazy fox.> > > > > > >>>> ^^^ ^ ^^= ^> > > > > > >>>>If you have a whole paragrap= h to replace you do not need> to> > > use> > > > &g= t; > >>>>the arrow to point out the differences> > >= ; > > > >>>>> > > > > > >>>= > INTRODUCTION, 2nd paragraph> > > > > > >>>&= gt;> > > > > > >>>> Replace OLD:> > >= ; > > > >>>>> > > > > > >>>= > alsdfja;sldjf;lajsd;fljas;dlfj;> > > > > > >>&= gt;>> > > > > > >>>> With NEW:> > &g= t; > > > >>>>> > > > > > >>>= ;> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > >>= >>> > > > > > >>>>Spacing or indentatio= n problems...> > > > > > >>>>> > > &= gt; > > >>>> Section 10, 1st paragraph (remove spaces>= between> > > bit> > > > > > >>>> an= d of, add space after butter)> > > > > > >>>>= > > > > > > >>>> OLD:> > > > >= > >>>>> > > > > > >>>> Better= botter bought a bit> > > > > > >>>> of bitte= r butterMary mary quite contrary> > > > > > >>>&= gt;> > > > > > >>>> NEW:> > > > &= gt; > >>>>> > > > > > >>>> Bet= ter botter bought a bit of bitter butter> > > > > > >&= gt;>>> > > > > > >>>> Mary mary quite c= ontrary> > > > > > >>>>> > > > &g= t; > >>>>This document will NOT be published until we receiv= e> > > agreement, from> > > > > > >>>&g= t;ALL listed authors, that the document is ready for> > > publicat= ion.> > > > > > >>>>> > > > > = > >>>>Thanks for your cooperation,> > > > > &= gt; >>>>> > > > > > >>>>-RFC Edit= or> > > > > > >>>>> > > > > &g= t; >>>>> > > > > > >>>>Title : RA= DIUS Extension for Digest> > > > > > >>>> Aut= hentication> > > > > > >>>>Author(s) : B. Ste= rman, D. Sadolevsky,> > > > > > >>>> D. Schwa= rtz, D. Williams,> > > > > > >>>> W. Beck>= > > > > > >>>>Working Group Chair(s) : Bernard = Aboba, David Nelson> > > > > > >>>>Area Direc= tor(s) : Dan Romascanu, Ronald Bonica> > > > > > >>= >> > > > > > >
= --_850a5faa-11aa-4c9f-9f82-831ac36344fd_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Dec 22 13:01:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J68em-0000Dq-Mf for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 22 Dec 2007 13:01:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J68el-0003r6-Lp for radext-archive-IeZ9sae2@lists.ietf.org; Sat, 22 Dec 2007 13:01:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J68al-000ONZ-52 for radiusext-data@psg.com; Sat, 22 Dec 2007 17:56:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.154] (helo=bay0-omc2-s18.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J68ai-000ONC-2z for radiusext@ops.ietf.org; Sat, 22 Dec 2007 17:56:53 +0000 Received: from BAY117-W17 ([207.46.8.52]) by bay0-omc2-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Dec 2007 09:56:48 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_" X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Sam Hartman , , Subject: RE: [ Comments on automated key management and crypto agility Date: Sat, 22 Dec 2007 09:56:47 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2007 17:56:48.0053 (UTC) FILETIME=[05BBC650:01C844C4] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To clarify -- RADIUS has previously used MD5 as a stream cipher to protect attributes inc= luding passwords (User-Password, Tunnel-Password) and keys (keying attributes within RFC 254= 8). =20 While the use of MD5 for integrity protection has a set of issues (e.g. col= lisions), the use of MD5 as a stream cipher brings up another set of issues, such as known plaintext= attacks. =20 Given this, the ability to negotiate alternative "hiding" mechanisms is con= sidered an important part of RADIUS crypto-agility. =20 However, this is logically separate from the need to provide end-to-end pro= tection for key transport.=20 So far, the need to solve the end-to-end key transport problem has not been= part of RADIUS crypto-agility requirements. Should it be?=20 Note that it is possible for a crypto-agility solution to solve the "hiding= " problem without solving the end-to-end transport problem.=20 With Diameter, it was clear that the IESG expected a solution to both probl= ems -- ciphersuite negotiation (via TLS/IKE) as well as a mechanism for avoiding key disclosur= e to proxies=20 (e.g. redirect).=20 The current RADIUS crypto-agility requirements only appear to require solut= ion to the=20 former problem (ciphersuite negotiation), but not the latter (key disclosur= e). That said, there has been some discussion of how the current proposals (RADIUS crypto-= agility and=20 RADIUS/DTLS) could address the key disclosure problem. > From: hartmans-ietf@mit.edu > To: radext-chairs@tools.ietf.org; radiusext@ops.ietf.org > Date: Thu, 20 Dec 2007 22:44:10 -0500 > Subject: [ Comments on automated key management and crypto agility >=20 >=20 >=20 >=20 > It's my understanding that you are in the middle or have just finished > a consensus call regarding automated key management and radius crypto > agility. >=20 > I gave the chairs some advice on this topic a while ago. It turns out > I completely failed to understand the question I was asked. >=20 >=20 > I assumed that the crypto agility work was intended to strengthen > radius's integrity protection and dependence on md5. >=20 > However as I understand now, the scope of the work also includes a > real solution to the key transport problem. >=20 > So I don't think the advice I gave the WG applies. >=20 > I don't know if this changes any of your deliberations, but I just though= t I'd write and let you know that I was confused. >=20 > Here's my current understanding of the situation in this space. >=20 > * RFC 3962 says that we should have a way so that people do not need > to expose keys to third parties (proxies). This is not mandatory to > use, but we need to have a solution for that problem. >=20 > * Diameter has the redirect mechanism which handles this need in some > deployments. >=20 > * Our protocols don't force you to use proxies, but there are a lot of > good reasons why you might want to do so. >=20 >=20 > * Hokey may need to have a solution to do key management that meets > the RFC 3962 requirements. >=20 > * It may be the easiest place for hokey to solve its problem if it has > one is at the radius key transport level. >=20 > * That doesn't inherently make it radext's problem to solve. We also > still haven't even figured out how much of this is hokey's problem. >=20 > I'm trying to understand this all better and to try and figure out > what sort of consensus we want to build. --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To clarify --

RADIUS has previously used MD5 as a stream cipher to p= rotect attributes including passwords
(User-Password, Tunnel-Password) a= nd keys (keying attributes within RFC 2548). 

While the use of= MD5 for integrity protection has a set of issues (e.g. collisions), the us= e of MD5
as a stream cipher brings up another set of issues, such as kno= wn plaintext attacks. 

Given this, the ability to negotiate al= ternative "hiding" mechanisms is considered an important part
of RADIUS = crypto-agility.  

However, this is logically separate fro= m the need to provide end-to-end protection for key transport.

So f= ar, the need to solve the end-to-end key transport problem has not been par= t of RADIUS
crypto-agility requirements.  Should it be?

Not= e that it is possible for a crypto-agility solution to solve the "hiding" p= roblem without solving the
end-to-end transport problem.

With Di= ameter, it was clear that the IESG expected a solution to both problems -- = ciphersuite
negotiation (via TLS/IKE) as well as a mechanism for avoidin= g key disclosure to proxies
(e.g. redirect).

The current RADIUS= crypto-agility requirements only appear to require solution to the
for= mer problem (ciphersuite negotiation), but not the latter (key disclosure).=   That said,
there has been some discussion of how the current prop= osals (RADIUS crypto-agility and
RADIUS/DTLS) could address the key dis= closure problem.



> From: hartmans-ietf@mit.edu
> To= : radext-chairs@tools.ietf.org; radiusext@ops.ietf.org
> Date: Thu, 2= 0 Dec 2007 22:44:10 -0500
> Subject: [ Comments on automated key man= agement and crypto agility
>
>
>
>
> It's= my understanding that you are in the middle or have just finished
> = a consensus call regarding automated key management and radius crypto
&g= t; agility.
>
> I gave the chairs some advice on this topic a = while ago. It turns out
> I completely failed to understand the ques= tion I was asked.
>
>
> I assumed that the crypto agili= ty work was intended to strengthen
> radius's integrity protection an= d dependence on md5.
>
> However as I understand now, the scop= e of the work also includes a
> real solution to the key transport pr= oblem.
>
> So I don't think the advice I gave the WG applies.<= br>>
> I don't know if this changes any of your deliberations, bu= t I just thought I'd write and let you know that I was confused.
> > Here's my current understanding of the situation in this space.
&= gt;
> * RFC 3962 says that we should have a way so that people do no= t need
> to expose keys to third parties (proxies). This is not ma= ndatory to
> use, but we need to have a solution for that problem.<= br>>
> * Diameter has the redirect mechanism which handles this n= eed in some
> deployments.
>
> * Our protocols don't f= orce you to use proxies, but there are a lot of
> good reasons why = you might want to do so.
>
>
> * Hokey may need to have= a solution to do key management that meets
> the RFC 3962 requirem= ents.
>
> * It may be the easiest place for hokey to solve its= problem if it has
> one is at the radius key transport level.
&= gt;
> * That doesn't inherently make it radext's problem to solve. = We also
> still haven't even figured out how much of this is hoke= y's problem.
>
> I'm trying to understand this all better and = to try and figure out
> what sort of consensus we want to build.
<= /body> = --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 23 00:56:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6JpM-0001w6-TK for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 00:56:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6JpI-0001cn-II for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 00:56:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6Jjz-0002KD-4Q for radiusext-data@psg.com; Sun, 23 Dec 2007 05:51:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6JjZ-0002IV-FA for radiusext@ops.ietf.org; Sun, 23 Dec 2007 05:50:59 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id 6141D8C31E; Sun, 23 Dec 2007 15:50:39 +1000 (EST) From: Mike McCauley To: Bernard Aboba Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sun, 23 Dec 2007 15:50:37 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org References: <20071107005849.GC28431@isi.edu> <20071221231446.GB5266@isi.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231550.38670.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Hi Bernard, Have the test vectors in section 6 Examples been checked? How? Im not sure I entirely agree with the Digest-Response values in the B->C messages Cheers. On Sunday 23 December 2007 03:37, Bernard Aboba wrote: > RFC 4590bis is now being held in AUTH48, pending final verification. > > What started as a "simple" IANA-problem fix has turned into a longer > odyssey due to the discovery of additional errors/omissions. > > In attempt to bring this story to a close, we need to make very sure that > we have looked over this document carefully so that we don't have to go > through this again with RFC 4590ter. > > So if you have ever had any interest in RADIUS Digest Authentication, now > would be the time to look over the AUTH48 version of the document, and > speak up if there is a problem. > > > Date: Fri, 21 Dec 2007 15:14:46 -0800 > > From: rfc-editor@rfc-editor.org > > To: beckw@t-systems.com > > CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; > > dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; > > rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; > > rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090 > > NOW AVAILABLE > > > > Greeings Wolfgang, > > > > Just a reminder that we are waiting to hear from you before continuing > > on with the publication process. > > > > Please see the email below for document information. > > > > Thank you. > > > > RFC Editor > > > > On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > > > Hi Wolfgang, > > > > > > Just a friendly reminder that we are waiting to hear from you before > > > continuing on with the publication process for RFC 5090 > > > . > > > > > > Please review the files located at: > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > > > > > > Note that this diff file highlights only the differences between the > > > last posted version of the document and the current text file. The > > > previously posted versions (during AUTH48) are available as: > > > > > > The originally posted AUTH48 files: > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > > > > > > Version 2 (includes author updates) of AUTH48 files: > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > > > Note that this file highlights only the differences between the > > > version 1 and 2 text files. > > > > > > We will wait to hear from you before continuing on with the > > > publication process. > > > > > > Thank you. > > > > > > RFC Editor/sg > > > > > > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > > > > I also talked to Wolfgang at IETF 70. He wanted to check the > > > > document over carefully to make sure there were no further issues. > > > > > Subject: RE: AUTH48 [SG]: RFC 5090 > > > > NOW AVAILABLE> Date: Mon, 10 > > > > Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: > > > > rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: > > > > david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; > > > > dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; > > > > d.b.nelson@comcast.net> > Yes,> > David Schwartz saw him at the ietf > > > > meeting and worked through the draft> with him. I think we should be > > > > hearing from him soon.> > Baruch> > > -----Original Message-----> > > > > From: RFC Editor [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, > > > > December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> > > > > Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; > > > > dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; > > > > Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: > > > > AUTH48 [SG]: RFC 5090 > NOW > > > > AVAILABLE> > All,> > Just checking to see if you have had any luck > > > > contacting Wolfgang?> > Thanks!> > RFC Editor/sg> > On Tue, Nov 27, > > > > 2007 at 09:21:45PM +0200, Baruch Sterman wrote:> > David Schwartz > > > > will be at the IETF meetings next week. Maybe Wolfgang> > will be > > > > there and he can nudge him to answer. Lets hold off until we> see> > > > > > if that way forward works. If not, we can go with option 3.> > > > > > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > From: > > > > RFC Editor [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, > > > > November 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> > > > > > Subject: Re: AUTH48 [SG]: RFC 5090> > > > > > > NOW AVAILABLE> > > > Hi > > > > Baruch,> > > > We have a couple of ways to move forward.> > > > 1. > > > > The author can be removed as an author, and moved to the> > > > > > Acknowledgements section.> > > > 2. We can create a Contributor's > > > > section and have him listed there.> > > > 3. We can request that the > > > > AD approve the document in place of the> > unavailabe author. > > > > > > > > Option 3 has been done before in instances where the missing author> > > > > > made sizeable contributions to the document, so the other authors> > > > > > did not feel comfortable removing the individuals name as an> > > > > > author. > > > > It sounds as though 3 may be the proper way forward. > > > > If this is the> > case, we will send an email to the ADs requesting > > > > their approval in> > place of Wolfgang (the message will be cc'ed to > > > > all relevant> > parties, including Wolfgang). > > > > If the above > > > > suggestions are unacceptable and you have an alternative> > solution, > > > > please let us know. > > > > Thank you.> > > > RFC Editor> > > > On > > > > Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I > > > > wrote to Wolfgang as well, but got no response. What is the> > > > > > procedure> > > in this case? I am sure that Wolfgang would be ok with > > > > the changes.> > The> > > last email I received was on October 19 > > > > where he said that he had> made> > > the one correction (suggested by > > > > Ellermann) in the cnonce value. > > > > > > Baruch> > > > > > > > > > > > > -----Original Message-----> > > From: RFC Editor > > > > [mailto:rfc-editor@rfc-editor.org] > > > Sent: Wednesday, November > > > > 21, 2007 10:35 PM> > > To: David Williams; Baruch Sterman; > > > > dscreat@dscreat.com; David> > Schwartz;> > > beckw@t-systems.com> > > > > > > Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC> > > > > > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090> > > > > > > > > NOW AVAILABLE> > > > > > > > > > Greetings Wolfgang,> > > > > > We do not believe we have received > > > > your response regarding this> > > document's readiness for > > > > publication as an RFC. Please review the> > > text and let us know if > > > > you are content with the document as it now> > > appears at:> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > Note > > > > that this diff file highlights only the changes between the> last > > > > > > > posted version of the document and the current text file.> > > > > > > > > > > > > The last versions of the document are available as:> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html> > > > > > > Note that this diff file highlights only the changes between v1 and> > > > > > > the v2.> > > > > > We will wait to hear from you before > > > > continuing on with the> > > publication process.> > > > > > Thank > > > > you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at > > > > 05:13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We > > > > have corrected the text as indicated below and posted the> revised> > > > > > > > version of the document at:> > > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > Note that this diff file highlights only the changes betwee the> > > > > last> > > > > > posted version of the document and the current text > > > > file.> > > > > > > > Please review the document and let us know if > > > > you approve this> > > > text for publication.> > > > > > > > We > > > > believe we are waiting for the following approvals:> > > > > > > > > > > > Baruch Sterman - done > > > > Daniel Sadolevsky - done> > > > David > > > > Schwartz - done> > > > David Williams> > > > Wolfgang Beck> > > > > > > > > > > > Bernard Aboba - done> > > > > > > > > > > > Thank you.> > > > > > > > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov 06, 2007 at > > > > 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > > > > > > > > > > > Please confer and let us know how the text should/should not use> > > > > > the> > > > > quote marks. It sounds as though this email was for > > > > discussion.> > If> > > > > the changes below are acceptable, we will > > > > make the changes and> > post> > > a> > > > > revised version of the > > > > document.> > > > > > > > > > Also, please note the following status > > > > of document approvals:> > > > > > > > > > Baruch Sterman - done > > > > (although we would like to know if you> agree> > > > > with the > > > > changes described below)> > > > > Daniel Sadolevsky - done> > > > > > > > > David Schwartz> > > > > David Williams> > > > > Wolfgang Beck> > > > > > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will wait to > > > > hear further before continuing on with the> > > publication> > > > > > > > > process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor> > > > > > > > > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, > > > > David Williams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > > > > > > These look good, and I agree with your consistency comment. I> > > > > > > have a few > > > > > > more specific changes to suggest that I would > > > > like you and> > others> > > to > > > > > > review as well. But first > > > > a couple of general style comments> > that> > > require > > > > > > > > > > no changes to the document.> > > > > > > > > > > > General comment > > > > #1: I tried to find a definitive style guide> to> > > use of > > > > > > > > > > single quotes versus double quotes and found there is no hard> > > > > > > guidelines, > > > > > > that consistency is most important:> > > > > > > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > > > > > > http://forum.wordreference.com/showthread.php?t=120946> > > > > > > > > > Though I tend to think that double quotes are more commonly> used> > > > > > > and match > > > > > > the syntax of more popular programming > > > > languages, but there> are> > so> > > many > > > > > > quoted items in > > > > the document and it has been this way for a> long> > > time, so > > > > > > > > > > best to leave as is.> > > > > > > > > > > > General comment #2: > > > > When refering to responses from the radius> > > server > > > > > > > > > > there are a lot of instances of a comment similiar to "without> > > > > > > surrounding > > > > > > quotes" that potentially could be removed for > > > > readability.> > > Especially if > > > > > > there were a more concise > > > > definition up-front about the> general> > > form of > > > > > > > > > > values returned from the radius server. But I am a little> > > > > > > hesitant to > > > > > > just strip them out now.> > > > > > > > > > > > > > > > Specific comments, to build on top of your list:> > > > > > > > > > > > > > > > In section 2.1.2, 1st paragraph should not have quotes around> > > > > > > nonce. > > > > > > Paragraph should read:> > > > > > > > > > > > If > > > > a matching (Proxy-)Authorization header is present and> > > contains> > > > > > > > > > HTTP Digest information, the RADIUS client checks the > > > > nonce> > > > > > parameter.> > > > > > > > > > > > In next paragraph, > > > > do not need quotes around response.> > Paragraph> > > should > > > > > > > > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the > > > > nonce, it takes the> > header> > > > > > directives and puts them > > > > into a RADIUS Access-Request> packet.> > > It> > > > > > puts the > > > > response directive into a Digest-Response> attribute> > > and> > > > > > > > > > the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,> > > > > > > username,> > > > > > and opaque directives into the respective > > > > Digest-Realm,> > > Digest-Nonce,> > > > > > Digest-URI, Digest-Qop, > > > > Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > > > Nonce-Count, > > > > Digest-Username, and Digest-Opaque attributes.> > > The> > > > > > > > > > RADIUS client puts the request method into the> Digest-Method> > > > > > > > > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to > > > > the items you point out, in> the> > > last > > > > > > paragraph, > > > > nextnounce does not need quoting. Paragraph> should> > > read:> > > > > > > > > > > > > > > > When the RADIUS server provides a Digest-Nextnonce> > > > > attribute> > in> > > the> > > > > > Access-Accept packet, the RADIUS > > > > client puts the contents> of> > > this> > > > > > attribute into a > > > > nextnonce directive. Now it can send an> > HTTP-> > > > > > style > > > > response.> > > > > > > > > > > > In section 2.1.4, 2nd paragraph, the > > > > stale directive should> not> > > need > > > > > > quoting. Paragraph > > > > should read:> > > > > > > > > > > > If the RADIUS client receives an > > > > Access-Challenge packet 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> > > > > > surrounding quotes), the > > > > RADIUS client sends an error> > response> > > (401> > > > > > or 407) > > > > containing a WWW-/Proxy-Authenticate header with> the> > > > > > > > > > directive stale and the digest directives derived from the> > > > > > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I think > > > > the wording of the last sentence in this same> > > paragraph > > > > > > > > > > could be improved. So that the paragraph reads more like:> > > > > > > > > > > > > > > > If the RADIUS client receives an Access-Challenge > > > > packet 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> > > > > > surrounding quotes), the RADIUS client sends an > > > > error> > response> > > (401> > > > > > or 407) containing a > > > > WWW-/Proxy-Authenticate header with> the> > > > > > stale directive > > > > set to 'true' and the digest directives> > derived> > > from> > > > > > > > > > the Digest-* attributes.> > > > > > > > > > > > In section 3.10, > > > > 1st paragraph, I believe the term "qop-level"> > is> > > ill > > > > > > > > > > defined and should not be used, that qop directive or> qop-value> > > > > > > would be > > > > > > better. In other words the paragraph should > > > > read:> > > > > > > > > > > > When using the qop-value 'auth-int', a > > > > hash of the> > > HTTP-style> > > > > > message body's contents is > > > > required for digest> > > calculation.> > > > > > Instead of sending > > > > the complete body of the message,> > only> > > its> > > > > > hash > > > > value is sent. This hash value can be used> > directly> > > in> > > > > > > > > > the digest calculation.> > > > > > > > > > > > In section 3.15, > > > > auth-param doesn't need quoting. So that the> > > paragraph > > > > > > > > > > becomes:> > > > > > > > > > > > This attribute is a placeholder for > > > > future extensions> > and> > > > > > corresponds to the auth-param > > > > parameter defined in> > > Section> > > > > > 3.2.1 of [RFC2617]. The > > > > Digest-Auth-Param is the> > > mechanism> > > > > > whereby the RADIUS > > > > client and RADIUS server can> > exchange> > > auth-> > > > > > param > > > > extension parameters contained within Digest> > > headers that> > > > > > > > > > are not understood by the RADIUS client and for which> > > there > > > > are> > > > > > no corresponding stand-alone attributes.> > > > > > > > > > > > > > > > In section 3.17, domain doesn't need quoting. So that the> > > > > > > paragraph > > > > > > becomes:> > > > > > > > > > > > When a > > > > RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > > > > > > > MAY send one or more Digest-Domain attributes in its> > > Access-> > > > > > > > > > Challenge packet. The RADIUS client puts them into> the> > > > > > > quoted,> > > > > > space-separated list of URIs of the domain > > > > directive> of> > a> > > > > > WWW-Authenticate header. Together with > > > > Digest-Realm,> > the> > > URIs> > > > > > in the list define the > > > > protection space (see> [RFC2617],> > > Section> > > > > > 3.2.1) for > > > > some HTTP-style protocols. This attribute> > > MUST only> > > > > > > > > > be used in Access-Challenge and Accounting-Request> > > packets.> > > > > > > > > > > > > > > > In section 3.19, 1st paragraph, in addtion to no > > > > quotes around> > > rspauth as > > > > > > you pointed out, I believe > > > > there should be no quotes around> qop.> > > So that > > > > > > the > > > > paragraph reads:> > > > > > > > > > > > This attribute is used to > > > > allow the generation of an> > > > > > Authentication-Info header, > > > > even if the HTTP-style> > > response's> > > > > > body is required > > > > for the calculation of the rspauth> > > value.> > > > > > It SHOULD > > > > be used in Access-Accept packets if the> > > required> > > > > > > > > > quality of protection (qop) is 'auth-int'.> > > > > > > > > > > > > > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri, 19 Oct 2007, > > > > 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After lengthy > > > > discussions with my father-in-law who is a> > > professor of> > > > > > > > > > >English, I agree with Dave's method of using quotes only in> the> > > > > > > value of> > > > > > >an attribute/directive, but not in > > > > referencing the> > > attribute/directive> > > > > > >by name. As > > > > such, I have some changes.> > > > > > >> > > > > > >In section 2.1.3 > > > > 3rd paragraph should not have quotes around> > the> > > word> > > > > > > > > > >rspauth. Sentence should read:> > > > > > >> > > > > > > * If the > > > > Digest-Qop attribute's value is 'auth' or not> > > specified,> > > > > > > > > > > the RADIUS client puts the Digest-Response-Auth> > > > > > > attribute's> > > > > > > content into the Authentication-Info > > > > header's rspauth> > > > > > > directive of the HTTP-style response.> > > > > > > > > > >> > > > > > >Same section 5th paragraph - no quotes around > > > > qop and> > algorithm:> > > > > > >> > > > > > > o If the > > > > Access-Accept packet contains a Digest-HA1> > attribute,> > > the> > > > > > > > > > > RADIUS client checks the qop and algorithm directives in> > > > > > the> > > > > > > Authorization header of the HTTP-style request it > > > > wants> to> > > > > > > authorize:> > > > > > >> > > > > > >Next > > > > paragraph - no quotes around qop> > > > > > >> > > > > > > * If the > > > > qop directive is missing or its value is> 'auth',> > > the> > > > > > > > > > > RADIUS client ignores the Digest-HA1 attribute. It> > does> > > > > > > not> > > > > > > include an Authentication-Info header in its> > > > > HTTP-style> > > > > > > response.> > > > > > >> > > > > > >Next > > > > paragraph - no quotes around qop or rspauth.> > > > > > >> > > > > > > > > > > * If the qop directive's value is 'auth-int' and at> least> > > > > > > one> > > > > > > of the following conditions is true, the RADIUS> > > > > client> > > > > > > calculates the contents of the HTTP-style > > > > response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > > > > > > > >> > > > > > >2 paragraphs later - no quotes around rspauth> > > > > > > > > > >> > > > > > > The RADIUS client creates the HTTP-style response> > > > > > message> > > and> > > > > > > calculates the hash of this message's > > > > body. It uses> > the> > > result> > > > > > > and the Digest-URI > > > > attribute's value of the> > corresponding> > > > > > > Access-Request > > > > packet to perform the H(A2)> calculation.> > > It> > > > > > > takes > > > > the Digest-Nonce, Digest-Nonce-Count,> > > Digest-CNonce, and> > > > > > > > > > > Digest-Qop values of the corresponding Access-Request> > and> > > > > > > the> > > > > > > Digest-HA1 attribute's value to finish the> > > > > computation> > of> > > the> > > > > > > rspauth value.> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no > > > > quotes around rspauth> > > > > > >> > > > > > > This attribute > > > > enables the RADIUS server to prove> > > possession of> > > > > > > > > > > the password. If the previously received Digest-Qop> > > attribute> > > > > > > > > > > was 'auth-int' (without surrounding 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 packets. The RADIUS client> > puts> > > the> > > > > > > > > > > attribute value without surrounding quotes into the> > > rspauth> > > > > > > > > > > directive of the Authentication-Info header.> > > > > > > > > > >> > > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes > > > > around nextnonce> > > > > > >> > > > > > > The RADIUS server MAY put > > > > a Digest-Nextnonce> attribute> > > into an> > > > > > > Access-Accept > > > > packet. If this attribute is present,> > the> > > RADIUS> > > > > > > > > > > client MUST put the contents of this attribute into> the> > > > > > > > > > > nextnonce directive of an Authentication-Info header> in> > > its> > > > > > > > > > > HTTP-style response. This attribute MUST only be> used> > > > > > in> > > > > > > Access-Accept packets.> > > > > > >> > > > > > >> > > > > > > > > > >Section 3.7, 4th paragraph - no quotes around uri> > > > > > > > > > >> > > > > > > If the HTTP-style request has an Authorization> > > > > header,> > > the> > > > > > > RADIUS client puts the value of the uri > > > > directive> found> > > in> > > > > > > the HTTP-style request > > > > Authorization header (known as> > > "digest-> > > > > > > uri-value" > > > > in Section 3.2.2 of [RFC2617]) without> > > surrounding> > > > > > > > > > > quotes into this attribute. If there is no> > Authorization> > > > > > > > > > > header, the RADIUS client takes the value of the> > request> > > > > > > URI> > > > > > > from the HTTP-style request it wants to > > > > authenticate.> > > > > > >> > > > > > >> > > > > > >Section 3.8, 4th > > > > paragraph - no quotes around qop> > > > > > >> > > > > > > In > > > > Access-Requests, the RADIUS client takes the value> > of> > > the> > > > > > > > > > > qop directive (qop-value as described in [RFC2617])> > > > > > from> > > the> > > > > > > HTTP-style request it wants to > > > > authenticate. In> > Access-> > > > > > > Challenge packets, the > > > > RADIUS server puts a desired> > > qop-value> > > > > > > into this > > > > attribute. If the RADIUS server supports> > more> > > than> > > > > > > > > > > one "quality of protection" value, it puts each> > qop-value> > > > > > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> > > > > > > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > > > > > > >> > > > > > > This attribute is sent by a RADIUS server in order to> > > > > > > notify> > > > > > > the RADIUS client whether it has accepted a > > > > nonce.> If> > > the> > > > > > > nonce presented by the RADIUS client > > > > was stale, the> > value> > > is> > > > > > > 'true' and is 'false' > > > > otherwise. The RADIUS client> > puts> > > the> > > > > > > content of > > > > this attribute into a stale directive of> the> > > WWW-> > > > > > > > > > > Authenticate header in the HTTP-style response to the> > > request> > > > > > > > > > > it wants to authenticate. The attribute MUST only be> > > > > > > used in> > > > > > > Access-Challenge packets.> > > > > > >> > > > > > > > > > >3.19 1st paragraph - no quotes around rspauth> > > > > > >> > > > > > > > > > > This attribute is used to allow the generation of an> > > > > > > > > > > Authentication-Info header, even if the HTTP-style> > > response's> > > > > > > > > > > body is required for the calculation of the rspauth> > > > > > > value.> > > > > > > It SHOULD be used in Access-Accept packets if > > > > the> > > required> > > > > > > quality of protection ('qop') is > > > > 'auth-int'.> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > >I think that does it. Even if this is not right, at least it> > > > > > > should now> > > > > > >be consistent.> > > > > > >> > > > > > > > > > >Comments?> > > > > > >> > > > > > >Baruch> > > > > > >> > > > > > >> > > > > > > > > > >> > > > > > >-----Original Message-----> > > > > > >From: > > > > RFC Editor [mailto:rfc-editor@rfc-editor.org]> > > > > > >Sent: > > > > Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> > > > > > > > > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;> > > > > > > > > > >beckw@t-systems.com; radext-ads@tools.ietf.org;> > > > > > > > > > >radext-chairs@tools.ietf.org; RFC Editor> > > > > > >Subject: Re: > > > > AUTH48 [SG]: RFC 5090> > > > > > > > > > > > > >NOW AVAILABLE> > > > > > >> > > > > > >Greeting all,> > > > > > > > > > >> > > > > > >We have not heard further regarding the issues below > > > > or other> > > changes> > > > > > >that may be required before > > > > publishing this document as an> RFC.> > > > > > >Please review the > > > > document and let us know if there are any> > > > > > >corrections > > > > required.> > > > > > >> > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > > > >> > > > > > >We will wait to hear from you before continuing on > > > > with the> > > > > > >publication process.> > > > > > >> > > > > > > > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> > > > > > > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> > > > > > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > > > > > > >>> > > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While > > > > reviewing > during> > > AUTH48,> > > > > > > > > > >>>please consider the following.> > > > > > >>>> > > > > > > > > > >>>In previous dialog, we had the following exchange:> > > > > > >>>> > > > > > > > > > >>>>>2. Please explain the usage of the single quote marks > > > > (')> > in> > > > > > >>>>>this document. There seems to be > > > > inconsistency, but we> are> > > > > > >>>>>unable to determine which > > > > values/attributes/parameters> you> > > > > > >>>>>wanted to appear in > > > > quote marks. For example, we see> > > > > > >>>>>> > > > > > > > > > >>>>>'auth-int'/"auth-int"> > > > > > >>>>>'rspauth' > > > > directive/rspauth directive> > > > > > >>>>>'rspauth' value/rspauth > > > > value> > > > > > >>>>>> > > > > > >>>>As RfC 2617 always uses ", > > > > replacing all 's in question> with> > "> > > seems> > > > > > >>>>the > > > > right thing to do.> > > > > > >>>> > > > > > >>>Please note that we > > > > did not replace all 's with "s because> > > > > > >>>RFC 4590 uses > > > > 's. However, if you feel that the document> > > should be> > > > > > > > > > >>>more alignmed with RFC 2617, please let us know and we will> > > > > > > make> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are > > > > taking a vote, I would prefer using " instead of '> > > around> > > > > > > > > > >the> > > > > > >>value strings. I think it is better to stay > > > > aligned with> 2617> > > rather> > > > > > >than> > > > > > >>4590. > > > > Also I believe the " usage is more commonly used in> > other> > > > > > > > > > >>specifications.> > > > > > >>> > > > > > >>>> > > > > > >>>Also, > > > > we had a difficult time understanding the use of 's.> > We> > > > > > > > > > >>>inserted 's around auth-int, auth, qop, and rspauth when> they> > > > > > > were> > > > > > >>>used as values or directives. However, we did > > > > not attempt> to> > > include> > > > > > >>>'s for *all* directives > > > > and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let > > > > us know if this is not correct.> > > > > > >>> > > > > > >>I agree it > > > > is confusing. Looking at 2617 I don't think it> is> > > entirely> > > > > > > > > > >> > > > > > >>consistent either, as I see references to ["qop" > > > > directive]> as> > > well as> > > > > > >the> > > > > > >>unquoted > > > > form [qop directive].> > > > > > >>> > > > > > >>I am no authority on > > > > style but my initial thought is to> > suggest> > > > > > >removing '> > > > > > > > > > >>and " from keywords when refering to a directive name > > > > rather> > > than its> > > > > > >>literal value, and then use "" when > > > > refering to a value.> For> > > example,> > > > > > >the> > > > > > > > > > >>existing 5090 text would then become:> > > > > > >>> > > > > > > > > > >>> > > > > > >> o If the Access-Accept packet contains a > > > > Digest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the > > > > qop and algorithm directives> in> > > the> > > > > > >> Authorization > > > > header of the HTTP-style request it> wants> > to> > > > > > >> > > > > authorize:> > > > > > >>> > > > > > >> * If the qop directive is > > > > missing or its value is> > "auth",> > > the> > > > > > >> RADIUS > > > > client ignores the Digest-HA1 attribute. It> > > does not> > > > > > > > > > >> include an Authentication-Info header in its> > HTTP-style> > > > > > > > > > >> response.> > > > > > >>> > > > > > >>> > > > > > > > > > >>However when examing 2617 in more detail, using " around the> > > > > > > directive> > > > > > >> > > > > > >>names would be more consistent > > > > with that draft. For example> > > this> > > > > > >would> > > > > > > > > > >>become:> > > > > > >>> > > > > > >>> > > > > > > > > > >> o If the Access-Accept packet contains a Digest-HA1> > > > > > > attribute, the> > > > > > >> RADIUS client checks the "qop" and > > > > "algorithm"> > directives> > > in the> > > > > > >> Authorization > > > > header of the HTTP-style request it> wants> > to> > > > > > >> > > > > authorize:> > > > > > >>> > > > > > >> * If the "qop" directive is > > > > missing or its value is> > > "auth", the> > > > > > >> RADIUS client > > > > ignores the Digest-HA1 attribute. It> > > does not> > > > > > >> > > > > include an Authentication-Info header in its> > HTTP-style> > > > > > > > > > >> response.> > > > > > >>> > > > > > >>> > > > > > > > > > >>Prehaps others can weigh in one which they believe is most> > > > > > > > > > >appropriate.> > > > > > >>I believe either would be a > > > > slight improvement on the> existing> > > text> > > > > > >which> > > > > > > > > > >>uses single quotes around the string values.> > > > > > >>> > > > > > > > > > >>thanks,> > > > > > >>-david> > > > > > >>> > > > > > >>>> > > > > > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RFC Editor> > > > > > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 at > > > > 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org> > > > > > >wrote:> > > > > > > > > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > > > > > > > > > >>>>Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC > > > > AUTHOR(S):> > > > > > >>>>--------------> > > > > > >>>>> > > > > > > > > > >>>>This is your LAST CHANCE to make changes to your RFC to> be:> > > > > > > > > > >>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> > > > > > > published> > > > > > >as> > > > > > >>>>an RFC we *WILL NOT* make > > > > any changes.> > > > > > >>>>> > > > > > >>>>Please check your > > > > document at:> > > > > > >>>>> > > > > > > > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > > > >>>>> > > > > > >>>>ATTENTION: The editing process occasionally > > > > introduces> > errors> > > that> > > > > > >>>>were not in the > > > > Internet Draft. Although the RFC Editor> > tries> > > very> > > > > > > > > > >>>>hard to catch all errors, proofreading the text at least> > > > > > > twice,> > > > > > >typos> > > > > > >>>>can slip through. You, as an > > > > author of the RFC, are> taking> > > > > > >>>>responsibility for the > > > > correctness of the final product> when> > > you OK> > > > > > > > > > >>>>publication. You should therefore proofread the entire> RFC> > > > > > > > > > >carefully> > > > > > >>>>and without assumptions. Errors in > > > > RFCs last forever.> > > > > > >>>>> > > > > > >>>>NOTE: We have run a > > > > diff tool that compares the approved> > > > > > >internet-draft> > > > > > > > > > >>>>against our edited RFC version of the document. Please> > > > > > review> > > this> > > > > > >>>>file at:> > > > > > >>>>> > > > > >> > > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > > > >>>>> > > > > > >>>>Please note that we used a slightly altered > > > > version of the> > > > > > >originally> > > > > > >>>>submitted ID to > > > > create the diff file above. To make the> > file> > > more> > > > > > > > > > >>>>useful, we moved the terminology section to to appear> after> > > > > > > the> > > > > > >>>>introduction, but we did not alter the text.> > > > > > > > > > >>>>> > > > > > >>>>The document will NOT BE PUBLISHED until > > > > ALL of the> authors> > > listed> > > > > > >in> > > > > > >>>>the RFC > > > > have affirmed that the document is ready to be> > > > > > > > > > >>>>published, as ALL of the authors are equally responsible> for> > > > > > > > > > >verifying> > > > > > >>>>the documents readiness for > > > > publication.> > > > > > >>>>> > > > > > >>>>** Please send us a list > > > > of suitable keywords for this> > > document,> > > > > > >over> > > > > > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> > > > > > > > > > >>>> Frequently INCORRECT information includes> > > > > > > > > > >>>>> > > > > > >>>> - Contact Information> > > > > > >>>> - > > > > References (are they up to date)> > > > > > >>>> - Section Numbers> > > > > > > > > > >>>> (especially if you originally put the copyright> > > > > > > > > > >somewhere> > > > > > >>>> other than the VERY end of the document, > > > > or if> > you> > > > > > >>>> numbered the 'Status of the Memo' > > > > field)> > > > > > >>>>> > > > > > >>>>Please send us the changes, *DO > > > > NOT* send a new document> > with> > > the> > > > > > >>>>changes > > > > made. (If we think that the changes might be more> > > than> > > > > > > > > > >>>>editorial we will contact the AD or the IESG to confirm> that> > > > > > > the> > > > > > >>>>changes do not require review.)> > > > > > > > > > >>>>> > > > > > >>>>Send us the changes in THIS format.> > > > > > > > > > >>>>> > > > > > >>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > > > > > > paragraph]> > > > > > >>>> 2) the text you want changed,> > > > > > > > > > >>>> 3) the new correct text and> > > > > > >>>> 4) if the changes > > > > are spacing or indentation> than> > > please> > > > > > >note> > > > > > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>>FOR EXAMPLE:> > > > > > > > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> > > > > > >>>>> > > > > > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jumped over the > > > > lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> The > > > > quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> > > > > > > > > > >>>>If you have a whole paragraph to replace you do not need> > > > > to> > > use> > > > > > >>>>the arrow to point out the differences> > > > > > > > > > >>>>> > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > > > > > > >>>>> > > > > > >>>> Replace OLD:> > > > > > >>>>> > > > > > >>>> > > > > alsdfja;sldjf;lajsd;fljas;dlfj;> > > > > > >>>>> > > > > > >>>> With > > > > NEW:> > > > > > >>>>> > > > > > >>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > > > > > >>>>> > > > > > >>>>Spacing or indentation problems...> > > > > > > > > > >>>>> > > > > > >>>> Section 10, 1st paragraph (remove spaces> > > > > between> > > bit> > > > > > >>>> and of, add space after butter)> > > > > > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > > > >>>> > > > > Better botter bought a bit> > > > > > >>>> of bitter butterMary mary > > > > quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>> > > > > > > > > > >>>> Better botter bought a bit of bitter butter> > > > > > > > > > >>>>> > > > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > > > > > > > > >>>>This document will NOT be published until we receive> > > > > > > agreement, from> > > > > > >>>>ALL listed authors, that the document > > > > is ready for> > > publication.> > > > > > >>>>> > > > > > >>>>Thanks > > > > for your cooperation,> > > > > > >>>>> > > > > > >>>>-RFC Editor> > > > > > > > > > >>>>> > > > > > >>>>> > > > > > >>>>Title : RADIUS Extension > > > > for Digest> > > > > > >>>> Authentication> > > > > > >>>>Author(s) : > > > > B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz, D. Williams,> > > > > > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s) : > > > > Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan > > > > Romascanu, Ronald Bonica> > > > > > >>>> > > > > > > -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 23 02:52:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Lcv-00044q-DR for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 02:52:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6Lcs-0002yQ-6h for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 02:52:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6LYr-000AlJ-Eu for radiusext-data@psg.com; Sun, 23 Dec 2007 07:47:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.98] (helo=bay0-omc1-s26.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6LYW-000AkS-Ib for radiusext@ops.ietf.org; Sun, 23 Dec 2007 07:47:38 +0000 Received: from BAY117-W25 ([207.46.8.60]) by bay0-omc1-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Dec 2007 23:47:28 -0800 Message-ID: X-Originating-IP: [71.197.208.131] From: Bernard Aboba To: Mike McCauley CC: Subject: RE: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sat, 22 Dec 2007 23:47:28 -0800 Importance: Normal In-Reply-To: <200712231550.38670.mikem@open.com.au> References: <20071107005849.GC28431@isi.edu> <20071221231446.GB5266@isi.edu> <200712231550.38670.mikem@open.com.au> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2007 07:47:28.0628 (UTC) FILETIME=[1107FB40:01C84538] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 The test vectors in Section 6 are one of the major open questions. Wolfgan= g did the original checks, but subsequent reviewers kept finding errors in = them, so they have been revised several times.=20 What do you think is wrong with the B->C messages?=20 ---------------------------------------- > From: mikem@open.com.au > To: bernard_aboba@hotmail.com > Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE > Date: Sun, 23 Dec 2007 15:50:37 +1000 > CC: radiusext@ops.ietf.org >=20 > Hi Bernard, >=20 > Have the test vectors in section 6 Examples been checked? How? Im not sur= e I=20 > entirely agree with the Digest-Response values in the B->C messages >=20 > Cheers. >=20 > On Sunday 23 December 2007 03:37, Bernard Aboba wrote: >> RFC 4590bis is now being held in AUTH48, pending final verification. >> >> What started as a "simple" IANA-problem fix has turned into a longer >> odyssey due to the discovery of additional errors/omissions. >> >> In attempt to bring this story to a close, we need to make very sure tha= t >> we have looked over this document carefully so that we don't have to go >> through this again with RFC 4590ter. >> >> So if you have ever had any interest in RADIUS Digest Authentication, no= w >> would be the time to look over the AUTH48 version of the document, and >> speak up if there is a problem. >> >>> Date: Fri, 21 Dec 2007 15:14:46 -0800 >>> From: rfc-editor@rfc-editor.org >>> To: beckw@t-systems.com >>> CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; >>> dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; >>> rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; >>> rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090=20 >>> NOW AVAILABLE >>> >>> Greeings Wolfgang, >>> >>> Just a reminder that we are waiting to hear from you before continuing >>> on with the publication process. >>> >>> Please see the email below for document information. >>> >>> Thank you. >>> >>> RFC Editor >>> >>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: >>>> Hi Wolfgang, >>>> >>>> Just a friendly reminder that we are waiting to hear from you before >>>> continuing on with the publication process for RFC 5090 >>>> . >>>> >>>> Please review the files located at: >>>> >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html >>>> >>>> Note that this diff file highlights only the differences between the >>>> last posted version of the document and the current text file. The >>>> previously posted versions (during AUTH48) are available as: >>>> >>>> The originally posted AUTH48 files: >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html >>>> >>>> Version 2 (includes author updates) of AUTH48 files: >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html >>>> Note that this file highlights only the differences between the >>>> version 1 and 2 text files. >>>> >>>> We will wait to hear from you before continuing on with the >>>> publication process. >>>> >>>> Thank you. >>>> >>>> RFC Editor/sg >>>> >>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: >>>>> I also talked to Wolfgang at IETF 70. He wanted to check the >>>>> document over carefully to make sure there were no further issues. =20 >>>>>> Subject: RE: AUTH48 [SG]: RFC 5090 >>>>> NOW AVAILABLE> Date: Mon, 10 >>>>> Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: >>>>> rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: >>>>> david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; >>>>> dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; >>>>> d.b.nelson@comcast.net>> Yes,>> David Schwartz saw him at the ietf >>>>> meeting and worked through the draft> with him. I think we should be >>>>> hearing from him soon.>> Baruch>>> -----Original Message-----> >>>>> From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> Sent: Monday, >>>>> December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> >>>>> Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; >>>>> dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; >>>>> Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: >>>>> AUTH48 [SG]: RFC 5090 > NOW >>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck >>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27, >>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz >>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be >>>>> there and he can nudge him to answer. Lets hold off until we> see>> >>>>> if that way forward works. If not, we can go with option 3.>>>> >>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From: >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>> Sent: Tuesday, >>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>> >>>>> Subject: Re: AUTH48 [SG]: RFC 5090> >>>>> >> NOW AVAILABLE>>>> Hi >>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1. >>>>> The author can be removed as an author, and moved to the>> >>>>> Acknowledgements section.>>>> 2. We can create a Contributor's >>>>> section and have him listed there.>>>> 3. We can request that the >>>>> AD approve the document in place of the>> unavailabe author.>>>> >>>>> Option 3 has been done before in instances where the missing author> >>>>>> made sizeable contributions to the document, so the other authors> >>>>>> did not feel comfortable removing the individuals name as an>> >>>>> author.>>>> It sounds as though 3 may be the proper way forward. >>>>> If this is the>> case, we will send an email to the ADs requesting >>>>> their approval in>> place of Wolfgang (the message will be cc'ed to >>>>> all relevant>> parties, including Wolfgang).>>>> If the above >>>>> suggestions are unacceptable and you have an alternative>> solution, >>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On >>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I >>>>> wrote to Wolfgang as well, but got no response. What is the>> >>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with >>>>> the changes.>> The>>> last email I received was on October 19 >>>>> where he said that he had> made>>> the one correction (suggested by >>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>> >>>>> -----Original Message----->>> From: RFC Editor >>>>> [mailto:rfc-editor@rfc-editor.org]>>> Sent: Wednesday, November >>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman; >>>>> dscreat@dscreat.com; David>> Schwartz;>>> beckw@t-systems.com>>> >>>>> Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC>> >>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>> >>>>> >>> NOW AVAILABLE>>>>>> >>>>> Greetings Wolfgang,>>>>>> We do not believe we have received >>>>> your response regarding this>>> document's readiness for >>>>> publication as an RFC. Please review the>>> text and let us know if >>>>> you are content with the document as it now>>> appears at:>>>>> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note >>>>> that this diff file highlights only the changes between the> last>> >>>>>> posted version of the document and the current text file.>>>>> >>>>>>>>> The last versions of the document are available as:>>>>> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>> >>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>> >>>>> Note that this diff file highlights only the changes between v1 and> >>>>>>> the v2.>>>>>> We will wait to hear from you before >>>>> continuing on with the>>> publication process.>>>>>> Thank >>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at >>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We >>>>> have corrected the text as indicated below and posted the> revised>> >>>>>>> version of the document at:>>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>> >>>>> Note that this diff file highlights only the changes betwee the> >>>>> last>>>>>> posted version of the document and the current text >>>>> file.>>>>>>>> Please review the document and let us know if >>>>> you approve this>>>> text for publication.>>>>>>>> We >>>>> believe we are waiting for the following approvals:>>>>>>>> >>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David >>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>> >>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>> >>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at >>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>> >>>>>>> Please confer and let us know how the text should/should not use> >>>>>> the>>>>> quote marks. It sounds as though this email was for >>>>> discussion.>> If>>>>> the changes below are acceptable, we will >>>>> make the changes and>> post>>> a>>>>> revised version of the >>>>> document.>>>>>>>>>> Also, please note the following status >>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done >>>>> (although we would like to know if you> agree>>>>> with the >>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>> >>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>> >>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to >>>>> hear further before continuing on with the>>> publication>>>>> >>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor> >>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400, >>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>> >>>>> These look good, and I agree with your consistency comment. I>>> >>>>> have a few>>>>>> more specific changes to suggest that I would >>>>> like you and>> others>>> to>>>>>> review as well. But first >>>>> a couple of general style comments>> that>>> require>>>>>> >>>>> no changes to the document.>>>>>>>>>>>> General comment >>>>> #1: I tried to find a definitive style guide> to>>> use of>>>> >>>>>>> single quotes versus double quotes and found there is no hard>> >>>>>> guidelines,>>>>>> that consistency is most important:>>>> >>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>> >>>>> http://forum.wordreference.com/showthread.php?t=3D120946>>>>>> >>>>> Though I tend to think that double quotes are more commonly> used>> >>>>>> and match>>>>>> the syntax of more popular programming >>>>> languages, but there> are>> so>>> many>>>>>> quoted items in >>>>> the document and it has been this way for a> long>>> time, so>>> >>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2: >>>>> When refering to responses from the radius>>> server>>>>>> >>>>> there are a lot of instances of a comment similiar to "without>>> >>>>> surrounding>>>>>> quotes" that potentially could be removed for >>>>> readability.>>> Especially if>>>>>> there were a more concise >>>>> definition up-front about the> general>>> form of>>>>>> >>>>> values returned from the radius server. But I am a little>>> >>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>> >>>>>> Specific comments, to build on top of your list:>>>>>>>>>> >>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>> >>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If >>>>> a matching (Proxy-)Authorization header is present and>>> contains> >>>>>>>>>> HTTP Digest information, the RADIUS client checks the >>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph, >>>>> do not need quotes around response.>> Paragraph>>> should>>>> >>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the >>>>> nonce, it takes the>> header>>>>>> directives and puts them >>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the >>>>> response directive into a Digest-Response> attribute>>> and>>>> >>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>> >>>>> username,>>>>>> and opaque directives into the respective >>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop, >>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count, >>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>> >>>>> RADIUS client puts the request method into the> Digest-Method>>>> >>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to >>>>> the items you point out, in> the>>> last>>>>>> paragraph, >>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>> >>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce> >>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS >>>>> client puts the contents> of>>> this>>>>>> attribute into a >>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style >>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the >>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph >>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an >>>>> Access-Challenge packet 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>>>>>> surrounding quotes), the >>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407) >>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>> >>>>> directive stale and the digest directives derived from the>>> >>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think >>>>> the wording of the last sentence in this same>>> paragraph>>>> >>>>>>> could be improved. So that the paragraph reads more like:>>>> >>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge >>>>> packet 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>>>>>> surrounding quotes), the RADIUS client sends an >>>>> error>> response>>> (401>>>>>> or 407) containing a >>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive >>>>> set to 'true' and the digest directives>> derived>>> from>>>>> >>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10, >>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>> >>>>>>> defined and should not be used, that qop directive or> qop-value> >>>>>>> would be>>>>>> better. In other words the paragraph should >>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a >>>>> hash of the>>> HTTP-style>>>>>> message body's contents is >>>>> required for digest>>> calculation.>>>>>> Instead of sending >>>>> the complete body of the message,>> only>>> its>>>>>> hash >>>>> value is sent. This hash value can be used>> directly>>> in>>>> >>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15, >>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>> >>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for >>>>> future extensions>> and>>>>>> corresponds to the auth-param >>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The >>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS >>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param >>>>> extension parameters contained within Digest>>> headers that>>>> >>>>>>> are not understood by the RADIUS client and for which>>> there >>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>> >>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the> >>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a >>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>> >>>>>> MAY send one or more Digest-Domain attributes in its>>> Access-> >>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>> >>>>>> quoted,>>>>>> space-separated list of URIs of the domain >>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with >>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the >>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for >>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>> >>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>> >>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no >>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe >>>>> there should be no quotes around> qop.>>> So that>>>>>> the >>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to >>>>> allow the generation of an>>>>>> Authentication-Info header, >>>>> even if the HTTP-style>>> response's>>>>>> body is required >>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD >>>>> be used in Access-Accept packets if the>>> required>>>>>> >>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>> >>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007, >>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy >>>>> discussions with my father-in-law who is a>>> professor of>>>>> >>>>>>>English, I agree with Dave's method of using quotes only in> the> >>>>>>> value of>>>>>>>an attribute/directive, but not in >>>>> referencing the>>> attribute/directive>>>>>>>by name. As >>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3 >>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>> >>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the >>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>> >>>>>>>> the RADIUS client puts the Digest-Response-Auth>>> >>>>> attribute's>>>>>>> content into the Authentication-Info >>>>> header's rspauth>>>>>>> directive of the HTTP-style response.> >>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around >>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the >>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>> >>>>>>>>>> RADIUS client checks the qop and algorithm directives in>> >>>>> the>>>>>>> Authorization header of the HTTP-style request it >>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the >>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>> >>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>> >>>>> not>>>>>>> include an Authentication-Info header in its> >>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next >>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>> >>>>>> * If the qop directive's value is 'auth-int' and at> least>>> >>>>> one>>>>>>> of the following conditions is true, the RADIUS> >>>>> client>>>>>>> calculates the contents of the HTTP-style >>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>> >>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>> >>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response> >>>>>> message>>> and>>>>>>> calculates the hash of this message's >>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI >>>>> attribute's value of the>> corresponding>>>>>>> Access-Request >>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes >>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>> >>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>> >>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the> >>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no >>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute >>>>> enables the RADIUS server to prove>>> possession of>>>>>>> >>>>> the password. If the previously received Digest-Qop>>> attribute>> >>>>>>>>>> was 'auth-int' (without surrounding 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 packets. The RADIUS client>> puts>>> the>>>>> >>>>>>> attribute value without surrounding quotes into the>>> rspauth> >>>>>>>>>>> directive of the Authentication-Info header.>>>>>> >>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes >>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put >>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept >>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>> >>>>> client MUST put the contents of this attribute into> the>>>>>>> >>>>> nextnonce directive of an Authentication-Info header> in>>> its>> >>>>>>>>>> HTTP-style response. This attribute MUST only be> used>> >>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>> >>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>> >>>>>>>>>>>>> If the HTTP-style request has an Authorization> >>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri >>>>> directive> found>>> in>>>>>>> the HTTP-style request >>>>> Authorization header (known as>>> "digest->>>>>>> uri-value" >>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>> >>>>> quotes into this attribute. If there is no>> Authorization>>>>> >>>>>>> header, the RADIUS client takes the value of the>> request>>> >>>>> URI>>>>>>> from the HTTP-style request it wants to >>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In >>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>> >>>>>>>>>> qop directive (qop-value as described in [RFC2617])>> >>>>> from>>> the>>>>>>> HTTP-style request it wants to >>>>> authenticate. In>> Access->>>>>>> Challenge packets, the >>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this >>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>> >>>>>> one "quality of protection" value, it puts each>> qop-value>>> >>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>> >>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>> >>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to> >>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a >>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client >>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false' >>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of >>>>> this attribute into a stale directive of> the>>> WWW->>>>>>> >>>>> Authenticate header in the HTTP-style response to the>>> request>> >>>>>>>>>> it wants to authenticate. The attribute MUST only be>>> >>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>> >>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>> >>>>>>>> This attribute is used to allow the generation of an>>>>>> >>>>>> Authentication-Info header, even if the HTTP-style>>> response's> >>>>>>>>>>> body is required for the calculation of the rspauth>>> >>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if >>>>> the>>> required>>>>>>> quality of protection ('qop') is >>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>I think that does it. Even if this is not right, at least it> >>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>> >>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From: >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>>>>>>>Sent: >>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>> >>>>>>>>>Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>>> >>>>>>>>>beckw@t-systems.com; radext-ads@tools.ietf.org;>>>>>> >>>>>>radext-chairs@tools.ietf.org; RFC Editor>>>>>>>Subject: Re: >>>>> AUTH48 [SG]: RFC 5090>>> >>> >>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>> >>>>>>>>>>>>>>We have not heard further regarding the issues below >>>>> or other>>> changes>>>>>>>that may be required before >>>>> publishing this document as an> RFC.>>>>>>>Please review the >>>>> document and let us know if there are any>>>>>>>corrections >>>>> required.>>>>>>>>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>> >>>>>>>>>>>>>>We will wait to hear from you before continuing on >>>>> with the>>>>>>>publication process.>>>>>>>>>>>>> >>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>> >>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> >>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>> >>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While >>>>> reviewing > during>>> AUTH48,> >>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>> >>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>> >>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks >>>>> (')>> in>>>>>>>>>>>this document. There seems to be >>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which >>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in >>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>> >>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth' >>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth >>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ", >>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the >>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we >>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses >>>>> 's. However, if you feel that the document>>> should be>>>>>> >>>>>>>>more alignmed with RFC 2617, please let us know and we will>>> >>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are >>>>> taking a vote, I would prefer using " instead of '>>> around>>>> >>>>>>>>the>>>>>>>>value strings. I think it is better to stay >>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590. >>>>> Also I believe the " usage is more commonly used in>> other>>>>> >>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also, >>>>> we had a difficult time understanding the use of 's.>> We>>>>>> >>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>> >>>>>> were>>>>>>>>>used as values or directives. However, we did >>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives >>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let >>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it >>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>> >>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop" >>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted >>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on >>>>> style but my initial thought is to>> suggest>>>>>>>removing '> >>>>>>>>>>>>and " from keywords when refering to a directive name >>>>> rather>>> than its>>>>>>>>literal value, and then use "" when >>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>> >>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o If the Access-Accept packet contains a >>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the >>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> >>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is >>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS >>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>> >>>>>>> include an Authentication-Info header in its>> HTTP-style>>>> >>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>> >>>>>>>However when examing 2617 in more detail, using " around the>>> >>>>> directive>>>>>>>>>>>>>>>names would be more consistent >>>>> with that draft. For example>>> this>>>>>>>would>>>>>> >>>>>>>become:>>>>>>>>>>>>>>>>>>>> >>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>> >>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and >>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> >>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is >>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client >>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>> >>>>> include an Authentication-Info header in its>> HTTP-style>>>>>> >>>>>>> response.>>>>>>>>>>>>>>>>>> >>>>>>>>>>>Prehaps others can weigh in one which they believe is most> >>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a >>>>> slight improvement on the> existing>>> text>>>>>>>which>>> >>>>>>>>>>uses single quotes around the string values.>>>>>>>>>> >>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at >>>>> 03:11:50PM -0700,>>> rfc-editor@rfc-editor.org>>>>>>>wrote:> >>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>> >>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC >>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>> >>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>> >>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> >>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make >>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your >>>>> document at:>>>>>>>>>>>>>>>> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>> >>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally >>>>> introduces>> errors>>> that>>>>>>>>>>were not in the >>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>> >>>>>>>>>hard to catch all errors, proofreading the text at least>>> >>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an >>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the >>>>> correctness of the final product> when>>> you OK>>>>>> >>>>>>>>>publication. You should therefore proofread the entire> RFC>>> >>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in >>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a >>>>> diff tool that compares the approved>>>>>>>internet-draft>>> >>>>>>>>>>>>against our edited RFC version of the document. Please>> >>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> >>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered >>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to >>>>> create the diff file above. To make the>> file>>> more>>>>>> >>>>>>>>>useful, we moved the terminology section to to appear> after>>> >>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>> >>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until >>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC >>>>> have affirmed that the document is ready to be>>>>>> >>>>>>>>>published, as ALL of the authors are equally responsible> for>> >>>>>>>>>>verifying>>>>>>>>>>the documents readiness for >>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list >>>>> of suitable keywords for this>>> document,>>>>>>>over>>>> >>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>> >>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>> >>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> - >>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>> >>>>>>>>>>>>> (especially if you originally put the copyright>>>>> >>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document, >>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo' >>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO >>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes >>>>> made. (If we think that the changes might be more>>> than>>>>> >>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that> >>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>> >>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>> >>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>> >>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>> >>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes >>>>> are spacing or indentation> than>>> please>>>>>>>note>>>> >>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>> >>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>> >>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the >>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The >>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>> >>>>>>>>>>>>>If you have a whole paragraph to replace you do not need> >>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>> >>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>> >>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>> >>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With >>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> >>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>> >>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces> >>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>> >>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>> >>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary >>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>> >>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>> >>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>> >>>>>>>>>>>This document will NOT be published until we receive>>> >>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document >>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks >>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension >>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) : >>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,> >>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) : >>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan >>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>> >=20 > --=20 > Mike McCauley mikem@open.com.au > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW > 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.= au > Phone +61 7 5598-7474 Fax +61 7 5598-7070 >=20 > Radiator: the most portable, flexible and configurable RADIUS server=20 > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,=20 > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,=20 > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 23 04:12:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6Msv-0003wF-FC for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 04:12:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6Msq-00040M-Ea for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 23 Dec 2007 04:12:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6Mo5-000GjW-0b for radiusext-data@psg.com; Sun, 23 Dec 2007 09:07:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [218.214.125.86] (helo=zulu.open.com.au) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J6Mne-000Gh5-5a for radiusext@ops.ietf.org; Sun, 23 Dec 2007 09:07:26 +0000 Received: from localhost (localhost [IPv6:::1]) by zulu.open.com.au (Postfix) with ESMTP id DDCE68C376; Sun, 23 Dec 2007 19:07:08 +1000 (EST) From: Mike McCauley To: Bernard Aboba Subject: Re: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sun, 23 Dec 2007 19:07:08 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org References: <20071107005849.GC28431@isi.edu> <200712231550.38670.mikem@open.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231907.08645.mikem@open.com.au> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 578a6250515af634f1df71bcb88a4859 Hello Bernard, On Sunday 23 December 2007 17:47, Bernard Aboba wrote: > The test vectors in Section 6 are one of the major open questions. > Wolfgang did the original checks, but subsequent reviewers kept finding > errors in them, so they have been revised several times. > > What do you think is wrong with the B->C messages? I havent been able to reproduce the Digest-Response that is given the 2 samples in the RFC. I have some sample code that produces the correct digest result as given in RFC2617, but that same code gives Digest-Response different to that given in RFC5090 in both examples. Here is some sample code, FYI, in perl. You can see that its set up to test against either RFC2617 test data or RFC5090. The response it calculates for the RFC5090 test data is not the one given in the RFC use Digest::MD5; use strict; # RFC5090 web browser (second example) # FAILS #my $username = '12345678'; #my $realm = 'example.com'; #my $qop = 'auth'; #my $nonce = 'a3086ac8'; #my $cnonce = '56593a80'; #my $nc = '00000001'; #my $pw = 'secret'; #my $method = 'GET'; #my $uri = '/index.html'; #my $expected = 'ba623217b5ec024d30c4aaef9d8494de'; # RFC2617 OK: my $username = 'Mufasa'; my $realm = 'testrealm@host.com'; my $qop = 'auth'; my $nonce = 'dcd98b7102dd2f0e8b11d0f600bfb0c093'; my $cnonce = '0a4f113b'; my $nc = '00000001'; my $pw = 'Circle Of Life'; my $method = 'GET'; my $uri = '/dir/index.html'; my $expected = '6629fae49393a05397450978507c4ef1'; # auth my $ha1 = Digest::MD5::md5_hex("$username:$realm:$pw"); my $ha2 = Digest::MD5::md5_hex("$method:$uri"); my $response = Digest::MD5::md5_hex("$ha1:$nonce:$nc:$cnonce:$qop:$ha2"); print $response eq $expected ? "OK\n" : "WRONG RESPONSE\n"; Hope that helps. Cheers. > > > ---------------------------------------- > > > From: mikem@open.com.au > > To: bernard_aboba@hotmail.com > > Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE > > Date: Sun, 23 Dec 2007 15:50:37 +1000 > > CC: radiusext@ops.ietf.org > > > > Hi Bernard, > > > > Have the test vectors in section 6 Examples been checked? How? Im not > > sure I entirely agree with the Digest-Response values in the B->C > > messages > > > > Cheers. > > > > On Sunday 23 December 2007 03:37, Bernard Aboba wrote: > >> RFC 4590bis is now being held in AUTH48, pending final verification. > >> > >> What started as a "simple" IANA-problem fix has turned into a longer > >> odyssey due to the discovery of additional errors/omissions. > >> > >> In attempt to bring this story to a close, we need to make very sure > >> that we have looked over this document carefully so that we don't have > >> to go through this again with RFC 4590ter. > >> > >> So if you have ever had any interest in RADIUS Digest Authentication, > >> now would be the time to look over the AUTH48 version of the document, > >> and speak up if there is a problem. > >> > >>> Date: Fri, 21 Dec 2007 15:14:46 -0800 > >>> From: rfc-editor@rfc-editor.org > >>> To: beckw@t-systems.com > >>> CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; > >>> dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; > >>> rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; > >>> rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090 > >>> NOW AVAILABLE > >>> > >>> Greeings Wolfgang, > >>> > >>> Just a reminder that we are waiting to hear from you before continuing > >>> on with the publication process. > >>> > >>> Please see the email below for document information. > >>> > >>> Thank you. > >>> > >>> RFC Editor > >>> > >>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > >>>> Hi Wolfgang, > >>>> > >>>> Just a friendly reminder that we are waiting to hear from you before > >>>> continuing on with the publication process for RFC 5090 > >>>> . > >>>> > >>>> Please review the files located at: > >>>> > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > >>>> > >>>> Note that this diff file highlights only the differences between the > >>>> last posted version of the document and the current text file. The > >>>> previously posted versions (during AUTH48) are available as: > >>>> > >>>> The originally posted AUTH48 files: > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > >>>> > >>>> Version 2 (includes author updates) of AUTH48 files: > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > >>>> Note that this file highlights only the differences between the > >>>> version 1 and 2 text files. > >>>> > >>>> We will wait to hear from you before continuing on with the > >>>> publication process. > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/sg > >>>> > >>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > >>>>> I also talked to Wolfgang at IETF 70. He wanted to check the > >>>>> document over carefully to make sure there were no further issues. > >>>>> > >>>>>> Subject: RE: AUTH48 [SG]: RFC 5090 > >>>>> > >>>>> NOW AVAILABLE> Date: Mon, 10 > >>>>> Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: > >>>>> rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: > >>>>> david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; > >>>>> dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; > >>>>> d.b.nelson@comcast.net>> Yes,>> David Schwartz saw him at the ietf > >>>>> meeting and worked through the draft> with him. I think we should be > >>>>> hearing from him soon.>> Baruch>>> -----Original Message-----> > >>>>> From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> Sent: Monday, > >>>>> December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> > >>>>> Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; > >>>>> dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; > >>>>> Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: > >>>>> AUTH48 [SG]: RFC 5090 > NOW > >>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck > >>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27, > >>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz > >>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be > >>>>> there and he can nudge him to answer. Lets hold off until we> see>> > >>>>> if that way forward works. If not, we can go with option 3.>>>> > >>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From: > >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>> Sent: Tuesday, > >>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>> > >>>>> Subject: Re: AUTH48 [SG]: RFC 5090> > >>>>> > >>>>> >> NOW AVAILABLE>>>> Hi > >>>>> > >>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1. > >>>>> The author can be removed as an author, and moved to the>> > >>>>> Acknowledgements section.>>>> 2. We can create a Contributor's > >>>>> section and have him listed there.>>>> 3. We can request that the > >>>>> AD approve the document in place of the>> unavailabe author.>>>> > >>>>> Option 3 has been done before in instances where the missing author> > >>>>> > >>>>>> made sizeable contributions to the document, so the other authors> > >>>>>> did not feel comfortable removing the individuals name as an>> > >>>>> > >>>>> author.>>>> It sounds as though 3 may be the proper way forward. > >>>>> If this is the>> case, we will send an email to the ADs requesting > >>>>> their approval in>> place of Wolfgang (the message will be cc'ed to > >>>>> all relevant>> parties, including Wolfgang).>>>> If the above > >>>>> suggestions are unacceptable and you have an alternative>> solution, > >>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On > >>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I > >>>>> wrote to Wolfgang as well, but got no response. What is the>> > >>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with > >>>>> the changes.>> The>>> last email I received was on October 19 > >>>>> where he said that he had> made>>> the one correction (suggested by > >>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>> > >>>>> -----Original Message----->>> From: RFC Editor > >>>>> [mailto:rfc-editor@rfc-editor.org]>>> Sent: Wednesday, November > >>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman; > >>>>> dscreat@dscreat.com; David>> Schwartz;>>> beckw@t-systems.com>>> > >>>>> Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC>> > >>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>> > >>>>> > >>>>> >>> NOW AVAILABLE>>>>>> > >>>>> > >>>>> Greetings Wolfgang,>>>>>> We do not believe we have received > >>>>> your response regarding this>>> document's readiness for > >>>>> publication as an RFC. Please review the>>> text and let us know if > >>>>> you are content with the document as it now>>> appears at:>>>>> > >>>>> > >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note > >>>>> that this diff file highlights only the changes between the> last>> > >>>>> > >>>>>> posted version of the document and the current text file.>>>>> > >>>>>> > >>>>>>>>> The last versions of the document are available as:>>>>> > >>>>>> > >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>> > >>>>> > >>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>> > >>>>> Note that this diff file highlights only the changes between v1 and> > >>>>> > >>>>>>> the v2.>>>>>> We will wait to hear from you before > >>>>> > >>>>> continuing on with the>>> publication process.>>>>>> Thank > >>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at > >>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We > >>>>> have corrected the text as indicated below and posted the> revised>> > >>>>> > >>>>>>> version of the document at:>>>>>>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>> > >>>>> Note that this diff file highlights only the changes betwee the> > >>>>> last>>>>>> posted version of the document and the current text > >>>>> file.>>>>>>>> Please review the document and let us know if > >>>>> you approve this>>>> text for publication.>>>>>>>> We > >>>>> believe we are waiting for the following approvals:>>>>>>>> > >>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David > >>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>> > >>>>> > >>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>> > >>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at > >>>>> > >>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>> > >>>>> > >>>>>>> Please confer and let us know how the text should/should not use> > >>>>>> > >>>>>> the>>>>> quote marks. It sounds as though this email was for > >>>>> > >>>>> discussion.>> If>>>>> the changes below are acceptable, we will > >>>>> make the changes and>> post>>> a>>>>> revised version of the > >>>>> document.>>>>>>>>>> Also, please note the following status > >>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done > >>>>> (although we would like to know if you> agree>>>>> with the > >>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>> > >>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>> > >>>>> > >>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to > >>>>> > >>>>> hear further before continuing on with the>>> publication>>>>> > >>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor> > >>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400, > >>>>> > >>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>> > >>>>> These look good, and I agree with your consistency comment. I>>> > >>>>> have a few>>>>>> more specific changes to suggest that I would > >>>>> like you and>> others>>> to>>>>>> review as well. But first > >>>>> a couple of general style comments>> that>>> require>>>>>> > >>>>> no changes to the document.>>>>>>>>>>>> General comment > >>>>> #1: I tried to find a definitive style guide> to>>> use of>>>> > >>>>> > >>>>>>> single quotes versus double quotes and found there is no hard>> > >>>>>> > >>>>>> guidelines,>>>>>> that consistency is most important:>>>> > >>>>>> > >>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>> > >>>>> > >>>>> http://forum.wordreference.com/showthread.php?t=120946>>>>>> > >>>>> Though I tend to think that double quotes are more commonly> used>> > >>>>> > >>>>>> and match>>>>>> the syntax of more popular programming > >>>>> > >>>>> languages, but there> are>> so>>> many>>>>>> quoted items in > >>>>> the document and it has been this way for a> long>>> time, so>>> > >>>>> > >>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2: > >>>>> > >>>>> When refering to responses from the radius>>> server>>>>>> > >>>>> there are a lot of instances of a comment similiar to "without>>> > >>>>> surrounding>>>>>> quotes" that potentially could be removed for > >>>>> readability.>>> Especially if>>>>>> there were a more concise > >>>>> definition up-front about the> general>>> form of>>>>>> > >>>>> values returned from the radius server. But I am a little>>> > >>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>> > >>>>> > >>>>>> Specific comments, to build on top of your list:>>>>>>>>>> > >>>>>> > >>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>> > >>>>>> > >>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If > >>>>> > >>>>> a matching (Proxy-)Authorization header is present and>>> contains> > >>>>> > >>>>>>>>>> HTTP Digest information, the RADIUS client checks the > >>>>> > >>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph, > >>>>> do not need quotes around response.>> Paragraph>>> should>>>> > >>>>> > >>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the > >>>>> > >>>>> nonce, it takes the>> header>>>>>> directives and puts them > >>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the > >>>>> response directive into a Digest-Response> attribute>>> and>>>> > >>>>> > >>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>> > >>>>> > >>>>> username,>>>>>> and opaque directives into the respective > >>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop, > >>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count, > >>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>> > >>>>> RADIUS client puts the request method into the> Digest-Method>>>> > >>>>> > >>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to > >>>>> > >>>>> the items you point out, in> the>>> last>>>>>> paragraph, > >>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>> > >>>>> > >>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce> > >>>>> > >>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS > >>>>> client puts the contents> of>>> this>>>>>> attribute into a > >>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style > >>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the > >>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph > >>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an > >>>>> Access-Challenge packet 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>>>>>> surrounding quotes), the > >>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407) > >>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>> > >>>>> directive stale and the digest directives derived from the>>> > >>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think > >>>>> the wording of the last sentence in this same>>> paragraph>>>> > >>>>> > >>>>>>> could be improved. So that the paragraph reads more like:>>>> > >>>>>>> > >>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge > >>>>> > >>>>> packet 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>>>>>> surrounding quotes), the RADIUS client sends an > >>>>> error>> response>>> (401>>>>>> or 407) containing a > >>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive > >>>>> set to 'true' and the digest directives>> derived>>> from>>>>> > >>>>> > >>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10, > >>>>> > >>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>> > >>>>> > >>>>>>> defined and should not be used, that qop directive or> qop-value> > >>>>>>> would be>>>>>> better. In other words the paragraph should > >>>>> > >>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a > >>>>> hash of the>>> HTTP-style>>>>>> message body's contents is > >>>>> required for digest>>> calculation.>>>>>> Instead of sending > >>>>> the complete body of the message,>> only>>> its>>>>>> hash > >>>>> value is sent. This hash value can be used>> directly>>> in>>>> > >>>>> > >>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15, > >>>>> > >>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>> > >>>>> > >>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for > >>>>> > >>>>> future extensions>> and>>>>>> corresponds to the auth-param > >>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The > >>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS > >>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param > >>>>> extension parameters contained within Digest>>> headers that>>>> > >>>>> > >>>>>>> are not understood by the RADIUS client and for which>>> there > >>>>> > >>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>> > >>>>> > >>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the> > >>>>>>> > >>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a > >>>>> > >>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>> > >>>>> > >>>>>> MAY send one or more Digest-Domain attributes in its>>> Access-> > >>>>>> > >>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>> > >>>>>> > >>>>>> quoted,>>>>>> space-separated list of URIs of the domain > >>>>> > >>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with > >>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the > >>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for > >>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>> > >>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>> > >>>>> > >>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no > >>>>> > >>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe > >>>>> there should be no quotes around> qop.>>> So that>>>>>> the > >>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to > >>>>> allow the generation of an>>>>>> Authentication-Info header, > >>>>> even if the HTTP-style>>> response's>>>>>> body is required > >>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD > >>>>> be used in Access-Accept packets if the>>> required>>>>>> > >>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>> > >>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007, > >>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy > >>>>> discussions with my father-in-law who is a>>> professor of>>>>> > >>>>> > >>>>>>>English, I agree with Dave's method of using quotes only in> the> > >>>>>>> value of>>>>>>>an attribute/directive, but not in > >>>>> > >>>>> referencing the>>> attribute/directive>>>>>>>by name. As > >>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3 > >>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>> > >>>>> > >>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the > >>>>> > >>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>> > >>>>> > >>>>>>>> the RADIUS client puts the Digest-Response-Auth>>> > >>>>> > >>>>> attribute's>>>>>>> content into the Authentication-Info > >>>>> header's rspauth>>>>>>> directive of the HTTP-style response.> > >>>>> > >>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around > >>>>> > >>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the > >>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>> > >>>>> > >>>>>>>>>> RADIUS client checks the qop and algorithm directives in>> > >>>>> > >>>>> the>>>>>>> Authorization header of the HTTP-style request it > >>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next > >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the > >>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>> > >>>>> > >>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>> > >>>>> > >>>>> not>>>>>>> include an Authentication-Info header in its> > >>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next > >>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>> > >>>>> > >>>>>> * If the qop directive's value is 'auth-int' and at> least>>> > >>>>> > >>>>> one>>>>>>> of the following conditions is true, the RADIUS> > >>>>> client>>>>>>> calculates the contents of the HTTP-style > >>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>> > >>>>> > >>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response> > >>>>>> > >>>>>> message>>> and>>>>>>> calculates the hash of this message's > >>>>> > >>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI > >>>>> attribute's value of the>> corresponding>>>>>>> Access-Request > >>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes > >>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>> > >>>>> > >>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>> > >>>>>> > >>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the> > >>>>> > >>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no > >>>>> > >>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute > >>>>> enables the RADIUS server to prove>>> possession of>>>>>>> > >>>>> the password. If the previously received Digest-Qop>>> attribute>> > >>>>> > >>>>>>>>>> was 'auth-int' (without surrounding 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 packets. The RADIUS client>> puts>>> the>>>>> > >>>>> > >>>>>>> attribute value without surrounding quotes into the>>> rspauth> > >>>>>>> > >>>>>>>>>>> directive of the Authentication-Info header.>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes > >>>>> > >>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put > >>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept > >>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>> > >>>>> client MUST put the contents of this attribute into> the>>>>>>> > >>>>> nextnonce directive of an Authentication-Info header> in>>> its>> > >>>>> > >>>>>>>>>> HTTP-style response. This attribute MUST only be> used>> > >>>>> > >>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> If the HTTP-style request has an Authorization> > >>>>> > >>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri > >>>>> directive> found>>> in>>>>>>> the HTTP-style request > >>>>> Authorization header (known as>>> "digest->>>>>>> uri-value" > >>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>> > >>>>> quotes into this attribute. If there is no>> Authorization>>>>> > >>>>> > >>>>>>> header, the RADIUS client takes the value of the>> request>>> > >>>>> > >>>>> URI>>>>>>> from the HTTP-style request it wants to > >>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th > >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In > >>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>> > >>>>> > >>>>>>>>>> qop directive (qop-value as described in [RFC2617])>> > >>>>> > >>>>> from>>> the>>>>>>> HTTP-style request it wants to > >>>>> authenticate. In>> Access->>>>>>> Challenge packets, the > >>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this > >>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>> > >>>>> > >>>>>> one "quality of protection" value, it puts each>> qop-value>>> > >>>>> > >>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>> > >>>>> > >>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to> > >>>>>>> > >>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a > >>>>> > >>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client > >>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false' > >>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of > >>>>> this attribute into a stale directive of> the>>> WWW->>>>>>> > >>>>> Authenticate header in the HTTP-style response to the>>> request>> > >>>>> > >>>>>>>>>> it wants to authenticate. The attribute MUST only be>>> > >>>>> > >>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>> > >>>>> > >>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>> > >>>>>>> > >>>>>>>> This attribute is used to allow the generation of an>>>>>> > >>>>>> > >>>>>> Authentication-Info header, even if the HTTP-style>>> response's> > >>>>>> > >>>>>>>>>>> body is required for the calculation of the rspauth>>> > >>>>> > >>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if > >>>>> the>>> required>>>>>>> quality of protection ('qop') is > >>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>I think that does it. Even if this is not right, at least it> > >>>>>>> > >>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>> > >>>>>> > >>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From: > >>>>> > >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>>>>>>>Sent: > >>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>> > >>>>> > >>>>>>>>>Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>>> > >>>>>>>>>beckw@t-systems.com; radext-ads@tools.ietf.org;>>>>>> > >>>>>> > >>>>>>radext-chairs@tools.ietf.org; RFC Editor>>>>>>>Subject: Re: > >>>>> > >>>>> AUTH48 [SG]: RFC 5090>>> >>> > >>>>> > >>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>> > >>>>>>>>> > >>>>>>>>>>>>>>We have not heard further regarding the issues below > >>>>> > >>>>> or other>>> changes>>>>>>>that may be required before > >>>>> publishing this document as an> RFC.>>>>>>>Please review the > >>>>> document and let us know if there are any>>>>>>>corrections > >>>>> required.>>>>>>>>>>>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>> > >>>>> > >>>>>>>>>>>>>>We will wait to hear from you before continuing on > >>>>> > >>>>> with the>>>>>>>publication process.>>>>>>>>>>>>> > >>>>> > >>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>> > >>>>>> > >>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> > >>>>>>> > >>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While > >>>>> > >>>>> reviewing > during>>> AUTH48,> > >>>>> > >>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>> > >>>>>>>> > >>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks > >>>>> > >>>>> (')>> in>>>>>>>>>>>this document. There seems to be > >>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which > >>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in > >>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth' > >>>>> > >>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth > >>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ", > >>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the > >>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we > >>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses > >>>>> 's. However, if you feel that the document>>> should be>>>>>> > >>>>> > >>>>>>>>more alignmed with RFC 2617, please let us know and we will>>> > >>>>> > >>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are > >>>>> taking a vote, I would prefer using " instead of '>>> around>>>> > >>>>> > >>>>>>>>the>>>>>>>>value strings. I think it is better to stay > >>>>> > >>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590. > >>>>> Also I believe the " usage is more commonly used in>> other>>>>> > >>>>> > >>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also, > >>>>> > >>>>> we had a difficult time understanding the use of 's.>> We>>>>>> > >>>>> > >>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>> > >>>>>> > >>>>>> were>>>>>>>>>used as values or directives. However, we did > >>>>> > >>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives > >>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let > >>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it > >>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>> > >>>>> > >>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop" > >>>>> > >>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted > >>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on > >>>>> style but my initial thought is to>> suggest>>>>>>>removing '> > >>>>> > >>>>>>>>>>>>and " from keywords when refering to a directive name > >>>>> > >>>>> rather>>> than its>>>>>>>>literal value, and then use "" when > >>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>> > >>>>> > >>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>>>>> o If the Access-Accept packet contains a > >>>>> > >>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the > >>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization > >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> > >>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is > >>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS > >>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>> > >>>>> > >>>>>>> include an Authentication-Info header in its>> HTTP-style>>>> > >>>>>>> > >>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>However when examing 2617 in more detail, using " around the>>> > >>>>> > >>>>> directive>>>>>>>>>>>>>>>names would be more consistent > >>>>> with that draft. For example>>> this>>>>>>>would>>>>>> > >>>>> > >>>>>>>become:>>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>> > >>>>> > >>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and > >>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization > >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> > >>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is > >>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client > >>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>> > >>>>> include an Authentication-Info header in its>> HTTP-style>>>>>> > >>>>> > >>>>>>> response.>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>Prehaps others can weigh in one which they believe is most> > >>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a > >>>>> > >>>>> slight improvement on the> existing>>> text>>>>>>>which>>> > >>>>> > >>>>>>>>>>uses single quotes around the string values.>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at > >>>>> > >>>>> 03:11:50PM -0700,>>> rfc-editor@rfc-editor.org>>>>>>>wrote:> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC > >>>>> > >>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>> > >>>>>>>>> > >>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> > >>>>>>> > >>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make > >>>>> > >>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your > >>>>> document at:>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally > >>>>> > >>>>> introduces>> errors>>> that>>>>>>>>>>were not in the > >>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>> > >>>>> > >>>>>>>>>hard to catch all errors, proofreading the text at least>>> > >>>>> > >>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an > >>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the > >>>>> correctness of the final product> when>>> you OK>>>>>> > >>>>> > >>>>>>>>>publication. You should therefore proofread the entire> RFC>>> > >>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in > >>>>> > >>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a > >>>>> diff tool that compares the approved>>>>>>>internet-draft>>> > >>>>> > >>>>>>>>>>>>against our edited RFC version of the document. Please>> > >>>>> > >>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> > >>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered > >>>>> > >>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to > >>>>> create the diff file above. To make the>> file>>> more>>>>>> > >>>>> > >>>>>>>>>useful, we moved the terminology section to to appear> after>>> > >>>>> > >>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until > >>>>> > >>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC > >>>>> have affirmed that the document is ready to be>>>>>> > >>>>> > >>>>>>>>>published, as ALL of the authors are equally responsible> for>> > >>>>>>>>> > >>>>>>>>>>verifying>>>>>>>>>>the documents readiness for > >>>>> > >>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list > >>>>> of suitable keywords for this>>> document,>>>>>>>over>>>> > >>>>> > >>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> - > >>>>> > >>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>> > >>>>> > >>>>>>>>>>>>> (especially if you originally put the copyright>>>>> > >>>>>>> > >>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document, > >>>>> > >>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo' > >>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO > >>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes > >>>>> made. (If we think that the changes might be more>>> than>>>>> > >>>>> > >>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that> > >>>>>>> > >>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>> > >>>>>>> > >>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>> > >>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>> > >>>>> > >>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>> > >>>>> > >>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes > >>>>> > >>>>> are spacing or indentation> than>>> please>>>>>>>note>>>> > >>>>> > >>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the > >>>>> > >>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The > >>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>> > >>>>> > >>>>>>>>>>>>>If you have a whole paragraph to replace you do not need> > >>>>> > >>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With > >>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces> > >>>>> > >>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary > >>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>> > >>>>> > >>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>This document will NOT be published until we receive>>> > >>>>> > >>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document > >>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks > >>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension > >>>>> > >>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) : > >>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,> > >>>>> > >>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) : > >>>>> > >>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan > >>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>> > > > > -- > > Mike McCauley mikem@open.com.au > > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > http://www.open.com.au Phone +61 7 5598-7474 Fax > > +61 7 5598-7070 > > > > Radiator: the most portable, flexible and configurable RADIUS server > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 12:41:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aG3-0000kD-N3 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:41:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7aG3-0004ar-4D for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:41:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aA9-000HJ1-Se for radiusext-data@psg.com; Wed, 26 Dec 2007 17:35:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aA6-000HIL-Kn for radiusext@ops.ietf.org; Wed, 26 Dec 2007 17:35:24 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id E28BCA704E; Wed, 26 Dec 2007 09:35:17 -0800 (PST) Message-ID: <47729084.8060206@nitros9.org> Date: Wed, 26 Dec 2007 18:33:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? References: <003401c83a92$db6ed850$924c88f0$@net> In-Reply-To: <003401c83a92$db6ed850$924c88f0$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Glen Zorn wrote: > During the meeting last week, I thought that there were a couple of > questions/comments on Jabber regarding the changes that I proposed to > the extended attribute format (adding a bit to distinguish between new > TLVs and legacy RADIUS attributes in extended attributes) but I didn't > quite catch them. Would those who presented those remarks mind > repeating them in email? TIA. WiMAX uses the same attribute format as proposed here. Changes that are incompatible with WiMAX should be discouraged. If it's just stealing a bit (which WiMAX doesn't use), that sounds fine. The ability to group legacy RADIUS attributes via a method other than tags would be good. One question: If we DO permit this for legacy RADIUS attributes, what does the "C" bit mean? Do we use the WiMAX method for splitting attributes encrypted with the "Tunnel-Password" method? 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: From owner-radiusext@ops.ietf.org Wed Dec 26 12:56:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aUP-0000gc-CM for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:56:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7aUP-0004nR-0E for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:56:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aP1-000IpS-I6 for radiusext-data@psg.com; Wed, 26 Dec 2007 17:50:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aOy-000Ip4-Qy for radiusext@ops.ietf.org; Wed, 26 Dec 2007 17:50:46 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 2863CA704E for ; Wed, 26 Dec 2007 09:50:36 -0800 (PST) Message-ID: <47729414.9070608@nitros9.org> Date: Wed, 26 Dec 2007 18:49:08 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: [ Comments on automated key management and crypto agility References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Bernard Aboba wrote: > However, this is logically separate from the need to provide end-to-end > protection for key transport. What is "end to end" ? Not to be dumb, but there are a number of parties involved: supplicant (or end user software) NAS (or AP) local RADIUS server intermediate proxies (0 or more) home RADIUS server (may be the same as the local RADIUS server) Which ends are we talking about? The EAP-TLS methods allow the supplicant and home server to agree on a key. So any "end to end" problem would appear to be getting keying material from the supplicant OR home server to the NAS, without exposing that material to any local server, or proxy server. > So far, the need to solve the end-to-end key transport problem has not > been part of RADIUS > crypto-agility requirements. Should it be? I don't see how we could do NAS to home server key transport in RADIUS. So the answer is (I think) "No". Any end-to-end key transport should involve EAP-TLS methods *and* RADIUS, I think. Just doing it in one or the other wouldn't work. If we tried to do it in RADIUS, we would end up with something that looked nothing like RADIUS. > With Diameter, it was clear that the IESG expected a solution to both > problems -- ciphersuite > negotiation (via TLS/IKE) as well as a mechanism for avoiding key > disclosure to proxies > (e.g. redirect). redirects have problems in practical deployments. Intermediate nodes often exist for commercial reasons, both for business relationships and for application of intermediary policies. 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: From owner-radiusext@ops.ietf.org Wed Dec 26 12:59:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aX6-0005FJ-86 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:59:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7aX5-0004pa-KO for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:59:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aRg-000J2q-8e for radiusext-data@psg.com; Wed, 26 Dec 2007 17:53:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.166] (helo=bay0-omc2-s30.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aRD-000J0Y-Ba for radiusext@ops.ietf.org; Wed, 26 Dec 2007 17:53:17 +0000 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 09:53:02 -0800 X-Originating-IP: [67.183.152.50] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: RADEXT WG last call on RADIUS Design Guidelines Document Date: Wed, 26 Dec 2007 09:53:05 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01C847A5.1CCD6D60" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 26 Dec 2007 17:53:02.0873 (UTC) FILETIME=[292B0890:01C847E8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a multi-part message in MIME format. ------=_NextPart_000_00CC_01C847A5.1CCD6D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the=20 "RADIUS Design Guidelines" document, prior to sending=20 it to the IESG for publication as a Proposed=20 Standard. The document is available for inspection here:=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt RADEXT WG last call will complete on January 15, 2008. Please respond to this solicitation if you have read the document, regardless of = whether you have comments to provide or not. In your email, please state whether = you=20 believe that the document is ready for publication. =20 If you have comments to provide, please send them to the=20 RADEXT WG mailing list (radiusext@ops.ietf.org),=20 using the format described in the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/ ------=_NextPart_000_00CC_01C847A5.1CCD6D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is an announcement of RADEXT WG = last call on=20 the
"RADIUS Design = Guidelines" document, prior=20 to sending
it to the IESG for publication as a = Proposed=20
Standard.  The document is = available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.= txt

RADEXT WG last call will complete on = January 15,=20 2008.  Please respond
to this solicitation if you have read = the=20 document, regardless of whether you
have comments to provide or = not.  In your=20 email, please state whether you
believe that the document is ready = for=20 publication. 
 
If you have comments to provide, = please send them=20 to the
RADEXT WG mailing list (radiusext@ops.ietf.org),
using the format described in the = RADEXT Issues=20 tracker:
http://www.drizzle.com/~aboba/RADEXT/
------=_NextPart_000_00CC_01C847A5.1CCD6D60-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 12:59:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7aXg-0007DL-IJ for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:59:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7aXe-0004q7-Af for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 12:59:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aRk-000J3C-R9 for radiusext-data@psg.com; Wed, 26 Dec 2007 17:53:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.17] (helo=QMTA10.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aRZ-000J2H-L3 for radiusext@ops.ietf.org; Wed, 26 Dec 2007 17:53:27 +0000 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with comcast id VSFn1Y00K0mv7h05A0EP00; Wed, 26 Dec 2007 17:53:24 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA11.westchester.pa.mail.comcast.net with comcast id VVtP1Y00A53lGY33X00000; Wed, 26 Dec 2007 17:53:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=zz3dB5q32WxJMubKTZMA:9 a=o38THE0GYv1231c4rLAikQABfSIA:4 a=tqucuuI3bnEA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> In-Reply-To: <47729084.8060206@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 09:52:47 -0800 Message-ID: <005d01c847e8$20c81f30$62585d90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH5bdl4qB55+LFT+K87w6d0sThIwAAHOvg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Glen Zorn wrote: > During the meeting last week, I thought that there were a couple of > questions/comments on Jabber regarding the changes that I proposed to > the extended attribute format (adding a bit to distinguish between new > TLVs and legacy RADIUS attributes in extended attributes) but I didn't > quite catch them. Would those who presented those remarks mind > repeating them in email? TIA. WiMAX uses the same attribute format as proposed here. Changes that are incompatible with WiMAX should be discouraged. [gwz] I'm not at all sure why that would be the case; I don't recall the IETF bending over backwards to be compatible w/anyone else's VSAs... [/gwz] If it's just stealing a bit (which WiMAX doesn't use), that sounds fine. The ability to group legacy RADIUS attributes via a method other than tags would be good. [gwz] Actually, I've convinced myself that a) this idea was not quite baked & b) I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes at 0x100, that would seem to solve a couple of problems nicely. [/gwz] One question: If we DO permit this for legacy RADIUS attributes, what does the "C" bit mean? Do we use the WiMAX method for splitting attributes encrypted with the "Tunnel-Password" method? [gwz] I don't know what method that is, but I'm not sure why those attributes would be treated differently than others. [/gwz] 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: From owner-radiusext@ops.ietf.org Wed Dec 26 13:03:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7abF-0002dD-C5 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:03:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7abE-0004uT-DT for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:03:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aYS-000Ja1-IW for radiusext-data@psg.com; Wed, 26 Dec 2007 18:00:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aY0-000JXu-7V for radiusext@ops.ietf.org; Wed, 26 Dec 2007 18:00:19 +0000 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id VUxT1Y00A0SCNGk0505R00; Wed, 26 Dec 2007 18:00:02 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA09.westchester.pa.mail.comcast.net with comcast id VW001Y00153lGY33V00000; Wed, 26 Dec 2007 18:00:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=HnDihN7l37cA:10 a=No5EcEP4AAAA:8 a=lHIK1t_c1lC-7DL5jYkA:9 a=UIe76RprqC-e4kpik9AA:7 a=KuLx1bp-CeaukJ0WFJvUHD3_6bMA:4 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <47729414.9070608@nitros9.org> In-Reply-To: <47729414.9070608@nitros9.org> Subject: RE: [ Comments on automated key management and crypto agility Date: Wed, 26 Dec 2007 09:59:23 -0800 Message-ID: <005e01c847e9$0dcbc7f0$296357d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH6I1hz+I309tPQD+urxR21Ysz4AAAC18g Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ... redirects have problems in practical deployments. Intermediate nodes often exist for commercial reasons, both for business relationships and for application of intermediary policies. [gwz] And, unfortunately, that's just scratching the surface; how that lame scheme got into an RFC I'll never know... [/gwz] Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 13:04:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7acD-0003ys-Ig for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:04:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7acD-0004vn-6F for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:04:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aZO-000Jf2-6R for radiusext-data@psg.com; Wed, 26 Dec 2007 18:01:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.158] (helo=bay0-omc2-s22.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aZL-000JeM-Np for radiusext@ops.ietf.org; Wed, 26 Dec 2007 18:01:28 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 10:01:23 -0800 X-Originating-IP: [67.183.152.50] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> To: "Alan DeKok" , "Glen Zorn" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> X-Unsent: 1 Subject: Re: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 10:01:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 26 Dec 2007 18:01:23.0542 (UTC) FILETIME=[53970F60:01C847E9] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > WiMAX uses the same attribute format as proposed here. Changes that > are incompatible with WiMAX should be discouraged. I would agree. If the extensions remain compatible with WiMAX then the amount of code duplication will be minimized. > If it's just stealing a bit (which WiMAX doesn't use), that sounds > fine. The ability to group legacy RADIUS attributes via a method other > than tags would be good. > > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? We need to be careful about feature creep here. The original purpose of the Extended Attributes document was to extend the RADIUS attribute space. If the document is now taking on new problems (extending capabilities of the RADIUS protocol or changing the semantics of existing attributes) then that problem needs to be clearly stated, and justification needs to be provided. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 13:21:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7asN-0008FG-Dv for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:21:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7asL-0005FW-7J for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:21:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aoX-000L6y-Hf for radiusext-data@psg.com; Wed, 26 Dec 2007 18:17:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.56] (helo=QMTA06.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7aoU-000L6c-RJ for radiusext@ops.ietf.org; Wed, 26 Dec 2007 18:17:08 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id VRLf1Y00C16AWCU0A0Lu00; Wed, 26 Dec 2007 18:17:06 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id VWH41Y00353lGY38S00000; Wed, 26 Dec 2007 18:17:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=KyU8gm_5oIyxiH_ZlMUA:9 a=pzxYAvxED1nxWDAwYLQA:7 a=t-OMm-fGHK-DBl3VacWkXzZdn2wA:4 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: , "'Alan DeKok'" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> In-Reply-To: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 10:16:28 -0800 Message-ID: <006b01c847eb$70096650$501c32f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH6VnSyItJtpl6RvSUZWLy43jIIwAAIzhw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d > WiMAX uses the same attribute format as proposed here. Changes that > are incompatible with WiMAX should be discouraged. I would agree. If the extensions remain compatible with WiMAX then the amount of code duplication will be minimized. [gwz] If we're suddenly worried about the size of code for processing VSAs, it would seem to make much more sense to be compatible with cisco's VSAs since they are far more widely deployed than WiMax's (and probably always will be). [/gwz] > If it's just stealing a bit (which WiMAX doesn't use), that sounds > fine. The ability to group legacy RADIUS attributes via a method other > than tags would be good. > > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? We need to be careful about feature creep here. The original purpose of the Extended Attributes document was to extend the RADIUS attribute space. If the document is now taking on new problems (extending capabilities of the RADIUS protocol or changing the semantics of existing attributes) then that problem needs to be clearly stated, and justification needs to be provided. [gwz] I'm not suggesting anything of the sort: the capabilities for sending large attributes & grouping them already exist (although in limited ways); I'm talking about standardizing these existing capabilies, not adding new ones. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 13:49:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bK9-00078Z-VQ for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:49:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7bK8-0005o1-84 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:49:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bDc-000NXx-6s for radiusext-data@psg.com; Wed, 26 Dec 2007 18:43:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.156] (helo=bay0-omc2-s20.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bCt-000NSX-Ey for radiusext@ops.ietf.org; Wed, 26 Dec 2007 18:42:33 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 10:42:16 -0800 X-Originating-IP: [67.183.152.50] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <47729414.9070608@nitros9.org> To: "Alan DeKok" , References: <47729414.9070608@nitros9.org> Subject: Re: E2E and crypto-agility X-Unsent: 1 Date: Wed, 26 Dec 2007 10:42:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 26 Dec 2007 18:42:16.0635 (UTC) FILETIME=[09BF58B0:01C847EF] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > What is "end to end" ? I think it means something like "protection of RADIUS attributes from disclosure to parties other than the NAS and home server". > I don't see how we could do NAS to home server key transport in > RADIUS. So the answer is (I think) "No". In the AAA WG there were a number of mechanisms investigated by which a NAS and home server could derive a key that could be used to protect attributes from disclosure to proxies. These methods included Kerberos and CMS. For example, see: http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt So I think the question is not "can it be done?" but rather "how does this relate to RADIUS crypto-agility?" and "should solving this problem be a requirement?" -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 13:56:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bQh-0000u0-58 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:56:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7bQg-0005x1-Oe for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 13:56:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bMl-000OQ0-Vf for radiusext-data@psg.com; Wed, 26 Dec 2007 18:52:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.173] (helo=bay0-omc2-s37.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bMi-000OPa-Vx for radiusext@ops.ietf.org; Wed, 26 Dec 2007 18:52:30 +0000 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s37.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 10:52:28 -0800 X-Originating-IP: [67.183.152.50] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <47729414.9070608@nitros9.org> To: "Alan DeKok" , References: <47729414.9070608@nitros9.org> Subject: Re: Comments on "practical deployments" X-Unsent: 1 Date: Wed, 26 Dec 2007 10:52:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 26 Dec 2007 18:52:28.0997 (UTC) FILETIME=[76BE5F50:01C847F0] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a > problems in practical deployments. Which "practical deployments" are we talking about? While proxies are widely used today to facilitate inter-domain roaming, as far as I know, the combination of inter-domain roaming and EAP is very rare. While EAP-based technologies such as WiMAX may change the situation, as I understand it, the use of EAP today is largely confined to enterprise scenarios. For example, the vast majority of all IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP. In terms of major EAP deployments that support inter-domain roaming with substantial usage, one deployment (EDUROAM) is several orders of magnitude larger than any other that I am aware of. As far as I know, EDUROAM does not use Diameter nor are there any major deployments of Diameter EAP. Am I missing something, or are there really any "practical experience" here? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 14:17:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bkw-00040E-KO for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:17:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7bkv-0006Oi-6Z for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:17:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bgO-00008f-LR for radiusext-data@psg.com; Wed, 26 Dec 2007 19:12:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bgK-00007n-10 for radiusext@ops.ietf.org; Wed, 26 Dec 2007 19:12:47 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id DC41BA704E; Wed, 26 Dec 2007 11:12:33 -0800 (PST) Message-ID: <4772A741.40303@nitros9.org> Date: Wed, 26 Dec 2007 20:10:57 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> In-Reply-To: <005d01c847e8$20c81f30$62585d90$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Glen Zorn wrote: > I'm not at all sure why that would be the case; I don't recall the IETF > bending over backwards to be compatible w/anyone else's VSAs... The last thing I need right now is yet another incompatible VSA format. > Actually, I've convinced myself that a) this idea was not quite baked & b) I > was wrong about making the Ext-Type field just one octet. If we make the > Ext-Type field 16 bits in length _and_ start numbering the new attributes at > 0x100, that would seem to solve a couple of problems nicely. I understand... I'm not sure I completely agree. > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? > [gwz] > I don't know what method that is, but I'm not sure why those attributes > would be treated differently than others. > [/gwz] Neither am I. But they are. 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: From owner-radiusext@ops.ietf.org Wed Dec 26 14:20:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7bnu-0007tC-P5 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:20:34 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7bnu-0006V0-Ec for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:20:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bkX-0000Ut-9L for radiusext-data@psg.com; Wed, 26 Dec 2007 19:17:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7bkS-0000UO-7W for radiusext@ops.ietf.org; Wed, 26 Dec 2007 19:17:04 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 3EB39A704E; Wed, 26 Dec 2007 11:16:53 -0800 (PST) Message-ID: <4772A842.8090308@nitros9.org> Date: Wed, 26 Dec 2007 20:15:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <006b01c847eb$70096650$501c32f0$@net> In-Reply-To: <006b01c847eb$70096650$501c32f0$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Glen Zorn wrote: > If we're suddenly worried about the size of code for processing VSAs, it > would seem to make much more sense to be compatible with cisco's VSAs since > they are far more widely deployed than WiMax's (and probably always will > be). Yes... but strings? Really? > I'm not suggesting anything of the sort: the capabilities for sending large > attributes & grouping them already exist (although in limited ways); I'm > talking about standardizing these existing capabilies, not adding new ones. If we can get the functionality of the new extended attributes applied to legacy RADIUS, I'm all for it. But I don't want it to be a lot of work... that causes bugs and interoperability issues. My preferences are to leave the extended attributes defined the way they are right now. Anything else starts to cause issues. e.g. legacy attributes encapsulated in a VSA.... what happens with legacy implementations? The only image that comes to mind is a cloud going *boom*. 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: From owner-radiusext@ops.ietf.org Wed Dec 26 14:37:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7c4N-00058A-DA for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:37:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7c4K-0006su-W7 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:37:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7c0c-0001er-2d for radiusext-data@psg.com; Wed, 26 Dec 2007 19:33:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7c0Y-0001ds-Vg for radiusext@ops.ietf.org; Wed, 26 Dec 2007 19:33:40 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 8AB3CA704E; Wed, 26 Dec 2007 11:33:17 -0800 (PST) Message-ID: <4772AC0D.1000401@nitros9.org> Date: Wed, 26 Dec 2007 20:31:25 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" References: <47729414.9070608@nitros9.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Bernard_Aboba@hotmail.com wrote: >> problems in practical deployments. > > Which "practical deployments" are we talking about? RADIUS proxies. There are multiple inter-telco && inter-country deployments using RADIUS. I'm not aware of any similar large-scale deployment of Diameter. (i.e. everyone I've talked to says "perhaps one day we'll move to Diameter".) > While proxies are widely used today to facilitate inter-domain > roaming, as far as I know, the combination of inter-domain roaming > and EAP is very rare. The FMCA is trialling exactly this. > While EAP-based technologies such as WiMAX may change the > situation, as I understand it, the use of EAP today is largely confined > to enterprise scenarios. For example, the vast majority of all > IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP. Yes. In fact, the use of EAP *prevents* a large number of business models for network access. > In terms of major EAP deployments that support inter-domain roaming > with substantial usage, one deployment (EDUROAM) is several orders of > magnitude larger than any other that I am aware of. UMA leverages EAP and RADIUS, but it's buried deep in the network. > As far as I know, EDUROAM does not use Diameter nor are there any > major deployments of Diameter EAP. Yes. > Am I missing something, or are there really any "practical experience" > here? Practical experience with existing AAA servers, proxies, and business models. The current technology is RADIUS. I'm trying to figure out how AAA redirection (and avoiding the intermediary proxies) helps anyone. I don't think it does. 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: From owner-radiusext@ops.ietf.org Wed Dec 26 14:58:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7cOk-0005Px-2h for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:58:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7cOj-0007V7-A0 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 14:58:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cK1-00039b-Mr for radiusext-data@psg.com; Wed, 26 Dec 2007 19:53:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.152] (helo=bay0-omc2-s16.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cJY-00037M-WF for radiusext@ops.ietf.org; Wed, 26 Dec 2007 19:53:31 +0000 Received: from BAY117-W31 ([207.46.8.66]) by bay0-omc2-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 11:53:16 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_52ab49c8-2d30-4f2d-a476-48f4b20945a4_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Subject: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection Date: Wed, 26 Dec 2007 11:53:16 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Dec 2007 19:53:16.0586 (UTC) FILETIME=[F4E048A0:01C847F8] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attribute= s for=20 Filtering and Redirection": http://ops.ietf.org/lists/radiusext/2007/msg00494.html http://ops.ietf.org/lists/radiusext/2007/msg00541.html This WG last call was to last until Monday, July 23, 2007. During the WG last call, only a single comment was received, from Hannes=20 Tschofenig: http://ops.ietf.org/lists/radiusext/2007/msg00496.html No other messages were posted to the RADEXT WG mailing list indicating that= =20 WG participants had read the document. Given the light level of participation, the WG last=20 call was extended for 10 more days (until August 28, 2007): http://ops.ietf.org/lists/radiusext/2007/msg00633.html No comments were received during that WG last call either. Given that no comments have been received during the last two RADEXT WG las= t calls, we are going to bring the document to RADEXT WG call again. This = RADEXT WG last call will last until January 15, 2008.=20 If you have read the=20 document and approve of its publication as a Proposed Standard, please post= =20 your approval to the list, even if you have no comments to provide. If you have comments, please provide them in the format described on the=20 RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attri= butes for=20 Filtering and Redirection": 
http://ops.ietf.org/lists/radiuse=
xt/2007/msg00494.html
http://ops.ietf.org/lists/radiusext/2=
007/msg00541.html

This WG last call was to last until Monday, Ju=
ly 23, 2007.
During the WG last call, only a single comment wa= s received, from Hannes=20 Tschofenig: 
http://ops.ietf.org/lists/radiuse=
xt/2007/msg00496.html

No other messages were posted to the R=
ADEXT WG mailing list indicating that=20
WG participants had read the document.

Given the light level of participation, the WG l= ast=20 call was extended for 10 more days (until August 28, 2007):
htt= p://ops.ietf.org/lists/radiusext/2007/msg00633.html

No comments were= received during that WG last call either.

Given that no comments ha= ve been received during the last two RADEXT WG last calls, we are going to = bring the document to RADEXT WG call again.  This RADEXT WG last call = will last until January 15, 2008.

If you have read the=20 document and approve of its publication as a Proposed Standard, pl= ease post=20 your approval to the list, even if you have no comments to provide= . If you have comments, please provide them in the format described = on the=20 RADEXT WG Issues page: 
http://www.drizzle.com/~aboba/RADEXT/
= --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 15:08:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7cY5-0001Rr-67 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:08:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7cY4-0007fv-PF for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:08:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cVH-000441-2M for radiusext-data@psg.com; Wed, 26 Dec 2007 20:05:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.146] (helo=bay0-omc2-s10.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cVE-00043d-MK for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:05:21 +0000 Received: from BAY117-W34 ([207.46.8.69]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 12:05:16 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_79d372da-1d12-4de7-b820-a264809dd28f_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Alan DeKok CC: Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 12:05:16 -0800 Importance: Normal In-Reply-To: <4772AC0D.1000401@nitros9.org> References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Dec 2007 20:05:16.0979 (UTC) FILETIME=[A2438830:01C847FA] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 --_79d372da-1d12-4de7-b820-a264809dd28f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > While proxies are widely used today to facilitate inter-domain > > roaming, as far as I know, the combination of inter-domain roaming > > and EAP is very rare. >=20 > The FMCA is trialling exactly this. Is this the Fixed Mobile Covergence Alliance? =20 (This seemed the most likely of the expansions provided by Google, the othe= rs being: Family Motor Coach Association Florida Mosquito Control Association Florida Marine Contractors Association Friends of Montgomery County Animals) >> For example, the vast majority of all >> IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP= . >=20 > Yes. In fact, the use of EAP *prevents* a large number of business > models for network access. Could you expand on the problems? > UMA leverages EAP and RADIUS, but it's buried deep in the network. Yup. Doesn't seem like this would require inter-domain proxies. --_79d372da-1d12-4de7-b820-a264809dd28f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > While proxies are widely used today to facilitate inter-domain> > roaming, as far as I know, the combination of inter-domain roami= ng
> > and EAP is very rare.
>
> The FMCA is triall= ing exactly this.

Is this the Fixed Mobile Covergence Alliance? = ;

(This seemed the most likely of the expansions provided by Google= , the others being:

Family Motor Coach Association
Florida Mosqui= to Control Association
Florida Marine Contractors Association
Friends= of Montgomery County Animals)

>> For example, the vast majori= ty of all
>> IEEE 802.11 hotspot deployments use Web-based access = (e.g. UAM), not EAP.
>
> Yes. In fact, the use of EAP *prev= ents* a large number of business
> models for network access.

= Could you expand on the problems?

> UMA leverages EAP and RADIU= S, but it's buried deep in the network.

Yup.  Doesn't seem like= this would require inter-domain proxies.
= --_79d372da-1d12-4de7-b820-a264809dd28f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 15:10:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ca9-0005LH-EP for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:10:25 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7ca9-0007hi-1O for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:10:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cWw-0004DJ-IJ for radiusext-data@psg.com; Wed, 26 Dec 2007 20:07:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.48] (helo=QMTA05.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cWt-0004Ct-Sv for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:07:05 +0000 Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA05.westchester.pa.mail.comcast.net with comcast id VXRV1Y00E16LCl00503r00; Wed, 26 Dec 2007 20:07:03 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA06.westchester.pa.mail.comcast.net with comcast id VY721Y00453lGY33S00000; Wed, 26 Dec 2007 20:07:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=Kyim4CSX5NKUdEtlMBUA:9 a=cbHjhmENCSqF-5k9zT-pJ86qD7YA:4 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> In-Reply-To: <4772A741.40303@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:06:25 -0800 Message-ID: <007e01c847fa$cbae1a00$630a4e00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 > I'm not at all sure why that would be the case; I don't recall the IETF > bending over backwards to be compatible w/anyone else's VSAs... The last thing I need right now is yet another incompatible VSA format. [gwz] I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 15:14:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7ce6-0007qi-NZ for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:14:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7ce6-0007la-AR for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:14:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7caz-0004sS-R6 for radiusext-data@psg.com; Wed, 26 Dec 2007 20:11:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.64] (helo=QMTA07.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cat-0004rW-J2 for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:11:16 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id VUGt1Y0091GXsuc0A0PJ00; Wed, 26 Dec 2007 20:11:11 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id VYB91Y00E53lGY38T00000; Wed, 26 Dec 2007 20:11:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=2gqz4AnwQuraWKzKRoMA:9 a=0hdpQYvahjb6NZPfw4AA:7 a=vtWjhCY1dna__f4cXPx49tN_ulMA:4 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <006b01c847eb$70096650$501c32f0$@net> <4772A842.8090308@nitros9.org> In-Reply-To: <4772A842.8090308@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:10:32 -0800 Message-ID: <008801c847fb$5f8d0560$1ea71020$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH8+quH1rguFTjRHKfwlnn7KP5TwABuaYQ Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > If we're suddenly worried about the size of code for processing VSAs, it > would seem to make much more sense to be compatible with cisco's VSAs since > they are far more widely deployed than WiMax's (and probably always will > be). Yes... but strings? Really? [gwz] I know, but the point stands, no? [/gwz] > I'm not suggesting anything of the sort: the capabilities for sending large > attributes & grouping them already exist (although in limited ways); I'm > talking about standardizing these existing capabilies, not adding new ones. If we can get the functionality of the new extended attributes applied to legacy RADIUS, I'm all for it. But I don't want it to be a lot of work... that causes bugs and interoperability issues. My preferences are to leave the extended attributes defined the way they are right now. Anything else starts to cause issues. e.g. legacy attributes encapsulated in a VSA.... what happens with legacy implementations? The only image that comes to mind is a cloud going *boom*. [gwz] ;-) Not sure why, though -- they would be easily identified & it seems like the code we're talking about should already exist (that's why we chose these rather modest techniques in the first place, right?). [/gwz] 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: From owner-radiusext@ops.ietf.org Wed Dec 26 15:22:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7cmF-0002wC-IP for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:22:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7cmD-0007v0-8W for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:22:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7chm-0005T5-Te for radiusext-data@psg.com; Wed, 26 Dec 2007 20:18:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.149] (helo=bay0-omc2-s13.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7chk-0005Sj-B7 for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:18:17 +0000 Received: from BAY117-W37 ([207.46.8.72]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Dec 2007 12:18:16 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_6dd47e72-f355-459e-9cd1-8663ebd42293_" X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Alan DeKok CC: Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 12:18:16 -0800 Importance: Normal In-Reply-To: References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Dec 2007 20:18:16.0155 (UTC) FILETIME=[72B05AB0:01C847FC] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --_6dd47e72-f355-459e-9cd1-8663ebd42293_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The FMCA is trialling exactly this.=20 It will be interesting to see how well it works. I have previously been in= volved in a number of=20 inter-domain roaming trials. When the RADIUS traffic was routed through an= exchange point, the results were not very promising. With packet loss rates of 1-5%, RADIU= S retransmissions were pretty common and this would often lead to EAP retransmissions. The o= verall authentication times could get pretty long and sometimes authentication wou= ldn't complete at all. Most of the carriers we worked with ended up deploying web portals= instead :( --_6dd47e72-f355-459e-9cd1-8663ebd42293_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The FMCA is trialling exactly this.

It will be interesting to = see how well it works.  I have previously been involved in a number of=
inter-domain roaming trials.  When the RADIUS traffic was routed = through an exchange point,
the results were not very promising.  Wi= th packet loss rates of 1-5%, RADIUS retransmissions
were pretty common = and this would often lead to EAP retransmissions.  The overall
auth= entication times could get pretty long and sometimes authentication wouldn'= t complete
at all.  Most of the carriers we worked with ended up de= ploying web portals instead :(
= --_6dd47e72-f355-459e-9cd1-8663ebd42293_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 15:40:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7d3Q-0000dc-47 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:40:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7d3O-0008JB-Gv for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:40:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cxg-0006gr-6S for radiusext-data@psg.com; Wed, 26 Dec 2007 20:34:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [131.115.18.152] (helo=sehan001bb.han.telia.se) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7cxa-0006g9-JT for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:34:39 +0000 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 21:34:30 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 21:34:24 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9F17@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on "practical deployments" Thread-Index: AchH+sS7oemdAUhtTMa/Bsc3AOaVBwAAgeqg From: To: , Cc: X-OriginalArrivalTime: 26 Dec 2007 20:34:30.0286 (UTC) FILETIME=[B750F2E0:01C847FE] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi, > > > While proxies are widely used today to facilitate inter-domain=20 > > > roaming, as far as I know, the combination of=20 > inter-domain roaming=20 > > > and EAP is very rare. GSMA trialed (with a number of hotspot & GSM operators mainly in Europe & Asia) EAP-based 802.11 roaming few years ago. This concentrated mainly on EAP-SIM and EAP-AKA. > > The FMCA is trialling exactly this. >=20 > Is this the Fixed Mobile Covergence Alliance? =20 Yes. [snip] > >> For example, the vast majority of all IEEE 802.11 hotspot=20 > deployments=20 > >> use Web-based access (e.g. UAM), not EAP. > >=20 > > Yes. In fact, the use of EAP *prevents* a large number of business=20 > > models for network access. >=20 > Could you expand on the problems? >=20 > > UMA leverages EAP and RADIUS, but it's buried deep in the network. >=20 > Yup. Doesn't seem like this would require inter-domain proxies. In the existing specs for 3GPP GAN (i.e. the current UMA) inter-operator roaming is defined and reuses in a carbon-copy fashion 3GPP Interworking WLAN EAP-based RADIUS roaming interface. However, operator business models typically do not favor deployments where GAN would need inter-operator RADIUS interface.. at least I am not aware of any such deployments. Jouni >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 15:55:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7dHy-00037X-KA for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:55:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7dHy-000076-5Q for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 15:55:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7dDw-0007sh-PW for radiusext-data@psg.com; Wed, 26 Dec 2007 20:51:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7dDu-0007sL-AQ for radiusext@ops.ietf.org; Wed, 26 Dec 2007 20:51:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:51:25 -0800 Message-ID: In-Reply-To: <007e01c847fa$cbae1a00$630a4e00$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on modified Extended Attribute format? Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgA= References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> From: "Matt Holdrege" To: "Glen Zorn" , "Alan DeKok" Cc: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 17:18:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7eaJ-00058z-Hd for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 17:18:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7eaH-000228-Mr for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 17:18:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7eUg-000DU2-58 for radiusext-data@psg.com; Wed, 26 Dec 2007 22:12:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7eUc-000DTP-5G for radiusext@ops.ietf.org; Wed, 26 Dec 2007 22:12:52 +0000 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Va8T1Y0081GXsuc0A00Q00; Wed, 26 Dec 2007 22:12:49 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id VaCo1Y00C53lGY38T00000; Wed, 26 Dec 2007 22:12:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=ADibbwqiEUIBRv5OvloA:9 a=zddfWqKmWRMfovMHnHtPSau2CNgA:4 a=tqucuuI3bnEA:10 From: "Glen Zorn" To: "'Matt Holdrege'" Cc: , "'Alan DeKok'" References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> In-Reply-To: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 14:12:11 -0800 Message-ID: <00af01c8480c$5d526ef0$17f74cd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgAAAt9pkA== Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? [gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz] -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 22:03:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7j2L-0003hc-UX for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 22:03:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7j2K-0006Tu-Dj for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 22:03:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7ixs-0004gW-HR for radiusext-data@psg.com; Thu, 27 Dec 2007 02:59:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7ixq-0004fV-50 for radiusext@ops.ietf.org; Thu, 27 Dec 2007 02:59:19 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA06.westchester.pa.mail.comcast.net with comcast id VchK1Y0040QuhwU050Bp00; Thu, 27 Dec 2007 02:58:57 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.westchester.pa.mail.comcast.net with comcast id Veyt1Y00324Kx1C3N00000; Thu, 27 Dec 2007 02:58:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=tm4dRX4hCESgZWtCz7gA:9 a=9zLGdUSSZW4Jmfgw5rny5cSfqmMA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 21:58:54 -0500 Message-ID: <047101c84834$6add33c0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AchH6bKi6mr7v9FDS/emyMiHMVqnKAASb4ug Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Bernard Aboba writes... > > WiMAX uses the same attribute format as proposed here. Changes that > > are incompatible with WiMAX should be discouraged. > > I would agree. If the extensions remain compatible with WiMAX then > the amount of code duplication will be minimized. I'm not so sure that I agree. We should do what's right for the RADIUS community. If that happens to be compatible with WiMAX, then great. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 23:49:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7kgb-0004H1-CD for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:49:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7kga-00086N-S0 for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:49:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kcd-000B09-Fx for radiusext-data@psg.com; Thu, 27 Dec 2007 04:45:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kca-000Azn-JT for radiusext@ops.ietf.org; Thu, 27 Dec 2007 04:45:30 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 03E97A704E; Wed, 26 Dec 2007 20:45:15 -0800 (PST) Message-ID: <47732D87.5030501@nitros9.org> Date: Thu, 27 Dec 2007 05:43:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Bernard Aboba wrote: > Is this the Fixed Mobile Covergence Alliance? Yes. I've been advising on the interconnect. >> Yes. In fact, the use of EAP *prevents* a large number of business >> models for network access. > > Could you expand on the problems? A customer wants to buy access. Right now in WiFi hotspots, they connect to a walled garden, and type in credit card details. Once payment has been processed, they obtain network access. If the only way to obtain network access is via EAP, then you have a bootstrapping problem. Once the users have signed up, everything is great. The users who *haven't* signed up are shut out. Permanently. The issue is less EAP than EAPoL. Without a real network connection, it's impossible for a client machine to do much of anything. EAP could be used in a walled garden if PANA was widely deployed, for example. 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: From owner-radiusext@ops.ietf.org Wed Dec 26 23:54:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7kkr-00039T-Ll for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:54:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7kkr-00089s-AO for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:54:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kh2-000BH5-59 for radiusext-data@psg.com; Thu, 27 Dec 2007 04:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kgx-000BFy-BH for radiusext@ops.ietf.org; Thu, 27 Dec 2007 04:50:02 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 79B5EA704E; Wed, 26 Dec 2007 20:49:52 -0800 (PST) Message-ID: <47732E9D.4030803@nitros9.org> Date: Thu, 27 Dec 2007 05:48:29 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> In-Reply-To: <007e01c847fa$cbae1a00$630a4e00$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Glen Zorn wrote: > I understand, & sympathize; I think that it's important to remember that a > major reason that we ended up in the position of having multiple external > SDOs defining their own mutually incompatible VSAs is that we (the IETF) > refused to address RADIUS' problems in a useful and meaningful way. We have > an opportunity now to ameliorate if not solve that problem; I don't think > that we should pass it up. If we're going to re-design the attribute format from scratch again, I'd like to know what we've accomplished in the past year. There were proposals that were ugly, but solved almost all of the concerns that were raised. This includes the ability to group legacy RADIUS attributes in a "new" format. The one show-stopper I see is putting standard RADIUS attributes into a VSA. If this has *zero* impact on implementations that don't understand the new format, then it would be acceptable. Otherwise, it's an incompatible change to RADIUS. If we can't put standard attributes into the new format, then we should just pick a better format, and ideally one that's been deployed. The WiMAX format (plus grouping) seems to fit that definition fairly well. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Dec 26 23:56:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7knf-0000eI-9F for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:56:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7knd-0008CS-UX for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 26 Dec 2007 23:56:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kkZ-000Bc8-Jr for radiusext-data@psg.com; Thu, 27 Dec 2007 04:53:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7kkW-000Bbr-P6 for radiusext@ops.ietf.org; Thu, 27 Dec 2007 04:53:41 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 449D2A704E; Wed, 26 Dec 2007 20:53:33 -0800 (PST) Message-ID: <47732F83.1000907@nitros9.org> Date: Thu, 27 Dec 2007 05:52:19 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Bernard Aboba wrote: > It will be interesting to see how well it works. I have previously been > involved in a number of > inter-domain roaming trials. When the RADIUS traffic was routed through > an exchange point, > the results were not very promising. With packet loss rates of 1-5%, I'll track the tests, and see if we can do some measurements under load. For existing (non-EAP) proxies, I don't recall seeing loss rates that high. I'll go check, but I think latencies and loss have decreased, while bandwidth has increased in the net. Plus, most RADIUS interconnects are now done over Ipsec, which helps with the underlying reliability. > RADIUS retransmissions > were pretty common and this would often lead to EAP retransmissions. > The overall > authentication times could get pretty long and sometimes authentication > wouldn't complete > at all. Most of the carriers we worked with ended up deploying web > portals instead :( WiMAX is standardizing on EAP for authentication. Discussions are underway to design a standard interconnect architecture. So this appears to be less of a problem now. 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: From owner-radiusext@ops.ietf.org Thu Dec 27 00:52:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7lfJ-0005yr-4E for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 00:52:22 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7lfG-0000ZO-Sq for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 00:52:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7lbL-000EsC-8d for radiusext-data@psg.com; Thu, 27 Dec 2007 05:48:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [208.179.69.44] (helo=WV-MAILSRV2.strixsystems.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7lal-000Eoy-9W for radiusext@ops.ietf.org; Thu, 27 Dec 2007 05:47:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 21:47:35 -0800 Message-ID: In-Reply-To: <00af01c8480c$5d526ef0$17f74cd0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on modified Extended Attribute format? Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgAAAt9pkAAPrF/w References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> <00af01c8480c$5d526ef0$17f74cd0$@net> From: "Matt Holdrege" To: "Glen Zorn" Cc: , "Alan DeKok" Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 No kidding. I think my first RADIUS WG meeting was almost 12 years ago = at IETF 35. Take a look at = http://www3.ietf.org/proceedings/96mar/area.and.wg.reports/ops/radius/rad= ius.html and read the minutes. You might laugh at the irony, or more likely cry. Are the current AD's = aware of the history here? -Matt -----Original Message----- From: Glen Zorn [mailto:glenzorn@comcast.net]=20 Sent: Wednesday, December 26, 2007 11:12 PM To: Matt Holdrege Cc: radiusext@ops.ietf.org; 'Alan DeKok' Subject: RE: Questions on modified Extended Attribute format? Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? [gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz] -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 27 05:31:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7q11-0007WA-3t for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 05:31:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7q0z-0005It-FW for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 05:31:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7pvP-0004Gk-LC for radiusext-data@psg.com; Thu, 27 Dec 2007 10:25:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7puz-0004El-Du for radiusext@ops.ietf.org; Thu, 27 Dec 2007 10:25:01 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 845C9A704E; Thu, 27 Dec 2007 02:24:37 -0800 (PST) Message-ID: <47737D1C.5050208@nitros9.org> Date: Thu, 27 Dec 2007 11:23:24 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: E2E and crypto-agility References: <47729414.9070608@nitros9.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Bernard_Aboba@hotmail.com wrote: >> What is "end to end" ? > > I think it means something like "protection of RADIUS attributes from > disclosure to parties other than the NAS and home server". OK. I just wanted to be sure. > In the AAA WG there were a number of mechanisms investigated by > which a NAS and home server could derive a key that could be > used to protect attributes from disclosure to proxies. These methods > included Kerberos and CMS. For example, see: > http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt i.e. The NAS somehow knows a realm, knows how to talk to a server for that realm, and can obtain a secret key for that realm. > So I think the question is not "can it be done?" but rather "how does > this relate to RADIUS crypto-agility?" and > "should solving this problem be a requirement?" I would say that it is a problem we should try to solve. I'm not sure how much it affects crypto-agility. Back to my earlier question about "end to end", I think the only ends that matter are the end user and home server. The NAS is in contact with both, and can leverage it's relationship with the end user to do things that are normally impossible in RADIUS. If we assume that the end user and home RADIUS server can independently derive keying material, then the server can supply keying material to the NAS, and the end user can do the same. The NAS can then derive keying material, without it being exposed to anyone else. e.g. RADIUS, end-user: derive K', K'' RADIUS -> NAS: E = ENC(K') (using key K'') end-user -> NAS: K'' If we assume that each RADIUS hop also encrypts E using the Tunnel-Password method: T = tunnel_encrypt(per-hop-secret, E) Then we have the following properties: - no RADIUS proxy knows K' (they only know E) - The NAS can derive K' from E and K'' - an attacker watching RADIUS only knows T - an attacker watching the end-user traffic only knows K'' - an attacker watching *both* RADIUS and supplicant traffic knows T and K'', which is insufficient to derive K' - any intermediary RADIUS proxy that handles tunnel-password encryption can transport E. For EAP-TLS based methods, the TLS master session key can be used to derive keying material. We would need to define one new RADIUS attribute to transport the keying material E, and update EAPoL to transport K''. This capability could be negotiated between the NAS and supplicant, and advertised to the home RADIUS server by the supplicant, inside of the TLS tunnel. So far as crypto-agility goes, this method needs to be extensible to multiple key sizes, encryption methods, authentication hashes, etc. But it's independent of transport proposals such as DTLS or TLS. (insert standard disclaimer here: this proposal has not been vetted by a crypto expert) 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: From owner-radiusext@ops.ietf.org Thu Dec 27 11:27:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7vZr-0005gK-8M for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 11:27:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7vZp-0003Ua-OA for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 11:27:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7vTR-0007OB-Ux for radiusext-data@psg.com; Thu, 27 Dec 2007 16:20:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7vTP-0007NV-5L for radiusext@ops.ietf.org; Thu, 27 Dec 2007 16:20:44 +0000 Received: (qmail 4525 invoked from network); 27 Dec 2007 11:20:41 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 27 Dec 2007 11:20:41 -0500 From: "David B. Nelson" To: References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> <47732D87.5030501@nitros9.org> Subject: RE: Comments on "practical deployments" Date: Thu, 27 Dec 2007 11:18:10 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002c01c848a4$12f10180$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchIQ9X6kcwWfPT/QyOn0U83uBGF3AAYA2KA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47732D87.5030501@nitros9.org> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Alan DeKok writes... > A customer wants to buy access. Right now in WiFi hotspots, they > connect to a walled garden, and type in credit card details. Once > payment has been processed, they obtain network access. > > If the only way to obtain network access is via EAP, then you have a > bootstrapping problem. Once the users have signed up, everything is > great. The users who *haven't* signed up are shut out. Permanently. So, this is really an enrollment issue, not an authentication issue? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 27 11:32:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7veU-0007KL-2o for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 11:32:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7veT-0003ab-QN for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 11:32:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7vXY-0007gD-16 for radiusext-data@psg.com; Thu, 27 Dec 2007 16:25:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7vXV-0007ff-8C for radiusext@ops.ietf.org; Thu, 27 Dec 2007 16:24:58 +0000 Received: (qmail 4597 invoked from network); 27 Dec 2007 11:24:56 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 27 Dec 2007 11:24:56 -0500 From: "David B. Nelson" To: References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> <47732F83.1000907@nitros9.org> Subject: RE: Comments on "practical deployments" Date: Thu, 27 Dec 2007 11:22:25 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002d01c848a4$aae0ba30$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AchIRN4GACFo3G70QmeG9a8ddUK70wAX1arg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47732F83.1000907@nitros9.org> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Alan DeKok writes... > Plus, most RADIUS interconnects are now done over Ipsec, which helps > with the underlying reliability. I'm surprised to hear that (IPsec usage). Is this in selected topologies or deployment scenarios? If IPsec were really used for most RADIUS transmissions, wouldn't we have already solved the Crypto-Agility problem? :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 27 13:44:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7xi5-0004oO-AF for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:44:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7xi4-0006Mh-3W for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:44:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xat-000G2t-Gf for radiusext-data@psg.com; Thu, 27 Dec 2007 18:36:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xag-000G1B-Cb for radiusext@ops.ietf.org; Thu, 27 Dec 2007 18:36:33 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id C08FEA704E; Thu, 27 Dec 2007 10:36:15 -0800 (PST) Message-ID: <4773F056.6070102@nitros9.org> Date: Thu, 27 Dec 2007 19:35:02 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> <47732D87.5030501@nitros9.org> <002c01c848a4$12f10180$5d1216ac@xpsuperdvd2> In-Reply-To: <002c01c848a4$12f10180$5d1216ac@xpsuperdvd2> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a David B. Nelson wrote: >> If the only way to obtain network access is via EAP, then you have a >> bootstrapping problem. Once the users have signed up, everything is >> great. The users who *haven't* signed up are shut out. Permanently. > > So, this is really an enrollment issue, not an authentication issue? No. Think of roaming, which I've been spending a lot of time on lately. If authentication is required for any IP-based network access, then how do roaming users know that they can authenticate using the local network? Pre-provisioning devices with roaming knowledge doesn't scale, and it doesn't handle dynamic networks. 802.11af doesn't scale either, and isn't designed to scale. When the user doesn't have any network access, they can't determine whether or not authentication is possible. They can't determine which authentication credentials to use. So requiring authentication means *forbidding* network access to a large class of users who could *potentially* obtain network access. 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: From owner-radiusext@ops.ietf.org Thu Dec 27 13:44:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7xiF-0006Rc-9T for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:44:11 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7xiC-0006My-VW for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:44:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xda-000GGI-07 for radiusext-data@psg.com; Thu, 27 Dec 2007 18:39:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xdX-000GFo-4N for radiusext@ops.ietf.org; Thu, 27 Dec 2007 18:39:20 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 53B85A704E; Thu, 27 Dec 2007 10:39:15 -0800 (PST) Message-ID: <4773F108.6060300@nitros9.org> Date: Thu, 27 Dec 2007 19:38:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" References: <47729414.9070608@nitros9.org> <4772AC0D.1000401@nitros9.org> <47732F83.1000907@nitros9.org> <002d01c848a4$aae0ba30$5d1216ac@xpsuperdvd2> In-Reply-To: <002d01c848a4$aae0ba30$5d1216ac@xpsuperdvd2> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 David B. Nelson wrote: > I'm surprised to hear that (IPsec usage). Is this in selected topologies or > deployment scenarios? If IPsec were really used for most RADIUS > transmissions, wouldn't we have already solved the Crypto-Agility problem? Most roaming providers and large companies do AAA interchange via IPSec. IPSec doesn't solve Crypto-Agility because there's no way for the RADIUS server to discover, or enforce, authentication and encryption policies. The only security relationships between the two are maintained in administrators heads, or in scripts tying the two systems together. Neither method is scalable, maintainable, or standardizable. 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: From owner-radiusext@ops.ietf.org Thu Dec 27 13:46:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7xkN-0001QD-48 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:46:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7xkK-0006QZ-OY for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 13:46:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xg5-000GUh-IL for radiusext-data@psg.com; Thu, 27 Dec 2007 18:41:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [209.85.146.178] (helo=wa-out-1112.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xfT-000GRC-W9 for radiusext@ops.ietf.org; Thu, 27 Dec 2007 18:41:40 +0000 Received: by wa-out-1112.google.com with SMTP id v27so5008212wah.23 for ; Thu, 27 Dec 2007 10:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=XvmfpDNS2jdgiEl0iD96rNO2/Tj3A6TdDXjX5MTYj44=; b=fJK7kfcbentwZffvq16d32H5uxzlJiLG3KcGRPff2whheEhYzA3sFDVz5VZcaQXvbf9bocKoLmLHNf+Lrz8Q7r0MCgZjwbvu2pxLEXnFUq79/BAR8HCCcVTKATNKxmvDsB0QoXIPp+v45GtTRQeZPOtJM0VD3WUCKTnNLhyU/5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=R5btNTC06IBswOjAFFVyTu1w+CCeYYrahWMHpp/BO7X25Th3A1fANnGVOlSDM//dn/qetJjJzSvvbn5QLLVRjiUonq9bbTxyKTO+R25IByRPQ++Mtbhh3gjIeoDg3lN2rPSPMPzqkGsNeF3Twdf1dyMB1gy9d4qLpy18wh1HysE= Received: by 10.115.77.1 with SMTP id e1mr6800137wal.103.1198780877402; Thu, 27 Dec 2007 10:41:17 -0800 (PST) Received: by 10.115.60.12 with HTTP; Thu, 27 Dec 2007 10:41:17 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 13:41:17 -0500 From: "Greg Weber" To: Bernard_Aboba@hotmail.com Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document Cc: radiusext@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17060_15529360.1198780877398" References: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e ------=_Part_17060_15529360.1198780877398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I went through the current RADIUS Guidelines doc and do not have anytechnical comments -one question and a couple minor editorial comments below. I think the doc can be passed to IESG. Question: In the description of polymorphic attributes (sec 3.2), what does this mean: "...the meaning of an attribute may depend on earlier packets in a sequence." ? Is that referring to a request/challenge sequence? Minor Editorial changes: Sec 1.1: "it's usage" -> "its usage" Sec 2.1.3: "to introduced" -> "to be introduced" Sec 2.1.3: "This issues" -> "These issues" Sec 2.1.3: "attributes involve authentication" -> "attributes involving authentication" Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last paragraph. That's not a good example anymore as we've earlier called IPv6 a basic data type in Sec 2.1.1. Sec 2.2: Last paragraph has the wrong indentation Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD" Sec 3.1.3: Expand PEC acronym at first use? Sec A.1.2: "not included nested groups" -> "not include nested groups" Greg On Dec 26, 2007 12:53 PM, wrote: > This is an announcement of RADEXT WG last call on the > "RADIUS Design Guidelines" document, prior to sending > it to the IESG for publication as a Proposed > Standard. The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt > > RADEXT WG last call will complete on January 15, 2008. Please respond > to this solicitation if you have read the document, regardless of whether > you > have comments to provide or not. In your email, please state whether you > believe that the document is ready for publication. > > If you have comments to provide, please send them to the > RADEXT WG mailing list (radiusext@ops.ietf.org), > using the format described in the RADEXT Issues tracker: > http://www.drizzle.com/~aboba/RADEXT/ > ------=_Part_17060_15529360.1198780877398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I went through the current RADIUS Guidelines doc and do not have any
technical comments -one question and a couple minor editorial comments
below.  I think the doc can be passed to IESG.

Question:  In the description of polymorphic attributes (sec 3.2), what 
does this mean:  "...the meaning of an attribute may depend on earlier
packets in a sequence."  ?   Is that referring to a request/challenge sequence?

Minor Editorial changes:
Sec 1.1: "it's usage" -> "its usage"
Sec 2.1.3: "to introduced" -> "to be introduced"
Sec 2.1.3: "This issues" -> "These issues"
Sec 2.1.3: "attributes involve authentication" -> "attributes involving authentication"
Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last paragraph.  That's not
  a good example anymore as we've earlier called IPv6 a basic data type in Sec 2.1.1.
Sec 2.2: Last paragraph has the wrong indentation
Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD"
Sec 3.1.3: Expand PEC acronym at first use?
Sec A.1.2: "not included nested groups" -> "not include nested groups"

Greg


On Dec 26, 2007 12:53 PM, < Bernard_Aboba@hotmail.com> wrote:
This is an announcement of RADEXT WG last call on the
"RADIUS Design Guidelines" document, prior to sending
it to the IESG for publication as a Proposed
Standard.  The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

RADEXT WG last call will complete on January 15, 2008.  Please respond
to this solicitation if you have read the document, regardless of whether you
have comments to provide or not.  In your email, please state whether you
believe that the document is ready for publication. 
 
If you have comments to provide, please send them to the
RADEXT WG mailing list (radiusext@ops.ietf.org),
using the format described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/

------=_Part_17060_15529360.1198780877398-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Dec 27 14:03:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7y1A-0002MU-CC for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 14:03:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7y19-0006os-TE for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 14:03:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xyO-000Hwt-CN for radiusext-data@psg.com; Thu, 27 Dec 2007 19:00:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J7xyI-000Hw2-8q for radiusext@ops.ietf.org; Thu, 27 Dec 2007 19:00:48 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 3F7E2A704E; Thu, 27 Dec 2007 11:00:41 -0800 (PST) Message-ID: <4773F60E.70001@nitros9.org> Date: Thu, 27 Dec 2007 19:59:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Greg Weber CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Greg Weber wrote: > I went through the current RADIUS Guidelines doc and do not have any > technical comments -one question and a couple minor editorial comments > below. I think the doc can be passed to IESG. Great! > Question: In the description of polymorphic attributes (sec 3.2), what > does this mean: "...the meaning of an attribute may depend on earlier > packets in a sequence." ? Is that referring to a request/challenge > sequence? Yes. Or, a series of otherwise unrelated Accounting-Requests. It's targeted at un-named SDO's and/or vendors who have horrid practices for dealing with attributes. Not just polymorphic attributes in one packet (if A then it's type B, otherwise it's type C), but across packets for *unrelated* sessions. > Minor Editorial changes: > Sec 1.1: "it's usage" -> "its usage" > Sec 2.1.3: "to introduced" -> "to be introduced" > Sec 2.1.3: "This issues" -> "These issues" > Sec 2.1.3: "attributes involve authentication" -> "attributes involving > authentication" > Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last > paragraph. That's not > a good example anymore as we've earlier called IPv6 a basic data type > in Sec 2.1.1. > Sec 2.2: Last paragraph has the wrong indentation > Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD" > Sec 3.1.3: Expand PEC acronym at first use? Already done in Section 2.2. > Sec A.1.2: "not included nested groups" -> "not include nested groups" All other changes are good, thanks. 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: From owner-radiusext@ops.ietf.org Thu Dec 27 18:35:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J82G1-0006wW-BU for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 18:35:21 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J82Fz-0003g0-OB for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 27 Dec 2007 18:35:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J82AT-000Fq0-C9 for radiusext-data@psg.com; Thu, 27 Dec 2007 23:29:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.24] (helo=QMTA02.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J82A1-000Fnq-Te for radiusext@ops.ietf.org; Thu, 27 Dec 2007 23:29:23 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id VyqN1Y00816AWCU0A02d00; Thu, 27 Dec 2007 23:29:09 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id VzV81Y00653lGY38S00000; Thu, 27 Dec 2007 23:29:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=48vgC7mUAAAA:8 a=No5EcEP4AAAA:8 a=ECnOX4djFyjpVVWMxboA:9 a=UWfgv0dW2oblu7RHuf8A:7 a=_wMaV0gE8aUV72-Uf9d3EpytRIYA:4 a=tqucuuI3bnEA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> <47732E9D.4030803@nitros9.org> In-Reply-To: <47732E9D.4030803@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Thu, 27 Dec 2007 15:28:26 -0800 Message-ID: <00b401c848e0$2f0e9c60$8d2bd520$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchIRFH0Fy3x6ehPQu6lbVwDQtyEOQACiamA Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Glen Zorn wrote: > I understand, & sympathize; I think that it's important to remember that a > major reason that we ended up in the position of having multiple external > SDOs defining their own mutually incompatible VSAs is that we (the IETF) > refused to address RADIUS' problems in a useful and meaningful way. We have > an opportunity now to ameliorate if not solve that problem; I don't think > that we should pass it up. If we're going to re-design the attribute format from scratch again, I'd like to know what we've accomplished in the past year. [gwz] I don't know where the "from scratch" comes from; there is a format defined in http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 .txt. I am suggesting adding a single octet to the format which A) would considerably enlarge the new type space and B) _could_ be used to standardize functionality that has been added to RADIUS over the years in an ad hoc fashion. [/gwz] There were proposals that were ugly, but solved almost all of the concerns that were raised. This includes the ability to group legacy RADIUS attributes in a "new" format. The one show-stopper I see is putting standard RADIUS attributes into a VSA. If this has *zero* impact on implementations that don't understand the new format, then it would be acceptable. Otherwise, it's an incompatible change to RADIUS. [gwz] Interesting definition of "incompatible". If that is in fact the standard to be met we may as well just fold up our tents and go home since there is _no_ change that could be made which would have "*zero* impact on implementations that don't understand". [/gwz] If we can't put standard attributes into the new format, then we should just pick a better format, and ideally one that's been deployed. The WiMAX format (plus grouping) seems to fit that definition fairly well. [gwz] Can you tell us what it looks like? [/gwz] Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 28 03:49:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Atn-0003n9-Kq for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 03:48:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8Atn-0005XK-1U for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 03:48:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8Anc-000MKM-BS for radiusext-data@psg.com; Fri, 28 Dec 2007 08:42:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8An6-000MIR-SZ for radiusext@ops.ietf.org; Fri, 28 Dec 2007 08:42:21 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 063F2A704E; Fri, 28 Dec 2007 00:41:55 -0800 (PST) Message-ID: <4774B67D.7040603@nitros9.org> Date: Fri, 28 Dec 2007 09:40:29 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> <47732E9D.4030803@nitros9.org> <00b401c848e0$2f0e9c60$8d2bd520$@net> In-Reply-To: <00b401c848e0$2f0e9c60$8d2bd520$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Glen Zorn wrote: > [gwz] I don't know where the "from scratch" comes from; there is a format > defined in > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 > .txt. I am suggesting adding a single octet to the format which Opens it up for change again, after a long discussion, where everyone had agreed that the format in -00 was acceptable. > Interesting definition of "incompatible". If that is in fact the standard > to be met we may as well just fold up our tents and go home since there is > _no_ change that could be made which would have "*zero* impact on > implementations that don't understand". It's not about changes, it's about *compatible* changes to the *standard* attributes. Let me re-phrase: - standard RADIUS attributes in a VSA MUST be compatible with existing implementations that only understand standard RADIUS attributes Put that way, it's obviously impossible. Since RADIUS has no capability negotiation, there's no way for the NAS to tell the server it is capable of that new functionality. Therefore, the proposed change is incompatible with existing deployments. > If we can't put standard attributes into the new format, then we > should just pick a better format, and ideally one that's been deployed. > The WiMAX format (plus grouping) seems to fit that definition fairly well. > > [gwz] > Can you tell us what it looks like? > [/gwz] The format in -00, which achieved WG consensus after long and protracted discussion. 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: From owner-radiusext@ops.ietf.org Fri Dec 28 06:20:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8DG9-00031C-EB for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 06:20:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8DG8-0001tn-UV for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 06:20:13 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8DAt-0005ns-70 for radiusext-data@psg.com; Fri, 28 Dec 2007 11:14:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8DAp-0005nW-TM for radiusext@ops.ietf.org; Fri, 28 Dec 2007 11:14:45 +0000 Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 62A68A704E; Fri, 28 Dec 2007 03:14:34 -0800 (PST) Message-ID: <4774DA45.4040106@nitros9.org> Date: Fri, 28 Dec 2007 12:13:09 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Bernard Aboba wrote: > Given that no comments have been received during the last two RADEXT WG > last calls, we are going to bring the document to RADEXT WG call again. > This RADEXT WG last call will last until January 15, 2008. Some comments: 1.4: It may be useful to note that an Accounting-Request packet MAY be generated when the NAS cannot apply an attribute in the Access-Accept. The Accounting Request MAY contain Error-Cause, with value "Unsupported Attribute" (401), and Acct-Status-Type = Stop, Acct-Terminate-Cause = NAS-Error. This serves as limited capability feedback. Page 12: "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent. The IPv6 equivalent is...? It could be specified here. "ipoptions" Match if the IP header contains the comma separated list of options specified in spec. The supported Can we allow hexadecimal specifications of options, too? This would be useful, and would match the rest of the document (e.g. IP proto as a number, icmptypes, ...) A similar comment applies for tcpoptions. 3.1: Acct-NAS-Traffic-Rule is a complex attribute not meeting the suggestions in the guidelines document. Is there another way to achieve the same end? Since the extended attributes draft is still pending, I think the answer is "no". 1.3: Capability advertisement could be done in a limited way by permitting NAS-Traffic-Rule in an Access-Request. Allowing this has practical uses, too. e.g. a WiFi hotspot (walled garden) could advertise upstream that it is *currently* blocking traffic, by sending it's filter rule: NAS-Traffic-Rule = "v1 redirect http://....local-login/" Similarly, a NAS requiring 802.1x could send: NAS-Traffic-Rule = "v1 permit inout l2:ether2:0x888e from any to NAS-MAC-address" i.e. EAPoL is permitted, everything else is discarded. This information is useful for upstream servers, and can help them make better policy decisions. It solves a serious problem in many current deployments, where you have no idea what the NAS is currently doing... 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: From owner-radiusext@ops.ietf.org Fri Dec 28 11:41:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8IHN-00004r-BF for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 11:41:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8IHL-0008Je-N9 for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 11:41:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8IC7-0003no-36 for radiusext-data@psg.com; Fri, 28 Dec 2007 16:36:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.40] (helo=QMTA04.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8IBh-0003ld-Pc for radiusext@ops.ietf.org; Fri, 28 Dec 2007 16:36:06 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id WGHL1Y0041HpZEs0A01700; Fri, 28 Dec 2007 16:35:57 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id WGbw1Y00853lGY38a00000; Fri, 28 Dec 2007 16:35:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=Gn-g1Pkd9IgA:10 a=48vgC7mUAAAA:8 a=Blv05YPQ_f2cQ_di2GEA:9 a=zPp6G401ZRb-dlDJdAEVKiws7pMA:4 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: "'Alan DeKok'" Cc: References: <003401c83a92$db6ed850$924c88f0$@net> <47729084.8060206@nitros9.org> <005d01c847e8$20c81f30$62585d90$@net> <4772A741.40303@nitros9.org> <007e01c847fa$cbae1a00$630a4e00$@net> <47732E9D.4030803@nitros9.org> <00b401c848e0$2f0e9c60$8d2bd520$@net> <4774B67D.7040603@nitros9.org> In-Reply-To: <4774B67D.7040603@nitros9.org> Subject: RE: Questions on modified Extended Attribute format? Date: Fri, 28 Dec 2007 08:35:11 -0800 Message-ID: <005601c8496f$9e430910$dac91b30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchJLY23MN1TT6VZTlKErx/oS6i0uwAQHKnw Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 ... > [gwz] I don't know where the "from scratch" comes from; there is a format > defined in > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 > .txt. I am suggesting adding a single octet to the format which Opens it up for change again, after a long discussion, where everyone had agreed that the format in -00 was acceptable. > Interesting definition of "incompatible". If that is in fact the standard > to be met we may as well just fold up our tents and go home since there is > _no_ change that could be made which would have "*zero* impact on > implementations that don't understand". It's not about changes, it's about *compatible* changes to the *standard* attributes. Let me re-phrase: - standard RADIUS attributes in a VSA MUST be compatible with existing implementations that only understand standard RADIUS attributes Put that way, it's obviously impossible. Since RADIUS has no capability negotiation, there's no way for the NAS to tell the server it is capable of that new functionality. Therefore, the proposed change is incompatible with existing deployments. [gwz] As I said, put that way or any other way you like, ANY change is incompatible with existing deployments. If one were to add a new "standard" attribute (in the old format or the proposed VSA-like format or any other) it would be incompatible with existing deployments. The whole idea of extended attributes REQUIRES that existing deployment be updated, no matter how they are formatted. [/gwz] > If we can't put standard attributes into the new format, then we > should just pick a better format, and ideally one that's been deployed. > The WiMAX format (plus grouping) seems to fit that definition fairly well. > > [gwz] > Can you tell us what it looks like? > [/gwz] The format in -00, which achieved WG consensus after long and protracted discussion. [gwz] Actually, while the timeframe was long, the discussion wasn't: I've only received a couple of comments on it in the last months. It _did_ take an inordinate amount of time to reject the 'Diameterization' of RADIUS, though... [/gwz] 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: From owner-radiusext@ops.ietf.org Fri Dec 28 16:28:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Ml3-0005gy-6W for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 16:28:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8Ml1-0006C9-Kn for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 16:28:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8MgK-0000oF-Df for radiusext-data@psg.com; Fri, 28 Dec 2007 21:23:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.175] (helo=bay0-omc2-s39.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8MgH-0000nn-VJ for radiusext@ops.ietf.org; Fri, 28 Dec 2007 21:23:51 +0000 Received: from BAY117-W16 ([207.46.8.51]) by bay0-omc2-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 13:23:49 -0800 Message-ID: X-Originating-IP: [67.183.152.50] From: Bernard Aboba To: Subject: Re: new format Date: Fri, 28 Dec 2007 13:23:49 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Dec 2007 21:23:49.0771 (UTC) FILETIME=[F02205B0:01C84997] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 [gwz]=20 Actually, I've convinced myself that a) this idea was not quite baked & b) = I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes a= t 0x100, that would seem to solve a couple of problems nicely. [BA] Could you elaborate on the new design and the issues this would solve= ? = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 28 17:57:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8O8w-0002ad-DG for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 17:57:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8O8v-0001iq-Vx for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 28 Dec 2007 17:57:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8O5J-0007Qb-QH for radiusext-data@psg.com; Fri, 28 Dec 2007 22:53:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.30.17] (helo=QMTA10.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1J8O5H-0007QG-2S for radiusext@ops.ietf.org; Fri, 28 Dec 2007 22:53:44 +0000 Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id WDwW1Y00T0x6nqcAA0iF00; Fri, 28 Dec 2007 22:53:41 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id WNtg1Y00753lGY38Y00000; Fri, 28 Dec 2007 22:53:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=zz3dB5q32WxJMubKTZMA:9 a=o3soeppdtKtru9tUsjeJ8RAn-s4A:4 a=4qiyTvuS2hIA:10 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: References: In-Reply-To: Subject: RE: new format Date: Fri, 28 Dec 2007 14:52:53 -0800 Message-ID: <00b201c849a4$61fdb420$25f91c60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchJmI0HHakdGdEEQNqLn3Xy23n13wACcYBg Content-Language: en-us Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 [gwz] Actually, I've convinced myself that a) this idea was not quite baked & b) I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes at 0x100, that would seem to solve a couple of problems nicely. [BA] Could you elaborate on the new design and the issues this would solve? [gwz] Making the Ext-Type field 16 bits instead of 8 basically eliminates the prospect of running out of attribute numbers. Starting the Ext-Type numbering at 0x100 instead of 1 eliminates any conflict between the extended attribute types and existing standard attributes; because the type spaces do not conflict and it's easy to differentiate between extended and standard attributes encapsulated in the new format (the most significant octet is always zero for standard attributes & never zero for extended types), this open the possibility of including standard attributes in the new format & getting the benefits of grouping, etc. for them as well as newly defined attributes. My motivation for suggesting this change is that it just occurred to me that all these groovy new capabilities defined for the extended attributes are nice but not especially useful (how many new standard attributes will we define? 5? 10? 20?) unless they could be applied to existing attributes, too. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Dec 2007 22:54:15 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" Cc: Subject: RE: new format Date: Fri, 28 Dec 2007 14:52:53 -0800 Message-ID: <00b201c849a4$61fdb420$25f91c60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchJmI0HHakdGdEEQNqLn3Xy23n13wACcYBg Content-Language: en-us [gwz] Actually, I've convinced myself that a) this idea was not quite baked & b) I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes at 0x100, that would seem to solve a couple of problems nicely. [BA] Could you elaborate on the new design and the issues this would solve? [gwz] Making the Ext-Type field 16 bits instead of 8 basically eliminates the prospect of running out of attribute numbers. Starting the Ext-Type numbering at 0x100 instead of 1 eliminates any conflict between the extended attribute types and existing standard attributes; because the type spaces do not conflict and it's easy to differentiate between extended and standard attributes encapsulated in the new format (the most significant octet is always zero for standard attributes & never zero for extended types), this open the possibility of including standard attributes in the new format & getting the benefits of grouping, etc. for them as well as newly defined attributes. My motivation for suggesting this change is that it just occurred to me that all these groovy new capabilities defined for the extended attributes are nice but not especially useful (how many new standard attributes will we define? 5? 10? 20?) unless they could be applied to existing attributes, too. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 28 Dec 2007 21:25:02 +0000 Message-ID: From: Bernard Aboba To: Subject: Re: new format Date: Fri, 28 Dec 2007 13:23:49 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 [gwz]=20 Actually, I've convinced myself that a) this idea was not quite baked & b) = I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes a= t 0x100, that would seem to solve a couple of problems nicely. [BA] Could you elaborate on the new design and the issues this would solve= ? = -- to unsubscribe send a message to radiusext-request@ops.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, 28 Dec 2007 16:37:22 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: RE: Questions on modified Extended Attribute format? Date: Fri, 28 Dec 2007 08:35:11 -0800 Message-ID: <005601c8496f$9e430910$dac91b30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchJLY23MN1TT6VZTlKErx/oS6i0uwAQHKnw Content-Language: en-us ... > [gwz] I don't know where the "from scratch" comes from; there is a format > defined in > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 > .txt. I am suggesting adding a single octet to the format which Opens it up for change again, after a long discussion, where everyone had agreed that the format in -00 was acceptable. > Interesting definition of "incompatible". If that is in fact the standard > to be met we may as well just fold up our tents and go home since there is > _no_ change that could be made which would have "*zero* impact on > implementations that don't understand". It's not about changes, it's about *compatible* changes to the *standard* attributes. Let me re-phrase: - standard RADIUS attributes in a VSA MUST be compatible with existing implementations that only understand standard RADIUS attributes Put that way, it's obviously impossible. Since RADIUS has no capability negotiation, there's no way for the NAS to tell the server it is capable of that new functionality. Therefore, the proposed change is incompatible with existing deployments. [gwz] As I said, put that way or any other way you like, ANY change is incompatible with existing deployments. If one were to add a new "standard" attribute (in the old format or the proposed VSA-like format or any other) it would be incompatible with existing deployments. The whole idea of extended attributes REQUIRES that existing deployment be updated, no matter how they are formatted. [/gwz] > If we can't put standard attributes into the new format, then we > should just pick a better format, and ideally one that's been deployed. > The WiMAX format (plus grouping) seems to fit that definition fairly well. > > [gwz] > Can you tell us what it looks like? > [/gwz] The format in -00, which achieved WG consensus after long and protracted discussion. [gwz] Actually, while the timeframe was long, the discussion wasn't: I've only received a couple of comments on it in the last months. It _did_ take an inordinate amount of time to reject the 'Diameterization' of RADIUS, though... [/gwz] 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, 28 Dec 2007 11:15:40 +0000 Message-ID: <4774DA45.4040106@nitros9.org> Date: Fri, 28 Dec 2007 12:13:09 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Given that no comments have been received during the last two RADEXT WG > last calls, we are going to bring the document to RADEXT WG call again. > This RADEXT WG last call will last until January 15, 2008. Some comments: 1.4: It may be useful to note that an Accounting-Request packet MAY be generated when the NAS cannot apply an attribute in the Access-Accept. The Accounting Request MAY contain Error-Cause, with value "Unsupported Attribute" (401), and Acct-Status-Type = Stop, Acct-Terminate-Cause = NAS-Error. This serves as limited capability feedback. Page 12: "any" Keyword for 0.0.0.0/0 or the IPv6 equivalent. The IPv6 equivalent is...? It could be specified here. "ipoptions" Match if the IP header contains the comma separated list of options specified in spec. The supported Can we allow hexadecimal specifications of options, too? This would be useful, and would match the rest of the document (e.g. IP proto as a number, icmptypes, ...) A similar comment applies for tcpoptions. 3.1: Acct-NAS-Traffic-Rule is a complex attribute not meeting the suggestions in the guidelines document. Is there another way to achieve the same end? Since the extended attributes draft is still pending, I think the answer is "no". 1.3: Capability advertisement could be done in a limited way by permitting NAS-Traffic-Rule in an Access-Request. Allowing this has practical uses, too. e.g. a WiFi hotspot (walled garden) could advertise upstream that it is *currently* blocking traffic, by sending it's filter rule: NAS-Traffic-Rule = "v1 redirect http://....local-login/" Similarly, a NAS requiring 802.1x could send: NAS-Traffic-Rule = "v1 permit inout l2:ether2:0x888e from any to NAS-MAC-address" i.e. EAPoL is permitted, everything else is discarded. This information is useful for upstream servers, and can help them make better policy decisions. It solves a serious problem in many current deployments, where you have no idea what the NAS is currently doing... 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, 28 Dec 2007 08:43:35 +0000 Message-ID: <4774B67D.7040603@nitros9.org> Date: Fri, 28 Dec 2007 09:40:29 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > [gwz] I don't know where the "from scratch" comes from; there is a format > defined in > http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 > .txt. I am suggesting adding a single octet to the format which Opens it up for change again, after a long discussion, where everyone had agreed that the format in -00 was acceptable. > Interesting definition of "incompatible". If that is in fact the standard > to be met we may as well just fold up our tents and go home since there is > _no_ change that could be made which would have "*zero* impact on > implementations that don't understand". It's not about changes, it's about *compatible* changes to the *standard* attributes. Let me re-phrase: - standard RADIUS attributes in a VSA MUST be compatible with existing implementations that only understand standard RADIUS attributes Put that way, it's obviously impossible. Since RADIUS has no capability negotiation, there's no way for the NAS to tell the server it is capable of that new functionality. Therefore, the proposed change is incompatible with existing deployments. > If we can't put standard attributes into the new format, then we > should just pick a better format, and ideally one that's been deployed. > The WiMAX format (plus grouping) seems to fit that definition fairly well. > > [gwz] > Can you tell us what it looks like? > [/gwz] The format in -00, which achieved WG consensus after long and protracted discussion. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 23:30:30 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: RE: Questions on modified Extended Attribute format? Date: Thu, 27 Dec 2007 15:28:26 -0800 Message-ID: <00b401c848e0$2f0e9c60$8d2bd520$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchIRFH0Fy3x6ehPQu6lbVwDQtyEOQACiamA Content-Language: en-us Glen Zorn wrote: > I understand, & sympathize; I think that it's important to remember that a > major reason that we ended up in the position of having multiple external > SDOs defining their own mutually incompatible VSAs is that we (the IETF) > refused to address RADIUS' problems in a useful and meaningful way. We have > an opportunity now to ameliorate if not solve that problem; I don't think > that we should pass it up. If we're going to re-design the attribute format from scratch again, I'd like to know what we've accomplished in the past year. [gwz] I don't know where the "from scratch" comes from; there is a format defined in http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00 .txt. I am suggesting adding a single octet to the format which A) would considerably enlarge the new type space and B) _could_ be used to standardize functionality that has been added to RADIUS over the years in an ad hoc fashion. [/gwz] There were proposals that were ugly, but solved almost all of the concerns that were raised. This includes the ability to group legacy RADIUS attributes in a "new" format. The one show-stopper I see is putting standard RADIUS attributes into a VSA. If this has *zero* impact on implementations that don't understand the new format, then it would be acceptable. Otherwise, it's an incompatible change to RADIUS. [gwz] Interesting definition of "incompatible". If that is in fact the standard to be met we may as well just fold up our tents and go home since there is _no_ change that could be made which would have "*zero* impact on implementations that don't understand". [/gwz] If we can't put standard attributes into the new format, then we should just pick a better format, and ideally one that's been deployed. The WiMAX format (plus grouping) seems to fit that definition fairly well. [gwz] Can you tell us what it looks like? [/gwz] Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 19:01:14 +0000 Message-ID: <4773F60E.70001@nitros9.org> Date: Thu, 27 Dec 2007 19:59:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Greg Weber CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greg Weber wrote: > I went through the current RADIUS Guidelines doc and do not have any > technical comments -one question and a couple minor editorial comments > below. I think the doc can be passed to IESG. Great! > Question: In the description of polymorphic attributes (sec 3.2), what > does this mean: "...the meaning of an attribute may depend on earlier > packets in a sequence." ? Is that referring to a request/challenge > sequence? Yes. Or, a series of otherwise unrelated Accounting-Requests. It's targeted at un-named SDO's and/or vendors who have horrid practices for dealing with attributes. Not just polymorphic attributes in one packet (if A then it's type B, otherwise it's type C), but across packets for *unrelated* sessions. > Minor Editorial changes: > Sec 1.1: "it's usage" -> "its usage" > Sec 2.1.3: "to introduced" -> "to be introduced" > Sec 2.1.3: "This issues" -> "These issues" > Sec 2.1.3: "attributes involve authentication" -> "attributes involving > authentication" > Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last > paragraph. That's not > a good example anymore as we've earlier called IPv6 a basic data type > in Sec 2.1.1. > Sec 2.2: Last paragraph has the wrong indentation > Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD" > Sec 3.1.3: Expand PEC acronym at first use? Already done in Section 2.2. > Sec A.1.2: "not included nested groups" -> "not include nested groups" All other changes are good, thanks. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 18:42:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=XvmfpDNS2jdgiEl0iD96rNO2/Tj3A6TdDXjX5MTYj44=; b=fJK7kfcbentwZffvq16d32H5uxzlJiLG3KcGRPff2whheEhYzA3sFDVz5VZcaQXvbf9bocKoLmLHNf+Lrz8Q7r0MCgZjwbvu2pxLEXnFUq79/BAR8HCCcVTKATNKxmvDsB0QoXIPp+v45GtTRQeZPOtJM0VD3WUCKTnNLhyU/5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=R5btNTC06IBswOjAFFVyTu1w+CCeYYrahWMHpp/BO7X25Th3A1fANnGVOlSDM//dn/qetJjJzSvvbn5QLLVRjiUonq9bbTxyKTO+R25IByRPQ++Mtbhh3gjIeoDg3lN2rPSPMPzqkGsNeF3Twdf1dyMB1gy9d4qLpy18wh1HysE= Message-ID: Date: Thu, 27 Dec 2007 13:41:17 -0500 From: "Greg Weber" To: Bernard_Aboba@hotmail.com Subject: Re: RADEXT WG last call on RADIUS Design Guidelines Document Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17060_15529360.1198780877398" ------=_Part_17060_15529360.1198780877398 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I went through the current RADIUS Guidelines doc and do not have anytechnical comments -one question and a couple minor editorial comments below. I think the doc can be passed to IESG. Question: In the description of polymorphic attributes (sec 3.2), what does this mean: "...the meaning of an attribute may depend on earlier packets in a sequence." ? Is that referring to a request/challenge sequence? Minor Editorial changes: Sec 1.1: "it's usage" -> "its usage" Sec 2.1.3: "to introduced" -> "to be introduced" Sec 2.1.3: "This issues" -> "These issues" Sec 2.1.3: "attributes involve authentication" -> "attributes involving authentication" Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last paragraph. That's not a good example anymore as we've earlier called IPv6 a basic data type in Sec 2.1.1. Sec 2.2: Last paragraph has the wrong indentation Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD" Sec 3.1.3: Expand PEC acronym at first use? Sec A.1.2: "not included nested groups" -> "not include nested groups" Greg On Dec 26, 2007 12:53 PM, wrote: > This is an announcement of RADEXT WG last call on the > "RADIUS Design Guidelines" document, prior to sending > it to the IESG for publication as a Proposed > Standard. The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt > > RADEXT WG last call will complete on January 15, 2008. Please respond > to this solicitation if you have read the document, regardless of whether > you > have comments to provide or not. In your email, please state whether you > believe that the document is ready for publication. > > If you have comments to provide, please send them to the > RADEXT WG mailing list (radiusext@ops.ietf.org), > using the format described in the RADEXT Issues tracker: > http://www.drizzle.com/~aboba/RADEXT/ > ------=_Part_17060_15529360.1198780877398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I went through the current RADIUS Guidelines doc and do not have any
technical comments -one question and a couple minor editorial comments
below.  I think the doc can be passed to IESG.

Question:  In the description of polymorphic attributes (sec 3.2), what 
does this mean:  "...the meaning of an attribute may depend on earlier
packets in a sequence."  ?   Is that referring to a request/challenge sequence?

Minor Editorial changes:
Sec 1.1: "it's usage" -> "its usage"
Sec 2.1.3: "to introduced" -> "to be introduced"
Sec 2.1.3: "This issues" -> "These issues"
Sec 2.1.3: "attributes involve authentication" -> "attributes involving authentication"
Sec 2.1.3: I'd remove the "(e.g., IPv6 address)" from the last paragraph.  That's not
  a good example anymore as we've earlier called IPv6 a basic data type in Sec 2.1.1.
Sec 2.2: Last paragraph has the wrong indentation
Sec 3.1.1: "vendors and SDOs they SHOULD" -> "vendors and SDOs SHOULD"
Sec 3.1.3: Expand PEC acronym at first use?
Sec A.1.2: "not included nested groups" -> "not include nested groups"

Greg


On Dec 26, 2007 12:53 PM, < Bernard_Aboba@hotmail.com> wrote:
This is an announcement of RADEXT WG last call on the
"RADIUS Design Guidelines" document, prior to sending
it to the IESG for publication as a Proposed
Standard.  The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

RADEXT WG last call will complete on January 15, 2008.  Please respond
to this solicitation if you have read the document, regardless of whether you
have comments to provide or not.  In your email, please state whether you
believe that the document is ready for publication. 
 
If you have comments to provide, please send them to the
RADEXT WG mailing list (radiusext@ops.ietf.org),
using the format described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/

------=_Part_17060_15529360.1198780877398-- -- to unsubscribe send a message to radiusext-request@ops.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, 27 Dec 2007 18:39:38 +0000 Message-ID: <4773F108.6060300@nitros9.org> Date: Thu, 27 Dec 2007 19:38:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > I'm surprised to hear that (IPsec usage). Is this in selected topologies or > deployment scenarios? If IPsec were really used for most RADIUS > transmissions, wouldn't we have already solved the Crypto-Agility problem? Most roaming providers and large companies do AAA interchange via IPSec. IPSec doesn't solve Crypto-Agility because there's no way for the RADIUS server to discover, or enforce, authentication and encryption policies. The only security relationships between the two are maintained in administrators heads, or in scripts tying the two systems together. Neither method is scalable, maintainable, or standardizable. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 18:37:53 +0000 Message-ID: <4773F056.6070102@nitros9.org> Date: Thu, 27 Dec 2007 19:35:02 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >> If the only way to obtain network access is via EAP, then you have a >> bootstrapping problem. Once the users have signed up, everything is >> great. The users who *haven't* signed up are shut out. Permanently. > > So, this is really an enrollment issue, not an authentication issue? No. Think of roaming, which I've been spending a lot of time on lately. If authentication is required for any IP-based network access, then how do roaming users know that they can authenticate using the local network? Pre-provisioning devices with roaming knowledge doesn't scale, and it doesn't handle dynamic networks. 802.11af doesn't scale either, and isn't designed to scale. When the user doesn't have any network access, they can't determine whether or not authentication is possible. They can't determine which authentication credentials to use. So requiring authentication means *forbidding* network access to a large class of users who could *potentially* obtain network access. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 16:25:17 +0000 From: "David B. Nelson" To: Subject: RE: Comments on "practical deployments" Date: Thu, 27 Dec 2007 11:22:25 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002d01c848a4$aae0ba30$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchIRN4GACFo3G70QmeG9a8ddUK70wAX1arg Alan DeKok writes... > Plus, most RADIUS interconnects are now done over Ipsec, which helps > with the underlying reliability. I'm surprised to hear that (IPsec usage). Is this in selected topologies or deployment scenarios? If IPsec were really used for most RADIUS transmissions, wouldn't we have already solved the Crypto-Agility problem? :-) -- to unsubscribe send a message to radiusext-request@ops.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, 27 Dec 2007 16:21:46 +0000 From: "David B. Nelson" To: Subject: RE: Comments on "practical deployments" Date: Thu, 27 Dec 2007 11:18:10 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002c01c848a4$12f10180$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchIQ9X6kcwWfPT/QyOn0U83uBGF3AAYA2KA Alan DeKok writes... > A customer wants to buy access. Right now in WiFi hotspots, they > connect to a walled garden, and type in credit card details. Once > payment has been processed, they obtain network access. > > If the only way to obtain network access is via EAP, then you have a > bootstrapping problem. Once the users have signed up, everything is > great. The users who *haven't* signed up are shut out. Permanently. So, this is really an enrollment issue, not an authentication issue? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 10:26:17 +0000 Message-ID: <47737D1C.5050208@nitros9.org> Date: Thu, 27 Dec 2007 11:23:24 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: E2E and crypto-agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: >> What is "end to end" ? > > I think it means something like "protection of RADIUS attributes from > disclosure to parties other than the NAS and home server". OK. I just wanted to be sure. > In the AAA WG there were a number of mechanisms investigated by > which a NAS and home server could derive a key that could be > used to protect attributes from disclosure to proxies. These methods > included Kerberos and CMS. For example, see: > http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt i.e. The NAS somehow knows a realm, knows how to talk to a server for that realm, and can obtain a secret key for that realm. > So I think the question is not "can it be done?" but rather "how does > this relate to RADIUS crypto-agility?" and > "should solving this problem be a requirement?" I would say that it is a problem we should try to solve. I'm not sure how much it affects crypto-agility. Back to my earlier question about "end to end", I think the only ends that matter are the end user and home server. The NAS is in contact with both, and can leverage it's relationship with the end user to do things that are normally impossible in RADIUS. If we assume that the end user and home RADIUS server can independently derive keying material, then the server can supply keying material to the NAS, and the end user can do the same. The NAS can then derive keying material, without it being exposed to anyone else. e.g. RADIUS, end-user: derive K', K'' RADIUS -> NAS: E = ENC(K') (using key K'') end-user -> NAS: K'' If we assume that each RADIUS hop also encrypts E using the Tunnel-Password method: T = tunnel_encrypt(per-hop-secret, E) Then we have the following properties: - no RADIUS proxy knows K' (they only know E) - The NAS can derive K' from E and K'' - an attacker watching RADIUS only knows T - an attacker watching the end-user traffic only knows K'' - an attacker watching *both* RADIUS and supplicant traffic knows T and K'', which is insufficient to derive K' - any intermediary RADIUS proxy that handles tunnel-password encryption can transport E. For EAP-TLS based methods, the TLS master session key can be used to derive keying material. We would need to define one new RADIUS attribute to transport the keying material E, and update EAPoL to transport K''. This capability could be negotiated between the NAS and supplicant, and advertised to the home RADIUS server by the supplicant, inside of the TLS tunnel. So far as crypto-agility goes, this method needs to be extensible to multiple key sizes, encryption methods, authentication hashes, etc. But it's independent of transport proposals such as DTLS or TLS. (insert standard disclaimer here: this proposal has not been vetted by a crypto expert) Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 05:49:09 +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: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 21:47:35 -0800 Message-ID: Thread-Topic: Questions on modified Extended Attribute format? Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgAAAt9pkAAPrF/w From: "Matt Holdrege" To: "Glen Zorn" Cc: , "Alan DeKok" No kidding. I think my first RADIUS WG meeting was almost 12 years ago = at IETF 35. Take a look at = http://www3.ietf.org/proceedings/96mar/area.and.wg.reports/ops/radius/rad= ius.html and read the minutes. You might laugh at the irony, or more likely cry. Are the current AD's = aware of the history here? -Matt -----Original Message----- From: Glen Zorn [mailto:glenzorn@comcast.net]=20 Sent: Wednesday, December 26, 2007 11:12 PM To: Matt Holdrege Cc: radiusext@ops.ietf.org; 'Alan DeKok' Subject: RE: Questions on modified Extended Attribute format? Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? [gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz] -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 04:54:03 +0000 Message-ID: <47732F83.1000907@nitros9.org> Date: Thu, 27 Dec 2007 05:52:19 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > It will be interesting to see how well it works. I have previously been > involved in a number of > inter-domain roaming trials. When the RADIUS traffic was routed through > an exchange point, > the results were not very promising. With packet loss rates of 1-5%, I'll track the tests, and see if we can do some measurements under load. For existing (non-EAP) proxies, I don't recall seeing loss rates that high. I'll go check, but I think latencies and loss have decreased, while bandwidth has increased in the net. Plus, most RADIUS interconnects are now done over Ipsec, which helps with the underlying reliability. > RADIUS retransmissions > were pretty common and this would often lead to EAP retransmissions. > The overall > authentication times could get pretty long and sometimes authentication > wouldn't complete > at all. Most of the carriers we worked with ended up deploying web > portals instead :( WiMAX is standardizing on EAP for authentication. Discussions are underway to design a standard interconnect architecture. So this appears to be less of a problem now. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 04:50:23 +0000 Message-ID: <47732E9D.4030803@nitros9.org> Date: Thu, 27 Dec 2007 05:48:29 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > I understand, & sympathize; I think that it's important to remember that a > major reason that we ended up in the position of having multiple external > SDOs defining their own mutually incompatible VSAs is that we (the IETF) > refused to address RADIUS' problems in a useful and meaningful way. We have > an opportunity now to ameliorate if not solve that problem; I don't think > that we should pass it up. If we're going to re-design the attribute format from scratch again, I'd like to know what we've accomplished in the past year. There were proposals that were ugly, but solved almost all of the concerns that were raised. This includes the ability to group legacy RADIUS attributes in a "new" format. The one show-stopper I see is putting standard RADIUS attributes into a VSA. If this has *zero* impact on implementations that don't understand the new format, then it would be acceptable. Otherwise, it's an incompatible change to RADIUS. If we can't put standard attributes into the new format, then we should just pick a better format, and ideally one that's been deployed. The WiMAX format (plus grouping) seems to fit that definition fairly well. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 04:46:15 +0000 Message-ID: <47732D87.5030501@nitros9.org> Date: Thu, 27 Dec 2007 05:43:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Is this the Fixed Mobile Covergence Alliance? Yes. I've been advising on the interconnect. >> Yes. In fact, the use of EAP *prevents* a large number of business >> models for network access. > > Could you expand on the problems? A customer wants to buy access. Right now in WiFi hotspots, they connect to a walled garden, and type in credit card details. Once payment has been processed, they obtain network access. If the only way to obtain network access is via EAP, then you have a bootstrapping problem. Once the users have signed up, everything is great. The users who *haven't* signed up are shut out. Permanently. The issue is less EAP than EAPoL. Without a real network connection, it's impossible for a client machine to do much of anything. EAP could be used in a walled garden if PANA was widely deployed, for example. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 27 Dec 2007 03:00:21 +0000 From: "David B. Nelson" To: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 21:58:54 -0500 Message-ID: <047101c84834$6add33c0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AchH6bKi6mr7v9FDS/emyMiHMVqnKAASb4ug Bernard Aboba writes... > > WiMAX uses the same attribute format as proposed here. Changes that > > are incompatible with WiMAX should be discouraged. > > I would agree. If the extensions remain compatible with WiMAX then > the amount of code duplication will be minimized. I'm not so sure that I agree. We should do what's right for the RADIUS community. If that happens to be compatible with WiMAX, then great. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 22:13:40 +0000 From: "Glen Zorn" To: "'Matt Holdrege'" Cc: , "'Alan DeKok'" Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 14:12:11 -0800 Message-ID: <00af01c8480c$5d526ef0$17f74cd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgAAAt9pkA== Content-Language: en-us Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? [gwz] Plus =E7a change, plus c'est la m=EAme chose... [/gwz] -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 20:52:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:51:25 -0800 Message-ID: Thread-Topic: Questions on modified Extended Attribute format? Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQAAGsRgA= From: "Matt Holdrege" To: "Glen Zorn" , "Alan DeKok" Cc: Glen, Didn't you say this same exact thing here a year or two ago? Or am I stuck in a time warp? Or is this group stuck in a time warp? -Matt (I'll go back into my hole now) -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn Sent: Wednesday, December 26, 2007 9:06 PM To: 'Alan DeKok' Cc: radiusext@ops.ietf.org Subject: RE: Questions on modified Extended Attribute format? [gwz]=20 I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 20:35:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 21:34:24 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9F17@SEHAN021MB.tcad.telia.se> Thread-Topic: Comments on "practical deployments" Thread-Index: AchH+sS7oemdAUhtTMa/Bsc3AOaVBwAAgeqg From: To: , Cc: Hi, > > > While proxies are widely used today to facilitate inter-domain=20 > > > roaming, as far as I know, the combination of=20 > inter-domain roaming=20 > > > and EAP is very rare. GSMA trialed (with a number of hotspot & GSM operators mainly in Europe & Asia) EAP-based 802.11 roaming few years ago. This concentrated mainly on EAP-SIM and EAP-AKA. > > The FMCA is trialling exactly this. >=20 > Is this the Fixed Mobile Covergence Alliance? =20 Yes. [snip] > >> For example, the vast majority of all IEEE 802.11 hotspot=20 > deployments=20 > >> use Web-based access (e.g. UAM), not EAP. > >=20 > > Yes. In fact, the use of EAP *prevents* a large number of business=20 > > models for network access. >=20 > Could you expand on the problems? >=20 > > UMA leverages EAP and RADIUS, but it's buried deep in the network. >=20 > Yup. Doesn't seem like this would require inter-domain proxies. In the existing specs for 3GPP GAN (i.e. the current UMA) inter-operator roaming is defined and reuses in a carbon-copy fashion 3GPP Interworking WLAN EAP-based RADIUS roaming interface. However, operator business models typically do not favor deployments where GAN would need inter-operator RADIUS interface.. at least I am not aware of any such deployments. Jouni >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 20:18:32 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_6dd47e72-f355-459e-9cd1-8663ebd42293_" From: Bernard Aboba To: Alan DeKok CC: Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 12:18:16 -0800 MIME-Version: 1.0 --_6dd47e72-f355-459e-9cd1-8663ebd42293_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The FMCA is trialling exactly this.=20 It will be interesting to see how well it works. I have previously been in= volved in a number of=20 inter-domain roaming trials. When the RADIUS traffic was routed through an= exchange point, the results were not very promising. With packet loss rates of 1-5%, RADIU= S retransmissions were pretty common and this would often lead to EAP retransmissions. The o= verall authentication times could get pretty long and sometimes authentication wou= ldn't complete at all. Most of the carriers we worked with ended up deploying web portals= instead :( --_6dd47e72-f355-459e-9cd1-8663ebd42293_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The FMCA is trialling exactly this.

It will be interesting to = see how well it works.  I have previously been involved in a number of=
inter-domain roaming trials.  When the RADIUS traffic was routed = through an exchange point,
the results were not very promising.  Wi= th packet loss rates of 1-5%, RADIUS retransmissions
were pretty common = and this would often lead to EAP retransmissions.  The overall
auth= entication times could get pretty long and sometimes authentication wouldn'= t complete
at all.  Most of the carriers we worked with ended up de= ploying web portals instead :(
= --_6dd47e72-f355-459e-9cd1-8663ebd42293_-- -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 20:11:37 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: , Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:10:32 -0800 Message-ID: <008801c847fb$5f8d0560$1ea71020$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchH8+quH1rguFTjRHKfwlnn7KP5TwABuaYQ Content-Language: en-us > If we're suddenly worried about the size of code for processing VSAs, it > would seem to make much more sense to be compatible with cisco's VSAs since > they are far more widely deployed than WiMax's (and probably always will > be). Yes... but strings? Really? [gwz] I know, but the point stands, no? [/gwz] > I'm not suggesting anything of the sort: the capabilities for sending large > attributes & grouping them already exist (although in limited ways); I'm > talking about standardizing these existing capabilies, not adding new ones. If we can get the functionality of the new extended attributes applied to legacy RADIUS, I'm all for it. But I don't want it to be a lot of work... that causes bugs and interoperability issues. My preferences are to leave the extended attributes defined the way they are right now. Anything else starts to cause issues. e.g. legacy attributes encapsulated in a VSA.... what happens with legacy implementations? The only image that comes to mind is a cloud going *boom*. [gwz] ;-) Not sure why, though -- they would be easily identified & it seems like the code we're talking about should already exist (that's why we chose these rather modest techniques in the first place, right?). [/gwz] 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, 26 Dec 2007 20:07:22 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 12:06:25 -0800 Message-ID: <007e01c847fa$cbae1a00$630a4e00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchH8+QgyomKZ9OBSR2hHFBZMYNg5QABjGnQ Content-Language: en-us > I'm not at all sure why that would be the case; I don't recall the IETF > bending over backwards to be compatible w/anyone else's VSAs... The last thing I need right now is yet another incompatible VSA format. [gwz] I understand, & sympathize; I think that it's important to remember that a major reason that we ended up in the position of having multiple external SDOs defining their own mutually incompatible VSAs is that we (the IETF) refused to address RADIUS' problems in a useful and meaningful way. We have an opportunity now to ameliorate if not solve that problem; I don't think that we should pass it up. [/gwz] ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 20:05:37 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_79d372da-1d12-4de7-b820-a264809dd28f_" From: Bernard Aboba To: Alan DeKok CC: Subject: RE: Comments on "practical deployments" Date: Wed, 26 Dec 2007 12:05:16 -0800 MIME-Version: 1.0 --_79d372da-1d12-4de7-b820-a264809dd28f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > While proxies are widely used today to facilitate inter-domain > > roaming, as far as I know, the combination of inter-domain roaming > > and EAP is very rare. >=20 > The FMCA is trialling exactly this. Is this the Fixed Mobile Covergence Alliance? =20 (This seemed the most likely of the expansions provided by Google, the othe= rs being: Family Motor Coach Association Florida Mosquito Control Association Florida Marine Contractors Association Friends of Montgomery County Animals) >> For example, the vast majority of all >> IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP= . >=20 > Yes. In fact, the use of EAP *prevents* a large number of business > models for network access. Could you expand on the problems? > UMA leverages EAP and RADIUS, but it's buried deep in the network. Yup. Doesn't seem like this would require inter-domain proxies. --_79d372da-1d12-4de7-b820-a264809dd28f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > While proxies are widely used today to facilitate inter-domain> > roaming, as far as I know, the combination of inter-domain roami= ng
> > and EAP is very rare.
>
> The FMCA is triall= ing exactly this.

Is this the Fixed Mobile Covergence Alliance? = ;

(This seemed the most likely of the expansions provided by Google= , the others being:

Family Motor Coach Association
Florida Mosqui= to Control Association
Florida Marine Contractors Association
Friends= of Montgomery County Animals)

>> For example, the vast majori= ty of all
>> IEEE 802.11 hotspot deployments use Web-based access = (e.g. UAM), not EAP.
>
> Yes. In fact, the use of EAP *prev= ents* a large number of business
> models for network access.

= Could you expand on the problems?

> UMA leverages EAP and RADIU= S, but it's buried deep in the network.

Yup.  Doesn't seem like= this would require inter-domain proxies.
= --_79d372da-1d12-4de7-b820-a264809dd28f_-- -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 19:54:27 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_52ab49c8-2d30-4f2d-a476-48f4b20945a4_" From: Bernard Aboba To: Subject: RADEXT WG last call on RADIUS Attributes for Filtering and Redirection Date: Wed, 26 Dec 2007 11:53:16 -0800 MIME-Version: 1.0 --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attribute= s for=20 Filtering and Redirection": http://ops.ietf.org/lists/radiusext/2007/msg00494.html http://ops.ietf.org/lists/radiusext/2007/msg00541.html This WG last call was to last until Monday, July 23, 2007. During the WG last call, only a single comment was received, from Hannes=20 Tschofenig: http://ops.ietf.org/lists/radiusext/2007/msg00496.html No other messages were posted to the RADEXT WG mailing list indicating that= =20 WG participants had read the document. Given the light level of participation, the WG last=20 call was extended for 10 more days (until August 28, 2007): http://ops.ietf.org/lists/radiusext/2007/msg00633.html No comments were received during that WG last call either. Given that no comments have been received during the last two RADEXT WG las= t calls, we are going to bring the document to RADEXT WG call again. This = RADEXT WG last call will last until January 15, 2008.=20 If you have read the=20 document and approve of its publication as a Proposed Standard, please post= =20 your approval to the list, even if you have no comments to provide. If you have comments, please provide them in the format described on the=20 RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On July 5, 2007 the RADEXT WG first began WG last call on "RADIUS Attri= butes for=20 Filtering and Redirection": 
http://ops.ietf.org/lists/radiuse=
xt/2007/msg00494.html
http://ops.ietf.org/lists/radiusext/2=
007/msg00541.html

This WG last call was to last until Monday, Ju=
ly 23, 2007.
During the WG last call, only a single comment wa= s received, from Hannes=20 Tschofenig: 
http://ops.ietf.org/lists/radiuse=
xt/2007/msg00496.html

No other messages were posted to the R=
ADEXT WG mailing list indicating that=20
WG participants had read the document.

Given the light level of participation, the WG l= ast=20 call was extended for 10 more days (until August 28, 2007):
htt= p://ops.ietf.org/lists/radiusext/2007/msg00633.html

No comments were= received during that WG last call either.

Given that no comments ha= ve been received during the last two RADEXT WG last calls, we are going to = bring the document to RADEXT WG call again.  This RADEXT WG last call = will last until January 15, 2008.

If you have read the=20 document and approve of its publication as a Proposed Standard, pl= ease post=20 your approval to the list, even if you have no comments to provide= . If you have comments, please provide them in the format described = on the=20 RADEXT WG Issues page: 
http://www.drizzle.com/~aboba/RADEXT/
= --_52ab49c8-2d30-4f2d-a476-48f4b20945a4_-- -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 19:34:06 +0000 Message-ID: <4772AC0D.1000401@nitros9.org> Date: Wed, 26 Dec 2007 20:31:25 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: Comments on "practical deployments" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: >> problems in practical deployments. > > Which "practical deployments" are we talking about? RADIUS proxies. There are multiple inter-telco && inter-country deployments using RADIUS. I'm not aware of any similar large-scale deployment of Diameter. (i.e. everyone I've talked to says "perhaps one day we'll move to Diameter".) > While proxies are widely used today to facilitate inter-domain > roaming, as far as I know, the combination of inter-domain roaming > and EAP is very rare. The FMCA is trialling exactly this. > While EAP-based technologies such as WiMAX may change the > situation, as I understand it, the use of EAP today is largely confined > to enterprise scenarios. For example, the vast majority of all > IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP. Yes. In fact, the use of EAP *prevents* a large number of business models for network access. > In terms of major EAP deployments that support inter-domain roaming > with substantial usage, one deployment (EDUROAM) is several orders of > magnitude larger than any other that I am aware of. UMA leverages EAP and RADIUS, but it's buried deep in the network. > As far as I know, EDUROAM does not use Diameter nor are there any > major deployments of Diameter EAP. Yes. > Am I missing something, or are there really any "practical experience" > here? Practical experience with existing AAA servers, proxies, and business models. The current technology is RADIUS. I'm trying to figure out how AAA redirection (and avoiding the intermediary proxies) helps anyone. I don't think it does. 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, 26 Dec 2007 19:17:21 +0000 Message-ID: <4772A842.8090308@nitros9.org> Date: Wed, 26 Dec 2007 20:15:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: Bernard_Aboba@hotmail.com, radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > If we're suddenly worried about the size of code for processing VSAs, it > would seem to make much more sense to be compatible with cisco's VSAs since > they are far more widely deployed than WiMax's (and probably always will > be). Yes... but strings? Really? > I'm not suggesting anything of the sort: the capabilities for sending large > attributes & grouping them already exist (although in limited ways); I'm > talking about standardizing these existing capabilies, not adding new ones. If we can get the functionality of the new extended attributes applied to legacy RADIUS, I'm all for it. But I don't want it to be a lot of work... that causes bugs and interoperability issues. My preferences are to leave the extended attributes defined the way they are right now. Anything else starts to cause issues. e.g. legacy attributes encapsulated in a VSA.... what happens with legacy implementations? The only image that comes to mind is a cloud going *boom*. 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, 26 Dec 2007 19:13:14 +0000 Message-ID: <4772A741.40303@nitros9.org> Date: Wed, 26 Dec 2007 20:10:57 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > I'm not at all sure why that would be the case; I don't recall the IETF > bending over backwards to be compatible w/anyone else's VSAs... The last thing I need right now is yet another incompatible VSA format. > Actually, I've convinced myself that a) this idea was not quite baked & b) I > was wrong about making the Ext-Type field just one octet. If we make the > Ext-Type field 16 bits in length _and_ start numbering the new attributes at > 0x100, that would seem to solve a couple of problems nicely. I understand... I'm not sure I completely agree. > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? > [gwz] > I don't know what method that is, but I'm not sure why those attributes > would be treated differently than others. > [/gwz] Neither am I. But they are. 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, 26 Dec 2007 18:52:54 +0000 Message-ID: From: To: "Alan DeKok" , Subject: Re: Comments on "practical deployments" Date: Wed, 26 Dec 2007 10:52:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > problems in practical deployments. Which "practical deployments" are we talking about? While proxies are widely used today to facilitate inter-domain roaming, as far as I know, the combination of inter-domain roaming and EAP is very rare. While EAP-based technologies such as WiMAX may change the situation, as I understand it, the use of EAP today is largely confined to enterprise scenarios. For example, the vast majority of all IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP. In terms of major EAP deployments that support inter-domain roaming with substantial usage, one deployment (EDUROAM) is several orders of magnitude larger than any other that I am aware of. As far as I know, EDUROAM does not use Diameter nor are there any major deployments of Diameter EAP. Am I missing something, or are there really any "practical experience" here? -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 18:43:55 +0000 Message-ID: From: To: "Alan DeKok" , Subject: Re: E2E and crypto-agility Date: Wed, 26 Dec 2007 10:42:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > What is "end to end" ? I think it means something like "protection of RADIUS attributes from disclosure to parties other than the NAS and home server". > I don't see how we could do NAS to home server key transport in > RADIUS. So the answer is (I think) "No". In the AAA WG there were a number of mechanisms investigated by which a NAS and home server could derive a key that could be used to protect attributes from disclosure to proxies. These methods included Kerberos and CMS. For example, see: http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt So I think the question is not "can it be done?" but rather "how does this relate to RADIUS crypto-agility?" and "should solving this problem be a requirement?" -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 18:17:37 +0000 From: "Glen Zorn" To: , "'Alan DeKok'" Cc: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 10:16:28 -0800 Message-ID: <006b01c847eb$70096650$501c32f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchH6VnSyItJtpl6RvSUZWLy43jIIwAAIzhw Content-Language: en-us > WiMAX uses the same attribute format as proposed here. Changes that > are incompatible with WiMAX should be discouraged. I would agree. If the extensions remain compatible with WiMAX then the amount of code duplication will be minimized. [gwz] If we're suddenly worried about the size of code for processing VSAs, it would seem to make much more sense to be compatible with cisco's VSAs since they are far more widely deployed than WiMax's (and probably always will be). [/gwz] > If it's just stealing a bit (which WiMAX doesn't use), that sounds > fine. The ability to group legacy RADIUS attributes via a method other > than tags would be good. > > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? We need to be careful about feature creep here. The original purpose of the Extended Attributes document was to extend the RADIUS attribute space. If the document is now taking on new problems (extending capabilities of the RADIUS protocol or changing the semantics of existing attributes) then that problem needs to be clearly stated, and justification needs to be provided. [gwz] I'm not suggesting anything of the sort: the capabilities for sending large attributes & grouping them already exist (although in limited ways); I'm talking about standardizing these existing capabilies, not adding new ones. [/gwz] -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 18:01:48 +0000 Message-ID: From: To: "Alan DeKok" , "Glen Zorn" Cc: Subject: Re: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 10:01:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > WiMAX uses the same attribute format as proposed here. Changes that > are incompatible with WiMAX should be discouraged. I would agree. If the extensions remain compatible with WiMAX then the amount of code duplication will be minimized. > If it's just stealing a bit (which WiMAX doesn't use), that sounds > fine. The ability to group legacy RADIUS attributes via a method other > than tags would be good. > > One question: If we DO permit this for legacy RADIUS attributes, what > does the "C" bit mean? Do we use the WiMAX method for splitting > attributes encrypted with the "Tunnel-Password" method? We need to be careful about feature creep here. The original purpose of the Extended Attributes document was to extend the RADIUS attribute space. If the document is now taking on new problems (extending capabilities of the RADIUS protocol or changing the semantics of existing attributes) then that problem needs to be clearly stated, and justification needs to be provided. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 18:00:52 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: RE: [ Comments on automated key management and crypto agility Date: Wed, 26 Dec 2007 09:59:23 -0800 Message-ID: <005e01c847e9$0dcbc7f0$296357d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchH6I1hz+I309tPQD+urxR21Ysz4AAAC18g Content-Language: en-us ... redirects have problems in practical deployments. Intermediate nodes often exist for commercial reasons, both for business relationships and for application of intermediary policies. [gwz] And, unfortunately, that's just scratching the surface; how that lame scheme got into an RFC I'll never know... [/gwz] Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Dec 2007 17:54:11 +0000 Message-ID: From: To: Subject: RADEXT WG last call on RADIUS Design Guidelines Document Date: Wed, 26 Dec 2007 09:53:05 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01C847A5.1CCD6D60" This is a multi-part message in MIME format. ------=_NextPart_000_00CC_01C847A5.1CCD6D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the=20 "RADIUS Design Guidelines" document, prior to sending=20 it to the IESG for publication as a Proposed=20 Standard. The document is available for inspection here:=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt RADEXT WG last call will complete on January 15, 2008. Please respond to this solicitation if you have read the document, regardless of = whether you have comments to provide or not. In your email, please state whether = you=20 believe that the document is ready for publication. =20 If you have comments to provide, please send them to the=20 RADEXT WG mailing list (radiusext@ops.ietf.org),=20 using the format described in the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/ ------=_NextPart_000_00CC_01C847A5.1CCD6D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is an announcement of RADEXT WG = last call on=20 the
"RADIUS Design = Guidelines" document, prior=20 to sending
it to the IESG for publication as a = Proposed=20
Standard.  The document is = available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.= txt

RADEXT WG last call will complete on = January 15,=20 2008.  Please respond
to this solicitation if you have read = the=20 document, regardless of whether you
have comments to provide or = not.  In your=20 email, please state whether you
believe that the document is ready = for=20 publication. 
 
If you have comments to provide, = please send them=20 to the
RADEXT WG mailing list (radiusext@ops.ietf.org),
using the format described in the = RADEXT Issues=20 tracker:
http://www.drizzle.com/~aboba/RADEXT/
------=_NextPart_000_00CC_01C847A5.1CCD6D60-- -- to unsubscribe send a message to radiusext-request@ops.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, 26 Dec 2007 17:53:54 +0000 From: "Glen Zorn" To: "'Alan DeKok'" Cc: Subject: RE: Questions on modified Extended Attribute format? Date: Wed, 26 Dec 2007 09:52:47 -0800 Message-ID: <005d01c847e8$20c81f30$62585d90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchH5bdl4qB55+LFT+K87w6d0sThIwAAHOvg Content-Language: en-us Glen Zorn wrote: > During the meeting last week, I thought that there were a couple of > questions/comments on Jabber regarding the changes that I proposed to > the extended attribute format (adding a bit to distinguish between new > TLVs and legacy RADIUS attributes in extended attributes) but I didn't > quite catch them. Would those who presented those remarks mind > repeating them in email? TIA. WiMAX uses the same attribute format as proposed here. Changes that are incompatible with WiMAX should be discouraged. [gwz] I'm not at all sure why that would be the case; I don't recall the IETF bending over backwards to be compatible w/anyone else's VSAs... [/gwz] If it's just stealing a bit (which WiMAX doesn't use), that sounds fine. The ability to group legacy RADIUS attributes via a method other than tags would be good. [gwz] Actually, I've convinced myself that a) this idea was not quite baked & b) I was wrong about making the Ext-Type field just one octet. If we make the Ext-Type field 16 bits in length _and_ start numbering the new attributes at 0x100, that would seem to solve a couple of problems nicely. [/gwz] One question: If we DO permit this for legacy RADIUS attributes, what does the "C" bit mean? Do we use the WiMAX method for splitting attributes encrypted with the "Tunnel-Password" method? [gwz] I don't know what method that is, but I'm not sure why those attributes would be treated differently than others. [/gwz] 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, 26 Dec 2007 17:51:15 +0000 Message-ID: <47729414.9070608@nitros9.org> Date: Wed, 26 Dec 2007 18:49:08 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: [ Comments on automated key management and crypto agility Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > However, this is logically separate from the need to provide end-to-end > protection for key transport. What is "end to end" ? Not to be dumb, but there are a number of parties involved: supplicant (or end user software) NAS (or AP) local RADIUS server intermediate proxies (0 or more) home RADIUS server (may be the same as the local RADIUS server) Which ends are we talking about? The EAP-TLS methods allow the supplicant and home server to agree on a key. So any "end to end" problem would appear to be getting keying material from the supplicant OR home server to the NAS, without exposing that material to any local server, or proxy server. > So far, the need to solve the end-to-end key transport problem has not > been part of RADIUS > crypto-agility requirements. Should it be? I don't see how we could do NAS to home server key transport in RADIUS. So the answer is (I think) "No". Any end-to-end key transport should involve EAP-TLS methods *and* RADIUS, I think. Just doing it in one or the other wouldn't work. If we tried to do it in RADIUS, we would end up with something that looked nothing like RADIUS. > With Diameter, it was clear that the IESG expected a solution to both > problems -- ciphersuite > negotiation (via TLS/IKE) as well as a mechanism for avoiding key > disclosure to proxies > (e.g. redirect). redirects have problems in practical deployments. Intermediate nodes often exist for commercial reasons, both for business relationships and for application of intermediary policies. 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, 26 Dec 2007 17:36:35 +0000 Message-ID: <47729084.8060206@nitros9.org> Date: Wed, 26 Dec 2007 18:33:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Glen Zorn CC: radiusext@ops.ietf.org Subject: Re: Questions on modified Extended Attribute format? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Glen Zorn wrote: > During the meeting last week, I thought that there were a couple of > questions/comments on Jabber regarding the changes that I proposed to > the extended attribute format (adding a bit to distinguish between new > TLVs and legacy RADIUS attributes in extended attributes) but I didn't > quite catch them. Would those who presented those remarks mind > repeating them in email? TIA. WiMAX uses the same attribute format as proposed here. Changes that are incompatible with WiMAX should be discouraged. If it's just stealing a bit (which WiMAX doesn't use), that sounds fine. The ability to group legacy RADIUS attributes via a method other than tags would be good. One question: If we DO permit this for legacy RADIUS attributes, what does the "C" bit mean? Do we use the WiMAX method for splitting attributes encrypted with the "Tunnel-Password" method? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 23 Dec 2007 09:08:19 +0000 From: Mike McCauley To: Bernard Aboba Subject: Re: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sun, 23 Dec 2007 19:07:08 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231907.08645.mikem@open.com.au> Hello Bernard, On Sunday 23 December 2007 17:47, Bernard Aboba wrote: > The test vectors in Section 6 are one of the major open questions. > Wolfgang did the original checks, but subsequent reviewers kept finding > errors in them, so they have been revised several times. > > What do you think is wrong with the B->C messages? I havent been able to reproduce the Digest-Response that is given the 2 samples in the RFC. I have some sample code that produces the correct digest result as given in RFC2617, but that same code gives Digest-Response different to that given in RFC5090 in both examples. Here is some sample code, FYI, in perl. You can see that its set up to test against either RFC2617 test data or RFC5090. The response it calculates for the RFC5090 test data is not the one given in the RFC use Digest::MD5; use strict; # RFC5090 web browser (second example) # FAILS #my $username = '12345678'; #my $realm = 'example.com'; #my $qop = 'auth'; #my $nonce = 'a3086ac8'; #my $cnonce = '56593a80'; #my $nc = '00000001'; #my $pw = 'secret'; #my $method = 'GET'; #my $uri = '/index.html'; #my $expected = 'ba623217b5ec024d30c4aaef9d8494de'; # RFC2617 OK: my $username = 'Mufasa'; my $realm = 'testrealm@host.com'; my $qop = 'auth'; my $nonce = 'dcd98b7102dd2f0e8b11d0f600bfb0c093'; my $cnonce = '0a4f113b'; my $nc = '00000001'; my $pw = 'Circle Of Life'; my $method = 'GET'; my $uri = '/dir/index.html'; my $expected = '6629fae49393a05397450978507c4ef1'; # auth my $ha1 = Digest::MD5::md5_hex("$username:$realm:$pw"); my $ha2 = Digest::MD5::md5_hex("$method:$uri"); my $response = Digest::MD5::md5_hex("$ha1:$nonce:$nc:$cnonce:$qop:$ha2"); print $response eq $expected ? "OK\n" : "WRONG RESPONSE\n"; Hope that helps. Cheers. > > > ---------------------------------------- > > > From: mikem@open.com.au > > To: bernard_aboba@hotmail.com > > Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE > > Date: Sun, 23 Dec 2007 15:50:37 +1000 > > CC: radiusext@ops.ietf.org > > > > Hi Bernard, > > > > Have the test vectors in section 6 Examples been checked? How? Im not > > sure I entirely agree with the Digest-Response values in the B->C > > messages > > > > Cheers. > > > > On Sunday 23 December 2007 03:37, Bernard Aboba wrote: > >> RFC 4590bis is now being held in AUTH48, pending final verification. > >> > >> What started as a "simple" IANA-problem fix has turned into a longer > >> odyssey due to the discovery of additional errors/omissions. > >> > >> In attempt to bring this story to a close, we need to make very sure > >> that we have looked over this document carefully so that we don't have > >> to go through this again with RFC 4590ter. > >> > >> So if you have ever had any interest in RADIUS Digest Authentication, > >> now would be the time to look over the AUTH48 version of the document, > >> and speak up if there is a problem. > >> > >>> Date: Fri, 21 Dec 2007 15:14:46 -0800 > >>> From: rfc-editor@rfc-editor.org > >>> To: beckw@t-systems.com > >>> CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; > >>> dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; > >>> rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; > >>> rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090 > >>> NOW AVAILABLE > >>> > >>> Greeings Wolfgang, > >>> > >>> Just a reminder that we are waiting to hear from you before continuing > >>> on with the publication process. > >>> > >>> Please see the email below for document information. > >>> > >>> Thank you. > >>> > >>> RFC Editor > >>> > >>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > >>>> Hi Wolfgang, > >>>> > >>>> Just a friendly reminder that we are waiting to hear from you before > >>>> continuing on with the publication process for RFC 5090 > >>>> . > >>>> > >>>> Please review the files located at: > >>>> > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > >>>> > >>>> Note that this diff file highlights only the differences between the > >>>> last posted version of the document and the current text file. The > >>>> previously posted versions (during AUTH48) are available as: > >>>> > >>>> The originally posted AUTH48 files: > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > >>>> > >>>> Version 2 (includes author updates) of AUTH48 files: > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > >>>> Note that this file highlights only the differences between the > >>>> version 1 and 2 text files. > >>>> > >>>> We will wait to hear from you before continuing on with the > >>>> publication process. > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/sg > >>>> > >>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > >>>>> I also talked to Wolfgang at IETF 70. He wanted to check the > >>>>> document over carefully to make sure there were no further issues. > >>>>> > >>>>>> Subject: RE: AUTH48 [SG]: RFC 5090 > >>>>> > >>>>> NOW AVAILABLE> Date: Mon, 10 > >>>>> Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: > >>>>> rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: > >>>>> david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; > >>>>> dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; > >>>>> d.b.nelson@comcast.net>> Yes,>> David Schwartz saw him at the ietf > >>>>> meeting and worked through the draft> with him. I think we should be > >>>>> hearing from him soon.>> Baruch>>> -----Original Message-----> > >>>>> From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> Sent: Monday, > >>>>> December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> > >>>>> Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; > >>>>> dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; > >>>>> Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: > >>>>> AUTH48 [SG]: RFC 5090 > NOW > >>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck > >>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27, > >>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz > >>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be > >>>>> there and he can nudge him to answer. Lets hold off until we> see>> > >>>>> if that way forward works. If not, we can go with option 3.>>>> > >>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From: > >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>> Sent: Tuesday, > >>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>> > >>>>> Subject: Re: AUTH48 [SG]: RFC 5090> > >>>>> > >>>>> >> NOW AVAILABLE>>>> Hi > >>>>> > >>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1. > >>>>> The author can be removed as an author, and moved to the>> > >>>>> Acknowledgements section.>>>> 2. We can create a Contributor's > >>>>> section and have him listed there.>>>> 3. We can request that the > >>>>> AD approve the document in place of the>> unavailabe author.>>>> > >>>>> Option 3 has been done before in instances where the missing author> > >>>>> > >>>>>> made sizeable contributions to the document, so the other authors> > >>>>>> did not feel comfortable removing the individuals name as an>> > >>>>> > >>>>> author.>>>> It sounds as though 3 may be the proper way forward. > >>>>> If this is the>> case, we will send an email to the ADs requesting > >>>>> their approval in>> place of Wolfgang (the message will be cc'ed to > >>>>> all relevant>> parties, including Wolfgang).>>>> If the above > >>>>> suggestions are unacceptable and you have an alternative>> solution, > >>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On > >>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I > >>>>> wrote to Wolfgang as well, but got no response. What is the>> > >>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with > >>>>> the changes.>> The>>> last email I received was on October 19 > >>>>> where he said that he had> made>>> the one correction (suggested by > >>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>> > >>>>> -----Original Message----->>> From: RFC Editor > >>>>> [mailto:rfc-editor@rfc-editor.org]>>> Sent: Wednesday, November > >>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman; > >>>>> dscreat@dscreat.com; David>> Schwartz;>>> beckw@t-systems.com>>> > >>>>> Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC>> > >>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>> > >>>>> > >>>>> >>> NOW AVAILABLE>>>>>> > >>>>> > >>>>> Greetings Wolfgang,>>>>>> We do not believe we have received > >>>>> your response regarding this>>> document's readiness for > >>>>> publication as an RFC. Please review the>>> text and let us know if > >>>>> you are content with the document as it now>>> appears at:>>>>> > >>>>> > >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note > >>>>> that this diff file highlights only the changes between the> last>> > >>>>> > >>>>>> posted version of the document and the current text file.>>>>> > >>>>>> > >>>>>>>>> The last versions of the document are available as:>>>>> > >>>>>> > >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>> > >>>>> > >>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>> > >>>>> Note that this diff file highlights only the changes between v1 and> > >>>>> > >>>>>>> the v2.>>>>>> We will wait to hear from you before > >>>>> > >>>>> continuing on with the>>> publication process.>>>>>> Thank > >>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at > >>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We > >>>>> have corrected the text as indicated below and posted the> revised>> > >>>>> > >>>>>>> version of the document at:>>>>>>>> > >>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>> > >>>>> Note that this diff file highlights only the changes betwee the> > >>>>> last>>>>>> posted version of the document and the current text > >>>>> file.>>>>>>>> Please review the document and let us know if > >>>>> you approve this>>>> text for publication.>>>>>>>> We > >>>>> believe we are waiting for the following approvals:>>>>>>>> > >>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David > >>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>> > >>>>> > >>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>> > >>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at > >>>>> > >>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>> > >>>>> > >>>>>>> Please confer and let us know how the text should/should not use> > >>>>>> > >>>>>> the>>>>> quote marks. It sounds as though this email was for > >>>>> > >>>>> discussion.>> If>>>>> the changes below are acceptable, we will > >>>>> make the changes and>> post>>> a>>>>> revised version of the > >>>>> document.>>>>>>>>>> Also, please note the following status > >>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done > >>>>> (although we would like to know if you> agree>>>>> with the > >>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>> > >>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>> > >>>>> > >>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to > >>>>> > >>>>> hear further before continuing on with the>>> publication>>>>> > >>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor> > >>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400, > >>>>> > >>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>> > >>>>> These look good, and I agree with your consistency comment. I>>> > >>>>> have a few>>>>>> more specific changes to suggest that I would > >>>>> like you and>> others>>> to>>>>>> review as well. But first > >>>>> a couple of general style comments>> that>>> require>>>>>> > >>>>> no changes to the document.>>>>>>>>>>>> General comment > >>>>> #1: I tried to find a definitive style guide> to>>> use of>>>> > >>>>> > >>>>>>> single quotes versus double quotes and found there is no hard>> > >>>>>> > >>>>>> guidelines,>>>>>> that consistency is most important:>>>> > >>>>>> > >>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>> > >>>>> > >>>>> http://forum.wordreference.com/showthread.php?t=120946>>>>>> > >>>>> Though I tend to think that double quotes are more commonly> used>> > >>>>> > >>>>>> and match>>>>>> the syntax of more popular programming > >>>>> > >>>>> languages, but there> are>> so>>> many>>>>>> quoted items in > >>>>> the document and it has been this way for a> long>>> time, so>>> > >>>>> > >>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2: > >>>>> > >>>>> When refering to responses from the radius>>> server>>>>>> > >>>>> there are a lot of instances of a comment similiar to "without>>> > >>>>> surrounding>>>>>> quotes" that potentially could be removed for > >>>>> readability.>>> Especially if>>>>>> there were a more concise > >>>>> definition up-front about the> general>>> form of>>>>>> > >>>>> values returned from the radius server. But I am a little>>> > >>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>> > >>>>> > >>>>>> Specific comments, to build on top of your list:>>>>>>>>>> > >>>>>> > >>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>> > >>>>>> > >>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If > >>>>> > >>>>> a matching (Proxy-)Authorization header is present and>>> contains> > >>>>> > >>>>>>>>>> HTTP Digest information, the RADIUS client checks the > >>>>> > >>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph, > >>>>> do not need quotes around response.>> Paragraph>>> should>>>> > >>>>> > >>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the > >>>>> > >>>>> nonce, it takes the>> header>>>>>> directives and puts them > >>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the > >>>>> response directive into a Digest-Response> attribute>>> and>>>> > >>>>> > >>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>> > >>>>> > >>>>> username,>>>>>> and opaque directives into the respective > >>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop, > >>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count, > >>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>> > >>>>> RADIUS client puts the request method into the> Digest-Method>>>> > >>>>> > >>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to > >>>>> > >>>>> the items you point out, in> the>>> last>>>>>> paragraph, > >>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>> > >>>>> > >>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce> > >>>>> > >>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS > >>>>> client puts the contents> of>>> this>>>>>> attribute into a > >>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style > >>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the > >>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph > >>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an > >>>>> Access-Challenge packet 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>>>>>> surrounding quotes), the > >>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407) > >>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>> > >>>>> directive stale and the digest directives derived from the>>> > >>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think > >>>>> the wording of the last sentence in this same>>> paragraph>>>> > >>>>> > >>>>>>> could be improved. So that the paragraph reads more like:>>>> > >>>>>>> > >>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge > >>>>> > >>>>> packet 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>>>>>> surrounding quotes), the RADIUS client sends an > >>>>> error>> response>>> (401>>>>>> or 407) containing a > >>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive > >>>>> set to 'true' and the digest directives>> derived>>> from>>>>> > >>>>> > >>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10, > >>>>> > >>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>> > >>>>> > >>>>>>> defined and should not be used, that qop directive or> qop-value> > >>>>>>> would be>>>>>> better. In other words the paragraph should > >>>>> > >>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a > >>>>> hash of the>>> HTTP-style>>>>>> message body's contents is > >>>>> required for digest>>> calculation.>>>>>> Instead of sending > >>>>> the complete body of the message,>> only>>> its>>>>>> hash > >>>>> value is sent. This hash value can be used>> directly>>> in>>>> > >>>>> > >>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15, > >>>>> > >>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>> > >>>>> > >>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for > >>>>> > >>>>> future extensions>> and>>>>>> corresponds to the auth-param > >>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The > >>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS > >>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param > >>>>> extension parameters contained within Digest>>> headers that>>>> > >>>>> > >>>>>>> are not understood by the RADIUS client and for which>>> there > >>>>> > >>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>> > >>>>> > >>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the> > >>>>>>> > >>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a > >>>>> > >>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>> > >>>>> > >>>>>> MAY send one or more Digest-Domain attributes in its>>> Access-> > >>>>>> > >>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>> > >>>>>> > >>>>>> quoted,>>>>>> space-separated list of URIs of the domain > >>>>> > >>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with > >>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the > >>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for > >>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>> > >>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>> > >>>>> > >>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no > >>>>> > >>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe > >>>>> there should be no quotes around> qop.>>> So that>>>>>> the > >>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to > >>>>> allow the generation of an>>>>>> Authentication-Info header, > >>>>> even if the HTTP-style>>> response's>>>>>> body is required > >>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD > >>>>> be used in Access-Accept packets if the>>> required>>>>>> > >>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>> > >>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007, > >>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy > >>>>> discussions with my father-in-law who is a>>> professor of>>>>> > >>>>> > >>>>>>>English, I agree with Dave's method of using quotes only in> the> > >>>>>>> value of>>>>>>>an attribute/directive, but not in > >>>>> > >>>>> referencing the>>> attribute/directive>>>>>>>by name. As > >>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3 > >>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>> > >>>>> > >>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the > >>>>> > >>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>> > >>>>> > >>>>>>>> the RADIUS client puts the Digest-Response-Auth>>> > >>>>> > >>>>> attribute's>>>>>>> content into the Authentication-Info > >>>>> header's rspauth>>>>>>> directive of the HTTP-style response.> > >>>>> > >>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around > >>>>> > >>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the > >>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>> > >>>>> > >>>>>>>>>> RADIUS client checks the qop and algorithm directives in>> > >>>>> > >>>>> the>>>>>>> Authorization header of the HTTP-style request it > >>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next > >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the > >>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>> > >>>>> > >>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>> > >>>>> > >>>>> not>>>>>>> include an Authentication-Info header in its> > >>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next > >>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>> > >>>>> > >>>>>> * If the qop directive's value is 'auth-int' and at> least>>> > >>>>> > >>>>> one>>>>>>> of the following conditions is true, the RADIUS> > >>>>> client>>>>>>> calculates the contents of the HTTP-style > >>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>> > >>>>> > >>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response> > >>>>>> > >>>>>> message>>> and>>>>>>> calculates the hash of this message's > >>>>> > >>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI > >>>>> attribute's value of the>> corresponding>>>>>>> Access-Request > >>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes > >>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>> > >>>>> > >>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>> > >>>>>> > >>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the> > >>>>> > >>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no > >>>>> > >>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute > >>>>> enables the RADIUS server to prove>>> possession of>>>>>>> > >>>>> the password. If the previously received Digest-Qop>>> attribute>> > >>>>> > >>>>>>>>>> was 'auth-int' (without surrounding 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 packets. The RADIUS client>> puts>>> the>>>>> > >>>>> > >>>>>>> attribute value without surrounding quotes into the>>> rspauth> > >>>>>>> > >>>>>>>>>>> directive of the Authentication-Info header.>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes > >>>>> > >>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put > >>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept > >>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>> > >>>>> client MUST put the contents of this attribute into> the>>>>>>> > >>>>> nextnonce directive of an Authentication-Info header> in>>> its>> > >>>>> > >>>>>>>>>> HTTP-style response. This attribute MUST only be> used>> > >>>>> > >>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> If the HTTP-style request has an Authorization> > >>>>> > >>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri > >>>>> directive> found>>> in>>>>>>> the HTTP-style request > >>>>> Authorization header (known as>>> "digest->>>>>>> uri-value" > >>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>> > >>>>> quotes into this attribute. If there is no>> Authorization>>>>> > >>>>> > >>>>>>> header, the RADIUS client takes the value of the>> request>>> > >>>>> > >>>>> URI>>>>>>> from the HTTP-style request it wants to > >>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th > >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In > >>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>> > >>>>> > >>>>>>>>>> qop directive (qop-value as described in [RFC2617])>> > >>>>> > >>>>> from>>> the>>>>>>> HTTP-style request it wants to > >>>>> authenticate. In>> Access->>>>>>> Challenge packets, the > >>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this > >>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>> > >>>>> > >>>>>> one "quality of protection" value, it puts each>> qop-value>>> > >>>>> > >>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>> > >>>>> > >>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>> > >>>>>>>>> > >>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to> > >>>>>>> > >>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a > >>>>> > >>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client > >>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false' > >>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of > >>>>> this attribute into a stale directive of> the>>> WWW->>>>>>> > >>>>> Authenticate header in the HTTP-style response to the>>> request>> > >>>>> > >>>>>>>>>> it wants to authenticate. The attribute MUST only be>>> > >>>>> > >>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>> > >>>>> > >>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>> > >>>>>>> > >>>>>>>> This attribute is used to allow the generation of an>>>>>> > >>>>>> > >>>>>> Authentication-Info header, even if the HTTP-style>>> response's> > >>>>>> > >>>>>>>>>>> body is required for the calculation of the rspauth>>> > >>>>> > >>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if > >>>>> the>>> required>>>>>>> quality of protection ('qop') is > >>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>I think that does it. Even if this is not right, at least it> > >>>>>>> > >>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>> > >>>>>> > >>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>> > >>>>>> > >>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From: > >>>>> > >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>>>>>>>Sent: > >>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>> > >>>>> > >>>>>>>>>Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>>> > >>>>>>>>>beckw@t-systems.com; radext-ads@tools.ietf.org;>>>>>> > >>>>>> > >>>>>>radext-chairs@tools.ietf.org; RFC Editor>>>>>>>Subject: Re: > >>>>> > >>>>> AUTH48 [SG]: RFC 5090>>> >>> > >>>>> > >>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>> > >>>>>>>>> > >>>>>>>>>>>>>>We have not heard further regarding the issues below > >>>>> > >>>>> or other>>> changes>>>>>>>that may be required before > >>>>> publishing this document as an> RFC.>>>>>>>Please review the > >>>>> document and let us know if there are any>>>>>>>corrections > >>>>> required.>>>>>>>>>>>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>> > >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>> > >>>>> > >>>>>>>>>>>>>>We will wait to hear from you before continuing on > >>>>> > >>>>> with the>>>>>>>publication process.>>>>>>>>>>>>> > >>>>> > >>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>> > >>>>>> > >>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> > >>>>>>> > >>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While > >>>>> > >>>>> reviewing > during>>> AUTH48,> > >>>>> > >>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>> > >>>>>>>> > >>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>> > >>>>>>>> > >>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks > >>>>> > >>>>> (')>> in>>>>>>>>>>>this document. There seems to be > >>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which > >>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in > >>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth' > >>>>> > >>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth > >>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ", > >>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the > >>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we > >>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses > >>>>> 's. However, if you feel that the document>>> should be>>>>>> > >>>>> > >>>>>>>>more alignmed with RFC 2617, please let us know and we will>>> > >>>>> > >>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are > >>>>> taking a vote, I would prefer using " instead of '>>> around>>>> > >>>>> > >>>>>>>>the>>>>>>>>value strings. I think it is better to stay > >>>>> > >>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590. > >>>>> Also I believe the " usage is more commonly used in>> other>>>>> > >>>>> > >>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also, > >>>>> > >>>>> we had a difficult time understanding the use of 's.>> We>>>>>> > >>>>> > >>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>> > >>>>>> > >>>>>> were>>>>>>>>>used as values or directives. However, we did > >>>>> > >>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives > >>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let > >>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it > >>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>> > >>>>> > >>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop" > >>>>> > >>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted > >>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on > >>>>> style but my initial thought is to>> suggest>>>>>>>removing '> > >>>>> > >>>>>>>>>>>>and " from keywords when refering to a directive name > >>>>> > >>>>> rather>>> than its>>>>>>>>literal value, and then use "" when > >>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>> > >>>>> > >>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>>>>> o If the Access-Accept packet contains a > >>>>> > >>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the > >>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization > >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> > >>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is > >>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS > >>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>> > >>>>> > >>>>>>> include an Authentication-Info header in its>> HTTP-style>>>> > >>>>>>> > >>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>However when examing 2617 in more detail, using " around the>>> > >>>>> > >>>>> directive>>>>>>>>>>>>>>>names would be more consistent > >>>>> with that draft. For example>>> this>>>>>>>would>>>>>> > >>>>> > >>>>>>>become:>>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>> > >>>>> > >>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and > >>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization > >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> > >>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is > >>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client > >>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>> > >>>>> include an Authentication-Info header in its>> HTTP-style>>>>>> > >>>>> > >>>>>>> response.>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>Prehaps others can weigh in one which they believe is most> > >>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a > >>>>> > >>>>> slight improvement on the> existing>>> text>>>>>>>which>>> > >>>>> > >>>>>>>>>>uses single quotes around the string values.>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at > >>>>> > >>>>> 03:11:50PM -0700,>>> rfc-editor@rfc-editor.org>>>>>>>wrote:> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC > >>>>> > >>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>> > >>>>>>>>> > >>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> > >>>>>>> > >>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make > >>>>> > >>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your > >>>>> document at:>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>> > >>>>>>>>> > >>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally > >>>>> > >>>>> introduces>> errors>>> that>>>>>>>>>>were not in the > >>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>> > >>>>> > >>>>>>>>>hard to catch all errors, proofreading the text at least>>> > >>>>> > >>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an > >>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the > >>>>> correctness of the final product> when>>> you OK>>>>>> > >>>>> > >>>>>>>>>publication. You should therefore proofread the entire> RFC>>> > >>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in > >>>>> > >>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a > >>>>> diff tool that compares the approved>>>>>>>internet-draft>>> > >>>>> > >>>>>>>>>>>>against our edited RFC version of the document. Please>> > >>>>> > >>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>> > >>>>> > >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> > >>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered > >>>>> > >>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to > >>>>> create the diff file above. To make the>> file>>> more>>>>>> > >>>>> > >>>>>>>>>useful, we moved the terminology section to to appear> after>>> > >>>>> > >>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until > >>>>> > >>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC > >>>>> have affirmed that the document is ready to be>>>>>> > >>>>> > >>>>>>>>>published, as ALL of the authors are equally responsible> for>> > >>>>>>>>> > >>>>>>>>>>verifying>>>>>>>>>>the documents readiness for > >>>>> > >>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list > >>>>> of suitable keywords for this>>> document,>>>>>>>over>>>> > >>>>> > >>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> - > >>>>> > >>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>> > >>>>> > >>>>>>>>>>>>> (especially if you originally put the copyright>>>>> > >>>>>>> > >>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document, > >>>>> > >>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo' > >>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO > >>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes > >>>>> made. (If we think that the changes might be more>>> than>>>>> > >>>>> > >>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that> > >>>>>>> > >>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>> > >>>>>>> > >>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>> > >>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>> > >>>>> > >>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>> > >>>>> > >>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes > >>>>> > >>>>> are spacing or indentation> than>>> please>>>>>>>note>>>> > >>>>> > >>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the > >>>>> > >>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The > >>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>> > >>>>> > >>>>>>>>>>>>>If you have a whole paragraph to replace you do not need> > >>>>> > >>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With > >>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces> > >>>>> > >>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>> > >>>>> > >>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary > >>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>> > >>>>> > >>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>This document will NOT be published until we receive>>> > >>>>> > >>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document > >>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks > >>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>> > >>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension > >>>>> > >>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) : > >>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,> > >>>>> > >>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) : > >>>>> > >>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan > >>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>> > > > > -- > > Mike McCauley mikem@open.com.au > > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > http://www.open.com.au Phone +61 7 5598-7474 Fax > > +61 7 5598-7070 > > > > Radiator: the most portable, flexible and configurable RADIUS server > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.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, 23 Dec 2007 07:48:27 +0000 Message-ID: From: Bernard Aboba To: Mike McCauley CC: Subject: RE: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sat, 22 Dec 2007 23:47:28 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 The test vectors in Section 6 are one of the major open questions. Wolfgan= g did the original checks, but subsequent reviewers kept finding errors in = them, so they have been revised several times.=20 What do you think is wrong with the B->C messages?=20 ---------------------------------------- > From: mikem@open.com.au > To: bernard_aboba@hotmail.com > Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE > Date: Sun, 23 Dec 2007 15:50:37 +1000 > CC: radiusext@ops.ietf.org >=20 > Hi Bernard, >=20 > Have the test vectors in section 6 Examples been checked? How? Im not sur= e I=20 > entirely agree with the Digest-Response values in the B->C messages >=20 > Cheers. >=20 > On Sunday 23 December 2007 03:37, Bernard Aboba wrote: >> RFC 4590bis is now being held in AUTH48, pending final verification. >> >> What started as a "simple" IANA-problem fix has turned into a longer >> odyssey due to the discovery of additional errors/omissions. >> >> In attempt to bring this story to a close, we need to make very sure tha= t >> we have looked over this document carefully so that we don't have to go >> through this again with RFC 4590ter. >> >> So if you have ever had any interest in RADIUS Digest Authentication, no= w >> would be the time to look over the AUTH48 version of the document, and >> speak up if there is a problem. >> >>> Date: Fri, 21 Dec 2007 15:14:46 -0800 >>> From: rfc-editor@rfc-editor.org >>> To: beckw@t-systems.com >>> CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; >>> dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; >>> rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; >>> rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090=20 >>> NOW AVAILABLE >>> >>> Greeings Wolfgang, >>> >>> Just a reminder that we are waiting to hear from you before continuing >>> on with the publication process. >>> >>> Please see the email below for document information. >>> >>> Thank you. >>> >>> RFC Editor >>> >>> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: >>>> Hi Wolfgang, >>>> >>>> Just a friendly reminder that we are waiting to hear from you before >>>> continuing on with the publication process for RFC 5090 >>>> . >>>> >>>> Please review the files located at: >>>> >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html >>>> >>>> Note that this diff file highlights only the differences between the >>>> last posted version of the document and the current text file. The >>>> previously posted versions (during AUTH48) are available as: >>>> >>>> The originally posted AUTH48 files: >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html >>>> >>>> Version 2 (includes author updates) of AUTH48 files: >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt >>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html >>>> Note that this file highlights only the differences between the >>>> version 1 and 2 text files. >>>> >>>> We will wait to hear from you before continuing on with the >>>> publication process. >>>> >>>> Thank you. >>>> >>>> RFC Editor/sg >>>> >>>> On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: >>>>> I also talked to Wolfgang at IETF 70. He wanted to check the >>>>> document over carefully to make sure there were no further issues. =20 >>>>>> Subject: RE: AUTH48 [SG]: RFC 5090 >>>>> NOW AVAILABLE> Date: Mon, 10 >>>>> Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: >>>>> rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: >>>>> david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; >>>>> dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; >>>>> d.b.nelson@comcast.net>> Yes,>> David Schwartz saw him at the ietf >>>>> meeting and worked through the draft> with him. I think we should be >>>>> hearing from him soon.>> Baruch>>> -----Original Message-----> >>>>> From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> Sent: Monday, >>>>> December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> >>>>> Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; >>>>> dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; >>>>> Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: >>>>> AUTH48 [SG]: RFC 5090 > NOW >>>>> AVAILABLE>> All,>> Just checking to see if you have had any luck >>>>> contacting Wolfgang?>> Thanks!>> RFC Editor/sg>> On Tue, Nov 27, >>>>> 2007 at 09:21:45PM +0200, Baruch Sterman wrote:>> David Schwartz >>>>> will be at the IETF meetings next week. Maybe Wolfgang>> will be >>>>> there and he can nudge him to answer. Lets hold off until we> see>> >>>>> if that way forward works. If not, we can go with option 3.>>>> >>>>> Thanks,>>>> Baruch>>>>>> -----Original Message----->> From: >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>> Sent: Tuesday, >>>>> November 27, 2007 12:41 AM>> To: Baruch Sterman>> Cc: RFC Editor>> >>>>> Subject: Re: AUTH48 [SG]: RFC 5090> >>>>> >> NOW AVAILABLE>>>> Hi >>>>> Baruch,>>>> We have a couple of ways to move forward.>>>> 1. >>>>> The author can be removed as an author, and moved to the>> >>>>> Acknowledgements section.>>>> 2. We can create a Contributor's >>>>> section and have him listed there.>>>> 3. We can request that the >>>>> AD approve the document in place of the>> unavailabe author.>>>> >>>>> Option 3 has been done before in instances where the missing author> >>>>>> made sizeable contributions to the document, so the other authors> >>>>>> did not feel comfortable removing the individuals name as an>> >>>>> author.>>>> It sounds as though 3 may be the proper way forward. >>>>> If this is the>> case, we will send an email to the ADs requesting >>>>> their approval in>> place of Wolfgang (the message will be cc'ed to >>>>> all relevant>> parties, including Wolfgang).>>>> If the above >>>>> suggestions are unacceptable and you have an alternative>> solution, >>>>> please let us know.>>>> Thank you.>>>> RFC Editor>>>> On >>>>> Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:>>> I >>>>> wrote to Wolfgang as well, but got no response. What is the>> >>>>> procedure>>> in this case? I am sure that Wolfgang would be ok with >>>>> the changes.>> The>>> last email I received was on October 19 >>>>> where he said that he had> made>>> the one correction (suggested by >>>>> Ellermann) in the cnonce value.>>>>>> Baruch>>>>>>>>> >>>>> -----Original Message----->>> From: RFC Editor >>>>> [mailto:rfc-editor@rfc-editor.org]>>> Sent: Wednesday, November >>>>> 21, 2007 10:35 PM>>> To: David Williams; Baruch Sterman; >>>>> dscreat@dscreat.com; David>> Schwartz;>>> beckw@t-systems.com>>> >>>>> Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC>> >>>>> Editor>>> Subject: Re: AUTH48 [SG]: RFC 5090>> >>>>> >>> NOW AVAILABLE>>>>>> >>>>> Greetings Wolfgang,>>>>>> We do not believe we have received >>>>> your response regarding this>>> document's readiness for >>>>> publication as an RFC. Please review the>>> text and let us know if >>>>> you are content with the document as it now>>> appears at:>>>>> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> Note >>>>> that this diff file highlights only the changes between the> last>> >>>>>> posted version of the document and the current text file.>>>>> >>>>>>>>> The last versions of the document are available as:>>>>> >>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html>>>> >>>>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html>>> >>>>> Note that this diff file highlights only the changes between v1 and> >>>>>>> the v2.>>>>>> We will wait to hear from you before >>>>> continuing on with the>>> publication process.>>>>>> Thank >>>>> you.>>>>>> RFC Editor>>>>>> On Fri, Nov 16, 2007 at >>>>> 05:13:04PM -0800, RFC Editor wrote:>>>> Authors,>>>>>>>> We >>>>> have corrected the text as indicated below and posted the> revised>> >>>>>>> version of the document at:>>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>> >>>>> Note that this diff file highlights only the changes betwee the> >>>>> last>>>>>> posted version of the document and the current text >>>>> file.>>>>>>>> Please review the document and let us know if >>>>> you approve this>>>> text for publication.>>>>>>>> We >>>>> believe we are waiting for the following approvals:>>>>>>>> >>>>> Baruch Sterman - done>>>> Daniel Sadolevsky - done>>>> David >>>>> Schwartz - done>>>> David Williams>>>> Wolfgang Beck>>>>>> >>>>>>> Bernard Aboba - done>>>>>>>>>>>> Thank you.>>>>>> >>>>>>> RFC Editor>>>>>>>>>>>> On Tue, Nov 06, 2007 at >>>>> 04:58:49PM -0800, RFC Editor wrote:>>>>> Authors,>>>>>>>> >>>>>>> Please confer and let us know how the text should/should not use> >>>>>> the>>>>> quote marks. It sounds as though this email was for >>>>> discussion.>> If>>>>> the changes below are acceptable, we will >>>>> make the changes and>> post>>> a>>>>> revised version of the >>>>> document.>>>>>>>>>> Also, please note the following status >>>>> of document approvals:>>>>>>>>>> Baruch Sterman - done >>>>> (although we would like to know if you> agree>>>>> with the >>>>> changes described below)>>>>> Daniel Sadolevsky - done>>>>> >>>>> David Schwartz>>>>> David Williams>>>>> Wolfgang Beck>>>> >>>>>>>>>>> Bernard Aboba - done>>>>>>>>>> We will wait to >>>>> hear further before continuing on with the>>> publication>>>>> >>>>> process.>>>>>>>>>> Thank you.>>>>>>>>>> RFC Editor> >>>>>>>>>>>>>>>>>>> On Fri, Oct 19, 2007 at 01:33:14PM -0400, >>>>> David Williams wrote:>>>>>> Hi Baruch,>>>>>>>>>>>> >>>>> These look good, and I agree with your consistency comment. I>>> >>>>> have a few>>>>>> more specific changes to suggest that I would >>>>> like you and>> others>>> to>>>>>> review as well. But first >>>>> a couple of general style comments>> that>>> require>>>>>> >>>>> no changes to the document.>>>>>>>>>>>> General comment >>>>> #1: I tried to find a definitive style guide> to>>> use of>>>> >>>>>>> single quotes versus double quotes and found there is no hard>> >>>>>> guidelines,>>>>>> that consistency is most important:>>>> >>>>>>> http://en.wikipedia.org/wiki/Quotation_mark>>>>>> >>>>> http://forum.wordreference.com/showthread.php?t=3D120946>>>>>> >>>>> Though I tend to think that double quotes are more commonly> used>> >>>>>> and match>>>>>> the syntax of more popular programming >>>>> languages, but there> are>> so>>> many>>>>>> quoted items in >>>>> the document and it has been this way for a> long>>> time, so>>> >>>>>>>> best to leave as is.>>>>>>>>>>>> General comment #2: >>>>> When refering to responses from the radius>>> server>>>>>> >>>>> there are a lot of instances of a comment similiar to "without>>> >>>>> surrounding>>>>>> quotes" that potentially could be removed for >>>>> readability.>>> Especially if>>>>>> there were a more concise >>>>> definition up-front about the> general>>> form of>>>>>> >>>>> values returned from the radius server. But I am a little>>> >>>>> hesitant to>>>>>> just strip them out now.>>>>>>>>>>> >>>>>> Specific comments, to build on top of your list:>>>>>>>>>> >>>>>>> In section 2.1.2, 1st paragraph should not have quotes around>> >>>>>> nonce.>>>>>> Paragraph should read:>>>>>>>>>>>> If >>>>> a matching (Proxy-)Authorization header is present and>>> contains> >>>>>>>>>> HTTP Digest information, the RADIUS client checks the >>>>> nonce>>>>>> parameter.>>>>>>>>>>>> In next paragraph, >>>>> do not need quotes around response.>> Paragraph>>> should>>>> >>>>>>> read:>>>>>>>>>>>> If the RADIUS client recognizes the >>>>> nonce, it takes the>> header>>>>>> directives and puts them >>>>> into a RADIUS Access-Request> packet.>>> It>>>>>> puts the >>>>> response directive into a Digest-Response> attribute>>> and>>>> >>>>>>> the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,>>> >>>>> username,>>>>>> and opaque directives into the respective >>>>> Digest-Realm,>>> Digest-Nonce,>>>>>> Digest-URI, Digest-Qop, >>>>> Digest-Algorithm, Digest-CNonce,>>> Digest->>>>>> Nonce-Count, >>>>> Digest-Username, and Digest-Opaque attributes.>>> The>>>>>> >>>>> RADIUS client puts the request method into the> Digest-Method>>>> >>>>>>> attribute.>>>>>>>>>>>> In section 2.1.3, in addtion to >>>>> the items you point out, in> the>>> last>>>>>> paragraph, >>>>> nextnounce does not need quoting. Paragraph> should>>> read:>>>> >>>>>>>>>>>>> When the RADIUS server provides a Digest-Nextnonce> >>>>> attribute>> in>>> the>>>>>> Access-Accept packet, the RADIUS >>>>> client puts the contents> of>>> this>>>>>> attribute into a >>>>> nextnonce directive. Now it can send an>> HTTP->>>>>> style >>>>> response.>>>>>>>>>>>> In section 2.1.4, 2nd paragraph, the >>>>> stale directive should> not>>> need>>>>>> quoting. Paragraph >>>>> should read:>>>>>>>>>>>> If the RADIUS client receives an >>>>> Access-Challenge packet 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>>>>>> surrounding quotes), the >>>>> RADIUS client sends an error>> response>>> (401>>>>>> or 407) >>>>> containing a WWW-/Proxy-Authenticate header with> the>>>>>> >>>>> directive stale and the digest directives derived from the>>> >>>>> Digest-*>>>>>> attributes.>>>>>>>>>>>> Except I think >>>>> the wording of the last sentence in this same>>> paragraph>>>> >>>>>>> could be improved. So that the paragraph reads more like:>>>> >>>>>>>>>>>>> If the RADIUS client receives an Access-Challenge >>>>> packet 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>>>>>> surrounding quotes), the RADIUS client sends an >>>>> error>> response>>> (401>>>>>> or 407) containing a >>>>> WWW-/Proxy-Authenticate header with> the>>>>>> stale directive >>>>> set to 'true' and the digest directives>> derived>>> from>>>>> >>>>>> the Digest-* attributes.>>>>>>>>>>>> In section 3.10, >>>>> 1st paragraph, I believe the term "qop-level">> is>>> ill>>>> >>>>>>> defined and should not be used, that qop directive or> qop-value> >>>>>>> would be>>>>>> better. In other words the paragraph should >>>>> read:>>>>>>>>>>>> When using the qop-value 'auth-int', a >>>>> hash of the>>> HTTP-style>>>>>> message body's contents is >>>>> required for digest>>> calculation.>>>>>> Instead of sending >>>>> the complete body of the message,>> only>>> its>>>>>> hash >>>>> value is sent. This hash value can be used>> directly>>> in>>>> >>>>>>> the digest calculation.>>>>>>>>>>>> In section 3.15, >>>>> auth-param doesn't need quoting. So that the>>> paragraph>>>>> >>>>>> becomes:>>>>>>>>>>>> This attribute is a placeholder for >>>>> future extensions>> and>>>>>> corresponds to the auth-param >>>>> parameter defined in>>> Section>>>>>> 3.2.1 of [RFC2617]. The >>>>> Digest-Auth-Param is the>>> mechanism>>>>>> whereby the RADIUS >>>>> client and RADIUS server can>> exchange>>> auth->>>>>> param >>>>> extension parameters contained within Digest>>> headers that>>>> >>>>>>> are not understood by the RADIUS client and for which>>> there >>>>> are>>>>>> no corresponding stand-alone attributes.>>>>>>> >>>>>>>>>> In section 3.17, domain doesn't need quoting. So that the> >>>>>>> paragraph>>>>>> becomes:>>>>>>>>>>>> When a >>>>> RADIUS client has asked for a nonce, the> RADIUS>>> server>>>>> >>>>>> MAY send one or more Digest-Domain attributes in its>>> Access-> >>>>>>>>>> Challenge packet. The RADIUS client puts them into> the>> >>>>>> quoted,>>>>>> space-separated list of URIs of the domain >>>>> directive> of>> a>>>>>> WWW-Authenticate header. Together with >>>>> Digest-Realm,>> the>>> URIs>>>>>> in the list define the >>>>> protection space (see> [RFC2617],>>> Section>>>>>> 3.2.1) for >>>>> some HTTP-style protocols. This attribute>>> MUST only>>>>>> >>>>> be used in Access-Challenge and Accounting-Request>>> packets.>>> >>>>>>>>>>>>>> In section 3.19, 1st paragraph, in addtion to no >>>>> quotes around>>> rspauth as>>>>>> you pointed out, I believe >>>>> there should be no quotes around> qop.>>> So that>>>>>> the >>>>> paragraph reads:>>>>>>>>>>>> This attribute is used to >>>>> allow the generation of an>>>>>> Authentication-Info header, >>>>> even if the HTTP-style>>> response's>>>>>> body is required >>>>> for the calculation of the rspauth>>> value.>>>>>> It SHOULD >>>>> be used in Access-Accept packets if the>>> required>>>>>> >>>>> quality of protection (qop) is 'auth-int'.>>>>>>>>>>>> >>>>> thanks,>>>>>> -david>>>>>>>>>>>> On Fri, 19 Oct 2007, >>>>> 1:43pm, Baruch Sterman wRote:>>>>>>>>>>>>>After lengthy >>>>> discussions with my father-in-law who is a>>> professor of>>>>> >>>>>>>English, I agree with Dave's method of using quotes only in> the> >>>>>>> value of>>>>>>>an attribute/directive, but not in >>>>> referencing the>>> attribute/directive>>>>>>>by name. As >>>>> such, I have some changes.>>>>>>>>>>>>>>In section 2.1.3 >>>>> 3rd paragraph should not have quotes around>> the>>> word>>>>> >>>>>>>rspauth. Sentence should read:>>>>>>>>>>>>>> * If the >>>>> Digest-Qop attribute's value is 'auth' or not>>> specified,>>>> >>>>>>>> the RADIUS client puts the Digest-Response-Auth>>> >>>>> attribute's>>>>>>> content into the Authentication-Info >>>>> header's rspauth>>>>>>> directive of the HTTP-style response.> >>>>>>>>>>>>>>>>>>Same section 5th paragraph - no quotes around >>>>> qop and>> algorithm:>>>>>>>>>>>>>> o If the >>>>> Access-Accept packet contains a Digest-HA1>> attribute,>>> the>> >>>>>>>>>> RADIUS client checks the qop and algorithm directives in>> >>>>> the>>>>>>> Authorization header of the HTTP-style request it >>>>> wants> to>>>>>>> authorize:>>>>>>>>>>>>>>Next >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> * If the >>>>> qop directive is missing or its value is> 'auth',>>> the>>>>>> >>>>>> RADIUS client ignores the Digest-HA1 attribute. It>> does>>> >>>>> not>>>>>>> include an Authentication-Info header in its> >>>>> HTTP-style>>>>>>> response.>>>>>>>>>>>>>>Next >>>>> paragraph - no quotes around qop or rspauth.>>>>>>>>>>>>> >>>>>> * If the qop directive's value is 'auth-int' and at> least>>> >>>>> one>>>>>>> of the following conditions is true, the RADIUS> >>>>> client>>>>>>> calculates the contents of the HTTP-style >>>>> response's>>> rspauth>>>>>>> directive:>>>>>>>>>>>> >>>>>>>>>>>>>>2 paragraphs later - no quotes around rspauth>>>> >>>>>>>>>>>>>>> The RADIUS client creates the HTTP-style response> >>>>>> message>>> and>>>>>>> calculates the hash of this message's >>>>> body. It uses>> the>>> result>>>>>>> and the Digest-URI >>>>> attribute's value of the>> corresponding>>>>>>> Access-Request >>>>> packet to perform the H(A2)> calculation.>>> It>>>>>>> takes >>>>> the Digest-Nonce, Digest-Nonce-Count,>>> Digest-CNonce, and>>>> >>>>>>>> Digest-Qop values of the corresponding Access-Request>> and>> >>>>>> the>>>>>>> Digest-HA1 attribute's value to finish the> >>>>> computation>> of>>> the>>>>>>> rspauth value.>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>Section 3.4 paragraph 1 - no >>>>> quotes around rspauth>>>>>>>>>>>>>> This attribute >>>>> enables the RADIUS server to prove>>> possession of>>>>>>> >>>>> the password. If the previously received Digest-Qop>>> attribute>> >>>>>>>>>> was 'auth-int' (without surrounding 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 packets. The RADIUS client>> puts>>> the>>>>> >>>>>>> attribute value without surrounding quotes into the>>> rspauth> >>>>>>>>>>> directive of the Authentication-Info header.>>>>>> >>>>>>>>>>>>>>>>>>>>Section 3.5 2nd paragraph - no quotes >>>>> around nextnonce>>>>>>>>>>>>>> The RADIUS server MAY put >>>>> a Digest-Nextnonce> attribute>>> into an>>>>>>> Access-Accept >>>>> packet. If this attribute is present,>> the>>> RADIUS>>>>>>> >>>>> client MUST put the contents of this attribute into> the>>>>>>> >>>>> nextnonce directive of an Authentication-Info header> in>>> its>> >>>>>>>>>> HTTP-style response. This attribute MUST only be> used>> >>>>> in>>>>>>> Access-Accept packets.>>>>>>>>>>>>>>>>> >>>>>>>>>Section 3.7, 4th paragraph - no quotes around uri>>>>>> >>>>>>>>>>>>> If the HTTP-style request has an Authorization> >>>>> header,>>> the>>>>>>> RADIUS client puts the value of the uri >>>>> directive> found>>> in>>>>>>> the HTTP-style request >>>>> Authorization header (known as>>> "digest->>>>>>> uri-value" >>>>> in Section 3.2.2 of [RFC2617]) without>>> surrounding>>>>>>> >>>>> quotes into this attribute. If there is no>> Authorization>>>>> >>>>>>> header, the RADIUS client takes the value of the>> request>>> >>>>> URI>>>>>>> from the HTTP-style request it wants to >>>>> authenticate.>>>>>>>>>>>>>>>>>>>>>Section 3.8, 4th >>>>> paragraph - no quotes around qop>>>>>>>>>>>>>> In >>>>> Access-Requests, the RADIUS client takes the value>> of>>> the>> >>>>>>>>>> qop directive (qop-value as described in [RFC2617])>> >>>>> from>>> the>>>>>>> HTTP-style request it wants to >>>>> authenticate. In>> Access->>>>>>> Challenge packets, the >>>>> RADIUS server puts a desired>>> qop-value>>>>>>> into this >>>>> attribute. If the RADIUS server supports>> more>>> than>>>>>> >>>>>> one "quality of protection" value, it puts each>> qop-value>>> >>>>> into>>>>>>> a separate Digest-Qop attribute.>>>>>>>>>> >>>>>>>>>Section 3.18 1st paragraph - no quotes around stale>>>>>> >>>>>>>>>>>>> This attribute is sent by a RADIUS server in order to> >>>>>>> notify>>>>>>> the RADIUS client whether it has accepted a >>>>> nonce.> If>>> the>>>>>>> nonce presented by the RADIUS client >>>>> was stale, the>> value>>> is>>>>>>> 'true' and is 'false' >>>>> otherwise. The RADIUS client>> puts>>> the>>>>>>> content of >>>>> this attribute into a stale directive of> the>>> WWW->>>>>>> >>>>> Authenticate header in the HTTP-style response to the>>> request>> >>>>>>>>>> it wants to authenticate. The attribute MUST only be>>> >>>>> used in>>>>>>> Access-Challenge packets.>>>>>>>>>>>> >>>>>>>3.19 1st paragraph - no quotes around rspauth>>>>>>>>>>> >>>>>>>> This attribute is used to allow the generation of an>>>>>> >>>>>> Authentication-Info header, even if the HTTP-style>>> response's> >>>>>>>>>>> body is required for the calculation of the rspauth>>> >>>>> value.>>>>>>> It SHOULD be used in Access-Accept packets if >>>>> the>>> required>>>>>>> quality of protection ('qop') is >>>>> 'auth-int'.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>I think that does it. Even if this is not right, at least it> >>>>>>> should now>>>>>>>be consistent.>>>>>>>>>>>>> >>>>>>Comments?>>>>>>>>>>>>>>Baruch>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>-----Original Message----->>>>>>>From: >>>>> RFC Editor [mailto:rfc-editor@rfc-editor.org]>>>>>>>Sent: >>>>> Monday, October 15, 2007 8:45 PM>>>>>>>To: David Williams>>> >>>>>>>>>Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>>> >>>>>>>>>beckw@t-systems.com; radext-ads@tools.ietf.org;>>>>>> >>>>>>radext-chairs@tools.ietf.org; RFC Editor>>>>>>>Subject: Re: >>>>> AUTH48 [SG]: RFC 5090>>> >>> >>>>>>>>>NOW AVAILABLE>>>>>>>>>>>>>>Greeting all,>>>>> >>>>>>>>>>>>>>We have not heard further regarding the issues below >>>>> or other>>> changes>>>>>>>that may be required before >>>>> publishing this document as an> RFC.>>>>>>>Please review the >>>>> document and let us know if there are any>>>>>>>corrections >>>>> required.>>>>>>>>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>>> >>>>> ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>>>> >>>>>>>>>>>>>>We will wait to hear from you before continuing on >>>>> with the>>>>>>>publication process.>>>>>>>>>>>>> >>>>>>Thank you.>>>>>>>>>>>>>>RFC Editor>>>>>>>>>>>> >>>>>>>On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> >>>>>>>>>>>>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:>>>>>> >>>>>>>>>>>>>>>>Authors,>>>>>>>>>>>>>>>>>>While >>>>> reviewing > during>>> AUTH48,> >>>>>>>>>>>>>please consider the following.>>>>>>>>>>>>>>> >>>>>>>>In previous dialog, we had the following exchange:>>>>>>>>>> >>>>>>>>>>>>>>>2. Please explain the usage of the single quote marks >>>>> (')>> in>>>>>>>>>>>this document. There seems to be >>>>> inconsistency, but we> are>>>>>>>>>>>unable to determine which >>>>> values/attributes/parameters> you>>>>>>>>>>>wanted to appear in >>>>> quote marks. For example, we see>>>>>>>>>>>>>>>>> >>>>>>>>>>'auth-int'/"auth-int">>>>>>>>>>>'rspauth' >>>>> directive/rspauth directive>>>>>>>>>>>'rspauth' value/rspauth >>>>> value>>>>>>>>>>>>>>>>>>>>>As RfC 2617 always uses ", >>>>> replacing all 's in question> with>> ">>> seems>>>>>>>>>>the >>>>> right thing to do.>>>>>>>>>>>>>>>>>>Please note that we >>>>> did not replace all 's with "s because>>>>>>>>>RFC 4590 uses >>>>> 's. However, if you feel that the document>>> should be>>>>>> >>>>>>>>more alignmed with RFC 2617, please let us know and we will>>> >>>>> make>>>>>>>>>this change.>>>>>>>>>>>>>>>>If we are >>>>> taking a vote, I would prefer using " instead of '>>> around>>>> >>>>>>>>the>>>>>>>>value strings. I think it is better to stay >>>>> aligned with> 2617>>> rather>>>>>>>than>>>>>>>>4590. >>>>> Also I believe the " usage is more commonly used in>> other>>>>> >>>>>>>>specifications.>>>>>>>>>>>>>>>>>>>>>>>>>>Also, >>>>> we had a difficult time understanding the use of 's.>> We>>>>>> >>>>>>>>inserted 's around auth-int, auth, qop, and rspauth when> they>> >>>>>> were>>>>>>>>>used as values or directives. However, we did >>>>> not attempt> to>>> include>>>>>>>>>'s for *all* directives >>>>> and values (e.g., realm and> opaque).>>> Please>>>>>>>>>let >>>>> us know if this is not correct.>>>>>>>>>>>>>>>>I agree it >>>>> is confusing. Looking at 2617 I don't think it> is>>> entirely>>> >>>>>>>>>>>>>>>>>consistent either, as I see references to ["qop" >>>>> directive]> as>>> well as>>>>>>>the>>>>>>>>unquoted >>>>> form [qop directive].>>>>>>>>>>>>>>>>I am no authority on >>>>> style but my initial thought is to>> suggest>>>>>>>removing '> >>>>>>>>>>>>and " from keywords when refering to a directive name >>>>> rather>>> than its>>>>>>>>literal value, and then use "" when >>>>> refering to a value.> For>>> example,>>>>>>>the>>>>>> >>>>>>>existing 5090 text would then become:>>>>>>>>>>>>>> >>>>>>>>>>>>>>> o If the Access-Accept packet contains a >>>>> Digest-HA1>>> attribute, the>>>>>>>> RADIUS client checks the >>>>> qop and algorithm directives> in>>> the>>>>>>>> Authorization >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> >>>>> authorize:>>>>>>>>>>>>>>>> * If the qop directive is >>>>> missing or its value is>> "auth",>>> the>>>>>>>> RADIUS >>>>> client ignores the Digest-HA1 attribute. It>>> does not>>>>>> >>>>>>> include an Authentication-Info header in its>> HTTP-style>>>> >>>>>>>>> response.>>>>>>>>>>>>>>>>>>>>>> >>>>>>>However when examing 2617 in more detail, using " around the>>> >>>>> directive>>>>>>>>>>>>>>>names would be more consistent >>>>> with that draft. For example>>> this>>>>>>>would>>>>>> >>>>>>>become:>>>>>>>>>>>>>>>>>>>> >>>>>>>>> o If the Access-Accept packet contains a Digest-HA1>>> >>>>> attribute, the>>>>>>>> RADIUS client checks the "qop" and >>>>> "algorithm">> directives>>> in the>>>>>>>> Authorization >>>>> header of the HTTP-style request it> wants>> to>>>>>>>> >>>>> authorize:>>>>>>>>>>>>>>>> * If the "qop" directive is >>>>> missing or its value is>>> "auth", the>>>>>>>> RADIUS client >>>>> ignores the Digest-HA1 attribute. It>>> does not>>>>>>>> >>>>> include an Authentication-Info header in its>> HTTP-style>>>>>> >>>>>>> response.>>>>>>>>>>>>>>>>>> >>>>>>>>>>>Prehaps others can weigh in one which they believe is most> >>>>>>>>>>>appropriate.>>>>>>>>I believe either would be a >>>>> slight improvement on the> existing>>> text>>>>>>>which>>> >>>>>>>>>>uses single quotes around the string values.>>>>>>>>>> >>>>>>>>>>>thanks,>>>>>>>>-david>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>Thank you.>>>>>>>>>>>>>>>>>>RFC Editor>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>On Thu, Oct 04, 2007 at >>>>> 03:11:50PM -0700,>>> rfc-editor@rfc-editor.org>>>>>>>wrote:> >>>>>>>>>>>>>>>>>>>>>>>>****IMPORTANT*****>>>>>>>>>>>>> >>>>>>>>>>>>Updated 2007/10/04>>>>>>>>>>>>>>>>>>>>RFC >>>>> AUTHOR(S):>>>>>>>>>>-------------->>>>>>>>>>>>>>>> >>>>>>>>>This is your LAST CHANCE to make changes to your RFC to> be:>>> >>>>>>>>>>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> >>>>>>> published>>>>>>>as>>>>>>>>>>an RFC we *WILL NOT* make >>>>> any changes.>>>>>>>>>>>>>>>>>>>>Please check your >>>>> document at:>>>>>>>>>>>>>>>> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt>>>>>> >>>>>>>>>>>>>>>>>>>ATTENTION: The editing process occasionally >>>>> introduces>> errors>>> that>>>>>>>>>>were not in the >>>>> Internet Draft. Although the RFC Editor>> tries>>> very>>>>>> >>>>>>>>>hard to catch all errors, proofreading the text at least>>> >>>>> twice,>>>>>>>typos>>>>>>>>>>can slip through. You, as an >>>>> author of the RFC, are> taking>>>>>>>>>>responsibility for the >>>>> correctness of the final product> when>>> you OK>>>>>> >>>>>>>>>publication. You should therefore proofread the entire> RFC>>> >>>>>>>>>carefully>>>>>>>>>>and without assumptions. Errors in >>>>> RFCs last forever.>>>>>>>>>>>>>>>>>>>>NOTE: We have run a >>>>> diff tool that compares the approved>>>>>>>internet-draft>>> >>>>>>>>>>>>against our edited RFC version of the document. Please>> >>>>> review>>> this>>>>>>>>>>file at:>>>>>>>>>>>>>>>>> >>>>>>>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html>>> >>>>>>>>>>>>>>>>>>>>>>Please note that we used a slightly altered >>>>> version of the>>>>>>>originally>>>>>>>>>>submitted ID to >>>>> create the diff file above. To make the>> file>>> more>>>>>> >>>>>>>>>useful, we moved the terminology section to to appear> after>>> >>>>> the>>>>>>>>>>introduction, but we did not alter the text.>>> >>>>>>>>>>>>>>>>>>>>>>The document will NOT BE PUBLISHED until >>>>> ALL of the> authors>>> listed>>>>>>>in>>>>>>>>>>the RFC >>>>> have affirmed that the document is ready to be>>>>>> >>>>>>>>>published, as ALL of the authors are equally responsible> for>> >>>>>>>>>>verifying>>>>>>>>>>the documents readiness for >>>>> publication.>>>>>>>>>>>>>>>>>>>>** Please send us a list >>>>> of suitable keywords for this>>> document,>>>>>>>over>>>> >>>>>>>>>>>and above those which appear in the title.>>>>>>>>>>>> >>>>>>>>>>>>> Frequently INCORRECT information includes>>>>>> >>>>>>>>>>>>>>>>>>> - Contact Information>>>>>>>>>> - >>>>> References (are they up to date)>>>>>>>>>> - Section Numbers>> >>>>>>>>>>>>> (especially if you originally put the copyright>>>>> >>>>>>>somewhere>>>>>>>>>> other than the VERY end of the document, >>>>> or if>> you>>>>>>>>>> numbered the 'Status of the Memo' >>>>> field)>>>>>>>>>>>>>>>>>>>>Please send us the changes, *DO >>>>> NOT* send a new document>> with>>> the>>>>>>>>>>changes >>>>> made. (If we think that the changes might be more>>> than>>>>> >>>>>>>>>>editorial we will contact the AD or the IESG to confirm> that> >>>>>>> the>>>>>>>>>>changes do not require review.)>>>>>> >>>>>>>>>>>>>>>>>>>Send us the changes in THIS format.>>>>>> >>>>>>>>>>>>>>>>>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd>>> >>>>> paragraph]>>>>>>>>>> 2) the text you want changed,>>>>>> >>>>>>>>> 3) the new correct text and>>>>>>>>>> 4) if the changes >>>>> are spacing or indentation> than>>> please>>>>>>>note>>>> >>>>>>>>>>> that.>>>>>>>>>>>>>>>>>>>>FOR EXAMPLE:>>>>>> >>>>>>>>>>>>>>>>>>> Section 5.6, 3rd paragraph>>>>>>>>>>>>> >>>>>>>>>>>> OLD:>>>>>>>>>> The quick brown fox jumped over the >>>>> lazy dog.>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>> The >>>>> quick brown dog jumps over the lazy fox.>>>>>>>>>> ^^^ ^ ^^^>> >>>>>>>>>>>>>If you have a whole paragraph to replace you do not need> >>>>> to>>> use>>>>>>>>>>the arrow to point out the differences>> >>>>>>>>>>>>>>>>>>>>>>> INTRODUCTION, 2nd paragraph>>>>>> >>>>>>>>>>>>>>>>>>> Replace OLD:>>>>>>>>>>>>>>>>>>>> >>>>> alsdfja;sldjf;lajsd;fljas;dlfj;>>>>>>>>>>>>>>>>>>>> With >>>>> NEW:>>>>>>>>>>>>>>>>>>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> >>>>>>>>>>>>>>>>>>>>>>>>Spacing or indentation problems...>>> >>>>>>>>>>>>>>>>>>>>>> Section 10, 1st paragraph (remove spaces> >>>>> between>>> bit>>>>>>>>>> and of, add space after butter)>>> >>>>>>>>>>>>>>>>>>>>>> OLD:>>>>>>>>>>>>>>>>>>>> >>>>> Better botter bought a bit>>>>>>>>>> of bitter butterMary mary >>>>> quite contrary>>>>>>>>>>>>>>>>>>>> NEW:>>>>>>>>>>> >>>>>>>>>>>>>> Better botter bought a bit of bitter butter>>>>>> >>>>>>>>>>>>>>>>>>> Mary mary quite contrary>>>>>>>>>>>>>> >>>>>>>>>>>This document will NOT be published until we receive>>> >>>>> agreement, from>>>>>>>>>>ALL listed authors, that the document >>>>> is ready for>>> publication.>>>>>>>>>>>>>>>>>>>>Thanks >>>>> for your cooperation,>>>>>>>>>>>>>>>>>>>>-RFC Editor>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Title : RADIUS Extension >>>>> for Digest>>>>>>>>>> Authentication>>>>>>>>>>Author(s) : >>>>> B. Sterman, D. Sadolevsky,>>>>>>>>>> D. Schwartz, D. Williams,> >>>>>>>>>>>>>> W. Beck>>>>>>>>>>Working Group Chair(s) : >>>>> Bernard Aboba, David Nelson>>>>>>>>>>Area Director(s) : Dan >>>>> Romascanu, Ronald Bonica>>>>>>>>>>>>>>>> >=20 > --=20 > Mike McCauley mikem@open.com.au > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW > 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.= au > Phone +61 7 5598-7474 Fax +61 7 5598-7070 >=20 > Radiator: the most portable, flexible and configurable RADIUS server=20 > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,=20 > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,=20 > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.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, 23 Dec 2007 05:52:02 +0000 From: Mike McCauley To: Bernard Aboba Subject: Re: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sun, 23 Dec 2007 15:50:37 +1000 User-Agent: KMail/1.8.2 Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712231550.38670.mikem@open.com.au> Hi Bernard, Have the test vectors in section 6 Examples been checked? How? Im not sure I entirely agree with the Digest-Response values in the B->C messages Cheers. On Sunday 23 December 2007 03:37, Bernard Aboba wrote: > RFC 4590bis is now being held in AUTH48, pending final verification. > > What started as a "simple" IANA-problem fix has turned into a longer > odyssey due to the discovery of additional errors/omissions. > > In attempt to bring this story to a close, we need to make very sure that > we have looked over this document carefully so that we don't have to go > through this again with RFC 4590ter. > > So if you have ever had any interest in RADIUS Digest Authentication, now > would be the time to look over the AUTH48 version of the document, and > speak up if there is a problem. > > > Date: Fri, 21 Dec 2007 15:14:46 -0800 > > From: rfc-editor@rfc-editor.org > > To: beckw@t-systems.com > > CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; > > dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com; > > rbonica@juniper.net; d.b.nelson@comcast.net; bernard_aboba@hotmail.com; > > rfc-editor@rfc-editor.org Subject: Re: AUTH48 [SG]: RFC 5090 > > NOW AVAILABLE > > > > Greeings Wolfgang, > > > > Just a reminder that we are waiting to hear from you before continuing > > on with the publication process. > > > > Please see the email below for document information. > > > > Thank you. > > > > RFC Editor > > > > On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > > > Hi Wolfgang, > > > > > > Just a friendly reminder that we are waiting to hear from you before > > > continuing on with the publication process for RFC 5090 > > > . > > > > > > Please review the files located at: > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > > > > > > Note that this diff file highlights only the differences between the > > > last posted version of the document and the current text file. The > > > previously posted versions (during AUTH48) are available as: > > > > > > The originally posted AUTH48 files: > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > > > > > > Version 2 (includes author updates) of AUTH48 files: > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > > > Note that this file highlights only the differences between the > > > version 1 and 2 text files. > > > > > > We will wait to hear from you before continuing on with the > > > publication process. > > > > > > Thank you. > > > > > > RFC Editor/sg > > > > > > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > > > > I also talked to Wolfgang at IETF 70. He wanted to check the > > > > document over carefully to make sure there were no further issues. > > > > > Subject: RE: AUTH48 [SG]: RFC 5090 > > > > NOW AVAILABLE> Date: Mon, 10 > > > > Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com> To: > > > > rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: > > > > david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; > > > > dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@hotmail.com; > > > > d.b.nelson@comcast.net> > Yes,> > David Schwartz saw him at the ietf > > > > meeting and worked through the draft> with him. I think we should be > > > > hearing from him soon.> > Baruch> > > -----Original Message-----> > > > > From: RFC Editor [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, > > > > December 10, 2007 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> > > > > Cc: David Schwartz; RFC Editor; dscreat@dscreat.com; > > > > dwilli@cisco.com;> Dan Romascanu; Ronald Bonica; > > > > Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: > > > > AUTH48 [SG]: RFC 5090 > NOW > > > > AVAILABLE> > All,> > Just checking to see if you have had any luck > > > > contacting Wolfgang?> > Thanks!> > RFC Editor/sg> > On Tue, Nov 27, > > > > 2007 at 09:21:45PM +0200, Baruch Sterman wrote:> > David Schwartz > > > > will be at the IETF meetings next week. Maybe Wolfgang> > will be > > > > there and he can nudge him to answer. Lets hold off until we> see> > > > > > if that way forward works. If not, we can go with option 3.> > > > > > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > From: > > > > RFC Editor [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, > > > > November 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> > > > > > Subject: Re: AUTH48 [SG]: RFC 5090> > > > > > > NOW AVAILABLE> > > > Hi > > > > Baruch,> > > > We have a couple of ways to move forward.> > > > 1. > > > > The author can be removed as an author, and moved to the> > > > > > Acknowledgements section.> > > > 2. We can create a Contributor's > > > > section and have him listed there.> > > > 3. We can request that the > > > > AD approve the document in place of the> > unavailabe author. > > > > > > > > Option 3 has been done before in instances where the missing author> > > > > > made sizeable contributions to the document, so the other authors> > > > > > did not feel comfortable removing the individuals name as an> > > > > > author. > > > > It sounds as though 3 may be the proper way forward. > > > > If this is the> > case, we will send an email to the ADs requesting > > > > their approval in> > place of Wolfgang (the message will be cc'ed to > > > > all relevant> > parties, including Wolfgang). > > > > If the above > > > > suggestions are unacceptable and you have an alternative> > solution, > > > > please let us know. > > > > Thank you.> > > > RFC Editor> > > > On > > > > Mon, Nov 26, 2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I > > > > wrote to Wolfgang as well, but got no response. What is the> > > > > > procedure> > > in this case? I am sure that Wolfgang would be ok with > > > > the changes.> > The> > > last email I received was on October 19 > > > > where he said that he had> made> > > the one correction (suggested by > > > > Ellermann) in the cnonce value. > > > > > > Baruch> > > > > > > > > > > > > -----Original Message-----> > > From: RFC Editor > > > > [mailto:rfc-editor@rfc-editor.org] > > > Sent: Wednesday, November > > > > 21, 2007 10:35 PM> > > To: David Williams; Baruch Sterman; > > > > dscreat@dscreat.com; David> > Schwartz;> > > beckw@t-systems.com> > > > > > > Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC> > > > > > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090> > > > > > > > > NOW AVAILABLE> > > > > > > > > > Greetings Wolfgang,> > > > > > We do not believe we have received > > > > your response regarding this> > > document's readiness for > > > > publication as an RFC. Please review the> > > text and let us know if > > > > you are content with the document as it now> > > appears at:> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > Note > > > > that this diff file highlights only the changes between the> last > > > > > > > posted version of the document and the current text file.> > > > > > > > > > > > > The last versions of the document are available as:> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html> > > > > > > Note that this diff file highlights only the changes between v1 and> > > > > > > the v2.> > > > > > We will wait to hear from you before > > > > continuing on with the> > > publication process.> > > > > > Thank > > > > you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at > > > > 05:13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We > > > > have corrected the text as indicated below and posted the> revised> > > > > > > > version of the document at:> > > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > Note that this diff file highlights only the changes betwee the> > > > > last> > > > > > posted version of the document and the current text > > > > file.> > > > > > > > Please review the document and let us know if > > > > you approve this> > > > text for publication.> > > > > > > > We > > > > believe we are waiting for the following approvals:> > > > > > > > > > > > Baruch Sterman - done > > > > Daniel Sadolevsky - done> > > > David > > > > Schwartz - done> > > > David Williams> > > > Wolfgang Beck> > > > > > > > > > > > Bernard Aboba - done> > > > > > > > > > > > Thank you.> > > > > > > > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov 06, 2007 at > > > > 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > > > > > > > > > > > Please confer and let us know how the text should/should not use> > > > > > the> > > > > quote marks. It sounds as though this email was for > > > > discussion.> > If> > > > > the changes below are acceptable, we will > > > > make the changes and> > post> > > a> > > > > revised version of the > > > > document.> > > > > > > > > > Also, please note the following status > > > > of document approvals:> > > > > > > > > > Baruch Sterman - done > > > > (although we would like to know if you> agree> > > > > with the > > > > changes described below)> > > > > Daniel Sadolevsky - done> > > > > > > > > David Schwartz> > > > > David Williams> > > > > Wolfgang Beck> > > > > > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will wait to > > > > hear further before continuing on with the> > > publication> > > > > > > > > process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor> > > > > > > > > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, > > > > David Williams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > > > > > > These look good, and I agree with your consistency comment. I> > > > > > > have a few > > > > > > more specific changes to suggest that I would > > > > like you and> > others> > > to > > > > > > review as well. But first > > > > a couple of general style comments> > that> > > require > > > > > > > > > > no changes to the document.> > > > > > > > > > > > General comment > > > > #1: I tried to find a definitive style guide> to> > > use of > > > > > > > > > > single quotes versus double quotes and found there is no hard> > > > > > > guidelines, > > > > > > that consistency is most important:> > > > > > > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > > > > > > http://forum.wordreference.com/showthread.php?t=120946> > > > > > > > > > Though I tend to think that double quotes are more commonly> used> > > > > > > and match > > > > > > the syntax of more popular programming > > > > languages, but there> are> > so> > > many > > > > > > quoted items in > > > > the document and it has been this way for a> long> > > time, so > > > > > > > > > > best to leave as is.> > > > > > > > > > > > General comment #2: > > > > When refering to responses from the radius> > > server > > > > > > > > > > there are a lot of instances of a comment similiar to "without> > > > > > > surrounding > > > > > > quotes" that potentially could be removed for > > > > readability.> > > Especially if > > > > > > there were a more concise > > > > definition up-front about the> general> > > form of > > > > > > > > > > values returned from the radius server. But I am a little> > > > > > > hesitant to > > > > > > just strip them out now.> > > > > > > > > > > > > > > > Specific comments, to build on top of your list:> > > > > > > > > > > > > > > > In section 2.1.2, 1st paragraph should not have quotes around> > > > > > > nonce. > > > > > > Paragraph should read:> > > > > > > > > > > > If > > > > a matching (Proxy-)Authorization header is present and> > > contains> > > > > > > > > > HTTP Digest information, the RADIUS client checks the > > > > nonce> > > > > > parameter.> > > > > > > > > > > > In next paragraph, > > > > do not need quotes around response.> > Paragraph> > > should > > > > > > > > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the > > > > nonce, it takes the> > header> > > > > > directives and puts them > > > > into a RADIUS Access-Request> packet.> > > It> > > > > > puts the > > > > response directive into a Digest-Response> attribute> > > and> > > > > > > > > > the realm, nonce, digest-uri, qop, algorithm, cnonce, nc,> > > > > > > username,> > > > > > and opaque directives into the respective > > > > Digest-Realm,> > > Digest-Nonce,> > > > > > Digest-URI, Digest-Qop, > > > > Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > > > Nonce-Count, > > > > Digest-Username, and Digest-Opaque attributes.> > > The> > > > > > > > > > RADIUS client puts the request method into the> Digest-Method> > > > > > > > > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to > > > > the items you point out, in> the> > > last > > > > > > paragraph, > > > > nextnounce does not need quoting. Paragraph> should> > > read:> > > > > > > > > > > > > > > > When the RADIUS server provides a Digest-Nextnonce> > > > > attribute> > in> > > the> > > > > > Access-Accept packet, the RADIUS > > > > client puts the contents> of> > > this> > > > > > attribute into a > > > > nextnonce directive. Now it can send an> > HTTP-> > > > > > style > > > > response.> > > > > > > > > > > > In section 2.1.4, 2nd paragraph, the > > > > stale directive should> not> > > need > > > > > > quoting. Paragraph > > > > should read:> > > > > > > > > > > > If the RADIUS client receives an > > > > Access-Challenge packet 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> > > > > > surrounding quotes), the > > > > RADIUS client sends an error> > response> > > (401> > > > > > or 407) > > > > containing a WWW-/Proxy-Authenticate header with> the> > > > > > > > > > directive stale and the digest directives derived from the> > > > > > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I think > > > > the wording of the last sentence in this same> > > paragraph > > > > > > > > > > could be improved. So that the paragraph reads more like:> > > > > > > > > > > > > > > > If the RADIUS client receives an Access-Challenge > > > > packet 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> > > > > > surrounding quotes), the RADIUS client sends an > > > > error> > response> > > (401> > > > > > or 407) containing a > > > > WWW-/Proxy-Authenticate header with> the> > > > > > stale directive > > > > set to 'true' and the digest directives> > derived> > > from> > > > > > > > > > the Digest-* attributes.> > > > > > > > > > > > In section 3.10, > > > > 1st paragraph, I believe the term "qop-level"> > is> > > ill > > > > > > > > > > defined and should not be used, that qop directive or> qop-value> > > > > > > would be > > > > > > better. In other words the paragraph should > > > > read:> > > > > > > > > > > > When using the qop-value 'auth-int', a > > > > hash of the> > > HTTP-style> > > > > > message body's contents is > > > > required for digest> > > calculation.> > > > > > Instead of sending > > > > the complete body of the message,> > only> > > its> > > > > > hash > > > > value is sent. This hash value can be used> > directly> > > in> > > > > > > > > > the digest calculation.> > > > > > > > > > > > In section 3.15, > > > > auth-param doesn't need quoting. So that the> > > paragraph > > > > > > > > > > becomes:> > > > > > > > > > > > This attribute is a placeholder for > > > > future extensions> > and> > > > > > corresponds to the auth-param > > > > parameter defined in> > > Section> > > > > > 3.2.1 of [RFC2617]. The > > > > Digest-Auth-Param is the> > > mechanism> > > > > > whereby the RADIUS > > > > client and RADIUS server can> > exchange> > > auth-> > > > > > param > > > > extension parameters contained within Digest> > > headers that> > > > > > > > > > are not understood by the RADIUS client and for which> > > there > > > > are> > > > > > no corresponding stand-alone attributes.> > > > > > > > > > > > > > > > In section 3.17, domain doesn't need quoting. So that the> > > > > > > paragraph > > > > > > becomes:> > > > > > > > > > > > When a > > > > RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > > > > > > > MAY send one or more Digest-Domain attributes in its> > > Access-> > > > > > > > > > Challenge packet. The RADIUS client puts them into> the> > > > > > > quoted,> > > > > > space-separated list of URIs of the domain > > > > directive> of> > a> > > > > > WWW-Authenticate header. Together with > > > > Digest-Realm,> > the> > > URIs> > > > > > in the list define the > > > > protection space (see> [RFC2617],> > > Section> > > > > > 3.2.1) for > > > > some HTTP-style protocols. This attribute> > > MUST only> > > > > > > > > > be used in Access-Challenge and Accounting-Request> > > packets.> > > > > > > > > > > > > > > > In section 3.19, 1st paragraph, in addtion to no > > > > quotes around> > > rspauth as > > > > > > you pointed out, I believe > > > > there should be no quotes around> qop.> > > So that > > > > > > the > > > > paragraph reads:> > > > > > > > > > > > This attribute is used to > > > > allow the generation of an> > > > > > Authentication-Info header, > > > > even if the HTTP-style> > > response's> > > > > > body is required > > > > for the calculation of the rspauth> > > value.> > > > > > It SHOULD > > > > be used in Access-Accept packets if the> > > required> > > > > > > > > > quality of protection (qop) is 'auth-int'.> > > > > > > > > > > > > > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri, 19 Oct 2007, > > > > 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After lengthy > > > > discussions with my father-in-law who is a> > > professor of> > > > > > > > > > >English, I agree with Dave's method of using quotes only in> the> > > > > > > value of> > > > > > >an attribute/directive, but not in > > > > referencing the> > > attribute/directive> > > > > > >by name. As > > > > such, I have some changes.> > > > > > >> > > > > > >In section 2.1.3 > > > > 3rd paragraph should not have quotes around> > the> > > word> > > > > > > > > > >rspauth. Sentence should read:> > > > > > >> > > > > > > * If the > > > > Digest-Qop attribute's value is 'auth' or not> > > specified,> > > > > > > > > > > the RADIUS client puts the Digest-Response-Auth> > > > > > > attribute's> > > > > > > content into the Authentication-Info > > > > header's rspauth> > > > > > > directive of the HTTP-style response.> > > > > > > > > > >> > > > > > >Same section 5th paragraph - no quotes around > > > > qop and> > algorithm:> > > > > > >> > > > > > > o If the > > > > Access-Accept packet contains a Digest-HA1> > attribute,> > > the> > > > > > > > > > > RADIUS client checks the qop and algorithm directives in> > > > > > the> > > > > > > Authorization header of the HTTP-style request it > > > > wants> to> > > > > > > authorize:> > > > > > >> > > > > > >Next > > > > paragraph - no quotes around qop> > > > > > >> > > > > > > * If the > > > > qop directive is missing or its value is> 'auth',> > > the> > > > > > > > > > > RADIUS client ignores the Digest-HA1 attribute. It> > does> > > > > > > not> > > > > > > include an Authentication-Info header in its> > > > > HTTP-style> > > > > > > response.> > > > > > >> > > > > > >Next > > > > paragraph - no quotes around qop or rspauth.> > > > > > >> > > > > > > > > > > * If the qop directive's value is 'auth-int' and at> least> > > > > > > one> > > > > > > of the following conditions is true, the RADIUS> > > > > client> > > > > > > calculates the contents of the HTTP-style > > > > response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > > > > > > > >> > > > > > >2 paragraphs later - no quotes around rspauth> > > > > > > > > > >> > > > > > > The RADIUS client creates the HTTP-style response> > > > > > message> > > and> > > > > > > calculates the hash of this message's > > > > body. It uses> > the> > > result> > > > > > > and the Digest-URI > > > > attribute's value of the> > corresponding> > > > > > > Access-Request > > > > packet to perform the H(A2)> calculation.> > > It> > > > > > > takes > > > > the Digest-Nonce, Digest-Nonce-Count,> > > Digest-CNonce, and> > > > > > > > > > > Digest-Qop values of the corresponding Access-Request> > and> > > > > > > the> > > > > > > Digest-HA1 attribute's value to finish the> > > > > computation> > of> > > the> > > > > > > rspauth value.> > > > > > >> > > > > > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no > > > > quotes around rspauth> > > > > > >> > > > > > > This attribute > > > > enables the RADIUS server to prove> > > possession of> > > > > > > > > > > the password. If the previously received Digest-Qop> > > attribute> > > > > > > > > > > was 'auth-int' (without surrounding 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 packets. The RADIUS client> > puts> > > the> > > > > > > > > > > attribute value without surrounding quotes into the> > > rspauth> > > > > > > > > > > directive of the Authentication-Info header.> > > > > > > > > > >> > > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes > > > > around nextnonce> > > > > > >> > > > > > > The RADIUS server MAY put > > > > a Digest-Nextnonce> attribute> > > into an> > > > > > > Access-Accept > > > > packet. If this attribute is present,> > the> > > RADIUS> > > > > > > > > > > client MUST put the contents of this attribute into> the> > > > > > > > > > > nextnonce directive of an Authentication-Info header> in> > > its> > > > > > > > > > > HTTP-style response. This attribute MUST only be> used> > > > > > in> > > > > > > Access-Accept packets.> > > > > > >> > > > > > >> > > > > > > > > > >Section 3.7, 4th paragraph - no quotes around uri> > > > > > > > > > >> > > > > > > If the HTTP-style request has an Authorization> > > > > header,> > > the> > > > > > > RADIUS client puts the value of the uri > > > > directive> found> > > in> > > > > > > the HTTP-style request > > > > Authorization header (known as> > > "digest-> > > > > > > uri-value" > > > > in Section 3.2.2 of [RFC2617]) without> > > surrounding> > > > > > > > > > > quotes into this attribute. If there is no> > Authorization> > > > > > > > > > > header, the RADIUS client takes the value of the> > request> > > > > > > URI> > > > > > > from the HTTP-style request it wants to > > > > authenticate.> > > > > > >> > > > > > >> > > > > > >Section 3.8, 4th > > > > paragraph - no quotes around qop> > > > > > >> > > > > > > In > > > > Access-Requests, the RADIUS client takes the value> > of> > > the> > > > > > > > > > > qop directive (qop-value as described in [RFC2617])> > > > > > from> > > the> > > > > > > HTTP-style request it wants to > > > > authenticate. In> > Access-> > > > > > > Challenge packets, the > > > > RADIUS server puts a desired> > > qop-value> > > > > > > into this > > > > attribute. If the RADIUS server supports> > more> > > than> > > > > > > > > > > one "quality of protection" value, it puts each> > qop-value> > > > > > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> > > > > > > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > > > > > > >> > > > > > > This attribute is sent by a RADIUS server in order to> > > > > > > notify> > > > > > > the RADIUS client whether it has accepted a > > > > nonce.> If> > > the> > > > > > > nonce presented by the RADIUS client > > > > was stale, the> > value> > > is> > > > > > > 'true' and is 'false' > > > > otherwise. The RADIUS client> > puts> > > the> > > > > > > content of > > > > this attribute into a stale directive of> the> > > WWW-> > > > > > > > > > > Authenticate header in the HTTP-style response to the> > > request> > > > > > > > > > > it wants to authenticate. The attribute MUST only be> > > > > > > used in> > > > > > > Access-Challenge packets.> > > > > > >> > > > > > > > > > >3.19 1st paragraph - no quotes around rspauth> > > > > > >> > > > > > > > > > > This attribute is used to allow the generation of an> > > > > > > > > > > Authentication-Info header, even if the HTTP-style> > > response's> > > > > > > > > > > body is required for the calculation of the rspauth> > > > > > > value.> > > > > > > It SHOULD be used in Access-Accept packets if > > > > the> > > required> > > > > > > quality of protection ('qop') is > > > > 'auth-int'.> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > >I think that does it. Even if this is not right, at least it> > > > > > > should now> > > > > > >be consistent.> > > > > > >> > > > > > > > > > >Comments?> > > > > > >> > > > > > >Baruch> > > > > > >> > > > > > >> > > > > > > > > > >> > > > > > >-----Original Message-----> > > > > > >From: > > > > RFC Editor [mailto:rfc-editor@rfc-editor.org]> > > > > > >Sent: > > > > Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> > > > > > > > > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;> > > > > > > > > > >beckw@t-systems.com; radext-ads@tools.ietf.org;> > > > > > > > > > >radext-chairs@tools.ietf.org; RFC Editor> > > > > > >Subject: Re: > > > > AUTH48 [SG]: RFC 5090> > > > > > > > > > > > > >NOW AVAILABLE> > > > > > >> > > > > > >Greeting all,> > > > > > > > > > >> > > > > > >We have not heard further regarding the issues below > > > > or other> > > changes> > > > > > >that may be required before > > > > publishing this document as an> RFC.> > > > > > >Please review the > > > > document and let us know if there are any> > > > > > >corrections > > > > required.> > > > > > >> > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > > > >> > > > > > >We will wait to hear from you before continuing on > > > > with the> > > > > > >publication process.> > > > > > >> > > > > > > > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> > > > > > > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> > > > > > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > > > > > > >>> > > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While > > > > reviewing > during> > > AUTH48,> > > > > > > > > > >>>please consider the following.> > > > > > >>>> > > > > > > > > > >>>In previous dialog, we had the following exchange:> > > > > > >>>> > > > > > > > > > >>>>>2. Please explain the usage of the single quote marks > > > > (')> > in> > > > > > >>>>>this document. There seems to be > > > > inconsistency, but we> are> > > > > > >>>>>unable to determine which > > > > values/attributes/parameters> you> > > > > > >>>>>wanted to appear in > > > > quote marks. For example, we see> > > > > > >>>>>> > > > > > > > > > >>>>>'auth-int'/"auth-int"> > > > > > >>>>>'rspauth' > > > > directive/rspauth directive> > > > > > >>>>>'rspauth' value/rspauth > > > > value> > > > > > >>>>>> > > > > > >>>>As RfC 2617 always uses ", > > > > replacing all 's in question> with> > "> > > seems> > > > > > >>>>the > > > > right thing to do.> > > > > > >>>> > > > > > >>>Please note that we > > > > did not replace all 's with "s because> > > > > > >>>RFC 4590 uses > > > > 's. However, if you feel that the document> > > should be> > > > > > > > > > >>>more alignmed with RFC 2617, please let us know and we will> > > > > > > make> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are > > > > taking a vote, I would prefer using " instead of '> > > around> > > > > > > > > > >the> > > > > > >>value strings. I think it is better to stay > > > > aligned with> 2617> > > rather> > > > > > >than> > > > > > >>4590. > > > > Also I believe the " usage is more commonly used in> > other> > > > > > > > > > >>specifications.> > > > > > >>> > > > > > >>>> > > > > > >>>Also, > > > > we had a difficult time understanding the use of 's.> > We> > > > > > > > > > >>>inserted 's around auth-int, auth, qop, and rspauth when> they> > > > > > > were> > > > > > >>>used as values or directives. However, we did > > > > not attempt> to> > > include> > > > > > >>>'s for *all* directives > > > > and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let > > > > us know if this is not correct.> > > > > > >>> > > > > > >>I agree it > > > > is confusing. Looking at 2617 I don't think it> is> > > entirely> > > > > > > > > > >> > > > > > >>consistent either, as I see references to ["qop" > > > > directive]> as> > > well as> > > > > > >the> > > > > > >>unquoted > > > > form [qop directive].> > > > > > >>> > > > > > >>I am no authority on > > > > style but my initial thought is to> > suggest> > > > > > >removing '> > > > > > > > > > >>and " from keywords when refering to a directive name > > > > rather> > > than its> > > > > > >>literal value, and then use "" when > > > > refering to a value.> For> > > example,> > > > > > >the> > > > > > > > > > >>existing 5090 text would then become:> > > > > > >>> > > > > > > > > > >>> > > > > > >> o If the Access-Accept packet contains a > > > > Digest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the > > > > qop and algorithm directives> in> > > the> > > > > > >> Authorization > > > > header of the HTTP-style request it> wants> > to> > > > > > >> > > > > authorize:> > > > > > >>> > > > > > >> * If the qop directive is > > > > missing or its value is> > "auth",> > > the> > > > > > >> RADIUS > > > > client ignores the Digest-HA1 attribute. It> > > does not> > > > > > > > > > >> include an Authentication-Info header in its> > HTTP-style> > > > > > > > > > >> response.> > > > > > >>> > > > > > >>> > > > > > > > > > >>However when examing 2617 in more detail, using " around the> > > > > > > directive> > > > > > >> > > > > > >>names would be more consistent > > > > with that draft. For example> > > this> > > > > > >would> > > > > > > > > > >>become:> > > > > > >>> > > > > > >>> > > > > > > > > > >> o If the Access-Accept packet contains a Digest-HA1> > > > > > > attribute, the> > > > > > >> RADIUS client checks the "qop" and > > > > "algorithm"> > directives> > > in the> > > > > > >> Authorization > > > > header of the HTTP-style request it> wants> > to> > > > > > >> > > > > authorize:> > > > > > >>> > > > > > >> * If the "qop" directive is > > > > missing or its value is> > > "auth", the> > > > > > >> RADIUS client > > > > ignores the Digest-HA1 attribute. It> > > does not> > > > > > >> > > > > include an Authentication-Info header in its> > HTTP-style> > > > > > > > > > >> response.> > > > > > >>> > > > > > >>> > > > > > > > > > >>Prehaps others can weigh in one which they believe is most> > > > > > > > > > >appropriate.> > > > > > >>I believe either would be a > > > > slight improvement on the> existing> > > text> > > > > > >which> > > > > > > > > > >>uses single quotes around the string values.> > > > > > >>> > > > > > > > > > >>thanks,> > > > > > >>-david> > > > > > >>> > > > > > >>>> > > > > > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RFC Editor> > > > > > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 at > > > > 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org> > > > > > >wrote:> > > > > > > > > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > > > > > > > > > >>>>Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC > > > > AUTHOR(S):> > > > > > >>>>--------------> > > > > > >>>>> > > > > > > > > > >>>>This is your LAST CHANCE to make changes to your RFC to> be:> > > > > > > > > > >>>>draft-ietf-radext-rfc4590bis-02.txt, once the document is> > > > > > > published> > > > > > >as> > > > > > >>>>an RFC we *WILL NOT* make > > > > any changes.> > > > > > >>>>> > > > > > >>>>Please check your > > > > document at:> > > > > > >>>>> > > > > > > > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > > > > > >>>>> > > > > > >>>>ATTENTION: The editing process occasionally > > > > introduces> > errors> > > that> > > > > > >>>>were not in the > > > > Internet Draft. Although the RFC Editor> > tries> > > very> > > > > > > > > > >>>>hard to catch all errors, proofreading the text at least> > > > > > > twice,> > > > > > >typos> > > > > > >>>>can slip through. You, as an > > > > author of the RFC, are> taking> > > > > > >>>>responsibility for the > > > > correctness of the final product> when> > > you OK> > > > > > > > > > >>>>publication. You should therefore proofread the entire> RFC> > > > > > > > > > >carefully> > > > > > >>>>and without assumptions. Errors in > > > > RFCs last forever.> > > > > > >>>>> > > > > > >>>>NOTE: We have run a > > > > diff tool that compares the approved> > > > > > >internet-draft> > > > > > > > > > >>>>against our edited RFC version of the document. Please> > > > > > review> > > this> > > > > > >>>>file at:> > > > > > >>>>> > > > > >> > > > > >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > > > > > > > >>>>> > > > > > >>>>Please note that we used a slightly altered > > > > version of the> > > > > > >originally> > > > > > >>>>submitted ID to > > > > create the diff file above. To make the> > file> > > more> > > > > > > > > > >>>>useful, we moved the terminology section to to appear> after> > > > > > > the> > > > > > >>>>introduction, but we did not alter the text.> > > > > > > > > > >>>>> > > > > > >>>>The document will NOT BE PUBLISHED until > > > > ALL of the> authors> > > listed> > > > > > >in> > > > > > >>>>the RFC > > > > have affirmed that the document is ready to be> > > > > > > > > > >>>>published, as ALL of the authors are equally responsible> for> > > > > > > > > > >verifying> > > > > > >>>>the documents readiness for > > > > publication.> > > > > > >>>>> > > > > > >>>>** Please send us a list > > > > of suitable keywords for this> > > document,> > > > > > >over> > > > > > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> > > > > > > > > > >>>> Frequently INCORRECT information includes> > > > > > > > > > >>>>> > > > > > >>>> - Contact Information> > > > > > >>>> - > > > > References (are they up to date)> > > > > > >>>> - Section Numbers> > > > > > > > > > >>>> (especially if you originally put the copyright> > > > > > > > > > >somewhere> > > > > > >>>> other than the VERY end of the document, > > > > or if> > you> > > > > > >>>> numbered the 'Status of the Memo' > > > > field)> > > > > > >>>>> > > > > > >>>>Please send us the changes, *DO > > > > NOT* send a new document> > with> > > the> > > > > > >>>>changes > > > > made. (If we think that the changes might be more> > > than> > > > > > > > > > >>>>editorial we will contact the AD or the IESG to confirm> that> > > > > > > the> > > > > > >>>>changes do not require review.)> > > > > > > > > > >>>>> > > > > > >>>>Send us the changes in THIS format.> > > > > > > > > > >>>>> > > > > > >>>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > > > > > > paragraph]> > > > > > >>>> 2) the text you want changed,> > > > > > > > > > >>>> 3) the new correct text and> > > > > > >>>> 4) if the changes > > > > are spacing or indentation> than> > > please> > > > > > >note> > > > > > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>>FOR EXAMPLE:> > > > > > > > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> > > > > > >>>>> > > > > > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jumped over the > > > > lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> The > > > > quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> > > > > > > > > > >>>>If you have a whole paragraph to replace you do not need> > > > > to> > > use> > > > > > >>>>the arrow to point out the differences> > > > > > > > > > >>>>> > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > > > > > > >>>>> > > > > > >>>> Replace OLD:> > > > > > >>>>> > > > > > >>>> > > > > alsdfja;sldjf;lajsd;fljas;dlfj;> > > > > > >>>>> > > > > > >>>> With > > > > NEW:> > > > > > >>>>> > > > > > >>>> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > > > > > >>>>> > > > > > >>>>Spacing or indentation problems...> > > > > > > > > > >>>>> > > > > > >>>> Section 10, 1st paragraph (remove spaces> > > > > between> > > bit> > > > > > >>>> and of, add space after butter)> > > > > > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > > > >>>> > > > > Better botter bought a bit> > > > > > >>>> of bitter butterMary mary > > > > quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>> > > > > > > > > > >>>> Better botter bought a bit of bitter butter> > > > > > > > > > >>>>> > > > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > > > > > > > > >>>>This document will NOT be published until we receive> > > > > > > agreement, from> > > > > > >>>>ALL listed authors, that the document > > > > is ready for> > > publication.> > > > > > >>>>> > > > > > >>>>Thanks > > > > for your cooperation,> > > > > > >>>>> > > > > > >>>>-RFC Editor> > > > > > > > > > >>>>> > > > > > >>>>> > > > > > >>>>Title : RADIUS Extension > > > > for Digest> > > > > > >>>> Authentication> > > > > > >>>>Author(s) : > > > > B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz, D. Williams,> > > > > > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s) : > > > > Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan > > > > Romascanu, Ronald Bonica> > > > > > >>>> > > > > > > -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc. -- to unsubscribe send a message to radiusext-request@ops.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, 22 Dec 2007 17:57:11 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_" From: Bernard Aboba To: Sam Hartman , , Subject: RE: [ Comments on automated key management and crypto agility Date: Sat, 22 Dec 2007 09:56:47 -0800 MIME-Version: 1.0 --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To clarify -- RADIUS has previously used MD5 as a stream cipher to protect attributes inc= luding passwords (User-Password, Tunnel-Password) and keys (keying attributes within RFC 254= 8). =20 While the use of MD5 for integrity protection has a set of issues (e.g. col= lisions), the use of MD5 as a stream cipher brings up another set of issues, such as known plaintext= attacks. =20 Given this, the ability to negotiate alternative "hiding" mechanisms is con= sidered an important part of RADIUS crypto-agility. =20 However, this is logically separate from the need to provide end-to-end pro= tection for key transport.=20 So far, the need to solve the end-to-end key transport problem has not been= part of RADIUS crypto-agility requirements. Should it be?=20 Note that it is possible for a crypto-agility solution to solve the "hiding= " problem without solving the end-to-end transport problem.=20 With Diameter, it was clear that the IESG expected a solution to both probl= ems -- ciphersuite negotiation (via TLS/IKE) as well as a mechanism for avoiding key disclosur= e to proxies=20 (e.g. redirect).=20 The current RADIUS crypto-agility requirements only appear to require solut= ion to the=20 former problem (ciphersuite negotiation), but not the latter (key disclosur= e). That said, there has been some discussion of how the current proposals (RADIUS crypto-= agility and=20 RADIUS/DTLS) could address the key disclosure problem. > From: hartmans-ietf@mit.edu > To: radext-chairs@tools.ietf.org; radiusext@ops.ietf.org > Date: Thu, 20 Dec 2007 22:44:10 -0500 > Subject: [ Comments on automated key management and crypto agility >=20 >=20 >=20 >=20 > It's my understanding that you are in the middle or have just finished > a consensus call regarding automated key management and radius crypto > agility. >=20 > I gave the chairs some advice on this topic a while ago. It turns out > I completely failed to understand the question I was asked. >=20 >=20 > I assumed that the crypto agility work was intended to strengthen > radius's integrity protection and dependence on md5. >=20 > However as I understand now, the scope of the work also includes a > real solution to the key transport problem. >=20 > So I don't think the advice I gave the WG applies. >=20 > I don't know if this changes any of your deliberations, but I just though= t I'd write and let you know that I was confused. >=20 > Here's my current understanding of the situation in this space. >=20 > * RFC 3962 says that we should have a way so that people do not need > to expose keys to third parties (proxies). This is not mandatory to > use, but we need to have a solution for that problem. >=20 > * Diameter has the redirect mechanism which handles this need in some > deployments. >=20 > * Our protocols don't force you to use proxies, but there are a lot of > good reasons why you might want to do so. >=20 >=20 > * Hokey may need to have a solution to do key management that meets > the RFC 3962 requirements. >=20 > * It may be the easiest place for hokey to solve its problem if it has > one is at the radius key transport level. >=20 > * That doesn't inherently make it radext's problem to solve. We also > still haven't even figured out how much of this is hokey's problem. >=20 > I'm trying to understand this all better and to try and figure out > what sort of consensus we want to build. --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To clarify --

RADIUS has previously used MD5 as a stream cipher to p= rotect attributes including passwords
(User-Password, Tunnel-Password) a= nd keys (keying attributes within RFC 2548). 

While the use of= MD5 for integrity protection has a set of issues (e.g. collisions), the us= e of MD5
as a stream cipher brings up another set of issues, such as kno= wn plaintext attacks. 

Given this, the ability to negotiate al= ternative "hiding" mechanisms is considered an important part
of RADIUS = crypto-agility.  

However, this is logically separate fro= m the need to provide end-to-end protection for key transport.

So f= ar, the need to solve the end-to-end key transport problem has not been par= t of RADIUS
crypto-agility requirements.  Should it be?

Not= e that it is possible for a crypto-agility solution to solve the "hiding" p= roblem without solving the
end-to-end transport problem.

With Di= ameter, it was clear that the IESG expected a solution to both problems -- = ciphersuite
negotiation (via TLS/IKE) as well as a mechanism for avoidin= g key disclosure to proxies
(e.g. redirect).

The current RADIUS= crypto-agility requirements only appear to require solution to the
for= mer problem (ciphersuite negotiation), but not the latter (key disclosure).=   That said,
there has been some discussion of how the current prop= osals (RADIUS crypto-agility and
RADIUS/DTLS) could address the key dis= closure problem.



> From: hartmans-ietf@mit.edu
> To= : radext-chairs@tools.ietf.org; radiusext@ops.ietf.org
> Date: Thu, 2= 0 Dec 2007 22:44:10 -0500
> Subject: [ Comments on automated key man= agement and crypto agility
>
>
>
>
> It's= my understanding that you are in the middle or have just finished
> = a consensus call regarding automated key management and radius crypto
&g= t; agility.
>
> I gave the chairs some advice on this topic a = while ago. It turns out
> I completely failed to understand the ques= tion I was asked.
>
>
> I assumed that the crypto agili= ty work was intended to strengthen
> radius's integrity protection an= d dependence on md5.
>
> However as I understand now, the scop= e of the work also includes a
> real solution to the key transport pr= oblem.
>
> So I don't think the advice I gave the WG applies.<= br>>
> I don't know if this changes any of your deliberations, bu= t I just thought I'd write and let you know that I was confused.
> > Here's my current understanding of the situation in this space.
&= gt;
> * RFC 3962 says that we should have a way so that people do no= t need
> to expose keys to third parties (proxies). This is not ma= ndatory to
> use, but we need to have a solution for that problem.<= br>>
> * Diameter has the redirect mechanism which handles this n= eed in some
> deployments.
>
> * Our protocols don't f= orce you to use proxies, but there are a lot of
> good reasons why = you might want to do so.
>
>
> * Hokey may need to have= a solution to do key management that meets
> the RFC 3962 requirem= ents.
>
> * It may be the easiest place for hokey to solve its= problem if it has
> one is at the radius key transport level.
&= gt;
> * That doesn't inherently make it radext's problem to solve. = We also
> still haven't even figured out how much of this is hoke= y's problem.
>
> I'm trying to understand this all better and = to try and figure out
> what sort of consensus we want to build.
<= /body> = --_5c2fec55-f7cc-4f89-9c57-3d3f789da0cd_-- -- to unsubscribe send a message to radiusext-request@ops.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, 22 Dec 2007 17:38:37 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_850a5faa-11aa-4c9f-9f82-831ac36344fd_" From: Bernard Aboba To: Subject: FW: AUTH48 [SG]: RFC 5090 NOW AVAILABLE Date: Sat, 22 Dec 2007 09:37:13 -0800 MIME-Version: 1.0 --_850a5faa-11aa-4c9f-9f82-831ac36344fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 4590bis is now being held in AUTH48, pending final verification.=20 What started as a "simple" IANA-problem fix has turned into a longer odysse= y due to the=20 discovery of additional errors/omissions. =20 In attempt to bring this story to a close, we need to make very sure that w= e have looked over this document carefully so that we don't have to go through this again with= RFC 4590ter.=20 So if you have ever had any interest in RADIUS Digest Authentication, now w= ould be the time to look over the AUTH48 version of the document, and speak up if there is a= problem. =20 > Date: Fri, 21 Dec 2007 15:14:46 -0800 > From: rfc-editor@rfc-editor.org > To: beckw@t-systems.com > CC: baruch.sterman@kayote.com; david.schwartz@xconnect.net; dscreat@dscre= at.com; dwilli@cisco.com; dromasca@avaya.com; rbonica@juniper.net; d.b.nels= on@comcast.net; bernard_aboba@hotmail.com; rfc-editor@rfc-editor.org > Subject: Re: AUTH48 [SG]: RFC 5090 = NOW AVAILABLE >=20 > Greeings Wolfgang, >=20 > Just a reminder that we are waiting to hear from you before continuing > on with the publication process. >=20 > Please see the email below for document information. >=20 > Thank you. >=20 > RFC Editor >=20 > On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote: > > Hi Wolfgang, > >=20 > > Just a friendly reminder that we are waiting to hear from you before > > continuing on with the publication process for RFC 5090 > > . =20 > >=20 > > Please review the files located at: > >=20 > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.html > >=20 > > Note that this diff file highlights only the differences between the > > last posted version of the document and the current text file. The > > previously posted versions (during AUTH48) are available as: > >=20 > > The originally posted AUTH48 files: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html > >=20 > > Version 2 (includes author updates) of AUTH48 files: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2.txt > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-diff.html > > Note that this file highlights only the differences between the > > version 1 and 2 text files. > >=20 > > We will wait to hear from you before continuing on with the > > publication process. > >=20 > > Thank you. > >=20 > > RFC Editor/sg > >=20 > >=20 > > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard Aboba wrote: > > >=20 > > > I also talked to Wolfgang at IETF 70. He wanted to check the documen= t over carefully to make sure there > > > were no further issues. > Subject: RE: AUTH48 [SG]: RFC 5090 NOW AVAILABLE> Date: Mon, 10 Dec 2007 20:30= :51 +0200> From: Baruch.Sterman@Kayote.com> To: rfc-editor@rfc-editor.org; = beckw@t-systems.com> CC: david.schwartz@xconnect.net; dscreat@dscreat.com; = dwilli@cisco.com; dromasca@avaya.com; rbonica@juniper.net; Bernard_Aboba@ho= tmail.com; d.b.nelson@comcast.net> > Yes,> > David Schwartz saw him at the = ietf meeting and worked through the draft> with him. I think we should be h= earing from him soon.> > Baruch> > > -----Original Message-----> From: RFC = Editor [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, December 10, 2007= 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> Cc: David Schwartz; RFC = Editor; dscreat@dscreat.com; dwilli@cisco.com;> Dan Romascanu; Ronald Bonic= a; Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subject: Re: AUTH48 = [SG]: RFC 5090 > NOW AVAILABLE> > All,= > > Just checking to see if you have had any luck contacting Wolfgang?> > T= hanks!> > RFC Editor/sg> > On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch= Sterman wrote:> > David Schwartz will be at the IETF meetings next week. M= aybe Wolfgang> > will be there and he can nudge him to answer. Lets hold of= f until we> see> > if that way forward works. If not, we can go with option= 3.> > > > Thanks,> > > > Baruch> > > > > > -----Original Message-----> > F= rom: RFC Editor [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, Novem= ber 27, 2007 12:41 AM> > To: Baruch Sterman> > Cc: RFC Editor> > Subject: R= e: AUTH48 [SG]: RFC 5090> > > NOW AVAI= LABLE> > > > Hi Baruch,> > > > We have a couple of ways to move forward.> >= > > 1. The author can be removed as an author, and moved to the> > Acknowl= edgements section.> > > > 2. We can create a Contributor's section and have= him listed there.> > > > 3. We can request that the AD approve the documen= t in place of the> > unavailabe author. > > > > Option 3 has been done befo= re in instances where the missing author> > made sizeable contributions to = the document, so the other authors> > did not feel comfortable removing the= individuals name as an> > author. > > > > It sounds as though 3 may be the= proper way forward. If this is the> > case, we will send an email to the A= Ds requesting their approval in> > place of Wolfgang (the message will be c= c'ed to all relevant> > parties, including Wolfgang). > > > > If the above = suggestions are unacceptable and you have an alternative> > solution, pleas= e let us know. > > > > Thank you.> > > > RFC Editor> > > > On Mon, Nov 26, = 2007 at 09:39:09AM +0200, Baruch Sterman wrote:> > > I wrote to Wolfgang as= well, but got no response. What is the> > procedure> > > in this case? I a= m sure that Wolfgang would be ok with the changes.> > The> > > last email I= received was on October 19 where he said that he had> made> > > the one co= rrection (suggested by Ellermann) in the cnonce value. > > > > > > Baruch> = > > > > > > > > -----Original Message-----> > > From: RFC Editor [mailto:rf= c-editor@rfc-editor.org] > > > Sent: Wednesday, November 21, 2007 10:35 PM>= > > To: David Williams; Baruch Sterman; dscreat@dscreat.com; David> > Schw= artz;> > > beckw@t-systems.com> > > Cc: radext-ads@tools.ietf.org; radext-c= hairs@tools.ietf.org; RFC> > Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090= > > > > > NOW AVAILABLE> > > > > > Gre= etings Wolfgang,> > > > > > We do not believe we have received your respons= e regarding this> > > document's readiness for publication as an RFC. Pleas= e review the> > > text and let us know if you are content with the document= as it now> > > appears at:> > > > > > ftp://ftp.rfc-editor.org/in-notes/au= thors/rfc5090.txt> > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-di= ff.html> > > Note that this diff file highlights only the changes between t= he> last > > > posted version of the document and the current text file.> >= > > > > > > > The last versions of the document are available as:> > > > >= > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> > > ftp://ftp.r= fc-editor.org/in-notes/authors/rfc5090v1-diff.html> > > > > > ftp://ftp.rfc= -editor.org/in-notes/authors/rfc5090v2.txt> > > ftp://ftp.rfc-editor.org/in= -notes/authors/rfc5090v2-diff.html> > > Note that this diff file highlights= only the changes between v1 and> > > the v2.> > > > > > We will wait to he= ar from you before continuing on with the> > > publication process.> > > > = > > Thank you.> > > > > > RFC Editor> > > > > > On Fri, Nov 16, 2007 at 05:= 13:04PM -0800, RFC Editor wrote:> > > > Authors,> > > > > > > > We have cor= rected the text as indicated below and posted the> revised> > > > version o= f the document at:> > > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors= /rfc5090.txt> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-diff.= html> > > > Note that this diff file highlights only the changes betwee the= > last> > > > > > posted version of the document and the current text file.= > > > > > > > > Please review the document and let us know if you approve t= his> > > > text for publication.> > > > > > > > We believe we are waiting f= or the following approvals:> > > > > > > > Baruch Sterman - done > > > > Da= niel Sadolevsky - done> > > > David Schwartz - done> > > > David Williams> = > > > Wolfgang Beck> > > > > > > > Bernard Aboba - done> > > > > > > > > > = > > Thank you.> > > > > > > > RFC Editor> > > > > > > > > > > > On Tue, Nov= 06, 2007 at 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,> > > > >= > > > > > Please confer and let us know how the text should/should not use= > > the> > > > > quote marks. It sounds as though this email was for discus= sion.> > If> > > > > the changes below are acceptable, we will make the cha= nges and> > post> > > a> > > > > revised version of the document.> > > > > = > > > > > Also, please note the following status of document approvals:> > = > > > > > > > > Baruch Sterman - done (although we would like to know if yo= u> agree> > > > > with the changes described below)> > > > > Daniel Sadolev= sky - done> > > > > David Schwartz> > > > > David Williams> > > > > Wolfgan= g Beck> > > > > > > > > > Bernard Aboba - done> > > > > > > > > > We will w= ait to hear further before continuing on with the> > > publication> > > > >= process.> > > > > > > > > > Thank you.> > > > > > > > > > RFC Editor> > > = > > > > > > > > > > > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Wil= liams wrote:> > > > > > Hi Baruch,> > > > > > > > > > > > These look good, = and I agree with your consistency comment. I> > > have a few > > > > > > mo= re specific changes to suggest that I would like you and> > others> > > to = > > > > > > review as well. But first a couple of general style comments> >= that> > > require > > > > > > no changes to the document.> > > > > > > > >= > > > General comment #1: I tried to find a definitive style guide> to> > = > use of > > > > > > single quotes versus double quotes and found there is = no hard> > > guidelines, > > > > > > that consistency is most important:> >= > > > > http://en.wikipedia.org/wiki/Quotation_mark> > > > > > http://foru= m.wordreference.com/showthread.php?t=3D120946> > > > > > Though I tend to t= hink that double quotes are more commonly> used> > > and match > > > > > > = the syntax of more popular programming languages, but there> are> > so> > >= many > > > > > > quoted items in the document and it has been this way for= a> long> > > time, so > > > > > > best to leave as is.> > > > > > > > > > = > > General comment #2: When refering to responses from the radius> > > ser= ver > > > > > > there are a lot of instances of a comment similiar to "with= out> > > surrounding > > > > > > quotes" that potentially could be removed = for readability.> > > Especially if > > > > > > there were a more concise d= efinition up-front about the> general> > > form of > > > > > > values retur= ned from the radius server. But I am a little> > > hesitant to > > > > > > = just strip them out now.> > > > > > > > > > > > Specific comments, to build= on top of your list:> > > > > > > > > > > > In section 2.1.2, 1st paragrap= h should not have quotes around> > > nonce. > > > > > > Paragraph should re= ad:> > > > > > > > > > > > If a matching (Proxy-)Authorization header is pr= esent and> > > contains> > > > > > HTTP Digest information, the RADIUS clie= nt checks the nonce> > > > > > parameter.> > > > > > > > > > > > In next pa= ragraph, do not need quotes around response.> > Paragraph> > > should > > >= > > > read:> > > > > > > > > > > > If the RADIUS client recognizes the non= ce, it takes the> > header> > > > > > directives and puts them into a RADIU= S Access-Request> packet.> > > It> > > > > > puts the response directive in= to a Digest-Response> attribute> > > and> > > > > > the realm, nonce, diges= t-uri, qop, algorithm, cnonce, nc,> > > username,> > > > > > and opaque dir= ectives into the respective Digest-Realm,> > > Digest-Nonce,> > > > > > Dig= est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,> > > Digest-> > > > >= > Nonce-Count, Digest-Username, and Digest-Opaque attributes.> > > The> > = > > > > RADIUS client puts the request method into the> Digest-Method> > > = > > > attribute.> > > > > > > > > > > > In section 2.1.3, in addtion to the= items you point out, in> the> > > last > > > > > > paragraph, nextnounce d= oes not need quoting. Paragraph> should> > > read:> > > > > > > > > > > > W= hen the RADIUS server provides a Digest-Nextnonce> attribute> > in> > > the= > > > > > > Access-Accept packet, the RADIUS client puts the contents> of> = > > this> > > > > > attribute into a nextnonce directive. Now it can send a= n> > HTTP-> > > > > > style response.> > > > > > > > > > > > In section 2.1= .4, 2nd paragraph, the stale directive should> not> > > need > > > > > > qu= oting. Paragraph should read:> > > > > > > > > > > > If the RADIUS client r= eceives an Access-Challenge packet in> > > response> > > > > > to an Access= -Request containing a Digest-Nonce attribute,> the> > > RADIUS> > > > > > s= erver did not accept the nonce. If a Digest-Stale> attribute> > > is> > > >= > > present in the Access-Challenge and has a value of 'true'> > > (withou= t> > > > > > surrounding quotes), the RADIUS client sends an error> > respo= nse> > > (401> > > > > > or 407) containing a WWW-/Proxy-Authenticate heade= r with> the> > > > > > directive stale and the digest directives derived fr= om the> > > Digest-*> > > > > > attributes.> > > > > > > > > > > > Except I= think the wording of the last sentence in this same> > > paragraph > > > >= > > could be improved. So that the paragraph reads more like:> > > > > > >= > > > > > If the RADIUS client receives an Access-Challenge packet in> > >= response> > > > > > to an Access-Request containing a Digest-Nonce attribu= te,> the> > > RADIUS> > > > > > server did not accept the nonce. If a Diges= t-Stale> attribute> > > is> > > > > > present in the Access-Challenge and h= as a value of 'true'> > > (without> > > > > > surrounding quotes), the RADI= US client sends an error> > response> > > (401> > > > > > or 407) containin= g a WWW-/Proxy-Authenticate header with> the> > > > > > stale directive set= to 'true' and the digest directives> > derived> > > from> > > > > > the Di= gest-* attributes.> > > > > > > > > > > > In section 3.10, 1st paragraph, I= believe the term "qop-level"> > is> > > ill > > > > > > defined and should= not be used, that qop directive or> qop-value> > > would be > > > > > > be= tter. In other words the paragraph should read:> > > > > > > > > > > > When= using the qop-value 'auth-int', a hash of the> > > HTTP-style> > > > > > m= essage body's contents is required for digest> > > calculation.> > > > > > = Instead of sending the complete body of the message,> > only> > > its> > > = > > > hash value is sent. This hash value can be used> > directly> > > in> = > > > > > the digest calculation.> > > > > > > > > > > > In section 3.15, a= uth-param doesn't need quoting. So that the> > > paragraph > > > > > > beco= mes:> > > > > > > > > > > > This attribute is a placeholder for future exte= nsions> > and> > > > > > corresponds to the auth-param parameter defined in= > > > Section> > > > > > 3.2.1 of [RFC2617]. The Digest-Auth-Param is the> = > > mechanism> > > > > > whereby the RADIUS client and RADIUS server can> >= exchange> > > auth-> > > > > > param extension parameters contained within= Digest> > > headers that> > > > > > are not understood by the RADIUS clien= t and for which> > > there are> > > > > > no corresponding stand-alone attr= ibutes.> > > > > > > > > > > > In section 3.17, domain doesn't need quoting= . So that the> > > paragraph > > > > > > becomes:> > > > > > > > > > > > Wh= en a RADIUS client has asked for a nonce, the> RADIUS> > > server> > > > > = > MAY send one or more Digest-Domain attributes in its> > > Access-> > > > = > > Challenge packet. The RADIUS client puts them into> the> > > quoted,> >= > > > > space-separated list of URIs of the domain directive> of> > a> > >= > > > WWW-Authenticate header. Together with Digest-Realm,> > the> > > URI= s> > > > > > in the list define the protection space (see> [RFC2617],> > > = Section> > > > > > 3.2.1) for some HTTP-style protocols. This attribute> > = > MUST only> > > > > > be used in Access-Challenge and Accounting-Request> = > > packets.> > > > > > > > > > > > In section 3.19, 1st paragraph, in addt= ion to no quotes around> > > rspauth as > > > > > > you pointed out, I beli= eve there should be no quotes around> qop.> > > So that > > > > > > the par= agraph reads:> > > > > > > > > > > > This attribute is used to allow the ge= neration of an> > > > > > Authentication-Info header, even if the HTTP-styl= e> > > response's> > > > > > body is required for the calculation of the rs= pauth> > > value.> > > > > > It SHOULD be used in Access-Accept packets if = the> > > required> > > > > > quality of protection (qop) is 'auth-int'.> > = > > > > > > > > > > thanks,> > > > > > -david> > > > > > > > > > > > On Fri= , 19 Oct 2007, 1:43pm, Baruch Sterman wRote:> > > > > > > > > > > > >After = lengthy discussions with my father-in-law who is a> > > professor of> > > >= > > >English, I agree with Dave's method of using quotes only in> the> > >= value of> > > > > > >an attribute/directive, but not in referencing the> >= > attribute/directive> > > > > > >by name. As such, I have some changes.> = > > > > > >> > > > > > >In section 2.1.3 3rd paragraph should not have quot= es around> > the> > > word> > > > > > >rspauth. Sentence should read:> > > = > > > >> > > > > > > * If the Digest-Qop attribute's value is 'auth' or not= > > > specified,> > > > > > > the RADIUS client puts the Digest-Response-Au= th> > > attribute's> > > > > > > content into the Authentication-Info heade= r's rspauth> > > > > > > directive of the HTTP-style response.> > > > > > >= > > > > > > >Same section 5th paragraph - no quotes around qop and> > algor= ithm:> > > > > > >> > > > > > > o If the Access-Accept packet contains a Di= gest-HA1> > attribute,> > > the> > > > > > > RADIUS client checks the qop a= nd algorithm directives in> > the> > > > > > > Authorization header of the = HTTP-style request it wants> to> > > > > > > authorize:> > > > > > >> > > >= > > >Next paragraph - no quotes around qop> > > > > > >> > > > > > > * If = the qop directive is missing or its value is> 'auth',> > > the> > > > > > >= RADIUS client ignores the Digest-HA1 attribute. It> > does> > > not> > > >= > > > include an Authentication-Info header in its> HTTP-style> > > > > > = > response.> > > > > > >> > > > > > >Next paragraph - no quotes around qop = or rspauth.> > > > > > >> > > > > > > * If the qop directive's value is 'au= th-int' and at> least> > > one> > > > > > > of the following conditions is = true, the RADIUS> client> > > > > > > calculates the contents of the HTTP-s= tyle response's> > > rspauth> > > > > > > directive:> > > > > > >> > > > > = > >> > > > > > >2 paragraphs later - no quotes around rspauth> > > > > > >>= > > > > > > The RADIUS client creates the HTTP-style response> > message> = > > and> > > > > > > calculates the hash of this message's body. It uses> >= the> > > result> > > > > > > and the Digest-URI attribute's value of the> = > corresponding> > > > > > > Access-Request packet to perform the H(A2)> ca= lculation.> > > It> > > > > > > takes the Digest-Nonce, Digest-Nonce-Count,= > > > Digest-CNonce, and> > > > > > > Digest-Qop values of the correspondin= g Access-Request> > and> > > the> > > > > > > Digest-HA1 attribute's value = to finish the> computation> > of> > > the> > > > > > > rspauth value.> > > = > > > >> > > > > > >> > > > > > >> > > > > > >Section 3.4 paragraph 1 - no = quotes around rspauth> > > > > > >> > > > > > > This attribute enables the = RADIUS server to prove> > > possession of> > > > > > > the password. If the= previously received Digest-Qop> > > attribute> > > > > > > was 'auth-int' = (without surrounding quotes), the> RADIUS> > > server> > > > > > > MUST sen= d a Digest-HA1 attribute instead of a> > > Digest-Response-> > > > > > > Au= th attribute. The Digest-Response-Auth attribute> > MUST> > > only> > > > >= > > be used in Access-Accept packets. The RADIUS client> > puts> > > the> = > > > > > > attribute value without surrounding quotes into the> > > rspaut= h> > > > > > > directive of the Authentication-Info header.> > > > > > >> >= > > > > >> > > > > > >Section 3.5 2nd paragraph - no quotes around nextnon= ce> > > > > > >> > > > > > > The RADIUS server MAY put a Digest-Nextnonce> = attribute> > > into an> > > > > > > Access-Accept packet. If this attribute= is present,> > the> > > RADIUS> > > > > > > client MUST put the contents o= f this attribute into> the> > > > > > > nextnonce directive of an Authentic= ation-Info header> in> > > its> > > > > > > HTTP-style response. This attri= bute MUST only be> used> > in> > > > > > > Access-Accept packets.> > > > > = > >> > > > > > >> > > > > > >Section 3.7, 4th paragraph - no quotes around = uri> > > > > > >> > > > > > > If the HTTP-style request has an Authorizatio= n> header,> > > the> > > > > > > RADIUS client puts the value of the uri di= rective> found> > > in> > > > > > > the HTTP-style request Authorization he= ader (known as> > > "digest-> > > > > > > uri-value" in Section 3.2.2 of [R= FC2617]) without> > > surrounding> > > > > > > quotes into this attribute. = If there is no> > Authorization> > > > > > > header, the RADIUS client take= s the value of the> > request> > > URI> > > > > > > from the HTTP-style req= uest it wants to authenticate.> > > > > > >> > > > > > >> > > > > > >Sectio= n 3.8, 4th paragraph - no quotes around qop> > > > > > >> > > > > > > In Ac= cess-Requests, the RADIUS client takes the value> > of> > > the> > > > > > = > qop directive (qop-value as described in [RFC2617])> > from> > > the> > >= > > > > HTTP-style request it wants to authenticate. In> > Access-> > > > = > > > Challenge packets, the RADIUS server puts a desired> > > qop-value> >= > > > > > into this attribute. If the RADIUS server supports> > more> > > = than> > > > > > > one "quality of protection" value, it puts each> > qop-va= lue> > > into> > > > > > > a separate Digest-Qop attribute.> > > > > > >> >= > > > > >Section 3.18 1st paragraph - no quotes around stale> > > > > > >>= > > > > > > This attribute is sent by a RADIUS server in order to> > > not= ify> > > > > > > the RADIUS client whether it has accepted a nonce.> If> > = > the> > > > > > > nonce presented by the RADIUS client was stale, the> > v= alue> > > is> > > > > > > 'true' and is 'false' otherwise. The RADIUS clien= t> > puts> > > the> > > > > > > content of this attribute into a stale dire= ctive of> the> > > WWW-> > > > > > > Authenticate header in the HTTP-style = response to the> > > request> > > > > > > it wants to authenticate. The att= ribute MUST only be> > > used in> > > > > > > Access-Challenge packets.> > = > > > > >> > > > > > >3.19 1st paragraph - no quotes around rspauth> > > > = > > >> > > > > > > This attribute is used to allow the generation of an> > = > > > > > Authentication-Info header, even if the HTTP-style> > > response'= s> > > > > > > body is required for the calculation of the rspauth> > > val= ue.> > > > > > > It SHOULD be used in Access-Accept packets if the> > > req= uired> > > > > > > quality of protection ('qop') is 'auth-int'.> > > > > > = >> > > > > > >> > > > > > >> > > > > > >> > > > > > >I think that does it. = Even if this is not right, at least it> > > should now> > > > > > >be consi= stent.> > > > > > >> > > > > > >Comments?> > > > > > >> > > > > > >Baruch> = > > > > > >> > > > > > >> > > > > > >> > > > > > >-----Original Message----= -> > > > > > >From: RFC Editor [mailto:rfc-editor@rfc-editor.org]> > > > > = > >Sent: Monday, October 15, 2007 8:45 PM> > > > > > >To: David Williams> >= > > > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;> > > > >= > >beckw@t-systems.com; radext-ads@tools.ietf.org;> > > > > > >radext-chai= rs@tools.ietf.org; RFC Editor> > > > > > >Subject: Re: AUTH48 [SG]: RFC 509= 0> > > > > > > > > >NOW AVAILABLE> > >= > > > >> > > > > > >Greeting all,> > > > > > >> > > > > > >We have not hea= rd further regarding the issues below or other> > > changes> > > > > > >tha= t may be required before publishing this document as an> RFC.> > > > > > >P= lease review the document and let us know if there are any> > > > > > >corr= ections required.> > > > > > >> > > > > > > ftp://ftp.rfc-editor.org/in-not= es/authors/rfc5090.txt> > > > > > > ftp://ftp.rfc-editor.org/in-notes/autho= rs/rfc5090-diff.html> > > > > > >> > > > > > >We will wait to hear from you= before continuing on with the> > > > > > >publication process.> > > > > > = >> > > > > > >Thank you.> > > > > > >> > > > > > >RFC Editor> > > > > > >> = > > > > > >On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:= > > > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRote:> > > > > > >>> = > > > > > >>>Authors,> > > > > > >>>> > > > > > >>>While reviewing > during> > > AUTH48,> > > > > > >>>please con= sider the following.> > > > > > >>>> > > > > > >>>In previous dialog, we ha= d the following exchange:> > > > > > >>>> > > > > > >>>>>2. Please explain = the usage of the single quote marks (')> > in> > > > > > >>>>>this document= . There seems to be inconsistency, but we> are> > > > > > >>>>>unable to de= termine which values/attributes/parameters> you> > > > > > >>>>>wanted to a= ppear in quote marks. For example, we see> > > > > > >>>>>> > > > > > >>>>>= 'auth-int'/"auth-int"> > > > > > >>>>>'rspauth' directive/rspauth directive= > > > > > > >>>>>'rspauth' value/rspauth value> > > > > > >>>>>> > > > > > = >>>>As RfC 2617 always uses ", replacing all 's in question> with> > "> > >= seems> > > > > > >>>>the right thing to do.> > > > > > >>>> > > > > > >>>P= lease note that we did not replace all 's with "s because> > > > > > >>>RFC= 4590 uses 's. However, if you feel that the document> > > should be> > > >= > > >>>more alignmed with RFC 2617, please let us know and we will> > > ma= ke> > > > > > >>>this change.> > > > > > >>> > > > > > >>If we are taking a= vote, I would prefer using " instead of '> > > around> > > > > > >the> > >= > > > >>value strings. I think it is better to stay aligned with> 2617> > = > rather> > > > > > >than> > > > > > >>4590. Also I believe the " usage is = more commonly used in> > other> > > > > > >>specifications.> > > > > > >>> = > > > > > >>>> > > > > > >>>Also, we had a difficult time understanding the= use of 's.> > We> > > > > > >>>inserted 's around auth-int, auth, qop, and= rspauth when> they> > > were> > > > > > >>>used as values or directives. H= owever, we did not attempt> to> > > include> > > > > > >>>'s for *all* dire= ctives and values (e.g., realm and> opaque).> > > Please> > > > > > >>>let = us know if this is not correct.> > > > > > >>> > > > > > >>I agree it is co= nfusing. Looking at 2617 I don't think it> is> > > entirely> > > > > > >> >= > > > > >>consistent either, as I see references to ["qop" directive]> as>= > > well as> > > > > > >the> > > > > > >>unquoted form [qop directive].> >= > > > > >>> > > > > > >>I am no authority on style but my initial thought = is to> > suggest> > > > > > >removing '> > > > > > >>and " from keywords wh= en refering to a directive name rather> > > than its> > > > > > >>literal v= alue, and then use "" when refering to a value.> For> > > example,> > > > >= > >the> > > > > > >>existing 5090 text would then become:> > > > > > >>> >= > > > > >>> > > > > > >> o If the Access-Accept packet contains a Di= gest-HA1> > > attribute, the> > > > > > >> RADIUS client checks the qop and= algorithm directives> in> > > the> > > > > > >> Authorization header of th= e HTTP-style request it> wants> > to> > > > > > >> authorize:> > > > > > >>= > > > > > > >> * If the qop directive is missing or its value is> > "auth",= > > > the> > > > > > >> RADIUS client ignores the Digest-HA1 attribute. It>= > > does not> > > > > > >> include an Authentication-Info header in its> >= HTTP-style> > > > > > >> response.> > > > > > >>> > > > > > >>> > >= > > > >>However when examing 2617 in more detail, using " around the> > > = directive> > > > > > >> > > > > > >>names would be more consistent with tha= t draft. For example> > > this> > > > > > >would> > > > > > >>become:> > > = > > > >>> > > > > > >>> > > > > > >> o If the Acce= ss-Accept packet contains a Digest-HA1> > > attribute, the> > > > > > >> RA= DIUS client checks the "qop" and "algorithm"> > directives> > > in the> > >= > > > >> Authorization header of the HTTP-style request it> wants> > to> >= > > > > >> authorize:> > > > > > >>> > > > > > >> * If the "qop" directive= is missing or its value is> > > "auth", the> > > > > > >> RADIUS client ig= nores the Digest-HA1 attribute. It> > > does not> > > > > > >> include an A= uthentication-Info header in its> > HTTP-style> > > > > > >> response.> > >= > > > >>> > > > > > >>> > > > > > >>Prehaps othe= rs can weigh in one which they believe is most> > > > > > >appropriate.> > = > > > > >>I believe either would be a slight improvement on the> existing> = > > text> > > > > > >which> > > > > > >>uses single quotes around the strin= g values.> > > > > > >>> > > > > > >>thanks,> > > > > > >>-david> > > > > >= >>> > > > > > >>>> > > > > > >>>Thank you.> > > > > > >>>> > > > > > >>>RF= C Editor> > > > > > >>>> > > > > > >>>> > > > > > >>>On Thu, Oct 04, 2007 a= t 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org> > > > > > >wrote:> > > = > > > >>>>> > > > > > >>>>****IMPORTANT*****> > > > > > >>>>> > > > > > >>>= >Updated 2007/10/04> > > > > > >>>>> > > > > > >>>>RFC AUTHOR(S):> > > > > = > >>>>--------------> > > > > > >>>>> > > > > > >>>>This is your LAST CHANC= E to make changes to your RFC to> be:> > > > > > >>>>draft-ietf-radext-rfc4= 590bis-02.txt, once the document is> > > published> > > > > > >as> > > > > = > >>>>an RFC we *WILL NOT* make any changes.> > > > > > >>>>> > > > > > >>>= >Please check your document at:> > > > > > >>>>> > > > > > >>>>ftp://ftp.rf= c-editor.org/in-notes/authors/rfc5090.txt> > > > > > >>>>> > > > > > >>>>AT= TENTION: The editing process occasionally introduces> > errors> > > that> >= > > > > >>>>were not in the Internet Draft. Although the RFC Editor> > tri= es> > > very> > > > > > >>>>hard to catch all errors, proofreading the text= at least> > > twice,> > > > > > >typos> > > > > > >>>>can slip through. Yo= u, as an author of the RFC, are> taking> > > > > > >>>>responsibility for t= he correctness of the final product> when> > > you OK> > > > > > >>>>public= ation. You should therefore proofread the entire> RFC> > > > > > >carefully= > > > > > > >>>>and without assumptions. Errors in RFCs last forever.> > > = > > > >>>>> > > > > > >>>>NOTE: We have run a diff tool that compares the a= pproved> > > > > > >internet-draft> > > > > > >>>>against our edited RFC ve= rsion of the document. Please> > review> > > this> > > > > > >>>>file at:> = > > > > > >>>>> > > > > >> >>>>ftp://ftp.rfc-editor.org/in-notes/authors/rf= c5090-diff.html> > > > > > >>>>> > > > > > >>>>Please note that we used a s= lightly altered version of the> > > > > > >originally> > > > > > >>>>submit= ted ID to create the diff file above. To make the> > file> > > more> > > > = > > >>>>useful, we moved the terminology section to to appear> after> > > t= he> > > > > > >>>>introduction, but we did not alter the text.> > > > > > >= >>>> > > > > > >>>>The document will NOT BE PUBLISHED until ALL of the> aut= hors> > > listed> > > > > > >in> > > > > > >>>>the RFC have affirmed that t= he document is ready to be> > > > > > >>>>published, as ALL of the authors = are equally responsible> for> > > > > > >verifying> > > > > > >>>>the docum= ents readiness for publication.> > > > > > >>>>> > > > > > >>>>** Please se= nd us a list of suitable keywords for this> > > document,> > > > > > >over>= > > > > > >>>>and above those which appear in the title.> > > > > > >>>>> = > > > > > >>>> Frequently INCORRECT information includes> > > > > > >>>>> >= > > > > >>>> - Contact Information> > > > > > >>>> - References (are they = up to date)> > > > > > >>>> - Section Numbers> > > > > > >>>> (especially i= f you originally put the copyright> > > > > > >somewhere> > > > > > >>>> ot= her than the VERY end of the document, or if> > you> > > > > > >>>> numbere= d the 'Status of the Memo' field)> > > > > > >>>>> > > > > > >>>>Please sen= d us the changes, *DO NOT* send a new document> > with> > > the> > > > > > = >>>>changes made. (If we think that the changes might be more> > > than> > = > > > > >>>>editorial we will contact the AD or the IESG to confirm> that> = > > the> > > > > > >>>>changes do not require review.)> > > > > > >>>>> > >= > > > >>>>Send us the changes in THIS format.> > > > > > >>>>> > > > > > >= >>> 1)*** SECTION #'s*** [i.e. Section 5, 2nd> > > paragraph]> > > > > > >>= >> 2) the text you want changed,> > > > > > >>>> 3) the new correct text an= d> > > > > > >>>> 4) if the changes are spacing or indentation> than> > > p= lease> > > > > > >note> > > > > > >>>> that.> > > > > > >>>>> > > > > > >>>= >FOR EXAMPLE:> > > > > > >>>>> > > > > > >>>> Section 5.6, 3rd paragraph> >= > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>> The quick brown fox jump= ed over the lazy dog.> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>> = The quick brown dog jumps over the lazy fox.> > > > > > >>>> ^^^ ^ ^^^> > >= > > > >>>>If you have a whole paragraph to replace you do not need> to> > = > use> > > > > > >>>>the arrow to point out the differences> > > > > > >>>>= > > > > > > >>>> INTRODUCTION, 2nd paragraph> > > > > > >>>>> > > > > > >>>= > Replace OLD:> > > > > > >>>>> > > > > > >>>> alsdfja;sldjf;lajsd;fljas;dl= fj;> > > > > > >>>>> > > > > > >>>> With NEW:> > > > > > >>>>> > > > > > >>= >> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > >>>>> > > > > > >>>>Spacing o= r indentation problems...> > > > > > >>>>> > > > > > >>>> Section 10, 1st p= aragraph (remove spaces> between> > > bit> > > > > > >>>> and of, add space= after butter)> > > > > > >>>>> > > > > > >>>> OLD:> > > > > > >>>>> > > > = > > >>>> Better botter bought a bit> > > > > > >>>> of bitter butterMary ma= ry quite contrary> > > > > > >>>>> > > > > > >>>> NEW:> > > > > > >>>>> > >= > > > >>>> Better botter bought a bit of bitter butter> > > > > > >>>>> > = > > > > >>>> Mary mary quite contrary> > > > > > >>>>> > > > > > >>>>This d= ocument will NOT be published until we receive> > > agreement, from> > > > = > > >>>>ALL listed authors, that the document is ready for> > > publication= .> > > > > > >>>>> > > > > > >>>>Thanks for your cooperation,> > > > > > >>= >>> > > > > > >>>>-RFC Editor> > > > > > >>>>> > > > > > >>>>> > > > > > >>= >>Title : RADIUS Extension for Digest> > > > > > >>>> Authentication> > > >= > > >>>>Author(s) : B. Sterman, D. Sadolevsky,> > > > > > >>>> D. Schwartz= , D. Williams,> > > > > > >>>> W. Beck> > > > > > >>>>Working Group Chair(s= ) : Bernard Aboba, David Nelson> > > > > > >>>>Area Director(s) : Dan Romas= canu, Ronald Bonica> > > > > > >>>> > > > > > > --_850a5faa-11aa-4c9f-9f82-831ac36344fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 4590bis is now being held in AUTH48, pending final verification.
What started as a "simple" IANA-problem fix has turned into a longer odys= sey due to the
discovery of additional errors/omissions. 

= In attempt to bring this story to a close, we need to make very sure that w= e have looked over
this document carefully so that we don't have to go t= hrough this again with RFC 4590ter.

So if you have ever had any int= erest in RADIUS Digest Authentication, now would be the time
to look ove= r the AUTH48 version of the document, and speak up if there is a problem.&n= bsp;

> Date: Fri, 21 Dec 2007 15:14:46 -0800
> From: rfc-e= ditor@rfc-editor.org
> To: beckw@t-systems.com
> CC: baruch.ste= rman@kayote.com; david.schwartz@xconnect.net; dscreat@dscreat.com; dwilli@c= isco.com; dromasca@avaya.com; rbonica@juniper.net; d.b.nelson@comcast.net; = bernard_aboba@hotmail.com; rfc-editor@rfc-editor.org
> Subject: Re: A= UTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAIL= ABLE
>
> Greeings Wolfgang,
>
> Just a reminder t= hat we are waiting to hear from you before continuing
> on with the p= ublication process.
>
> Please see the email below for documen= t information.
>
> Thank you.
>
> RFC Editor
&= gt;
> On Fri, Dec 14, 2007 at 02:51:11PM -0800, RFC Editor wrote:> > Hi Wolfgang,
> >
> > Just a friendly reminder= that we are waiting to hear from you before
> > continuing on wit= h the publication process for RFC 5090
> > <draft-ietf-radext-r= fc4590bis-09.txt>.
> >
> > Please review the files = located at:
> >
> > ftp://ftp.rfc-editor.org/in-notes= /authors/rfc5090.txt
> > ftp://ftp.rfc-editor.org/in-notes/auth= ors/rfc5090-diff.html
> >
> > Note that this diff file h= ighlights only the differences between the
> > last posted version= of the document and the current text file. The
> > previously po= sted versions (during AUTH48) are available as:
> >
> > = The originally posted AUTH48 files:
> > ftp://ftp.rfc-editor.or= g/in-notes/authors/rfc5090v1.txt
> > ftp://ftp.rfc-editor.org/i= n-notes/authors/rfc5090v1-diff.html
> >
> > Version 2 (i= ncludes author updates) of AUTH48 files:
> > ftp://ftp.rfc-edit= or.org/in-notes/authors/rfc5090v2.txt
> > ftp://ftp.rfc-editor.= org/in-notes/authors/rfc5090v2-diff.html
> > Note that this file h= ighlights only the differences between the
> > version 1 and 2 tex= t files.
> >
> > We will wait to hear from you before co= ntinuing on with the
> > publication process.
> >
>= ; > Thank you.
> >
> > RFC Editor/sg
> > > >
> > On Tue, Dec 11, 2007 at 05:08:35AM -0800, Bernard = Aboba wrote:
> > >
> > > I also talked to Wolfgang= at IETF 70. He wanted to check the document over carefully to make sure t= here
> > > were no further issues. > Subject: RE: AUTH48 [= SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE>= Date: Mon, 10 Dec 2007 20:30:51 +0200> From: Baruch.Sterman@Kayote.com&= gt; To: rfc-editor@rfc-editor.org; beckw@t-systems.com> CC: david.schwar= tz@xconnect.net; dscreat@dscreat.com; dwilli@cisco.com; dromasca@avaya.com;= rbonica@juniper.net; Bernard_Aboba@hotmail.com; d.b.nelson@comcast.net>= > Yes,> > David Schwartz saw him at the ietf meeting and worked t= hrough the draft> with him. I think we should be hearing from him soon.&= gt; > Baruch> > > -----Original Message-----> From: RFC Edit= or [mailto:rfc-editor@rfc-editor.org] > Sent: Monday, December 10, 2007 = 8:27 PM> To: beckw@t-systems.com; Baruch Sterman> Cc: David Schwartz;= RFC Editor; dscreat@dscreat.com; dwilli@cisco.com;> Dan Romascanu; Rona= ld Bonica; Bernard_Aboba@hotmail.com;> d.b.nelson@comcast.net> Subjec= t: Re: AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt>>= ; NOW AVAILABLE> > All,> > Just checking to see if you have had= any luck contacting Wolfgang?> > Thanks!> > RFC Editor/sg> = > On Tue, Nov 27, 2007 at 09:21:45PM +0200, Baruch Sterman wrote:> &g= t; David Schwartz will be at the IETF meetings next week. Maybe Wolfgang>= ; > will be there and he can nudge him to answer. Lets hold off until we= > see> > if that way forward works. If not, we can go with option = 3.> > > > Thanks,> > > > Baruch> > > > = > > -----Original Message-----> > From: RFC Editor [mailto:rfc-= editor@rfc-editor.org] > > Sent: Tuesday, November 27, 2007 12:41 AM&= gt; > To: Baruch Sterman> > Cc: RFC Editor> > Subject: Re: A= UTH48 [SG]: RFC 5090> <draft-ietf-radext-rfc4590bis-02.txt>> &g= t; NOW AVAILABLE> > > > Hi Baruch,> > > > We have a= couple of ways to move forward.> > > > 1. The author can be re= moved as an author, and moved to the> > Acknowledgements section.>= > > > 2. We can create a Contributor's section and have him liste= d there.> > > > 3. We can request that the AD approve the docum= ent in place of the> > unavailabe author. > > > > Option = 3 has been done before in instances where the missing author> > made = sizeable contributions to the document, so the other authors> > did n= ot feel comfortable removing the individuals name as an> > author. &g= t; > > > It sounds as though 3 may be the proper way forward. If t= his is the> > case, we will send an email to the ADs requesting their= approval in> > place of Wolfgang (the message will be cc'ed to all r= elevant> > parties, including Wolfgang). > > > > If the a= bove suggestions are unacceptable and you have an alternative> > solu= tion, please let us know. > > > > Thank you.> > > >= RFC Editor> > > > On Mon, Nov 26, 2007 at 09:39:09AM +0200, Ba= ruch Sterman wrote:> > > I wrote to Wolfgang as well, but got no r= esponse. What is the> > procedure> > > in this case? I am su= re that Wolfgang would be ok with the changes.> > The> > > l= ast email I received was on October 19 where he said that he had> made&g= t; > > the one correction (suggested by Ellermann) in the cnonce valu= e. > > > > > > Baruch> > > > > > > &= gt; > -----Original Message-----> > > From: RFC Editor [mailto:= rfc-editor@rfc-editor.org] > > > Sent: Wednesday, November 21, 200= 7 10:35 PM> > > To: David Williams; Baruch Sterman; dscreat@dscrea= t.com; David> > Schwartz;> > > beckw@t-systems.com> > = > Cc: radext-ads@tools.ietf.org; radext-chairs@tools.ietf.org; RFC> &= gt; Editor> > > Subject: Re: AUTH48 [SG]: RFC 5090> > <dr= aft-ietf-radext-rfc4590bis-02.txt>> > > NOW AVAILABLE> > = > > > > Greetings Wolfgang,> > > > > > We do = not believe we have received your response regarding this> > > doc= ument's readiness for publication as an RFC. Please review the> > >= ; text and let us know if you are content with the document as it now> &= gt; > appears at:> > > > > > ftp://ftp.rfc-editor.org/= in-notes/authors/rfc5090.txt> > > ftp://ftp.rfc-editor.org/in-note= s/authors/rfc5090-diff.html> > > Note that this diff file highligh= ts only the changes between the> last > > > posted version of t= he document and the current text file.> > > > > > > &g= t; > The last versions of the document are available as:> > > &= gt; > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1.txt> &= gt; > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v1-diff.html> = > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v= 2.txt> > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090v2-dif= f.html> > > Note that this diff file highlights only the changes b= etween v1 and> > > the v2.> > > > > > We will wa= it to hear from you before continuing on with the> > > publication= process.> > > > > > Thank you.> > > > > &= gt; RFC Editor> > > > > > On Fri, Nov 16, 2007 at 05:13:0= 4PM -0800, RFC Editor wrote:> > > > Authors,> > > >= > > > > We have corrected the text as indicated below and post= ed the> revised> > > > version of the document at:> > = > > > > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc= 5090.txt> > > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc50= 90-diff.html> > > > Note that this diff file highlights only th= e changes betwee the> last> > > > > > posted version o= f the document and the current text file.> > > > > > >= > Please review the document and let us know if you approve this> &g= t; > > text for publication.> > > > > > > > W= e believe we are waiting for the following approvals:> > > > &g= t; > > > Baruch Sterman - done > > > > Daniel Sadolevs= ky - done> > > > David Schwartz - done> > > > David= Williams> > > > Wolfgang Beck> > > > > > >= ; > Bernard Aboba - done> > > > > > > > > >= ; > > Thank you.> > > > > > > > RFC Editor>= ; > > > > > > > > > > > On Tue, Nov 06, 20= 07 at 04:58:49PM -0800, RFC Editor wrote:> > > > > Authors,&= gt; > > > > > > > > > Please confer and let us k= now how the text should/should not use> > the> > > > >= quote marks. It sounds as though this email was for discussion.> > I= f> > > > > the changes below are acceptable, we will make th= e changes and> > post> > > a> > > > > revised= version of the document.> > > > > > > > > > = Also, please note the following status of document approvals:> > >= > > > > > > > Baruch Sterman - done (although we woul= d like to know if you> agree> > > > > with the changes de= scribed below)> > > > > Daniel Sadolevsky - done> > &g= t; > > David Schwartz> > > > > David Williams> >= > > > Wolfgang Beck> > > > > > > > > &= gt; Bernard Aboba - done> > > > > > > > > > W= e will wait to hear further before continuing on with the> > > pub= lication> > > > > process.> > > > > > >= > > > Thank you.> > > > > > > > > >= RFC Editor> > > > > > > > > > > > >= > > On Fri, Oct 19, 2007 at 01:33:14PM -0400, David Williams wrote:&= gt; > > > > > Hi Baruch,> > > > > > > &= gt; > > > > These look good, and I agree with your consistency = comment. I> > > have a few > > > > > > more spec= ific changes to suggest that I would like you and> > others> > = > to > > > > > > review as well. But first a couple of= general style comments> > that> > > require > > > = > > > no changes to the document.> > > > > > >= ; > > > > > General comment #1: I tried to find a definitive= style guide> to> > > use of > > > > > > sing= le quotes versus double quotes and found there is no hard> > > gui= delines, > > > > > > that consistency is most important:&= gt; > > > > > http://en.wikipedia.org/wiki/Quotation_mark>= ; > > > > > http://forum.wordreference.com/showthread.php?t= =3D120946> > > > > > Though I tend to think that double q= uotes are more commonly> used> > > and match > > > >= ; > > the syntax of more popular programming languages, but there>= are> > so> > > many > > > > > > quoted it= ems in the document and it has been this way for a> long> > > t= ime, so > > > > > > best to leave as is.> > > &g= t; > > > > > > > > General comment #2: When referin= g to responses from the radius> > > server > > > > >= ; > there are a lot of instances of a comment similiar to "without> &= gt; > surrounding > > > > > > quotes" that potentially= could be removed for readability.> > > Especially if > > &g= t; > > > there were a more concise definition up-front about the&g= t; general> > > form of > > > > > > values retur= ned from the radius server. But I am a little> > > hesitant to >= ; > > > > > just strip them out now.> > > > >= > > > > > > > Specific comments, to build on top of y= our list:> > > > > > > > > > > > In sec= tion 2.1.2, 1st paragraph should not have quotes around> > > nonce= . > > > > > > Paragraph should read:> > > > &= gt; > > > > > > > If a matching (Proxy-)Authorization = header is present and> > > contains> > > > > > H= TTP Digest information, the RADIUS client checks the nonce> > > &g= t; > > parameter.> > > > > > > > > > &g= t; > In next paragraph, do not need quotes around response.> > Par= agraph> > > should > > > > > > read:> > &g= t; > > > > > > > > > If the RADIUS client recogn= izes the nonce, it takes the> > header> > > > > > d= irectives and puts them into a RADIUS Access-Request> packet.> > &= gt; It> > > > > > puts the response directive into a Dige= st-Response> attribute> > > and> > > > > > th= e realm, nonce, digest-uri, qop, algorithm, cnonce, nc,> > > usern= ame,> > > > > > and opaque directives into the respective= Digest-Realm,> > > Digest-Nonce,> > > > > > Dig= est-URI, Digest-Qop, Digest-Algorithm, Digest-CNonce,> > > Digest-= > > > > > > Nonce-Count, Digest-Username, and Digest-Opaq= ue attributes.> > > The> > > > > > RADIUS client= puts the request method into the> Digest-Method> > > > >= > attribute.> > > > > > > > > > > >= In section 2.1.3, in addtion to the items you point out, in> the> &g= t; > last > > > > > > paragraph, nextnounce does not n= eed quoting. Paragraph> should> > > read:> > > > &g= t; > > > > > > > When the RADIUS server provides a Dig= est-Nextnonce> attribute> > in> > > the> > > >= ; > > Access-Accept packet, the RADIUS client puts the contents> o= f> > > this> > > > > > attribute into a nextnonc= e directive. Now it can send an> > HTTP-> > > > > >= style response.> > > > > > > > > > > >= In section 2.1.4, 2nd paragraph, the stale directive should> not> &g= t; > need > > > > > > quoting. Paragraph should read:&= gt; > > > > > > > > > > > If the RADIUS cl= ient receives an Access-Challenge packet in> > > response> >= > > > > to an Access-Request containing a Digest-Nonce attribu= te,> the> > > RADIUS> > > > > > server did no= t accept the nonce. If a Digest-Stale> attribute> > > is> &g= t; > > > > present in the Access-Challenge and has a value of '= true'> > > (without> > > > > > surrounding quote= s), the RADIUS client sends an error> > response> > > (401&g= t; > > > > > or 407) containing a WWW-/Proxy-Authenticate he= ader with> the> > > > > > directive stale and the dige= st directives derived from the> > > Digest-*> > > > &g= t; > attributes.> > > > > > > > > > > &= gt; Except I think the wording of the last sentence in this same> > &= gt; paragraph > > > > > > could be improved. So that the = paragraph reads more like:> > > > > > > > > >= > > If the RADIUS client receives an Access-Challenge packet in> = > > response> > > > > > to an Access-Request contai= ning a Digest-Nonce attribute,> the> > > RADIUS> > > &= gt; > > server did not accept the nonce. If a Digest-Stale> attrib= ute> > > is> > > > > > present in the Access-Cha= llenge and has a value of 'true'> > > (without> > > > = > > surrounding quotes), the RADIUS client sends an error> > re= sponse> > > (401> > > > > > or 407) containing a= WWW-/Proxy-Authenticate header with> the> > > > > > s= tale directive set to 'true' and the digest directives> > derived>= > > from> > > > > > the Digest-* attributes.> &= gt; > > > > > > > > > > In section 3.10, 1st = paragraph, I believe the term "qop-level"> > is> > > ill >= ; > > > > > defined and should not be used, that qop directi= ve or> qop-value> > > would be > > > > > > be= tter. In other words the paragraph should read:> > > > > >= ; > > > > > > When using the qop-value 'auth-int', a hash= of the> > > HTTP-style> > > > > > message body'= s contents is required for digest> > > calculation.> > > = > > > Instead of sending the complete body of the message,> >= ; only> > > its> > > > > > hash value is sent. T= his hash value can be used> > directly> > > in> > >= > > > the digest calculation.> > > > > > > &= gt; > > > > In section 3.15, auth-param doesn't need quoting. S= o that the> > > paragraph > > > > > > becomes:&g= t; > > > > > > > > > > > This attribute is= a placeholder for future extensions> > and> > > > > &= gt; corresponds to the auth-param parameter defined in> > > Sectio= n> > > > > > 3.2.1 of [RFC2617]. The Digest-Auth-Param is= the> > > mechanism> > > > > > whereby the RADIU= S client and RADIUS server can> > exchange> > > auth-> &g= t; > > > > param extension parameters contained within Digest&g= t; > > headers that> > > > > > are not understood b= y the RADIUS client and for which> > > there are> > > >= ; > > no corresponding stand-alone attributes.> > > > >= ; > > > > > > > In section 3.17, domain doesn't need q= uoting. So that the> > > paragraph > > > > > > b= ecomes:> > > > > > > > > > > > When a R= ADIUS client has asked for a nonce, the> RADIUS> > > server>= > > > > > MAY send one or more Digest-Domain attributes in = its> > > Access-> > > > > > Challenge packet. Th= e RADIUS client puts them into> the> > > quoted,> > > = > > > space-separated list of URIs of the domain directive> of&= gt; > a> > > > > > WWW-Authenticate header. Together w= ith Digest-Realm,> > the> > > URIs> > > > > &= gt; in the list define the protection space (see> [RFC2617],> > &g= t; Section> > > > > > 3.2.1) for some HTTP-style protocol= s. This attribute> > > MUST only> > > > > > be u= sed in Access-Challenge and Accounting-Request> > > packets.> &= gt; > > > > > > > > > > In section 3.19, 1st = paragraph, in addtion to no quotes around> > > rspauth as > >= ; > > > > you pointed out, I believe there should be no quotes = around> qop.> > > So that > > > > > > the par= agraph reads:> > > > > > > > > > > > Th= is attribute is used to allow the generation of an> > > > > = > Authentication-Info header, even if the HTTP-style> > > respo= nse's> > > > > > body is required for the calculation of = the rspauth> > > value.> > > > > > It SHOULD be = used in Access-Accept packets if the> > > required> > > &= gt; > > quality of protection (qop) is 'auth-int'.> > > >= > > > > > > > > thanks,> > > > > &g= t; -david> > > > > > > > > > > > On Fri= , 19 Oct 2007, 1:43pm, Baruch Sterman wRote:> > > > > > &= gt; > > > > > >After lengthy discussions with my father-i= n-law who is a> > > professor of> > > > > > >= English, I agree with Dave's method of using quotes only in> the> >= ; > value of> > > > > > >an attribute/directive, bu= t not in referencing the> > > attribute/directive> > > &g= t; > > >by name. As such, I have some changes.> > > > = > > >> > > > > > >In section 2.1.3 3rd paragr= aph should not have quotes around> > the> > > word> > = > > > > >rspauth. Sentence should read:> > > > &= gt; > >> > > > > > > * If the Digest-Qop attribu= te's value is 'auth' or not> > > specified,> > > > >= ; > > the RADIUS client puts the Digest-Response-Auth> > > a= ttribute's> > > > > > > content into the Authenticatio= n-Info header's rspauth> > > > > > > directive of the = HTTP-style response.> > > > > > >> > > > &= gt; > >Same section 5th paragraph - no quotes around qop and> >= algorithm:> > > > > > >> > > > > > = > o If the Access-Accept packet contains a Digest-HA1> > attribute= ,> > > the> > > > > > > RADIUS client checks = the qop and algorithm directives in> > the> > > > > &g= t; > Authorization header of the HTTP-style request it wants> to> = > > > > > > authorize:> > > > > > >&= gt; > > > > > >Next paragraph - no quotes around qop> = > > > > > >> > > > > > > * If the qo= p directive is missing or its value is> 'auth',> > > the> &g= t; > > > > > RADIUS client ignores the Digest-HA1 attribute.= It> > does> > > not> > > > > > > inclu= de an Authentication-Info header in its> HTTP-style> > > > &= gt; > > response.> > > > > > >> > > >= ; > > >Next paragraph - no quotes around qop or rspauth.> > = > > > > >> > > > > > > * If the qop dir= ective's value is 'auth-int' and at> least> > > one> > &g= t; > > > > of the following conditions is true, the RADIUS> = client> > > > > > > calculates the contents of the HTT= P-style response's> > > rspauth> > > > > > > = directive:> > > > > > >> > > > > > &= gt;> > > > > > >2 paragraphs later - no quotes around = rspauth> > > > > > >> > > > > > >= The RADIUS client creates the HTTP-style response> > message> >= ; > and> > > > > > > calculates the hash of this me= ssage's body. It uses> > the> > > result> > > > = > > > and the Digest-URI attribute's value of the> > corresp= onding> > > > > > > Access-Request packet to perform t= he H(A2)> calculation.> > > It> > > > > > >= ; takes the Digest-Nonce, Digest-Nonce-Count,> > > Digest-CNonce, = and> > > > > > > Digest-Qop values of the correspondin= g Access-Request> > and> > > the> > > > > >= ; > Digest-HA1 attribute's value to finish the> computation> > = of> > > the> > > > > > > rspauth value.> &= gt; > > > > >> > > > > > >> > >= ; > > > >> > > > > > >Section 3.4 paragrap= h 1 - no quotes around rspauth> > > > > > >> > &= gt; > > > > This attribute enables the RADIUS server to prove&g= t; > > possession of> > > > > > > the password. = If the previously received Digest-Qop> > > attribute> > >= > > > > was 'auth-int' (without surrounding quotes), the> R= ADIUS> > > server> > > > > > > MUST send a Di= gest-HA1 attribute instead of a> > > Digest-Response-> > >= ; > > > > Auth attribute. The Digest-Response-Auth attribute>= ; > MUST> > > only> > > > > > > be used in= Access-Accept packets. The RADIUS client> > puts> > > the&g= t; > > > > > > attribute value without surrounding quotes= into the> > > rspauth> > > > > > > directive= of the Authentication-Info header.> > > > > > >> &= gt; > > > > >> > > > > > >Section 3.5 2= nd paragraph - no quotes around nextnonce> > > > > > >= > > > > > > > The RADIUS server MAY put a Digest-Nextn= once> attribute> > > into an> > > > > > > = Access-Accept packet. If this attribute is present,> > the> > &= gt; RADIUS> > > > > > > client MUST put the contents o= f this attribute into> the> > > > > > > nextnonce d= irective of an Authentication-Info header> in> > > its> >= > > > > > HTTP-style response. This attribute MUST only be&= gt; used> > in> > > > > > > Access-Accept packet= s.> > > > > > >> > > > > > >> = > > > > > >Section 3.7, 4th paragraph - no quotes around = uri> > > > > > >> > > > > > > If = the HTTP-style request has an Authorization> header,> > > the&g= t; > > > > > > RADIUS client puts the value of the uri di= rective> found> > > in> > > > > > > the HT= TP-style request Authorization header (known as> > > "digest-> = > > > > > > uri-value" in Section 3.2.2 of [RFC2617]) wit= hout> > > surrounding> > > > > > > quotes int= o this attribute. If there is no> > Authorization> > > > = > > > header, the RADIUS client takes the value of the> > re= quest> > > URI> > > > > > > from the HTTP-sty= le request it wants to authenticate.> > > > > > >> = > > > > > >> > > > > > >Section 3.8,= 4th paragraph - no quotes around qop> > > > > > >>= > > > > > > In Access-Requests, the RADIUS client takes = the value> > of> > > the> > > > > > > q= op directive (qop-value as described in [RFC2617])> > from> > &= gt; the> > > > > > > HTTP-style request it wants to au= thenticate. In> > Access-> > > > > > > Challenge= packets, the RADIUS server puts a desired> > > qop-value> >= > > > > > into this attribute. If the RADIUS server support= s> > more> > > than> > > > > > > one "q= uality of protection" value, it puts each> > qop-value> > > = into> > > > > > > a separate Digest-Qop attribute.>= > > > > > >> > > > > > >Section 3.1= 8 1st paragraph - no quotes around stale> > > > > > >&= gt; > > > > > > This attribute is sent by a RADIUS server= in order to> > > notify> > > > > > > the RAD= IUS client whether it has accepted a nonce.> If> > > the> &g= t; > > > > > nonce presented by the RADIUS client was stale,= the> > value> > > is> > > > > > > 'tru= e' and is 'false' otherwise. The RADIUS client> > puts> > > = the> > > > > > > content of this attribute into a stal= e directive of> the> > > WWW-> > > > > > >= Authenticate header in the HTTP-style response to the> > > reques= t> > > > > > > it wants to authenticate. The attribute= MUST only be> > > used in> > > > > > > Acces= s-Challenge packets.> > > > > > >> > > > &= gt; > >3.19 1st paragraph - no quotes around rspauth> > > &g= t; > > >> > > > > > > This attribute is used = to allow the generation of an> > > > > > > Authenticat= ion-Info header, even if the HTTP-style> > > response's> > &= gt; > > > > body is required for the calculation of the rspauth= > > > value.> > > > > > > It SHOULD be used i= n Access-Accept packets if the> > > required> > > > &g= t; > > quality of protection ('qop') is 'auth-int'.> > > >= ; > > >> > > > > > >> > > > > = > >> > > > > > >> > > > > > &g= t;I think that does it. Even if this is not right, at least it> > >= ; should now> > > > > > >be consistent.> > > = > > > >> > > > > > >Comments?> > >= ; > > > >> > > > > > >Baruch> > >= > > > >> > > > > > >> > > > &= gt; > >> > > > > > >-----Original Message-----&g= t; > > > > > >From: RFC Editor [mailto:rfc-editor@rfc-edi= tor.org]> > > > > > >Sent: Monday, October 15, 2007 8:= 45 PM> > > > > > >To: David Williams> > > >= ; > > >Cc: Baruch Sterman; dscreat@dscreat.com; David Schwartz;>= ; > > > > > >beckw@t-systems.com; radext-ads@tools.ietf.o= rg;> > > > > > >radext-chairs@tools.ietf.org; RFC Edit= or> > > > > > >Subject: Re: AUTH48 [SG]: RFC 5090> = > > <draft-ietf-radext-rfc4590bis-02.txt>> > > > &g= t; > >NOW AVAILABLE> > > > > > >> > > &= gt; > > >Greeting all,> > > > > > >> > = > > > > >We have not heard further regarding the issues belo= w or other> > > changes> > > > > > >that may = be required before publishing this document as an> RFC.> > > &g= t; > > >Please review the document and let us know if there are an= y> > > > > > >corrections required.> > > >= > > >> > > > > > > ftp://ftp.rfc-editor.org/= in-notes/authors/rfc5090.txt> > > > > > > ftp://ftp.rf= c-editor.org/in-notes/authors/rfc5090-diff.html> > > > > >= ; >> > > > > > >We will wait to hear from you befor= e continuing on with the> > > > > > >publication proce= ss.> > > > > > >> > > > > > >Than= k you.> > > > > > >> > > > > > >R= FC Editor> > > > > > >> > > > > > &g= t;On Sun, Oct 07, 2007 at 01:29:00PM -0400, David Williams> wrote:> &= gt; > > > > >>On Thu, 4 Oct 2007, 3:40pm, RFC Editor wRot= e:> > > > > > >>> > > > > > >&= gt;>Authors,> > > > > > >>>> > > >= ; > > >>>While reviewing <draft-ietf-radext-rfc4590bis-02= .txt>> during> > > AUTH48,> > > > > > >= >>please consider the following.> > > > > > >>= ;>> > > > > > >>>In previous dialog, we had t= he following exchange:> > > > > > >>>> > &= gt; > > > >>>>>2. Please explain the usage of the s= ingle quote marks (')> > in> > > > > > >>>= >>this document. There seems to be inconsistency, but we> are> = > > > > > >>>>>unable to determine which valu= es/attributes/parameters> you> > > > > > >>>&= gt;>wanted to appear in quote marks. For example, we see> > > &= gt; > > >>>>>> > > > > > >>>= ;>>'auth-int'/"auth-int"> > > > > > >>>>= ;>'rspauth' directive/rspauth directive> > > > > > >= ;>>>>'rspauth' value/rspauth value> > > > > >= >>>>>> > > > > > >>>>As RfC 2= 617 always uses ", replacing all 's in question> with> > "> >= ; > seems> > > > > > >>>>the right thing t= o do.> > > > > > >>>> > > > > >= ; >>>Please note that we did not replace all 's with "s because>= ; > > > > > >>>RFC 4590 uses 's. However, if you fe= el that the document> > > should be> > > > > > &= gt;>>more alignmed with RFC 2617, please let us know and we will> = > > make> > > > > > >>>this change.> &g= t; > > > > >>> > > > > > >>If we = are taking a vote, I would prefer using " instead of '> > > around= > > > > > > >the> > > > > > >>= value strings. I think it is better to stay aligned with> 2617> > = > rather> > > > > > >than> > > > > &= gt; >>4590. Also I believe the " usage is more commonly used in> &= gt; other> > > > > > >>specifications.> > >= ; > > > >>> > > > > > >>>> >= ; > > > > >>>Also, we had a difficult time understandi= ng the use of 's.> > We> > > > > > >>>inse= rted 's around auth-int, auth, qop, and rspauth when> they> > >= were> > > > > > >>>used as values or directives= . However, we did not attempt> to> > > include> > > &g= t; > > >>>'s for *all* directives and values (e.g., realm an= d> opaque).> > > Please> > > > > > >>&g= t;let us know if this is not correct.> > > > > > >>= > > > > > > >>I agree it is confusing. Looking at 2= 617 I don't think it> is> > > entirely> > > > > = > >> > > > > > >>consistent either, as I see = references to ["qop" directive]> as> > > well as> > > = > > > >the> > > > > > >>unquoted form [= qop directive].> > > > > > >>> > > > &g= t; > >>I am no authority on style but my initial thought is to>= > suggest> > > > > > >removing '> > > >= ; > > >>and " from keywords when refering to a directive name r= ather> > > than its> > > > > > >>literal v= alue, and then use "" when refering to a value.> For> > > examp= le,> > > > > > >the> > > > > > >&= gt;existing 5090 text would then become:> > > > > > >&= gt;> > > > > > >><snip>> > > > &g= t; > >> o If the Access-Accept packet contains a Digest-HA1> &g= t; > attribute, the> > > > > > >> RADIUS client = checks the qop and algorithm directives> in> > > the> > &= gt; > > > >> Authorization header of the HTTP-style request = it> wants> > to> > > > > > >> authorize:&g= t; > > > > > >>> > > > > > >> = * If the qop directive is missing or its value is> > "auth",> >= > the> > > > > > >> RADIUS client ignores the D= igest-HA1 attribute. It> > > does not> > > > > >= >> include an Authentication-Info header in its> > HTTP-style&= gt; > > > > > >> response.> > > > > >= ; >></snip>> > > > > > >>> > >= > > > >>However when examing 2617 in more detail, using " a= round the> > > directive> > > > > > >> >= ; > > > > >>names would be more consistent with that draf= t. For example> > > this> > > > > > >would>= ; > > > > > >>become:> > > > > > >= ;>> > > > > > >><snip more like RFC 2617>&= gt; > > > > > >> o If the Access-Accept packet contain= s a Digest-HA1> > > attribute, the> > > > > > &g= t;> RADIUS client checks the "qop" and "algorithm"> > directives&g= t; > > in the> > > > > > >> Authorization hea= der of the HTTP-style request it> wants> > to> > > > &= gt; > >> authorize:> > > > > > >>> >= > > > > >> * If the "qop" directive is missing or its va= lue is> > > "auth", the> > > > > > >> RADI= US client ignores the Digest-HA1 attribute. It> > > does not> &= gt; > > > > >> include an Authentication-Info header in i= ts> > HTTP-style> > > > > > >> response.> = > > > > > >></snip more like RFC 2617>> > = > > > > >>> > > > > > >>Prehaps o= thers can weigh in one which they believe is most> > > > > &= gt; >appropriate.> > > > > > >>I believe either = would be a slight improvement on the> existing> > > text> &g= t; > > > > >which> > > > > > >>uses = single quotes around the string values.> > > > > > >&g= t;> > > > > > >>thanks,> > > > > >= ; >>-david> > > > > > >>> > > > &= gt; > >>>> > > > > > >>>Thank you.&g= t; > > > > > >>>> > > > > > >&= gt;>RFC Editor> > > > > > >>>> > > &= gt; > > >>>> > > > > > >>>On Thu,= Oct 04, 2007 at 03:11:50PM -0700,> > > rfc-editor@rfc-editor.org&= gt; > > > > > >wrote:> > > > > > >&g= t;>>> > > > > > >>>>****IMPORTANT*****&= gt; > > > > > >>>>> > > > > > = >>>>Updated 2007/10/04> > > > > > >>>= ;>> > > > > > >>>>RFC AUTHOR(S):> > = > > > > >>>>--------------> > > > > = > >>>>> > > > > > >>>>This is = your LAST CHANCE to make changes to your RFC to> be:> > > > = > > >>>>draft-ietf-radext-rfc4590bis-02.txt, once the doc= ument is> > > published> > > > > > >as> &g= t; > > > > >>>>an RFC we *WILL NOT* make any change= s.> > > > > > >>>>> > > > > &g= t; >>>>Please check your document at:> > > > > &= gt; >>>>> > > > > > >>>>ftp://ftp= .rfc-editor.org/in-notes/authors/rfc5090.txt> > > > > > &= gt;>>>> > > > > > >>>>ATTENTION: The= editing process occasionally introduces> > errors> > > that= > > > > > > >>>>were not in the Internet Draf= t. Although the RFC Editor> > tries> > > very> > > = > > > >>>>hard to catch all errors, proofreading the t= ext at least> > > twice,> > > > > > >typos>= ; > > > > > >>>>can slip through. You, as an aut= hor of the RFC, are> taking> > > > > > >>>>= ;responsibility for the correctness of the final product> when> > = > you OK> > > > > > >>>>publication. You s= hould therefore proofread the entire> RFC> > > > > > &= gt;carefully> > > > > > >>>>and without assum= ptions. Errors in RFCs last forever.> > > > > > >>&= gt;>> > > > > > >>>>NOTE: We have run a di= ff tool that compares the approved> > > > > > >interne= t-draft> > > > > > >>>>against our edited RFC= version of the document. Please> > review> > > this> >= ; > > > > >>>>file at:> > > > > >= >>>>> > > > > >> >>>>ftp://ft= p.rfc-editor.org/in-notes/authors/rfc5090-diff.html> > > > >= > >>>>> > > > > > >>>>Please = note that we used a slightly altered version of the> > > > >= > >originally> > > > > > >>>>submitted= ID to create the diff file above. To make the> > file> > > = more> > > > > > >>>>useful, we moved the term= inology section to to appear> after> > > the> > > >= > > >>>>introduction, but we did not alter the text.>= > > > > > >>>>> > > > > > >= ;>>>The document will NOT BE PUBLISHED until ALL of the> author= s> > > listed> > > > > > >in> > > &g= t; > > >>>>the RFC have affirmed that the document is rea= dy to be> > > > > > >>>>published, as ALL of = the authors are equally responsible> for> > > > > > &g= t;verifying> > > > > > >>>>the documents read= iness for publication.> > > > > > >>>>> &g= t; > > > > >>>>** Please send us a list of suitable= keywords for this> > > document,> > > > > > >= ;over> > > > > > >>>>and above those which ap= pear in the title.> > > > > > >>>>> > &= gt; > > > >>>> Frequently INCORRECT information includ= es> > > > > > >>>>> > > > > &g= t; >>>> - Contact Information> > > > > > >= >>> - References (are they up to date)> > > > > >= ; >>>> - Section Numbers> > > > > > >>&= gt;> (especially if you originally put the copyright> > > > = > > >somewhere> > > > > > >>>> other= than the VERY end of the document, or if> > you> > > > &= gt; > >>>> numbered the 'Status of the Memo' field)> >= > > > > >>>>> > > > > > >>= >>Please send us the changes, *DO NOT* send a new document> > w= ith> > > the> > > > > > >>>>changes = made. (If we think that the changes might be more> > > than> &g= t; > > > > >>>>editorial we will contact the AD or = the IESG to confirm> that> > > the> > > > > >= >>>>changes do not require review.)> > > > > &g= t; >>>>> > > > > > >>>>Send us th= e changes in THIS format.> > > > > > >>>>>= > > > > > >>>> 1)*** SECTION #'s*** [i.e. Secti= on 5, 2nd> > > paragraph]> > > > > > >>>= ;> 2) the text you want changed,> > > > > > >>&g= t;> 3) the new correct text and> > > > > > >>>= ;> 4) if the changes are spacing or indentation> than> > > p= lease> > > > > > >note> > > > > > &g= t;>>> that.> > > > > > >>>>> >= > > > > >>>>FOR EXAMPLE:> > > > > &= gt; >>>>> > > > > > >>>> Section = 5.6, 3rd paragraph> > > > > > >>>>> > &= gt; > > > >>>> OLD:> > > > > > >&= gt;>> The quick brown fox jumped over the lazy dog.> > > >= ; > > >>>>> > > > > > >>>> = NEW:> > > > > > >>>> The quick brown dog jump= s over the lazy fox.> > > > > > >>>> ^^^ ^ ^^= ^> > > > > > >>>>If you have a whole paragrap= h to replace you do not need> to> > > use> > > > &g= t; > >>>>the arrow to point out the differences> > >= ; > > > >>>>> > > > > > >>>= > INTRODUCTION, 2nd paragraph> > > > > > >>>&= gt;> > > > > > >>>> Replace OLD:> > >= ; > > > >>>>> > > > > > >>>= > alsdfja;sldjf;lajsd;fljas;dlfj;> > > > > > >>&= gt;>> > > > > > >>>> With NEW:> > &g= t; > > > >>>>> > > > > > >>>= ;> nv;alkjd;lsf;aoisj;ltjka;sldkjf> > > > > > >>= >>> > > > > > >>>>Spacing or indentatio= n problems...> > > > > > >>>>> > > &= gt; > > >>>> Section 10, 1st paragraph (remove spaces>= between> > > bit> > > > > > >>>> an= d of, add space after butter)> > > > > > >>>>= > > > > > > >>>> OLD:> > > > >= > >>>>> > > > > > >>>> Better= botter bought a bit> > > > > > >>>> of bitte= r butterMary mary quite contrary> > > > > > >>>&= gt;> > > > > > >>>> NEW:> > > > &= gt; > >>>>> > > > > > >>>> Bet= ter botter bought a bit of bitter butter> > > > > > >&= gt;>>> > > > > > >>>> Mary mary quite c= ontrary> > > > > > >>>>> > > > &g= t; > >>>>This document will NOT be published until we receiv= e> > > agreement, from> > > > > > >>>&g= t;ALL listed authors, that the document is ready for> > > publicat= ion.> > > > > > >>>>> > > > > = > >>>>Thanks for your cooperation,> > > > > &= gt; >>>>> > > > > > >>>>-RFC Edit= or> > > > > > >>>>> > > > > &g= t; >>>>> > > > > > >>>>Title : RA= DIUS Extension for Digest> > > > > > >>>> Aut= hentication> > > > > > >>>>Author(s) : B. Ste= rman, D. Sadolevsky,> > > > > > >>>> D. Schwa= rtz, D. Williams,> > > > > > >>>> W. Beck>= > > > > > >>>>Working Group Chair(s) : Bernard = Aboba, David Nelson> > > > > > >>>>Area Direc= tor(s) : Dan Romascanu, Ronald Bonica> > > > > > >>= >> > > > > > >
= --_850a5faa-11aa-4c9f-9f82-831ac36344fd_-- -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 13:18:43 +0000 From: "David B. Nelson" To: Cc: "'li chunxiu'" Subject: RE: a question about Management Authorization -01 document Date: Thu, 20 Dec 2007 08:16:56 -0500 Message-ID: <002701c8430a$98e46ce0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AchC4lvIjVECTnqvSLS588WEMxtk7QAA/liwAAijE0A= Li Chunxiu writes... > Maybe there is need to define the "local scope" concept in the > draft-ietf-radext-management-authorization-01. We could certainly do that. I'll add that to the issues list. It works exactly like the Filter-Id attribute, which also relies on rules of local scope. Therefore, it's a well understood RADIUS operational paradigm. The rules are provisioned on all that NASes that are likely to need to know and apply them by some out of band means, such as via a MIB using SNMP, via the CLI or via FTP. Note that there is work in RADEXT to define attributes that supplement Filter-Id by provisioning and defining the rules at the same time. That is to say, defining a RADIUS filter rule attribute that actually contains the rules. This work leverages work done previously for Diameter. See RFC 4849. So far, there has been no effort to define similar self-contained management policy rules. -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 10:02:07 +0000 Date: Thu, 20 Dec 2007 18:01:04 +0800 From: li chunxiu Subject: Re:a question about Management Authorization -01 document To: j.schoenwaelder@jacobs-university.de Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000a01c842ef$3c27aff0$500c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchC4lvIjVECTnqvSLS588WEMxtk7QAA/liw > j/s wrote: > > But in the SNMP/Netconf Access Control process, there are 3 entities, agent, > > NAS and Radius server. Could you please explain how to define the "local > > scope" concept? > > For me, the agent and the NAS are effectively the same thing. From the > SNMP perspective, a manager talks to an agent. From a RADIUS > perspective, the agent acts as a NAS to the RADIUS server. See also > draft-ietf-isms-radius-usage-01.txt. Maybe there is need to define the "local scope" concept in the draft-ietf-radext-management-authorization-01. Regards Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 08:29:41 +0000 Date: Thu, 20 Dec 2007 09:28:25 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: ????: a question about Management Authorization -01 document Message-ID: <20071220082825.GA5307@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Thu, Dec 20, 2007 at 04:21:26PM +0800, li chunxiu wrote: > But in the SNMP/Netconf Access Control process, there are 3 entities, agent, > NAS and Radius server. Could you please explain how to define the "local > scope" concept? For me, the agent and the NAS are effectively the same thing. From the SNMP perspective, a manager talks to an agent. From a RADIUS perspective, the agent acts as a NAS to the RADIUS server. See also draft-ietf-isms-radius-usage-01.txt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 08:22:14 +0000 Date: Thu, 20 Dec 2007 16:21:26 +0800 From: li chunxiu Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?= To: j.schoenwaelder@jacobs-university.de Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000001c842e1$50892860$500c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Thread-index: AchC2lz2O38NQyeLSwaHW+9eNJ29bwABYp0g > > I agree with the point of view of a local policy named "read-only-group1" > > and another named "read-write-group1". > > If the Access Control is mainly done in NAS, the Access Control policy in > > Radius may be very simple, and the pattern of "read-only-group1" is ok. > > If the Radius needs to participate in the Access Control, there may be some > > complicate policies. If the policies are too complicated to be expressed in > > one Management-Policy-Id, which expression is better? Will the policies be > > separated to several parts in each Management-Policy-Id within each > > Access-Accept? And these parts will be composed to be whole policies in the > > NAS to accomplish the Access Control, right? > > Section 4 defines the purpose and scope of the access control policy > attributes. In particular, note that the Management-Policy-Id and > Management-Privilege-Level attributes are not meant to carry accress > control rules; they merely identify which locally known access control > rules to apply. Thank you for clarify this two concepts. But in the SNMP/Netconf Access Control process, there are 3 entities, agent, NAS and Radius server. Could you please explain how to define the "local scope" concept? Thanks, Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 07:33:16 +0000 Date: Thu, 20 Dec 2007 08:31:21 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: a question about Management Authorization -01 document Message-ID: <20071220073121.GA5258@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Thu, Dec 20, 2007 at 11:08:03AM +0800, li chunxiu wrote: > I agree with the point of view of a local policy named "read-only-group1" > and another named "read-write-group1". > If the Access Control is mainly done in NAS, the Access Control policy in > Radius may be very simple, and the pattern of "read-only-group1" is ok. > If the Radius needs to participate in the Access Control, there may be some > complicate policies. If the policies are too complicated to be expressed in > one Management-Policy-Id, which expression is better? Will the policies be > separated to several parts in each Management-Policy-Id within each > Access-Accept? And these parts will be composed to be whole policies in the > NAS to accomplish the Access Control, right? Section 4 defines the purpose and scope of the access control policy attributes. In particular, note that the Management-Policy-Id and Management-Privilege-Level attributes are not meant to carry accress control rules; they merely identify which locally known access control rules to apply. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.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, 20 Dec 2007 03:09:15 +0000 Date: Thu, 20 Dec 2007 11:08:03 +0800 From: li chunxiu Subject: RE: a question about Management Authorization -01 document To: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <000001c842b5$89489bd0$500c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzwABbisZAAGy1/IA== > Dave writes... > I take it that in this example the Management-Policy-Id is composed of two > separate elements, "Read-only" which provides an over-riding access control > policy of read only, and "group1", which provides some other access control > policy, perhaps based on access to certain branches of the management tree. > This is exactly the type of implementation that we discourage in the -01 > text. The content of Management-Policy-Id should be exactly one name of a > policy of local scope to the NAS. It should not be composed of sub-strings, > each of which separately names a different policy element. You could > certainly have a local policy named "read-only-group1" and another named > "read-write-group1". That might accomplish your objective. I agree with the point of view of a local policy named "read-only-group1" and another named "read-write-group1". If the Access Control is mainly done in NAS, the Access Control policy in Radius may be very simple, and the pattern of "read-only-group1" is ok. If the Radius needs to participate in the Access Control, there may be some complicate policies. If the policies are too complicated to be expressed in one Management-Policy-Id, which expression is better? Will the policies be separated to several parts in each Management-Policy-Id within each Access-Accept? And these parts will be composed to be whole policies in the NAS to accomplish the Access Control, right? > This could be workable, in that the Management-Policy-Id is restricted to a > single, flat name of local scope (no sub-fields). It is possible to define > a scenario in which two access control provisioning attributes are used in > the same Access-Accept, but... It would be necessary to define the > precedence relationship between them, should there be any conflicts in the > underlying access control rules that would result from application of the > polices in the NAS. That is also feasible to do. This needs to be researched. > The only use case that I can come up with in which it might be beneficial to > apply disparate, separately named management policies in a single > Access-Accept is the proxy RADIUS case, in which the operator of NAS and the > first hop proxy RADIUS server may wish to overlay restrictions on the access > control provisioned by the operator of the home RADIUS server. Unless these > policies are well coordinated, and the precedence relationships well > specified, the result may be unpredictable. I agree. Comments on this? Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.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, 19 Dec 2007 13:58:10 +0000 From: "David B. Nelson" To: "'li chunxiu'" , Subject: RE: a question about Management Authorization -01 document Date: Wed, 19 Dec 2007 08:57:01 -0500 Message-ID: <06e901c84247$086977a0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzwABbisZA= > Li Chunxiu writes... > Here is a situation: > 1.NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = " Read-only group1" I take it that in this example the Management-Policy-Id is composed of two separate elements, "Read-only" which provides an over-riding access control policy of read only, and "group1", which provides some other access control policy, perhaps based on access to certain branches of the management tree. This is exactly the type of implementation that we discourage in the -01 text. The content of Management-Policy-Id should be exactly one name of a policy of local scope to the NAS. It should not be composed of sub-strings, each of which separately names a different policy element. You could certainly have a local policy named "read-only-group1" and another named "read-write-group1". That might accomplish your objective. > 3. NETCONF access, defined by a policy, with the Management-Privilege- > Level > attribute: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 " > * Management-Privilege-Level (xx) = 15 > Comment:15 denotes Read-only > 16 denotes create ... ... This could be workable, in that the Management-Policy-Id is restricted to a single, flat name of local scope (no sub-fields). It is possible to define a scenario in which two access control provisioning attributes are used in the same Access-Accept, but... It would be necessary to define the precedence relationship between them, should there be any conflicts in the underlying access control rules that would result from application of the polices in the NAS. That is also feasible to do. > I think the 3rd example using the Management-Privilege-Level attribute > clarifies the use methods of Management-Privilege-Level attribute. > What is your opinion? My question is whether it is necessary to support the application of two (or more) separately defined (and named) access control policies in the NAS at one time? In any case where multiple, separate policies are applied, it is also possible to create a single name for the combined policy. Of course, if there are a large number of such sub-policies that can be combined, the number of unique, flat names to represent them becomes combinatorially large. However, I think it is a true statement that organizations using a form of role-based access control policy will typically only define a hand-full of really distinct roles. For that reason, I think that the "mix-and-match" capability of provisioning multiple local policies via RADIUS, either in separate attributes or as sub-elements of a single attribute, creates added complexity disproportionate to the practical value. But that's just my opinion. The only use case that I can come up with in which it might be beneficial to apply disparate, separately named management policies in a single Access-Accept is the proxy RADIUS case, in which the operator of NAS and the first hop proxy RADIUS server may wish to overlay restrictions on the access control provisioned by the operator of the home RADIUS server. Unless these policies are well coordinated, and the precedence relationships well specified, the result may be unpredictable. I tend to agree with Juergen Schoenwaelder's comments on whether this kind of approach will ever be required by NETCONF. However, if the WG members think that addressing the proxy RADIUS server (e.g. the access outsourcing) use case is important, we could do that, in a couple of different ways. Comments on this? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 19 Dec 2007 07:43:19 +0000 Date: Wed, 19 Dec 2007 08:41:53 +0100 From: Juergen Schoenwaelder To: li chunxiu Cc: "'David B. Nelson'" , radiusext@ops.ietf.org Subject: Re: ????: a question about Management Authorization -01 document Message-ID: <20071219074153.GA4146@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: li chunxiu , "'David B. Nelson'" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) On Wed, Dec 19, 2007 at 10:46:36AM +0800, li chunxiu wrote: > Here is a situation: > 1.NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = " Read-only group1" > 2. NETCONF access, defined by a policy: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 Read-only" > 3. NETCONF access, defined by a policy, with the Management-Privilege-Level > attribute: > * Service-Type (6) = Framed-Management (xx) > * Framed-Management-Protocol (xx) = NETCONF(3) > * Management-Policy-Id (xx) = "group1 " > * Management-Privilege-Level (xx) = 15 > Comment:15 denotes Read-only > 16 denotes create ... ... > I think the 3rd example using the Management-Privilege-Level attribute > clarifies the use methods of Management-Privilege-Level attribute. > What is your opinion? Since NETCONF right now does not have a defined access control system, the discussion is kind of pointless since implementations can do whatever they like. That said, let me say that I personally find a combination of Management-Policy-Id and Management-Privilege-Level somewhat strange. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- to unsubscribe send a message to radiusext-request@ops.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, 19 Dec 2007 02:47:38 +0000 Date: Wed, 19 Dec 2007 10:46:36 +0800 From: li chunxiu Subject: =?gb2312?B?tPC4tDogYSBxdWVzdGlvbiBhYm91dCBNYW5hZ2VtZW50IEF1dGhvcg==?= =?gb2312?B?aXphdGlvbiAtMDEgZG9jdW1lbnQ=?= To: "'David B. Nelson'" , radiusext@ops.ietf.org Message-id: <00e401c841e9$5fe04da0$500c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYAAaQSzw > Li Chunxiu writes... > > In the RADIUS NAS Management Authorization Draft=A3=ACthe added = attribute > > Management-Privilege-Level is an integer-valued attribute for use = with > > CLI access methods, I have a question about it, does it apply to the > > Framed-Management-Protocol? > The Management-Privilege-Level attribute was added to address a review > comment and a long standing use case. > In the -01 draft, we made it clear that the Management-Policy-Id = attribute > was to be a flat, simple name of local scope, and that the field was = not to > be overloaded with other kinds of elements, all in the name of good > interoperability. To address a need that might have tempted vendors = to > overload the Management-Policy-Id attribute and to provide a way to > provision a long standing CLI management parameter, we added the new > attribute. > The use case is that of integer valued-privilege level for CLI usages, = as > exemplified by the "enable' levels in Cisco's IOS. This use is common = in > other vendor's products, as well. > I don't see any reason that the Management-Privilege-Level attribute = could > not be made applicable to Framed-Management sessions, but I don't see = any > compelling reason for doing so. Having it available as a matter of protocol > symmetry might be nice, but is there actually a use case that it would > support? >=20 > > For example, in access control of SNMP protocol or Netconf protocol, = is > > it necessary to use the Management-Privilege-Level attribute? >=20 > It seems to me that the named policy of Management-Policy-Id would be > sufficient for uses such as SNMP or Netconf. Can you suggest a = situation > where it would be desirable to have an integer-valued parameter for > provisioning access control via either of these methods? >=20 Here is a situation: 1.NETCONF access, defined by a policy: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D " Read-only group1" 2. NETCONF access, defined by a policy: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D "group1 Read-only" 3. NETCONF access, defined by a policy, with the = Management-Privilege-Level attribute: * Service-Type (6) =3D Framed-Management (xx) * Framed-Management-Protocol (xx) =3D NETCONF(3) * Management-Policy-Id (xx) =3D "group1 " * Management-Privilege-Level (xx) =3D 15=20 Comment:15 denotes Read-only=20 16 denotes create ... ... I think the 3rd example using the Management-Privilege-Level attribute clarifies the use methods of Management-Privilege-Level attribute.=20 What is your opinion? Regards,=20 Li chunxiu -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 23:15:23 +0000 Message-ID: <47685448.70402@azairenet.com> Date: Tue, 18 Dec 2007 15:14:16 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bernard Aboba CC: "David B. Nelson" , radiusext@ops.ietf.org Subject: Re: Question on the Class attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Got it. Thanks for the responses. Vijay Bernard Aboba wrote: > > It appears to me that RFC 2865 requires the class attribute, if > > used, to be the same in the Access Accept and the Accounting > > Request. I agree with you that if the Accounting Request goes to > > a different server from the one that sent the Access Accept > > message, this matching does not make sense. The use of this > > attribute also may not make sense. > > The Class attribute is designed to allow the RADIUS authentication server > to provide information to be placed within accounting records. This is > typically most useful in situations where the accounting server may not > have access to all the information which the authentication server has > access to -- because if it did, why would the Class attribute be needed > at all? > > Accounting records need not even be handled by the same administrative > domain > (let alone the same RADIUS authentication server). So the Class > attribute does not > assume that the RADIUS authentication server and accounting server are the > same entity. -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 19:59:02 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_" From: Bernard Aboba To: Vijay Devarapalli , "David B. Nelson" CC: Subject: RE: Question on the Class attribute Date: Tue, 18 Dec 2007 11:58:00 -0800 MIME-Version: 1.0 --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It appears to me that RFC 2865 requires the class attribute, if> used, to= be the same in the Access Accept and the Accounting> Request. I agree with= you that if the Accounting Request goes to> a different server from the on= e that sent the Access Accept> message, this matching does not make sense. = The use of this> attribute also may not make sense. The Class attribute is designed to allow the RADIUS authentication server to provide information to be placed within accounting records. This is=20 typically most useful in situations where the accounting server may not have access to all the information which the authentication server has access to -- because if it did, why would the Class attribute be needed at = all?=20 =20 Accounting records need not even be handled by the same administrative doma= in=20 (let alone the same RADIUS authentication server). So the Class attribute = does not assume that the RADIUS authentication server and accounting server are the same entity. = --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It appears to me that RFC 2865 requires the class attribute, if
>= ; used, to be the same in the Access Accept and the Accounting
> Requ= est. I agree with you that if the Accounting Request goes to
> a diff= erent server from the one that sent the Access Accept
> message, this= matching does not make sense. The use of this
> attribute also may n= ot make sense.

The Class attribute is designed to allow the RADIUS authentication server to provide information to be placed within accounting records.  This i= s
typically most useful in situations where the accounting server may not
have access to all the information which the authentication server has
access to -- because if it did, why would the Class attribute be needed at = all?
 
Accounting records need not even be handled by the same administrative doma= in
(let alone the same RADIUS authentication server).  So the Class attri= bute does not
assume that the RADIUS authentication server and accounting server are the<= BR> same entity. 
= --_3fb94013-14d8-4a23-bbd6-9b7bbbee681d_-- -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 18:41:55 +0000 From: "David B. Nelson" To: "'Vijay Devarapalli'" Cc: Subject: RE: Question on the Class attribute Date: Tue, 18 Dec 2007 13:39:02 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015d01c841a5$43152e50$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AchBo1t2nUFxp5o4TXWbk3cuyF0T4gAAGnoQ Vijay Devarapalli writes... > It appears to me that RFC 2865 requires the class attribute, if > used, to be the same in the Access Accept and the Accounting > Request. It requires that the RADIUS client (NAS or proxy) not change the content of Class, and that it be passed intact in the Accounting-Request messages. Class is a "cookie" between the RADIUS Server and the RADIUS Accounting server, much as State is a "cookie" between the RADIUS Server (e.g. Access-Challenge message) and the RADIUS Server (e.g. Access-Request message). > Our AAA server does not implement this attribute right now. We > were asked to. I am trying to figure out what this attribute is > about, where it is commonly used, etc... It is used to "bind" sessions, as authorized by a RADIUS Server, to accounting records, as logged on a RADIUS Accounting Server. > However, it looks like the RADIUS AAA server behavior when the > value in the Class attribute in the Access Accept and Accounting > Request does not match is unspecified. That is correct, primarily because in the most general case there is no way for the RADIUS Accounting Server to perform the "does it match" check. It takes the correct handling of the Class attribute by the NAS and by proxies on faith, as that behavior is specified in RFC 2865. There may be ways to detect broken behavior around the handling of Class attributes by means of manual inspection of the server records. There may be ways to automate the Class checking in the special case of a tightly bound RADIUS Server and RADIUS Accounting Server, but that is beyond the scope of RFC 2865 or RFC 2866. -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 18:27:55 +0000 Message-ID: <47681092.8010706@azairenet.com> Date: Tue, 18 Dec 2007 10:25:22 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: Question on the Class attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David, David B. Nelson wrote: > Vijay Devarapalli wrote: > >> I had a question on the Class attribute [RFC 2865]. What should >> the RADIUS server do if the Class in the Access Accept message >> that it sent does not match with the Accounting Request message >> that comes later? > > Given that the RADIUS Accounting Server may be completely independent of > the RADIUS Server, how would a RADIUS Accounting Server, in the most > general case, be able to tell that the content of the Class attribute > had been modified? What session identifier information from other > RADIUS attributes would it use to make that determination? It appears to me that RFC 2865 requires the class attribute, if used, to be the same in the Access Accept and the Accounting Request. I agree with you that if the Accounting Request goes to a different server from the one that sent the Access Accept message, this matching does not make sense. The use of this attribute also may not make sense. > In the special case where the RADIUS Accounting Server is tightly > coupled with the RADIUS Server and has a priori knowledge of sessions > that the RADIUS Server has authorized, and therefore the intended value > of the Class attribute, it might be possible to take some action. In > these special cases it is not entirely clear what value exists in the > Class attribute. I have no idea either. > Could you elaborate on a particular use case that exemplifies your > concerns? Our AAA server does not implement this attribute right now. We were asked to. I am trying to figure out what this attribute is about, where it is commonly used, etc... However, it looks like the RADIUS AAA server behavior when the value in the Class attribute in the Access Accept and Accounting Request does not match is unspecified. Vijay -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 14:46:37 +0000 Message-ID: <4767DCD5.2070305@elbrysnetworks.com> Date: Tue, 18 Dec 2007 09:44:37 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli CC: radiusext@ops.ietf.org Subject: Re: Question on the Class attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I had a question on the Class attribute [RFC 2865]. What should > the RADIUS server do if the Class in the Access Accept message > that it sent does not match with the Accounting Request message > that comes later? Given that the RADIUS Accounting Server may be completely independent of the RADIUS Server, how would a RADIUS Accounting Server, in the most general case, be able to tell that the content of the Class attribute had been modified? What session identifier information from other RADIUS attributes would it use to make that determination? In the special case where the RADIUS Accounting Server is tightly coupled with the RADIUS Server and has a priori knowledge of sessions that the RADIUS Server has authorized, and therefore the intended value of the Class attribute, it might be possible to take some action. In these special cases it is not entirely clear what value exists in the Class attribute. Could you elaborate on a particular use case that exemplifies your concerns? -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 14:10:30 +0000 From: "David B. Nelson" To: Cc: Subject: RE: a question about Management Authorization -01 document Date: Tue, 18 Dec 2007 09:09:13 -0500 Message-ID: <055501c8417f$9270fef0$031716ac@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Thread-Index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8AAFxwlYA== Li Chunxiu writes... > In the RADIUS NAS Management Authorization Draft$B!$(Bthe added attribute > Management-Privilege-Level is an integer-valued attribute for use with > CLI access methods, I have a question about it, does it apply to the > Framed-Management-Protocol? The Management-Privilege-Level attribute was added to address a review comment and a long standing use case. In the -01 draft, we made it clear that the Management-Policy-Id attribute was to be a flat, simple name of local scope, and that the field was not to be overloaded with other kinds of elements, all in the name of good interoperability. To address a need that might have tempted vendors to overload the Management-Policy-Id attribute and to provide a way to provision a long standing CLI management parameter, we added the new attribute. The use case is that of integer valued-privilege level for CLI usages, as exemplified by the "enable' levels in Cisco's IOS. This use is common in other vendor's products, as well. I don't see any reason that the Management-Privilege-Level attribute could not be made applicable to Framed-Management sessions, but I don't see any compelling reason for doing so. Having it available as a matter of protocol symmetry might be nice, but is there actually a use case that it would support? > For example, in access control of SNMP protocol or Netconf protocol, is > it necessary to use the Management-Privilege-Level attribute? It seems to me that the named policy of Management-Policy-Id would be sufficient for uses such as SNMP or Netconf. Can you suggest a situation where it would be desirable to have an integer-valued parameter for provisioning access control via either of these methods? Regards, 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: Tue, 18 Dec 2007 03:09:21 +0000 Date: Tue, 18 Dec 2007 11:08:06 +0800 From: li chunxiu Subject: a question about Management Authorization -01 document To: "'David B. Nelson'" Cc: radiusext@ops.ietf.org Message-id: <007e01c84123$38dda610$500c6f0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQBX7Or8A= Hello, David In the RADIUS NAS Management Authorization Draft=A3=ACthe added = attribute Management-Privilege-Level is an integer-valued attribute for use with = CLI access methods, I have a question about it, does it apply to the Framed-Management-Protocol? For example, in access control of SNMP protocol or Netconf protocol, is = it necessary to use the Management-Privilege-Level attribute? Thanks, Chunxiu li -- to unsubscribe send a message to radiusext-request@ops.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, 18 Dec 2007 01:05:10 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5080 on Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20071218010249.6BEAF10032C@bosco.isi.edu> Date: Mon, 17 Dec 2007 17:02:49 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5080 Title: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes Author: D. Nelson, A. DeKok Status: Standards Track Date: December 2007 Mailbox: dnelson@elbrysnetworks.com, aland@freeradius.org Pages: 28 Characters: 64138 Updates: RFC2865, RFC2866, RFC2869, RFC3579 See-Also: I-D Tag: draft-ietf-radext-fixes-08.txt URL: http://www.rfc-editor.org/rfc/rfc5080.txt This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Dec 2007 19:07:32 +0000 Message-ID: <4766C83C.8030606@azairenet.com> Date: Mon, 17 Dec 2007 11:04:28 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Question on the Class attribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I had a question on the Class attribute [RFC 2865]. What should the RADIUS server do if the Class in the Access Accept message that it sent does not match with the Accounting Request message that comes later? RFC 2865 does say this attribute should never be modified by the client. But I think the server behavior should still be specified in case there is a mismatch. Is there any document that talks about this? Thanks in advance Vijay -- to unsubscribe send a message to radiusext-request@ops.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, 09 Dec 2007 18:42:55 +0000 From: "Glen Zorn" To: Cc: "'Glen Zorn'" Subject: Questions on modified Extended Attribute format? Date: Sun, 9 Dec 2007 10:39:33 -0800 Message-ID: <003401c83a92$db6ed850$924c88f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C83A4F.CD4B9850" Thread-Index: Acg6ktaKf9XFXvNvSVSLUNVxuO19Jw== Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0035_01C83A4F.CD4B9850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit During the meeting last week, I thought that there were a couple of questions/comments on Jabber regarding the changes that I proposed to the extended attribute format (adding a bit to distinguish between new TLVs and legacy RADIUS attributes in extended attributes) but I didn't quite catch them. Would those who presented those remarks mind repeating them in email? TIA. ------=_NextPart_000_0035_01C83A4F.CD4B9850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During the meeting last week, I thought that there = were a couple of questions/comments on Jabber regarding the changes that I = proposed to the extended attribute format (adding a bit to distinguish between new = TLVs and legacy RADIUS attributes in extended attributes) but I didn't quite = catch them.  Would those who presented those remarks mind repeating them = in email?  TIA.

------=_NextPart_000_0035_01C83A4F.CD4B9850-- -- to unsubscribe send a message to radiusext-request@ops.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, 07 Dec 2007 08:03:56 +0000 Message-ID: <4758FE03.5000201@nitros9.org> Date: Fri, 07 Dec 2007 09:02:11 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Stefan Winter CC: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Winter wrote: >> [ certs ] > That is exactly the plan. We are not quite there yet with full deployment, but > on our way. That addresses some of my concerns about scalability. > We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end > security, which is where my wish to have auto key mgmt came from. I think end-to-end security is outside of the scope of RADIUS. If hop-by-hop security is sufficient, then the requirements and assertions can go into a vendor-specific dictionary. 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, 07 Dec 2007 07:25:08 +0000 From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Fri, 7 Dec 2007 08:23:15 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Alan DeKok MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4311849.K2hZFybWMa"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712070823.21198.stefan.winter@restena.lu> --nextPart4311849.K2hZFybWMa Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, > I think Eduroam is the only (N x N) deployment I've seen where N > 10. And even we are avoiding N^2 complexity at the moment with a tree structure= :=20 star topology with central proxy from institutions within a country, star=20 topology of country proxies to root. If you care enough: even with RadSec and peer resolution, we might still ha= ve=20 proxies in between, for entirely non-technical reasons. Some countries want= =20 to reserve the right to filter attributes at a national level, so any=20 resolution technique would be configured on their side to end up at the=20 national TLD proxy, and be distributed onwards from there. > Since Eduroam is using RadSec, I suspect that the N^2 issue could be > solved by leveraging a central Eduroam Certificate Authority. It would > issue, and sign, certificates for each participating institution or > country. Each particpant would then be responsible for using those > certs, and for validating the certs of Eduroam partners. That is exactly the plan. We are not quite there yet with full deployment, = but=20 on our way. > > 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: > > a. RADIUS client-server communication is not an N^2 problem (except > > perhaps in the roaming > > situation where end-to-end protection is being provided). > > Yes. We are facing a requirement of RADIUS-at-roaming-end to RADIUS-at-thome-end= =20 security, which is where my wish to have auto key mgmt came from. The=20 concrete use case we have is that some countries need the age of a user to= =20 determine if he's legally allowed to get unfiltered internet access. This means we would need to transfer either birthday or at least age via=20 RADIUS. This kind of user attribute can be easily tied to a concrete=20 User-Name in most cases and is thus subject to law regulations regarding=20 transmission and storage of personal data. =46or the moment our only solution is to keep eduroam to higher ed and rese= arch=20 only, where all eligible users can be expected to be over eighteen. We are= =20 currently working on a quite sophisticated out-of-band handshaking for such= =20 data (there are more examples than just age), but would be a lot happier if= =20 there was an easy in-band solution. I agree though that our woes in that regard are pretty much unique. Greetings, Stefan =2D-=20 Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale= et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224= 73 --nextPart4311849.K2hZFybWMa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHWPTp+jm90f8eFWYRAvvYAJ40CyLReN3dKpfNEXsbv7TzNN5CgQCfbZ9H WeaiOMqV8OdnDJ6RrqObrDA= =hpmQ -----END PGP SIGNATURE----- --nextPart4311849.K2hZFybWMa-- -- to unsubscribe send a message to radiusext-request@ops.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, 07 Dec 2007 00:19:16 +0000 Message-ID: <47588F60.9000100@nitros9.org> Date: Fri, 07 Dec 2007 01:10:08 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: > This is a call for RADEXT WG mailing list consensus on this issue. > Does the mailing list agree > that Automated Key Management is not a requirement for a RADIUS > Crypto-agility solution? I agree Pointing to my response: http://psg.com/lists/radiusext/2007/msg00911.html > Some of the arguments made include: > > 1. While automated key management may prove convenient in some > circumstances (e.g. EDUROAM), > the demand is by no means universal, nor is the pain of the current > manual keying environment considered > acute by most customers. Most commercial deployments of RADIUS interconnects are either ( N x N ) - where N is small, < 5 (N x 1 + 1 x M) - where N and M may each be > 30 i.e. full interconnects are usually small. Otherwise, intermediary proxies are used to simplify the problem. I think Eduroam is the only (N x N) deployment I've seen where N > 10. Since Eduroam is using RadSec, I suspect that the N^2 issue could be solved by leveraging a central Eduroam Certificate Authority. It would issue, and sign, certificates for each participating institution or country. Each particpant would then be responsible for using those certs, and for validating the certs of Eduroam partners. > 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: > a. RADIUS client-server communication is not an N^2 problem (except > perhaps in the roaming > situation where end-to-end protection is being provided). Yes. > b. One of the goals of RADIUS crypto-agility is to remove the use of > stream ciphers. > c. RADIUS traffic is generally light enough that a credible > ciphersuite would not require rekey for a long time. Yes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 06 Dec 2007 23:52:59 +0000 From: glenzorn@comcast.net To: , Subject: Re: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Thu, 06 Dec 2007 23:51:47 +0000 Message-Id: <120620072351.15546.47588B1300003D9B00003CBA2200763704029D0196020A0409@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_15546_1196985107_0" --NextPart_Webmail_9m3u9jl4l_15546_1196985107_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I agree. -------------- Original message -------------- From: At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements. The consensus within the room was that Automated Key Management should not be added to the list of Crypto-agility requirements. This is a call for RADEXT WG mailing list consensus on this issue. Does the mailing list agree that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution? Some of the arguments made include: 1. While automated key management may prove convenient in some circumstances (e.g. EDUROAM), the demand is by no means universal, nor is the pain of the current manual keying environment considered acute by most customers. 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: a. RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming situation where end-to-end protection is being provided). b. One of the goals of RADIUS crypto-agility is to remove the use of stream ciphers. c. RADIUS traffic is generally light enough that a credible ciphersuite would not require rekey for a long time. So, does the WG agree with these arguments? Please respond to the list even if you have no new arguments to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70. --NextPart_Webmail_9m3u9jl4l_15546_1196985107_0 Content-Type: text/html Content-Transfer-Encoding: 8bit
I agree.
 
-------------- Original message --------------
From: <Bernard_Aboba@hotmail.com>
At IETF 70, we discussed the applicability of RFC 4107 to RADIUS Crypto-agility requirements.
 
The consensus within the room was that Automated Key Management should not be added to the list
of Crypto-agility requirements.
 
This is a call for RADEXT WG mailing list consensus on this issue.   Does the mailing list agree
that Automated Key Management is not a requirement for a RADIUS Crypto-agility solution?
 
Some of the arguments made include:
 
1. While automated key management may prove convenient in some circumstances (e.g. EDUROAM),
the demand is by no means universal, nor is the pain of the current manual keying environment considered
acute by most customers.
 
2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution:
  a. RADIUS client-server communication is not an N^2 problem (except perhaps in the roaming
situation where end-to-end protection is being provided). 
  b. One of the goals of RADIUS crypto-agility is to remove the use of stream ciphers.
  c.  RADIUS traffic is generally light enough that a credible ciphersuite would not require rekey for a long time.
 
So, does the WG agree with these arguments?  Please respond to the list even if you have no new arguments
to add, if only to say that you agree (or disagree) with the consensus in the room at IETF 70.
--NextPart_Webmail_9m3u9jl4l_15546_1196985107_0-- -- to unsubscribe send a message to radiusext-request@ops.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, 06 Dec 2007 18:34:09 +0000 Message-ID: From: To: Subject: RADEXT WG consensus on RFC 4107 applicability to RADIUS Crypto-Agility Requirements Date: Thu, 6 Dec 2007 10:33:17 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C837F3.6A2D3F70" This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C837F3.6A2D3F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF 70, we discussed the applicability of RFC 4107 to RADIUS = Crypto-agility requirements.=20 The consensus within the room was that Automated Key Management should = not be added to the list of Crypto-agility requirements.=20 This is a call for RADEXT WG mailing list consensus on this issue. = Does the mailing list agree that Automated Key Management is not a requirement for a RADIUS = Crypto-agility solution?=20 Some of the arguments made include: 1. While automated key management may prove convenient in some = circumstances (e.g. EDUROAM), the demand is by no means universal, nor is the pain of the current = manual keying environment considered acute by most customers.=20 2. RFC 4107 criteria do not apply to a RADIUS crypto-agile solution: a. RADIUS client-server communication is not an N^2 problem (except = perhaps in the roaming situation where end-to-end protection is being provided). =20 b. One of the goals of RADIUS crypto-agility is to remove the use of = stream ciphers. c. RADIUS traffic is generally light enough that a credible = ciphersuite would not require rekey for a long time.=20 So, does the WG agree with these arguments? Please respond to the list = even if you have no new arguments to add, if only to say that you agree (or disagree) with the consensus = in the room at IETF 70. ------=_NextPart_000_0051_01C837F3.6A2D3F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At IETF 70, we discussed the = applicability of RFC=20 4107 to RADIUS Crypto-agility requirements.
 
The consensus within the room was that = Automated=20 Key Management should not be added to the list
of Crypto-agility requirements. =
 
This is a call for RADEXT WG mailing = list consensus=20 on this issue.   Does the mailing list agree
that Automated Key Management is not a = requirement=20 for a RADIUS Crypto-agility solution?
 
Some of the arguments made = include:
 
1. While automated key management = may prove=20 convenient in some circumstances (e.g. EDUROAM),
the demand is by no means universal, = nor is the=20 pain of the current manual keying environment considered
acute by most customers.
 
2. RFC 4107 criteria do not apply to a = RADIUS=20 crypto-agile solution:
  a. RADIUS=20 client-server communication is not an N^2 problem (except perhaps in the = roaming
situation where end-to-end protection = is being=20 provided). 
  b. One of the goals of RADIUS = crypto-agility=20 is to remove the use of stream=20 ciphers.
  c.  RADIUS traffic is = generally=20 light enough that a credible ciphersuite would=20 not require rekey for a long time.
 
So, does the WG agree with these = arguments? =20 Please respond to the list even if you have no new = arguments
to add, if only to say that you agree = (or disagree)=20 with the consensus in the room at IETF 70.
------=_NextPart_000_0051_01C837F3.6A2D3F70-- -- to unsubscribe send a message to radiusext-request@ops.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, 05 Dec 2007 10:11:22 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-design-02.txt Message-Id: Date: Wed, 05 Dec 2007 05:10:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Design Guidelines Author(s) : G. Weber, et al. Filename : draft-ietf-radext-design-02.txt Pages : 31 Date : 2007-12-05 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-design-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-design-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-05050411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-design-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-design-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-05050411.I-D\@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Dec 2007 09:05:59 +0000 Message-ID: <47566959.7000709@deployingradius.com> Date: Wed, 05 Dec 2007 10:03:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: 'radext mailing list' Subject: Drafts for the meeting Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have put the drafts up on my web site: http://deployingradius.com/ietf/ I've included the DTLS draft, which has expired. I've also included the -02 draft, which I have just submitted. 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, 05 Dec 2007 03:49:12 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "radiusext@ops.ietf.org" Date: Wed, 5 Dec 2007 03:47:51 +0000 Subject: Request for review of RADIUS Attributes for IEEE 802 Networks Thread-Topic: Request for review of RADIUS Attributes for IEEE 802 Networks Thread-Index: AcgmODLyeeG1TRSFS16Yc4EGw4p4CgQuU01gAAAEyGA= Message-ID: Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0305_01C836AE.8E327520" MIME-Version: 1.0 ------=_NextPart_000_0305_01C836AE.8E327520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support this document as a RADEXT WG item. Cheers, MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner- > radiusext@ops.ietf.org] On Behalf Of David B. Nelson > Sent: Tuesday, November 13, 2007 1:00 PM > To: radiusext@ops.ietf.org > Subject: Request for review of RADIUS Attributes for IEEE 802 Networks > > The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was > revised on > July 30, 2007, after incorporating review from the IEEE 802.11 WG. > This > document appears on the RADEXT WG charter as a June 2006 milestone > "WLAN > Attributes draft submitted as a Proposed Standard RFC". It would be > good to > make additional progress on this document. It appears that all the > required > external (i.e. IEEE) review has been completed. > > Please review this draft to determine if it is ready to be taken on as > a > RADEXT WG work item. The draft is to be found at: > > http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt > > In light of the upcoming IETF-70 meeting, this request for review will > last > until December 7, 2007, i.e. approximately four weeks, including the > IETF > week. > > Please indicate whether you would like this document to be taken on as > a WG > work item. Please respond even if you have no issues with the document. > If > you have comments, please send the issues to the RADEXT WG mailing list > in > the format provided here: > > http://www.drizzle.com/~aboba/RADEXT/ > > Thanks! > > Regards, > > Dave Nelson > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: ------=_NextPart_000_0305_01C836AE.8E327520 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh2K9TSN0bRHs7 wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAIC20 InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLSzZW6NF4K3fkq NjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cYB0G8dY+vGp77 WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTIwNTAzNDc1MVowIwYJ KoZIhvcNAQkEMRYEFHWgoDTA9YF1d5RhZ8S3Wqfi5pFdMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgAbXdDsXk3m7b/H6i6qDFLVTi0fXZReyJ5kS82jdDJonRh68XRaPKlGeV+iWHHDX XfVEvkcpWIVoov5CdS4DBrpm7h1kYmCB86Z5aA049d0MoeP1/LbpTkMlDkOTX9Yoc7WpgIc2/fYr U0rbN8ZtMxu58H0/dUON0/MIp/RXddvrAAAAAAAA ------=_NextPart_000_0305_01C836AE.8E327520-- -- to unsubscribe send a message to radiusext-request@ops.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, 04 Dec 2007 19:04:19 +0000 Message-ID: From: To: Subject: IETF 70 slides available Date: Tue, 4 Dec 2007 11:00:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016E_01C83664.E6334B90" This is a multi-part message in MIME format. ------=_NextPart_000_016E_01C83664.E6334B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Slides for the IETF 70 meeting of the RADEXT WG are being posted online = as they arrive: https://datatracker.ietf.org/meeting/70/materials.html If you have not sent in your slides, please do so ASAP. ------=_NextPart_000_016E_01C83664.E6334B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Slides for the IETF 70 meeting of the = RADEXT WG are=20 being posted online as they arrive:
https://d= atatracker.ietf.org/meeting/70/materials.html
 
If you have not sent in your slides, = please do so=20 ASAP.
------=_NextPart_000_016E_01C83664.E6334B90-- -- to unsubscribe send a message to radiusext-request@ops.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, 03 Dec 2007 20:06:14 +0000 Message-ID: <47546148.4090708@deployingradius.com> Date: Mon, 03 Dec 2007 21:04:24 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: > Bernard Aboba writes... > > There is some overlap in coverage. My recommendation is to reorganize > the discussion as follows: ... > DBN: I think this text is very good. Updated as recommended. ... > DBN: I think this last sentence could be a bit more specific. All > attributes encode data. The question is what kind of data. I think what > you want to say is: Updated > DBN: I recommend clarifying this last sentence just a bit by: Updated. I'll post a new version before the meeting. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Dec 2007 19:59:20 +0000 Message-ID: <47545F93.30908@deployingradius.com> Date: Mon, 03 Dec 2007 20:57:07 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard_Aboba@hotmail.com CC: radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard_Aboba@hotmail.com wrote: > How about this? > > "Where the intent is to represent a specific IPv6 address, the IPv6 ... Done. > Suggest adding: "The threat is particularly severe when the opaque data Word-smithing: The threat is particularly severe when the opaque data does not originate from, or is checked by the NAS. In those cases, the RADIUS server is potentially exposed to attack by malware residing on an unauthenticated host. Applications consuming opaque data that reside on the RADIUS server SHOULD be properly isolated from the RADIUS server, and SHOULD run with minimal privileges. Any potential vulnerabilities in that application will then have minimal impact on the security of the system as a whole. (chopping long sentences, etc.) Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Dec 2007 17:05:23 +0000 From: "David B. Nelson" To: "'Bernard Aboba'" , Subject: RE: Review of draft-ietf-radext-design-01.txt Date: Mon, 3 Dec 2007 12:01:57 -0500 Organization: Elbrys Networks, Inc. Message-ID: <012c01c835ce$3694b6b0$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: Acg1TsKun+30oRoxQeyMJulnd/ZZQQAfepkQ Bernard Aboba writes... There is some overlap in coverage.=A0 My recommendation is to reorganize the discussion as follows: =A0 "1.=A0 Introduction =A0=A0 This document provides guidelines for the design of RADIUS = attributes =A0=A0 both within the IETF as well as within other Standards = Development =A0=A0 Organizations (SDOs).=A0 By articulating RADIUS design = guidelines, it=20 =A0=A0 is hoped that this document will encourage the development and =A0=A0 publication of high quality RADIUS attribute specifications. =A0=A0 The advice in this document will not be helpful unless it is put = to use.=A0 =A0=A0 As with "Guidelines for Authors and Reviewers of MIB Documents" =A0=A0 [RFC4181], it is expected that this document will enable authors = to =A0=A0 check their document against the guidelines prior to requesting a =A0=A0 review (such an "Expert Review" described in [RFC3575]).=A0 = Similarly, =A0=A0 it is hoped that this document will be of use to reviewers (such = as =A0=A0 WG participants or the AAA Doctors) in improving the consistency = of =A0=A0 reviews. =A0 =A0=A0 In order to meet these objectives, this document needs to cover = not =A0=A0 only the science of attribute design, but also the art.=A0 As a = result, =A0=A0 in addition to covering the most frequently encountered issues, = this =A0=A0 document attempts to provide some of the considerations = motivating =A0=A0 the guidelines. =A0 =A0=A0 In order to characterize current attribute usage, both the basic = and =A0=A0 complex data types defined in the existing RADIUS RFCs are = reviewed, =A0=A0 together with the ad-hoc extensions to that data model that have = been =A0=A0 used in Vendor-Specific Attributes. DBN: I think this text is very good. 1.1.=A0 Applicability =A0=A0 As RADIUS has become more widely accepted as a management = protocol, =A0=A0 its usage has become more prevalent, both within the IETF as well = as =A0=A0 within other SDOs.=A0 Given the expanded utilization of RADIUS, =A0=A0 it has become apparent that requiring SDOs to accomplish all = their=20 =A0=A0 RADIUS work within the IETF is inherently inefficient and = unscalable. =A0=A0 By articulating guidelines for RADIUS attribute design, this = document=20 =A0=A0 enables SDOs to design their own RADIUS attributes within the=20 =A0=A0 Vendor-Specific Attribute (VSA) space, seeking review from the = IETF. =A0=A0 In order enable IETF review of SDO RADIUS attribute = specifications, =A0=A0 the authors recommend: =A0 =A0=A0=A0=A0=A0 * Development of a program to encourage SDOs to make = their RADIUS =A0=A0=A0=A0=A0 attribute specifications publicly available; =A0=A0=A0=A0=A0 * Review of IETF and SDO specifications according to the =A0=A0=A0=A0=A0 guidelines proposed in this document; =A0 =A0=A0 The advice in this document applies to attributes used to encode =A0=A0 data. DBN: I think this last sentence could be a bit more specific. All attributes encode data. The question is what kind of data. I think = what you want to say is: The advice in this document applies to attributes used to encode service-provisioning or authentication data. =A0 RADIUS protocol changes, or specification of attributes that =A0=A0 can be used to provide new RADIUS commands (such as Service-Type) = are =A0=A0 out of scope. DBN: I recommend clarifying this last sentence just a bit by: s/can be used to provide new RADIUS commands/can be used to, in effect, provide new RADIUS commands/ =A0 Since protocol changes require greater expertise and =A0=A0 deeper review, such changes should not be undertaken outside the = IETF =A0=A0 and when handled within the IETF require "IETF Consensus" for =A0=A0 adoption, as noted in [RFC3575] Section 2.1. =A0 =A0=A0 As with protocol changes, this document does not provide guidance = to =A0=A0 document authors seeking to change the RADIUS operational model. =A0=A0 While RADIUS server implementations may keep state, the RADIUS =A0=A0 protocol is stateless, although information may be passed from = one =A0=A0 protocol transaction to another via the State Attribute.=A0 As a =A0=A0 result, documents which require stateful protocol behavior = without =A0=A0 use of the State Attribute are inherently incompatible with = RADIUS as =A0=A0 defined in [RFC2865], and need to be redesigned. =A0=A0 See [RFC5080] Section 2.1.1 for a more in-depth discussion of the = use =A0=A0 of the State Attribute." =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, 03 Dec 2007 15:43:35 +0000 Message-ID: From: To: "Alan DeKok" , Subject: Re: Review of draft-ietf-radext-design-01.txt Date: Mon, 3 Dec 2007 07:42:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> IPv6 address 128 bit value, most significant octet first. >> IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to >> 128 bits of value, most significant octet first. >> >> Judging by some recent specifications, there appears to be some confusion >> between these two types. Should an IPv6 address type always be used to >> represent an address (as opposed to the prefix type). If so, you might >> state this explicitly using some normative language. > > Hmm... suggestions? How about this? "Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to utilize the IPv6 Prefix type with a prefix length of 128 to represent an IPv6 address, this usage is NOT RECOMMENDED." > 2.1.4. Complex Attributes and Security > > The introduction of complex data types brings the potential for the > introduction of new security vulnerabilities. Experience shows that > the common data types have few security vulnerabilities, or else that > all known issues have been found and fixed. New data types require > new code, which may introduce new bugs, and therefore new attack > vectors. > > RADIUS servers are highly valued targets, as they control network > access and interact with databases that store usernames and > passwords. An extreme outcome of a vulnerability due to a new, > complex type would be that an attacker is capable of taking complete > control over the RADIUS server. > > The use of attributes representing opaque data does not reduce this > threat. The threat merely moves from the RADIUS server to the > application that consumes that opaque data. Suggest adding: "The threat is particularly severe when the opaque data is not originated or checked by the NAS, so that the RADIUS server is potentially exposed to attack by malware residing on a host. Applications consuming opaque data that reside on the RADIUS server > SHOULD be properly isolated from the RADIUS server, and SHOULD run > with minimal privileges. Any potential vulnerabilities in that > application will then have minimal impact on the security of the > system as a whole. -- to unsubscribe send a message to radiusext-request@ops.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, 03 Dec 2007 12:27:13 +0000 Message-ID: <4753F571.4000003@deployingradius.com> Date: Mon, 03 Dec 2007 13:24:17 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Review of draft-ietf-radext-design-01.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Designation > > I thought that this document was a BCP, no? -01 states that > it is "Standards Track". -00 was Standards Track, too. The next version can be changed to a BCP. > Sections 1 and 1.1 > > There is some overlap in coverage. My recommendation is to reorganize > the discussion as follows: ... OK. > BTW, I would also suggest a statement that this document does not apply > to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations > between a RADIUS client and server). > Section 2.1.1 OK. > IPv6 address 128 bit value, most significant octet first. > IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to > 128 bits of value, most significant octet first. > > Judging by some recent specifications, there appears to be some confusion > between these two types. Should an IPv6 address type always be used to > represent an address (as opposed to the prefix type). If so, you might > state this explicitly using some normative language. Hmm... suggestions? > integer64 64 bit unsigned value, most significant octet first. > > I believe that this type has also been used to express an IPv6 Identifier > value, no? Yes. That is mentioned in the following paragraph. I'll add a line here saying the same thing. > limitatations -> limitations Fixed, thanks. > Section 2.1.3 .. > I think it may be worth expanding this discussion of opaque data types > somewhat and covering additional implications, security related ones > in particular. Section 2.1.3 is already over two pages long. I suggest adding a new section immediately following it, "Complex attributes and Security": 2.1.4. Complex Attributes and Security The introduction of complex data types brings the potential for the introduction of new security vulnerabilities. Experience shows that the common data types have few security vulnerabilities, or else that all known issues have been found and fixed. New data types require new code, which may introduce new bugs, and therefore new attack vectors. RADIUS servers are highly valued targets, as they control network access and interact with databases that store usernames and passwords. An extreme outcome of a vulnerability due to a new, complex type would be that an attacker is capable of taking complete control over the RADIUS server. The use of attributes representing opaque data does not reduce this threat. The threat merely moves from the RADIUS server to the application that consumes that opaque data. Any such application SHOULD be properly isolated from the RADIUS server, and SHOULD run with minimal privileges. Any potential vulnerabilities in that application will then have minimal impact on the security of the system as a whole. I've also added text in the security section referencing 2.1.4. > Section 3.1.3 ... > Can you expand "PEC" on first use? Done in Section 2.2. > Rehosting may also require changes to the RADIUS data model > which will affect implementations that do not intend to support the > SDO specifications > > Period needed at the end of the sentence. Fixed, thanks. > > IDNITs check ... > ---------------------------------------------------------------------------- > == Using lowercase 'not' together with uppercase 'MUST' is not an accepted > usage according to RFC 2119. Please use 'MUST NOT' (if that is > what you > mean). Text changed to MUST NOT. > -- Looks like a reference, but probably isn't: '8' on line 1191 It's in a quote from another document. > == Unused Reference: 'RFC4005' is defined on line 795, but no explicit > reference was found in the text > '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, > "Diamete...' That reference can be deleted. > -- No information found for draft-ietf-radext-extended-attributes - is the > name correct? Yes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Dec 2007 01:43:02 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_" From: Bernard Aboba To: Subject: Review of draft-ietf-radext-design-01.txt Date: Sun, 2 Dec 2007 17:41:27 -0800 MIME-Version: 1.0 --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-radext-design-01.txt =20 Designation =20 I thought that this document was a BCP, no? -01 states thatit is "Standard= s Track".=20 =20 Sections 1 and 1.1 =20 There is some overlap in coverage. My recommendation is to reorganizethe d= iscussion as follows: =20 "1. Introduction This document provides guidelines for the design of RADIUS attributes = both within the IETF as well as within other Standards Development Organi= zations (SDOs). By articulating RADIUS design guidelines, it is hoped t= hat this document will encourage the development and publication of high = quality RADIUS attribute specifications. The advice in this document will not be helpful unless it is put to use.= As with "Guidelines for Authors and Reviewers of MIB Documents" [RFC= 4181], it is expected that this document will enable authors to check the= ir document against the guidelines prior to requesting a review (such an = "Expert Review" described in [RFC3575]). Similarly, it is hoped that thi= s document will be of use to reviewers (such as WG participants or the AA= A Doctors) in improving the consistency of reviews. =20 In order to meet these objectives, this document needs to cover not on= ly the science of attribute design, but also the art. As a result, in ad= dition to covering the most frequently encountered issues, this document = attempts to provide some of the considerations motivating the guidelines. =20 In order to characterize current attribute usage, both the basic and c= omplex data types defined in the existing RADIUS RFCs are reviewed, toget= her with the ad-hoc extensions to that data model that have been used in = Vendor-Specific Attributes. =20 1.1. Applicability As RADIUS has become more widely accepted as a management protocol, it= s usage has become more prevalent, both within the IETF as well as within= other SDOs. Given the expanded utilization of RADIUS, it has become app= arent that requiring SDOs to accomplish all their RADIUS work within the= IETF is inherently inefficient and unscalable. By articulating guidelines for RADIUS attribute design, this document = enables SDOs to design their own RADIUS attributes within the Vendor-Sp= ecific Attribute (VSA) space, seeking review from the IETF. In order enab= le IETF review of SDO RADIUS attribute specifications, the authors recomm= end: =20 * Development of a program to encourage SDOs to make their RADIUS = attribute specifications publicly available; * Review of IETF and SDO specifications according to the guideli= nes proposed in this document; =20 The advice in this document applies to attributes used to encode data.= RADIUS protocol changes, or specification of attributes that can be use= d to provide new RADIUS commands (such as Service-Type) are out of scope.= Since protocol changes require greater expertise and deeper review, suc= h changes should not be undertaken outside the IETF and when handled with= in the IETF require "IETF Consensus" for adoption, as noted in [RFC3575] = Section 2.1. =20 As with protocol changes, this document does not provide guidance to d= ocument authors seeking to change the RADIUS operational model. While RAD= IUS server implementations may keep state, the RADIUS protocol is statele= ss, although information may be passed from one protocol transaction to a= nother via the State Attribute. As a result, documents which require sta= teful protocol behavior without use of the State Attribute are inherently= incompatible with RADIUS as defined in [RFC2865], and need to be redesig= ned. See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use = of the State Attribute." =20 BTW, I would also suggest a statement that this document does not applyto n= ew uses of RADIUS (e.g. uses of RADIUS that go beyond conversationsbetween = a RADIUS client and server).=20 Section 2.1.1 IPv6 address 128 bit value, most significant octet first. IPv6 prefi= x 8 bits of reserved, 8 bits of prefix length, up to 12= 8 bits of value, most significant octet first. Judging by some recent specifications, there appears to be some confusionbe= tween these two types. Should an IPv6 address type always be used torepres= ent an address (as opposed to the prefix type). If so, you mightstate this= explicitly using some normative language.=20 =20 integer64 64 bit unsigned value, most significant octet first. =20 I believe that this type has also been used to express an IPv6 Identifierva= lue, no?=20 =20 Section 2.1.2 =20 " New attributes SHOULD NOT use this tagging method because of the limit= atations described above." =20 limitatations -> limitations =20 Section 2.1.3 =20 The only other exception to the recommendation against complex types i= s for types that can be treated as opaque data by the RADIUS server. For = example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 cont= ains a complex data type that is an EAP packet. Since these complex type= s do not need to be parsed by the RADIUS server, the issues arising from = policy language limitations do not arise. Similarly, since attributes of = these complex types can be configured on the server using a data type of = String, dictionary limitations are also not encountered. Section A.1 bel= ow includes a series of checklists that may be used to analyze a design f= or RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types. =20 I think it may be worth expanding this discussion of opaque data typessomew= hat and covering additional implications, security related onesin particula= r. In general, RADIUS servers are highly valued targets sothat the introdu= ction of complex data types brings withit the potential for introduction of= security vulnerabilities such asbuffer overflows. An extreme outcome woul= d be a vulnerability thatwould allow an attacker to take over the RADIUS se= rver. =20 The use of attributes representing opaque data does not reduce thisthreat, = it merely moves it from the RADIUS server to an applicationthat consumes RA= DIUS attributes. Should this application not beproperly isolated, or run w= ith extended privileges, then the introduction of new opaque data types (or= changes in the formatof existing opaque types) may introduce serious new s= ecurity vulnerabilities.=20 =20 Section 3.1.3 =20 This change control can be obtained by requesting a PEC from the Inter= net Assigned Number Authority (IANA), for use as a Vendor-Id within a Ven= dor-Specific attribute. =20 =20 Can you expand "PEC" on first use?=20 =20 Rehosting may also require changes to the RADIUS data model which will af= fect implementations that do not intend to support the SDO specifications Period needed at the end of the sentence.=20 =20 IDNITs check------------- The tool found a few warnings: =20 idnits 2.05.02=20 tmp/draft-ietf-radext-design-01.txt: - Failure fetching the file, proceedin= g without it.) Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: = --------------------------------------------------------------------------= -- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: = ---------------------------------------------------------------------------= - No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: ------= ---------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ------------------------------------------------= ---------------------------- =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not an acc= epted usage according to RFC 2119. Please use 'MUST NOT' (if that is w= hat you mean). Found 'MUST not' in this paragraph: Th= is Attribute is available to allow vendors to support their own extende= d Attributes not suitable for general usage. It MUST not affect the op= eration of the RADIUS protocol. Checking references for intended status: Proposed Standard -------------= --------------------------------------------------------------- (See RFC 3967 for information about using normative references to = lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 1191 'The = Text field consists of UTF-8 encoded 10646 [8] characters....' =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no explici= t reference was found in the text '[RFC4005] Calhoun, P., Zorn, G.,= Spence, D., and D. Mitton, "Diamete...' -- No information found for draft-ietf-radext-extended-attributes - is th= e name correct? Summary: 0 errors (**), 2 warnings (=3D=3D), 2 comments (--).---------= -----------------------------------------------------------------------= --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-radext-design-01.txt
 
Designation
 
I thought that this document was a BCP, no?  -01 states that
it is = "Standards Track". 
 
Sections 1 and 1.1
 
There is some overlap in coverage.  My recommendation is to reorganize=
the discussion as follows:
 
"1.  Introduction
   This document provides guidelines for the design of RADIUS att= ributes
   both within the IETF as well as within other Standa= rds Development
   Organizations (SDOs).  By articulating= RADIUS design guidelines, it
   is hoped that this document = will encourage the development and
   publication of high qual= ity RADIUS attribute specifications.
   The advice in this document will not be helpful unless it is p= ut to use. 
   As with "Guidelines for Authors and Revie= wers of MIB Documents"
   [RFC4181], it is expected that this = document will enable authors to
   check their document agains= t the guidelines prior to requesting a
   review (such an "Exp= ert Review" described in [RFC3575]).  Similarly,
   it is= hoped that this document will be of use to reviewers (such as
 &nb= sp; WG participants or the AAA Doctors) in improving the consistency of
=    reviews.
 
   In order to meet these objectives, this document needs to cove= r not
   only the science of attribute design, but also the ar= t.  As a result,
   in addition to covering the most freq= uently encountered issues, this
   document attempts to provid= e some of the considerations motivating
   the guidelines.
 
   In order to characterize current attribute usage, both the bas= ic and
   complex data types defined in the existing RADIUS RF= Cs are reviewed,
   together with the ad-hoc extensions to tha= t data model that have been
   used in Vendor-Specific Attribu= tes.
 
1.1.  Applicability
   As RADIUS has become more widely accepted as a management prot= ocol,
   its usage has become more prevalent, both within the = IETF as well as
   within other SDOs.  Given the expanded= utilization of RADIUS,
   it has become apparent that requiri= ng SDOs to accomplish all their
   RADIUS work within the IET= F is inherently inefficient and unscalable.
   By articulating guidelines for RADIUS attribute design, this d= ocument
   enables SDOs to design their own RADIUS attributes= within the
   Vendor-Specific Attribute (VSA) space, seeking= review from the IETF.
   In order enable IETF review of SDO R= ADIUS attribute specifications,
   the authors recommend:
 
      * Development of a program to encourage SDOs= to make their RADIUS
      attribute specifica= tions publicly available;
      * Review of IETF and SDO specifications acco= rding to the
      guidelines proposed in this = document;
 
   The advice in this document applies to attributes used to enco= de
   data.  RADIUS protocol changes, or specification of= attributes that
   can be used to provide new RADIUS commands= (such as Service-Type) are
   out of scope.  Since proto= col changes require greater expertise and
   deeper review, su= ch changes should not be undertaken outside the IETF
   and wh= en handled within the IETF require "IETF Consensus" for
   ado= ption, as noted in [RFC3575] Section 2.1.
 
   As with protocol changes, this document does not provide guida= nce to
   document authors seeking to change the RADIUS operat= ional model.
   While RADIUS server implementations may keep s= tate, the RADIUS
   protocol is stateless, although informatio= n may be passed from one
   protocol transaction to another vi= a the State Attribute.  As a
   result, documents which r= equire stateful protocol behavior without
   use of the State = Attribute are inherently incompatible with RADIUS as
   define= d in [RFC2865], and need to be redesigned.
   See [RFC5080] Section 2.1.1 for a more in-depth discussion of = the use
   of the State Attribute."
 
BTW, I would also suggest a statement that this document does not apply
= to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations
= between a RADIUS client and server).
Section 2.1.1

   IPv6 address   128 bit value, most significant o= ctet first.
   IPv6 prefix    8 bits of reserve= d, 8 bits of prefix length, up to
      &n= bsp;           128 bits o= f value, most significant octet first.

Judging by some recent specifications, there appears to be some confusi= on
between these two types.  Should an IPv6 address type always be = used to
represent an address (as opposed to the prefix type).  If s= o, you might
state this explicitly using some normative language.
 
   integer64      64 bit unsigned value,= most significant octet first.
 
I believe that this type has also been used to express an IPv6 Identifiervalue, no?
 
Section 2.1.2
 
"  New attributes SHOULD NOT use this tagging method because of the   limitatations described above."
 
limitatations -> limitations
 
Section 2.1.3
 
   The only other exception to the recommendation against complex= types
   is for types that can be treated as opaque data by t= he RADIUS server.
   For example, the EAP-Message attribute, d= efined in [RFC3579] Section
   3.1 contains a complex data typ= e that is an EAP packet.  Since these
   complex types do= not need to be parsed by the RADIUS server, the
   issues ari= sing from policy language limitations do not arise.
   Similar= ly, since attributes of these complex types can be configured
 &nbs= p; on the server using a data type of String, dictionary limitations are   also not encountered.  Section A.1 below includes a seri= es of
   checklists that may be used to analyze a design for R= ECOMMENDED and
   NOT RECOMMENDED behavior in relation to comp= lex types.
 
I think it may be worth expanding this discussion of opaque data types
s= omewhat and covering additional implications, security related ones
in p= articular.  In general, RADIUS servers are highly valued targets sothat the introduction of complex data types brings with
it the potentia= l for introduction of security vulnerabilities such as
buffer overflows.=   An extreme outcome would be a vulnerability that
would allow an a= ttacker to take over the RADIUS server.
 
The use of attributes representing opaque data does not reduce this
thre= at, it merely moves it from the RADIUS server to an application
that con= sumes RADIUS attributes.  Should this application not be
properly i= solated, or run with extended privileges, then the
introduction of new = opaque data types (or changes in the format
of existing opaque types) ma= y introduce serious new security
vulnerabilities.
 
Section 3.1.3
 
   This change control can be obtained by requesting a PEC from t= he
   Internet Assigned Number Authority (IANA), for use as a = Vendor-Id
   within a Vendor-Specific attribute. 
 
Can you expand "PEC" on first use?
 
Rehosting may also require changes to the RADIUS data model
  = which will affect implementations that do not intend to support the
&nb= sp;  SDO specifications

Period needed at the end of the sentence.
 

IDNITs check
-------------
The tool found a few warnings:
 
idnits 2.05.02
tmp/draft-ietf-radext-design-01.txt:
 - Failure fetching the file, = proceeding without it.)
  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4= 748:
  ------------------------------------------------------------= ----------------
     No issues found here.
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  -= ---------------------------------------------------------------------------=
     No issues found here.
  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  -------------= ---------------------------------------------------------------
     No issues found here.
  Miscellaneous warnings:
  ----------------------------------= ------------------------------------------
  =3D=3D Using lowercase 'not' together with uppercase 'MUST' is not a= n accepted
     usage according to RFC 2119.  P= lease use 'MUST NOT' (if that is what you
     mean)= .
    
     Found 'MUST not'= in this paragraph:
    
    = ; This Attribute is available to allow vendors to support their own
&nbs= p;    extended Attributes not suitable for general usage.&nb= sp; It MUST not affect
     the operation of the RAD= IUS protocol.

  Checking references for intended status: Proposed Standard
&n= bsp; ----------------------------------------------------------------------= ------
     (See RFC 3967 for information about using normativ= e references to
     lower-maturity documents in RFC= s)
  -- Looks like a reference, but probably isn't: '8' on line 1191
&= nbsp;    'The Text field consists of UTF-8 encoded 10646 [8]= characters....'
  =3D=3D Unused Reference: 'RFC4005' is defined on line 795, but no ex= plicit
     reference was found in the text
 = ;    '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mi= tton, "Diamete...'
  -- No information found for draft-ietf-radext-extended-attributes - = is the
     name correct?

     Summary: 0 errors (**), 2 warnings (=3D=3D), 2= comments (--).
--------------------------------------------------------= ------------------------
= --_60a8d9c3-4f9e-46f3-9371-bd3b267b2210_-- -- to unsubscribe send a message to radiusext-request@ops.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, 03 Dec 2007 00:35:48 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_" From: Bernard Aboba To: Subject: Updated agenda for IETF 70 Date: Sun, 2 Dec 2007 16:33:48 -0800 MIME-Version: 1.0 --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG AgendaWednesday December 5, 20079 AM - 11:30 AM, Cypress = Room 9 AM - 9:10 AM Preliminaries Blue Sheets Note Takers Jabber Scri= be Agenda bashing Document status Documents completing RADEXT WG last c= all (10 minutes) 9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKokhttp:/= /www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt 9:30 - 9:40 A= M RADIUS Authorization for NAS Management, David Nelsonhttp://www.ietf.or= g/internet-drafts/draft-ietf-radext-management-authorization-01.txt =20 WG Work items 9:40 - 9:50 Extended RADIUS Attributes, Glen Zornhttp://www.i= etf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt Pre-= WG Work Item Review 9:50- 10:00 IEEE 802 Attributes, Bernard Abobahttp://ww= w.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt =20 10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkarhttp://ww= w.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01.txt RADIUS Crypto-Agility (50 minutes) 10:10 - 10:25 RADEXT Crypto-agility Requ= irements and Selection Process, David Nelson 10:25 - 10:35 RADIUS + DTLS (A= lan DeKok)http://www.watersprings.org/pub/id/draft-dekok-radext-dtls-00.txt= 10:35 - 10:50 RADIUS Crypto-agility (Joe Salowey)http://www.watersprings.o= rg/pub/id/draft-zorn-radius-keywrap-13.txthttp://www.watersprings.org/pub/i= d/draft-zorn-radius-encattr-06.txt 10:50 - 11:10 Discussion Miscellaneous (= 10 minutes) 11:10 - 11:20 RADSEC (Stig Venaas)http://www.watersprings.org/p= ub/id/draft-winter-radsec-00.txt Discussion & Wrapup (10 minutes)= --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG Agenda
Wednesday December 5, 2007
9 AM - 11:30 AM, = Cypress Room
 
9 AM - 9:10 AM Preliminaries
   Blue= Sheets
   Note Takers
   Jabber Scribe
 =   Agenda bashing
   Document status
 
Document= s completing RADEXT WG last call (10 minutes)
 
9:20 - 9:30 AM&n= bsp; RADIUS Design Guidelines, Alan DeKok
http://www.ietf.org/inter= net-drafts/draft-ietf-radext-design-01.txt
 
9:30 - 9:40 AM&= nbsp;  RADIUS Authorization for NAS Management, David Nelson
http://www.ietf.org/internet-drafts/draft-ietf-radext-mana= gement-authorization-01.txt
 
WG Work items
 
9:40 - 9:50 Extended RADIUS Attributes, Glen Zor= n
http://www.ietf.org/internet-drafts/draft-ietf-radex= t-extended-attributes-00.txt
  
Pre-WG Work Item Revie= w
 
9:50- 10:00 IEEE 802 Attributes, Bernard Aboba
http://= www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
 
10:00 - 10:10 RADIUS support for EAP Re-authentication, K. Gaonkar
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-01= .txt
RADIUS Crypto-Agility (50 minutes)
 
10:10 - 10:25 RADEXT Crypto= -agility Requirements and Selection Process, David Nelson
 
10:2= 5 - 10:35 RADIUS + DTLS (Alan DeKok)
http://www.watersprings.org/pub/= id/draft-dekok-radext-dtls-00.txt
 
10:35 - 10:50 RADIUS Cry= pto-agility (Joe Salowey)
http://www.watersprings.org/pub/id/draft-= zorn-radius-keywrap-13.txt
http://www.watersprings.org/pub/id/d= raft-zorn-radius-encattr-06.txt
 
10:50 - 11:10 Discussion 
Miscellaneous (10 minutes)
 
11:10 - 11:20 RADSEC (S= tig Venaas)
http://www.watersprings.org/pub/id/draft-winter-radsec-00.txt=
 
Discussion & Wrapup (10 minutes)
= --_b5e76d51-be6a-4d63-afc6-d42bb2bc5a7a_-- -- to unsubscribe send a message to radiusext-request@ops.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, 01 Dec 2007 19:23:01 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_c2a0ec02-549c-4ff9-833b-ea517d635af3_" From: Bernard Aboba To: Subject: Please send slides Date: Sat, 1 Dec 2007 11:21:45 -0800 MIME-Version: 1.0 --_c2a0ec02-549c-4ff9-833b-ea517d635af3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a last call for agenda items for IETF 70. If you are not on the ag= enda and would like to present, please send email.=20 If you are on the agenda please confirm your availability and send slides A= SAP. --_c2a0ec02-549c-4ff9-833b-ea517d635af3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a last call for agenda items for IETF 70.  If you are not on t= he agenda and would like to present, please send email.

If you are = on the agenda please confirm your availability and send slides ASAP.
 = --_c2a0ec02-549c-4ff9-833b-ea517d635af3_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: