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

[Ken Murchison]

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.

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

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

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

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

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

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


Any scenarios that I missed?

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