[ietf-nntp] authinfo-02 changes

[Ken Murchison]

Charles Lindsey wrote:
> In <40EACA6F.5030703 at oceana.com> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>Attached are the changes I just made to the AUTHINFO draft based on 
>>comments from the list and those I received privately.  I did a diff 
>>against the nroff rather than the generated text, since the nroff isn't 
>>subject to changes in page breaks.  Please review and let me know if 
>>I've missed anything.
> 
> 
>>@@ -338,8 +342,7 @@
>>The AUTHINFO PASS command permits the client to use a clear-text
>>password to authenticate.  A compliant implementation MUST NOT
>>implement this mechanism without also implementing support for TLS
>>-[NNTP-TLS] or the DIGEST-MD5 SASL [DIGEST-MD5] authentication
>>-mechanism.  Use of this mechanism without an active strong encryption
>>+[NNTP-TLS].  Use of this mechanism without an active strong encryption
>>layer is deprecated as it exposes the user's password to all parties
>>on the network between the client and the server.  Any implementation
>>of this mechanism SHOULD be configurable to disable it unless a strong
> 
> 
> I am not sure I like this change.

The reason I removed DIGEST-MD5 from this part of the text was that it 
was (correctly) pointed out to me by Alexey Melnikov that DIGEST-MD5 has 
no relationship with USER/PASS whatsoever.

DIGEST-MD5 is still a mandatory to implement mechanism as stated in the 
SASL section.

If anyone has suggested text better that what was previously there, I'm 
willing to look at it.

> OK, you have removed any detailed requirements on the format of the
> authorization identity, which is fine by me, but now your text launches
> straight into a description of how that identity is to be included in an
> audit trail and/or inserted into the headers of the article. But at this
> point in your text there is no indication to the reader of what the
> authorization identity is, or where it came from.
> 
> I think therefore you need some text of the form:
> 
> "Once authenticated, the authorization identity generated by the SASL
> exchange (see section 2.2.2 above) SHOULD be included in an audit-trail
> associating ....."

Right.  I did a last minute cut of the existing text without checking 
the surrounding context.  I'll add text similar to what you suggest.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp