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

[Ken Murchison]

Clive D.W. Feather wrote:

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

Clive, thank for the feedback.  My comments are below.  On some, I've 
either deferred to Jeff or the group.


> 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

I never really liked the separate capabilties responses either.  I think 
this is a holdover from Chris' old draft.  I'm fine with your proposal.

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


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


> 
> 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.  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?  Any new or 
updated NNTP client which avoids using LIST EXTENSIONS (for any reason) 
would seem to be poorly written to me.


> 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 won't argue.  Jeff, am I missing an obvious reason why this was added?

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


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


> Section 2.1.1: drop the generic responses.

OK.

> 
> 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'm not sure I see the need for the distinction between [C] and [D].  As 
far as which response codes to use, I'll defer to the consensus.  I 
believe the ones currently in the draft we pulled from an email response 
from Russ and/or INN behavior.


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

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


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

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

This was Jeff's addition, I'll let him comment.


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

OK.

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

OK.  This was added to help appease those that thought that each 
challenge/response should be a separate command (which I stringly 
oppose).  We used the analogy to show that SASL is no different than a 
"multi-part" POST command).  I'll gladly remove it.

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


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


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

Or [B].


> 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 don't like this for #7, since its easier to just not use the initial 
response.  Ideally, we'd extend the command line length limit to 
accomodate SASL initial response, but I won't push for that right now. 
I definitely don't like this for #11 since we don't have any line length 
limitations on responses in the base spec AFAIK.  Nor do we have any 
limit to the length of multi-line responses (ARTICLE, etc).

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

I won't object if that's the consensus, but the current SASL text was 
pulled from the RFC1734bis and RFC2554bis drafts for uniformity.  Since 
both of these docs have already reached RFC status, we didn't want to 
try and reinvent the wheel.


> 
> 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 can't think of any reason why this wouldn't work.  No objection.


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


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

I think I agree.  As you have pointed out, we definitely need to look 
closely at authentication specific response codes.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp