[ietf-nntp] authinfo-02 changes

[Charles Lindsey]

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.

Suppose some server wants to move his users to SASL, but has no need
whatsoever to implement TLS - ever (this will be a common scenario, I
think).

But he realises the changeover is going to take a long time, so he needs
to allow them to continue to use AUTHINFO USER/PASS for some months to
give them time to acquire the necessary software at their ends.

For sure, he provides the SASL DIGEST-MD5 method, and maybe some other
SASL mechanisms too.

Under the old wording that was fine. He was covered (provided he did not
allow the changeover to spin out for too long).

But, under the new text, he is REQUIRED to implement the TLS mechanism
even though he does not want it, has no intention of using it, and for
sure his clients are not going to use it to cover their usage of AUTHINFO
USER/PASS because they do not possess TLS tools (and are only adopting
SASL tools under pressure). If the use of unencrypted AUTHINFO USER/PASS
has been good enough for those clients for the past 5 years, then surely
another few months is not going to make any difference, and at the end of
that time the server is going to disable the use of AUTHINFO USER/PASS
anyway, at which point he is free to remove the TLS mechanism (which
nobody has ever actually used).

It seems crazy to me. What has been gained? (What will actually happen, of
course, is that the server will just violate the standard over those few
months).



>@@ -831,30 +834,12 @@
> .LP
> 5. Authentication Tracking/Logging
> .IP
>-This section contains implementation suggestions and
>-notes of best current practice, and does not specify further network
>-protocol requirements.  
>-
>-When authentication succeeds, the server will create an "identity" (the
>-syntax resembles that of an email address) for the client using a
>-technique such as the following (note that when using SASL, "username"
>-corresponds to the authorization identity), for example:
>+This section contains implementation suggestions and notes of best
>+current practice, and does not specify further network protocol
>+requirements.
> 
>-.in 9
>-.ti 5
>-(1) Lookup the supplied username in an implementation-specific database
>-or directory to determine the primary email address for that user.
>-.ti 5
>-(2) Use the username directly as the email address if it is fully
>-qualified (i.e., includes "@hostname"), otherwise append a configured
>-"default domain" based on the IP address the client connected to.
>-.ti 5
>-(3) Use the username followed by "@" and then the result of a reverse
>-DNS lookup on the client's IP address.  If the reverse lookup fails, the
>-domain literal syntax defined in SMTP [SMTP] is appropriate.
>-.IP
> Once authenticated, the server SHOULD be configurable to generate an
>-audit trail associating the authentication identity with any articles
>+audit trail associating the authorization identity with any articles
> supplied during a POST operation, and this configuration SHOULD be the
> default.  This may be accomplished, for example, by inserting headers in
> the posted articles, or by a server logging mechanism.  The server MAY

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 ....."

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5