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

Russ Allbery rra at stanford.edu
Mon May 17 04:14:55 PDT 2004


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

> Authenticated state: it's now a bit more complicated. Some servers will
> only allow you to authenticate once and then you've stuck with it. These
> would give response [D]. But others might allow you to change your
> authentication. These then need to decide what to do if the *second* one
> fails - do they forget the first or do they retain it?

If a server is going to support reauthentication, I think we should
require that they remember the previous authentication until a new
authentication is successful.  Otherwise, there are just too many
headaches, and this way it's easier to explain.

> If we want to forbid PASS before USER, then that's fine with
> me. However, if so then we need a clear response code for this case (I
> don't think 381 is right)

What's wrong with 482?  That's what's always been used for this.

> and it means we are explicitly forbidding PASS-only authentication
> (where, for example, the user name is deduced from the connecting IP
> address).

Right.  I don't have a problem with that, although it does outlaw INN's
current hack.

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

>> Again, no argument.  I believe the current wording is based on INN
>> behavior.

> Then INN is broken.

400 in any circumstances other than as an initial greeting has very little
implementation out in the real world that I've seen.  I'll bet that pretty
much everyone uses 502 here.

> Yes we do - [NNTP-BASE] 3.1:

>     The first or only line of the response MUST NOT exceed 512 octets,
>     which includes the response code and the terminating CRLF pair; an
>     extension MAY specify a greater maximum for commands that it
>     defines, but not for any other command.

So we need to deal with this by explicitly waiving it or increasing it
somehow.  We had some discussion about this before, I know; I thought we'd
reached a conclusion, but maybe not.

> Um, I'm lost. I'm talking about the paragraph:

>     After a security layer is established, the server MUST still adver-
>     tise the SASL capability (with the same arguments as previously),
>     MUST still advertise the AUTHINFO capability (perhaps with zero
>     arguments), SHOULD NOT advertise SASL as an argument to the
>     AUTHINFO capability, and SHOULD NOT advertise the STARTTLS [NNTP-
>     TLS] capability.

> Firstly, this is talking about security layers (encryption, right?), not
> authentication. Why should you not advertise SASL but yet advertise what
> SASL offers?

Because you can detect a MIM attack that resulted in degraded security if
you look at the supported SASL mechanisms after the security layer was
negotiated and it differs from what was available before.  I'm not sure
this is actually all that useful, but it makes sense.

> Secondly, what stops the MIM continuing to suppress any incriminating
> evidence?

The assumption is that the security layer does, because in theory your
auth negotiation (which establishes the session key for the security
layer) was resistant to even a MIM attacker.

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



More information about the ietf-nntp mailing list