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

[Clive D.W. Feather]

I've now had time to work through the draft. I'm still at the "test the
concepts" stage rather than the "copy-editing" stage.

"#3" means "paragraph 3".

Section 2#3: I don't like the separate SASL response to LIST EXTENSIONS.
This implies that there are two separate extensions, and there aren't. It
just doesn't fit the @@@@. Instead of that, what's wrong with:

    AUTHINFO USER SASL:DIGEST-MD5,GSSAPI,PLAIN,EXTERNAL

?

Section 2#4: you can't enforce that MUST NOT, because the client might not
have done a LIST EXTENSIONS. Rather, if the server doesn't support any
AUTHINFO commands then AUTHINFO should return 500. But it's not clear to me
what "complies to this draft" means if neither form is supported.

I don't think we can sensibly legislate for unstandardised versions of
AUTHINFO; better just to leave this whole paragraph out.

Section 2#8: as elsewhere, I object to the "SHOULD use LIST EXTENSIONS
first" concept. A client should always be able to "suck it and see",
testing the response code.

I would drop the bit about 480, which contradicts the base document. Apart
from QUIT, a server *can* give 480 to anything, including HELP. At least,
the client shouldn't fall over if it gets a 480, and we've previously
suggested 480-to-everything as meaning "you need to log in".

Section 2#9: the second part needs rewording. This is a matter for
individual authentication mechanisms. In particular, a server MUST cope
with AUTHINFO PASS after AUTHINFO USER was rejected, while for AUTHINFO
SASL the continuation will be seen as a syntax error. I would leave things
to the individual commands.

Section 2.1: there's no reason to forbid pipelining.

Section 2.1.1: drop the generic responses.

Section 2.1.2: I think the response code handing is wrong. As I see it,
you've got several possible responses:
    [A] - you are now authenticated with these credentials
    [B] - authentication credentials rejected, you are not authenticated
    [C] - you were already authenticated with previous credentials, these
          new ones have been ignored
    [D] - I'm not allowing AUTHINFO USER/PASS in this state

When a client is not authenticated (so other commands are issuing 480
responses), then [A] or [B] apply. I suppose [D] might happen, but I can't
see when: if a privacy layer is needed, generic code 483 applies, and if
AUTHINFO USER is noever supported then generic code 501 applies.

When a client *is* authenticated, then the server can choose:
* never allow AUTHINFO USER again, [D] applies;
* allow AUTHINFO USER, in which case any of [A], [B], and [C] can happen
  ([B] if the server forgets the previous authentication, [C] if it doesn't).

I would suggest that [D] is clearly 502, [A] is 281, and [B] and [C] need
new (distinct) codes. [B] should be 481, and I would go for a 28x code
for [C] (though I wouldn't argue if you said it should be 48x).

I think that the ordering requirements *in the specification* are too
strict. For example, a server could permit PASS before USER if it wants, or
even use only PASS (for example if it's deriving the user name from the
connecting IP address). So I would suggest something like this instead of
paragraph 4 and the first bit of paragraph 1:

    The AUTHINFO USER and AUTHINFO PASS commands are used to present
    clear text credentials to the server. These credentials consist of
    a username, a password, or both (the distinction is that a password
    is expected to be kept secret while a username is not; this does
    not directly affect the protocol but may have an impact on user
    interfaces). The former is supplied through the AUTHINFO USER
    command and the latter through the AUTHINFO PASS command.

    If the server requires only a username, it MUST NOT give a 381 response
    to AUTHINFO USER and MUST give a 482 response to AUTHINFO PASS.

    If the server requires only a password, it MUST give a 381 response to
    AUTHINFO USER and MUST NOT give a 381 or 482 response to AUTHINFO PASS.

    If the server requires both credentials, it needs to associate the
    two. It will need to cache one until the other is received. The server
    MAY require the username to be presented first (in other words, not
    caching passwords) and MAY require the two AUTHINFO commands to be
    consecutive (in other words, only caching data until the next command).
    Where it does so:
    - response 381 means that the argument to this command was cached
    - response 482 means that the argument to this command was not cached
    and both these responses indicate that the other credential is still
    needed.

The server MUST NOT close the connection after a 502. If it wants to close
the connection, 400 is the correct response. Furthermore, "after a short
delay" is worse; it implies I'm allowed a couple more commands.

Surely the MUST NOT in #3 should be SHOULD NOT?

I'm not clear that there's a benefit to requiring UTF-8. Surely it's better
to treat the arguments as opaque data? White space can be largely dealt
with by adding ... to the command syntax, making it clear in the text that
this is a multi-word argument rather than multiple separate values.

Section 2.2.1: again, drop the generic responses. The responses should be
split by phase, as with POST.

Section 2.2.2:

I don't like the analogy in #3. Just delete it and merge #3 to #5 into one
paragraph.

501 is the wrong response in #5. This isn't a syntax error, it's a specific
argument meaning "I don't want to carry on". What you need is the same [A]
to [D] response codes discussed in 2.2.1. So following a "*" the response
is [B] (I suggested 481) or [C].

#6 is just conceptually wrong, since it will look to a generic parser like
no arguments (our generic syntax allows trailing junk). Rather, use "*" for
this case.

501 is the wrong response in #9: it's not a syntax error, it's a "you're
doing stuff in the wrong order" error. I suggest that this is another use
for 482.

Can I suggest that the line length problem (#7 and #11) could be solved by
allowing a trailing "\" to mean "this base64 string is continued on the
next line"? So:

    [C] AUTHINFO SASL PLAIN 2349uwEior928vtr\
    [C] 23049vneIOrvo53xcvw3482
    [S] 383 23vxifaignPDNOIsdurw234525\
    [S] sajkLHKHLHFKLHlshd2334==

(the syntax would be easier if the split has to be at a 4-character
boundary; I haven't used a space because that would make responses be
variable numbers of words).

I would suggest that #12, #20 and perhaps #22 and #23 belong in a separate
"interaction with [SASL]" sub-section.

Rather than two separate responses (281 and 283), wouldn't it be better if
the final success response had a "=" argument if there's no data returned?

I don't understand the thinking behind #18 at all. Can you explain?

I think #21 belongs in the generic stuff, before section 2.1.

Section 2.2.3: is 501 the right response for AUTHINFO SASL EXAMPLE? I think
503 is better. That allows the client to distinguish "doesn't do SASL" from
"doesn't do EXAMPLE".

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |