AUTHINFO/SASL responses (Was: [ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt)

[Clive D.W. Feather]

Ken Murchison said:
> - authentication failed/rejected.  Currently this is documented as 502, 
> per INN, but Clive suggests 481 and I tend to agree we need a temp code 
> which allows the client to try again.  For those servers which choose to 
> bail, 502 could still be allowed.

502 means "I won't let you try again". There's a need for a "you can try
again" code, and 481 feels right.

> - SASL auth cancelled by client (with "*" response).  Traditionally, 
> this is treated as an auth failure, so whatever we decide for failure 
> can be used.

Right.

> - SASL challenge/response can't be base64 decoded.  Traditionally, this 
> is treated as an auth failure, so whatever we decide for failure can be 
> used.

If it can't be decoded, that's a plain syntax error. 501 is the right
code for this. Or it should be a new code, say 581.

> - unknown SASL mechanism used.  This is essentially an unknown command 
> or unsupported command variant.  Clive suggests 503 and I have no objection.

Fine.

> - client sends initial SASL response for a mech that doesn't support it. 
>  This exchange "out of order" problem will cause the auth to fail. 
> Clive suggests 482.  I suggest the the failure code (481?) as an 
> alternative.

I think you want to distinguish this (protocol error) from a failure such
as wrong password.

Thinking about it, it's effectively providing too many arguments. So it's a
sort of syntax error. But I think it's worthwhile distinguishing this from
the normal syntax error case. What about 580? [5xx is "Command unknown,
unsupported, unavailable, or syntax error".]

What you then have is:

    AUTHINFO SASX                          501 unknown command
    AUTHINFO SASL MAGIC                    503 bad method
    AUTHINFO SASL DIGEST-MD5 sl23X04a      580 shouldn't provide data
    AUTHINFO SASL PLAIN ar3pOR==X6q        581 bad base64 encoding

> - SASL authentication succeeds.  Currently we're using two codes: 281 
> and 283.  283 is used when we have server success data (final server 
> challenge) and 281 is used when we don't (any text response can be used 
> after the 281).  Clive suggests using just one code which we could 
> accomodate by doing the following (modified slightly from Clive's proposal):
> 
> "28x" or "28x " -> no success data
> "28x =" -> empty success data
> "28x <base64> -> success data
> 
> where 28x is 282 or higher.

As I've said before, you can *NOT* do that because it breaks [NNTP-BASE];
a response must have a single consistent syntax and allow trailing junk.
If you need to distinguish "no success data" from "empty success data" then
you need separate arguments for them:

  "28x * trailing junk"           -> no success data
  "28x = trailing junk"           -> empty success data
  "28x base64stuff trailing junk" -> success data

[Doesn't the single equals sign break the "groups of 4" rule? Surely it
needs to be "===="? Similarly, wouldn't "****" be better than "*" here and
elsewhere?]

What is the difference between "no success data" and "empty success data"?

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