[ietf-nntp] Re: AUTHINFO/SASL responses

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> We need to decide which response codes should be used each possible
> scenario.  Those that come to mind are:

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

481 would indicate a temporary failure with authentication, implying that
the client should try the same username and password again.  Is that what
you mean?  Under what circumstances would one use that?

innd currently uses 481 equivalently to 502, but innd's AUTHINFO support
(as opposed to nnrpd's) is used by almost no one.

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

Sounds fine.

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

Alternately, one could use 482 for this, considering 482 to be generally
the error code for an improper auth protocol exchange.  I think that may
make more sense.

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

Sounds 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 like 482 because it distinguishes protocol failures from authentication
failures and provides more information to the client.  The client author
can be sure that there's probably a bug in their code.

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

282 is taken by XGTITLE.

I think we should define a new return code following the above proposal.
That sounds fine to me, and I'd rather keep 281 as the success code for
old-style authentication anyway.  SASL authentication is sufficiently
different that I think it's fine to have a separate return code.

> - reauth attempt when the server doesn't support it.  Clive suggests
> 502, and I tend to agree.

Sounds good.

> Any scenarios that I missed?

Not that I can think of.

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