ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?

[Clive D.W. Feather]

Ken Murchison said:
> I suppose it would be reasonable to allow pipelining LIST EXTENSIONS 
> with base (mandatory to implement) commands ONLY, but you just know that 
> some poorly written client will try to pipeline something that it 
> shouldn't (e.g., AUTHINFO USER/PASS before realizing that its not 
> supported).

Let's be clear here: the meaning of "command X can't be pipelined" is
actually "after receiving command X and before replying, the server can
throw away any received data". MODE READER is non-pipelined because the
fork/exec of the new server can do this; POST/IHAVE are non-pipelined
beause the fork/exec of postnews can do so.

If AUTHINFO is not supported, then it will return an error. But that's not
a reason for LIST EXTENSIONS to throw away the AUTHINFO command.

Now, I understand completely that there are dangers in using authentication
commands before checking if they are supported. But the correct place to
document that is in the Security Considerations section of the AUTHINFO
extension document (or *perhaps* its generic enough to go in the S.C. of
the base document). It is *not* to put odd restrictions on LIST EXTENSIONS.

Note that what you're saying is:

    [C] DATE
    [C] AUTHINFO SASL PLAIN asdlfnkasf
    [S] 111 20030910090204
    [S] 502 No mechanism available

is fine but, on the other hand:

    [C] LIST EXTENSIONS
    [C] AUTHINFO SASL PLAIN asdlfnkasf
    [S] 202 Extension list follows:
    [S] AUTHINFO USER
    [S] .
    [S] 502 No mechanism available

isn't.

> If a client caches the info, then it can potentially do something 
> stupid, like expose a user's plaintext password.  For example, consider 
> this conversation:
> 
> S: 200 eagle.oceana.com Cyrus NNTP v2.2.1-BETA server ready, posting allowed
> C: LIST EXTENSIONS
> S: 202 Extension list follows:
> S: AUTHINFO USER
> S: SASL CRAM-MD5 NTLM DIGEST-MD5
> S: STARTTLS
> S: STREAMING
> S: .
> C: STARTTLS
> S: 382 Begin TLS negotiation now
> verify error:num=19:self signed certificate in certificate chain
> TLS connection established: TLSv1 with cipher DES-CBC3-SHA (168/168 bits)
> C: LIST EXTENSIONS
> S: 202 Extension list follows:
> S: AUTHINFO USER
> S: SASL CRAM-MD5 NTLM DIGEST-MD5 PLAIN
> S: STREAMING
> S: .
> C: AUTHINFO SASL PLAIN a2VuAGtlbgBiYW5hbmEx
> S: 281 Success (tls protection)
> Authenticated.
> Security strength factor: 168
> 
> 
> If the client caches the last LIST EXTENSIONS response, then the next 
> time that it goes to authenticate (w/o checking LIST EXTENSIONS), it 
> will try to do so in the clear, which is "not a good thing":

Okay, I see that.

But that is something else that belongs in the Security Considerations
section of one of the documents.

You are assuming that clients will always use LIST EXTENSIONS to decide how
to do authentication. Surely it's equally likely that they'll just work
down their list of known methods in order of security, or something like
that?

In any case, forcing a LIST EXTENSIONS isn't going to cure any client that
badly designed.

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