Re: FW: AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE

[Mike McCauley <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 
> > <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> > > > > > >>>> > > > > > >

-- 
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: <http://psg.com/lists/radiusext/>