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

[Clive D.W. Feather]

Ken Murchison said:
>> 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.
> Obviously the server can't depend on the client following the MUST NOT, 
> and must be prepared to handle any "unsupported" command at any time. 
> But I don't seem any harm is trying to enforce friendly client behavior.

Encouraging good behaviour is fine, but I don't think that you can use
MUST, or even SHOULD, for this.

>> I don't think we can sensibly legislate for unstandardised versions of
>> AUTHINFO; better just to leave this whole paragraph out.
> Any legacy client won't be compliant with this draft anyways.  I think 
> we are just dictating that any clients which are updated to be compliant 
> must start using LIST EXTENSIONS for its intended purpose.

The intended purpose is to tell you what extensions are available. There is
no requirement to use it before using an extension, and I for one will
resist any such idea.

If there's consensus for a "there are no undocumented AUTHINFO option"
indicator, it should be "AUTHINFO NOLEGACY" or "AUTHINFO -" or something
like that (possibly combined with the existing flags, as
    AUTHINFO USER SASL:PLAIN NOLEGACY
), or else we should bite the bullet and change the name of the command.

>> 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 disagree.  Trial and error is old school due to the lack of a 
> capability discovery command.  Now that we've added such a command, 
> client's should use it.  This behavior can also be dangerous if the 
> client blindly attempts PLAIN with an initial response, thus exposing 
> the user's password.

That's a separate matter, to be dealt with in Security Considerations.

> Sure, the client could attempt PLAIN w/o the 
> initial response, or only try PLAIN as a last resort, but all this logic 
> to avoid a potential security problem seems hackish.  Why not just issue 
> LIST EXTENSIONS and see what the server will support?

Because it's overkill in many instances.

Consider the case where my ISP is providing news service. The link to the
ISP is not going to be the weak point and USER/PASS is sufficient for the
job. If USER fails, I'm not going to send the password; I'll just present
the error message to the user and see whether the server lets me do what I
wanted to anyway.

In this context, the extra round trip and complex parsing just isn't worth
the effort.

>> 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.
> I'm not sure which paragraph you are refering to.

The paragraph beginning "A client MAY attempt ..."; more precisely, the
text starting "The client MUST NOT under any circumstances ...".

I understand that there are security issues here, but I think this material
is better handled under the individual commands.

>> Section 2.1: there's no reason to forbid pipelining.
> They MUST NOT be pipelined if the server doesn't advertise support for 
> AUTHINFO USER, to avoid unnecessarily exposing the plaintext password. 
> if the server advertises support, then USER/PASS can be pipelined.  We 
> can probably add text to this effect.

So again it's a security issue rather than a protocol one. Again I don't
think this is the right way to address it (for example, if you have TLS
already in place then there's no security issue).

>> 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'm not sure I see the need for the distinction between [C] and [D].

Okay, let me try again.

There are two basic states, "unauthenticated" and "authenticated". They
need to be treated separately.

Unauthenticated state: there are three possible responses to an
authentication request:
    [A] - you are now authenticated with these credentials
    [B] - authentication credentials rejected, you are not authenticated
    [D] - I'm not allowing AUTHINFO USER/PASS in this state

Case [D] would apply if the server only authenticates clients coming from
certain IP addresses, for example. I'm thinking of the moral equivalent
of "no USER/PASS without TLS first", but in circumstances when 483 isn't
appropriate.

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?

Using my proposed responses of 281, 481, 284, and 502 respectively, then
here are the relevant transactions:

  Server type 1, single authentication only:

    [C] GROUP staff.announce
    [S] 480 group available to staff only
    [C] AUTHINFO USER clive
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 281 authenticated
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only
    [C] AUTHINFO USER root
    [S] 502 Can't change identity once authenticated
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only

  Server type 2, double authentication allowed: successful:

    [C] GROUP staff.announce
    [S] 480 group available to staff only
    [C] AUTHINFO USER clive
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 281 authenticated
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only
    [C] AUTHINFO USER root
    [S] 381 password needed
    [C] AUTHINFO PASS verysecret
    [S] 281 congratulations, you are now root
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected posting allowed

  Server type 2, double authentication allowed: failed, response [C]:

    [C] GROUP staff.announce
    [S] 480 group available to staff only
    [C] AUTHINFO USER clive
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 281 authenticated
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only
    [C] AUTHINFO USER root
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 284 wrong password, you remain authenticated as clive
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only

  Server type 2, double authentication allowed: failed, response [B]:

    [C] GROUP staff.announce
    [S] 480 group available to staff only
    [C] AUTHINFO USER clive
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 281 authenticated
    [C] GROUP staff.announce
    [S] 211 10 100 200 staff.announce selected read-only
    [C] AUTHINFO USER root
    [S] 381 password needed
    [C] AUTHINFO PASS secret
    [S] 481 wrong password, authentication forgotten
    [C] GROUP staff.announce
    [S] 480 group available to staff only

Does that help?

>> 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:
> I have no problem with your proposed text, provided that current 
> deployment dictates that PASS be allowed before USER.  If we're adding 
> this text to allow future implementations to do so, then I don't think 
> we want to add it.  USER/PASS should be deprecated in favor of SASL. 
> Its being documented here so that we have backwards compatibility with 
> existing deployment.  If current deployment is all USER then PASS (and 
> not PASS then USER), why allow the latter?

I have no idea what current deployment is like. I was trying to ensure that
the text reflected all possibilities.

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

I don't object to this, but it's not clear that's what we want and (if it
is then) it's not clear from the specification.

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

>> Surely the MUST NOT in #3 should be SHOULD NOT?
> The IETF will require a non-plaintext mechanism for interoperability. 
> We can pick whatever we want, but we must pick something.  DIGEST-MD5 
> and TLS + PLAIN seemed to make sense.

Is that a basis for MUST? If so, okay.

>> 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].
> Agreed.  [B] is the correct response (whatever we decide).

Or [C], depending on the server - see my discussion above.

>> #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.
> I don't see a problem which #6 as it stands.  If all we have is 
> whitespace after the mechanism name, then the initial response is empty 
> (since BASE64 doesn't use any whitespace chars).  Otherwise the 4th arg 
> is the initial response.

No, I'm talking about:

    In NNTP, a server challenge that contains no data is
    defined as a 383 reply with no text part.  Note that there is still
    a space following the reply code, so the complete response line is
    "383 ".

This is breaking NNTP-BASE concepts. *ANY* response in NNTP can be followed
by arbitrary junk and *ALL* responses must have consistent syntax so that
they can be parsed easily. I see no grounds to break this. Consider:

    [C] AUTHINFO SASL DIGEST-MD5
    [S] 383 This is a piece of trailing junk.
                ^

Is "This" a base64 encoding of 3 octets or is it part of the trailing junk?

>> 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"?
[...]
> I definitely don't like this for #11 since we don't have any line length 
> limitations on responses in the base spec AFAIK.

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. 

> Nor do we have any 
> limit to the length of multi-line responses (ARTICLE, etc).

Agreed for *subsequent* lines, but not for the line with the response code.

>> I don't understand the thinking behind #18 at all. Can you explain?
> The thought is to allow the client to detect MIM attacks.  One way for 
> an attacker to steal a password is to sit between the client and server 
> and force the client to use a plaintext mech by suppressing the 
> advertisment of more secure mechanisms.  After authentication, the 
> client can compare the list of available mechs offered before and after 
> authentication to see if they changed in any significant way.  If 
> DIGEST-MD5 is offered after, but not before, its possible that a MIM 
> attack took place.

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? Secondly, what stops the MIM continuing to suppress any
incriminating evidence? I'm afraid you're going to have to explain this
slowly to me - if I can't get it, then nor will half your audience.

While you're at it, please explain this bit from #16:

    (Note
    that a client MAY compare the advertised SASL mechanisms before and
    after authentication in order to detect an active down-negotiation
    attack).

(I understand the rest of the paragraph).

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