|
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 <draft-ietf-radext-rfc4590bis-02.txt> 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 > > <draft-ietf-radext-rfc4590bis-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/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 <draft-ietf-radext-rfc4590bis-02.txt> 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 <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:> > 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> <draft-ietf-radext-rfc4590bis-02.txt>> > 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> > <draft-ietf-radext-rfc4590bis-02.txt>> > > 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> > > <draft-ietf-radext-rfc4590bis-02.txt>> > > > > > >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 <draft-ietf-radext-rfc4590bis-02.txt>> 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:> > > > > > >>> > > > > > >><snip>> > > > > > >> 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.> > > > > > >></snip>> > > > > > >>> > > > > > >>However when examing 2617 in more detail, using " around the> > > directive> > > > > > >> > > > > > >>names would be more consistent with that draft. For example> > > this> > > > > > >would> > > > > > >>become:> > > > > > >>> > > > > > >><snip more like RFC 2617>> > > > > > >> 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.> > > > > > >></snip more like RFC 2617>> > > > > > >>> > > > > > >>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> > > > > > >>>> > > > > > > |