[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> NOW AVAILABLE
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: <http://psg.com/lists/radiusext/>