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

Russ Allbery rra at stanford.edu
Mon May 17 04:05:46 PDT 2004


Clive D W Feather <clive at demon.net> writes:

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

Agreed.

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

I would just change the MUST not to a SHOULD NOT.

> 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 think we should distinguish between SASL and USER/PASS here.  Clients do
use USER/PASS without LIST EXTENSIONS first.  I think it's valid to ask
clients not to continue to do that, since why expose the username if one
doesn't have to, but the SHOULD level sounds fine to me.

On the other hand, I think the client MUST send LIST EXTENSIONS before
doing AUTHINFO SASL.  After all, determining the list of SASL mechs is
part of the protocol.

So how about removing 2#4 completely and replacing the sentence at the end
of 2#8 with:

    A client intending to use AUTHINFO SASL MUST issue the LIST EXTENSIONS
    command to obtain the available authentication mechanisms before
    attempting authentication.  A client SHOULD issue LIST EXTENSIONS
    before attempting AUTHINFO USER/PASS to see if it is supported.

Along similar lines, the following paragraph from 2.2.2 should be struck
completely:

    The client SHOULD therefore send an LIST EXTENSIONS command as the
    first command after a successful SASL negotiation which results in
    the enabling of a security layer.

If the client doesn't intend to use any extensions, there's no reason why
it should bother with LIST EXTENSIONS after authentication.

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

I think we need to forbid it for QUIT, AUTHINFO, and LIST EXTENSIONS for
protocol reasons.  The client clearly shouldn't fall over no matter what
the server does, but that's a quality of implementation issue.

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

I disagree.  We forbid pipelining because the client MUST NOT send the
user's password if the server returns 502 in response to AUTHINFO USER.

> Section 2.1.1: drop the generic responses.

I think the 503 responses listed here are wrong regardless.  It looks like
503 is being used for what 403 is for.

Respnoses are otherwise discussed elsewhere.

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

innd does allow AUTHINFO PASS without AUTHINFO USER, but that's innd's
bizarre authentication that's rarely used and should be replaced
completely.

I really do not want to add any complexity at all to support this.  No
regular client expects or wants a server to accept these commands out of
order.  I'd prefer to just require that they always be given as USER and
then PASS.

> The server MUST NOT close the connection after a 502. If it wants to
> close the connection, 400 is the correct response.

I don't think we can get away with that here.

INN has been returning 502 in this situation since the beginning of time,
and has never returned 400 here (or, for that matter, anywhere other than
as the initial greeting).  If we switch suddenly to 400 from 502 here, I'm
afraid that we're going to cause interoperability problems (in particular,
clients popping up their generic "unknown response from server" errors
rather than the tailored "bad password" ones).

The server can close the connection at any time anyway.

> Furthermore, "after a short delay" is worse; it implies I'm allowed a
> couple more commands.

The "after a short delay" has got to go; that's the wrong way to get there
anyway.  If one wants to insert a delay to slow down a misbehaving client,
you insert the delay *before* returning the 502 response, not afterwards.

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

I think we can get away with saying MUST NOT here; more and more clients
support nntps, and I think it will make the IETF quite a bit happier.
This is a pretty big change to what's expected of clients, since we're
trying to solve the clear-text problem.

But I don't have a strong opinion here.

> I'm not clear that there's a benefit to requiring UTF-8.

We said that everything else is UTF-8, and it's consistent.  And treating
it as opaque data doesn't necessarily work either, depending on the input
mechanisms available to the user.

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

Agreed on the splitting.

> Section 2.2.2:

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

Agreed.

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

Using "=" for this case would be better.  Isn't that okay in SASL?

> 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==

Ugh, please no.

> 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 think that means something different, doesn't it?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list