[ietf-nntp] Re: I-D ACTION:draft-ietf-nntpext-authinfo-00.txt

[Peter Robinson]

Jeffrey M. Vinocur <jeff at litech.org> wrote:

| Surely someone has some sort of issues to bring up for discussion...

Well, I have some minor comments.  I don't know much about SASL so these
are mostly about the AUTHINFO USER/PASS.

> 1. Introduction
> 
>      Although NNTP [NNTP] has traditionally provided public access to
>      newsgroups, authentication is often useful, for example to control
>      resource consumption, to allow abusers of the POST command to be
>      identified, and restrict access to "local" newsgroups.
                      ^ to

[AUTHINFO USER/PASS]
>      [...] Due to their insecurity and
>      ubiquity they are formalized in this specification, but only for
>      use in combination with appropriate protection layers.

Is a 'protection layer' some kind of jargon defined elsewhere?  It seems
clumsy.  What about 'an appropriate encryption layer' if that's the
intent, or just 'security layers'?

> 2. The AUTHINFO Extension

>      [...] The "USER" argument
>      MUST NOT be advertised unless a strong encryption layer (e.g. TLS
>      [NNTP-TLS]) is in use or backward compatibility dictates otherwise.

By saying "... MUST NOT be *advertised* ...", this could be read as
allowing a server to lie by omission in LIST EXTENSIONS (i.e. to support
AUTHINFO USER but not advertise it).  Is that the intent?

>      The server may list the AUTHINFO capability with no arguments,
>      which indicates that it complies with this draft and does not per-
>      mit any authentication commands in its current state.  In this
>      case, the client MUST NOT attempt to utilize any AUTHINFO commands,
>      [...]

So a client can sometimes tell that authentication is definitely
inappropriate.  That's a welcome improvement.

>      An NNTP server MAY respond to any client command other than HELP,
>      LIST EXTENSIONS, AUTHINFO, or QUIT with a 480 response.

This doesn't explicitly say that the server can't respond with 480 for
those four commands, though I assume that's the intent.  Certainly
responding with 480 to AUTHINFO could cause a serious problem for a
badly written client, but doing so for the others would also be pretty
stupid.

[...]

>      A client MAY attempt the first step of authentication at any time
>      during a session to acquire additional privileges without receiving
>      a 480 response [...]

This is a welcome improvement documenting widespread existing practise.

But how about

'...without first receiving a 480 response...'?
            ^^^^^
to emphasize to a first-time reader who doesn't understand 480 out of
context that we're talking about the response to a previous command, not
the response to a client's "first step of authentication".

>      [...] (this is a change to the previous specification in
>      [NNTP-COMMON]).

Is it necessary to include this remark?  "[NNTP-COMMON]" wasn't exactly
clear on this point, and many client and servers already do this
perfectly happily.  In any case any client author reading this spec will
be prepared for it to fail.

[...]

>      If a client attempts to reauthenticate, the server may permit the
                                                          MAY ?
>      attempt, or may return 502 response indicating that the new authen-
                   MAY ?
>      tication data is rejected by the server.

Is the server allowed to close the connection immediately in this case?

AIUI 502 in this context has its generic meaning of 'not possible on
this connection, may be possible on a new connection' and not
'permission denied, go away' as it usually means in this document.  

This draft's wording only hints that getting a 502 after trying to
*re*authenticate might mean that the client should try again.  You could
add "The client MAY then attempt to reauthenticate on a new connection."
or words to that effect.

> 2.1. AUTHINFO USER/PASS

[...]

>      The AUTHINFO USER command is used to identify a specific entity to
>      the server using a simple username.  Once sent, the server will
>      cache the username and may send a 381 response requesting the pass-
>      word associated with that username.  Alternatively, the server may
>      immediately return a 281 response indicating that no password is
>      required.

In this paragraph and further on, there are lots of "may"s and "will"s.
Shouldn't they generally be "MAY"s and "SHOULD"s or "MUST"s etc.?

>      Should the server request a password using the 381
>      response, the client will send AUTHINFO PASS followed by a password
>      [...]

What should the client do if it was expecting 281 after AUTHINFO USER?
AUTHINFO PASS *?  '*' ought not to be anyone's password and that would
be inline with SASL further down.

This 'username only' authentication is interesting functionality.  Is it
in use at all?  In principle it's just as secure as AUTHINFO USER+PASS
if combined with encryption, but if the client thinks of the AUTHINFO
USER parameter as a username rather than a password, it might store it
in logs in the clear and echo it on screen etc. which would be bad.
This functionality does complicate things a little.  Can it be dropped?

I don't have time to go through SASL right now, but it is good that
these things being formalised.

Peter