Ken Murchison | 21 Oct 19:57 2002

Re: ietf-nntp AUTHINFO SASL protocol choices

Trying to revive an old thread.  Hopefully this will get to the list,
since it appears to be dead from my end.

After just having implemented draft-newman-nntpext-auth-01 (Jeff's
option 5) in a NNTP server that I'm writing for Cyrus IMAP, I figured
that I'd offer my $.02.  I'm not sure how/why the discussion ever
deviated from Chris' original work, but I feel that this is the correct
way to implement AUTHINFO SASL.  For those who haven't seen it or can't
find it (its about 4 years old), here is the relevent text:

     AUTHINFO SASL mechanism [initial-response]

     The AUTHINFO SASL command permits NNTP clients to authenticate
     using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5],
     KERBEROS_V4, GSSAPI or EXTERNAL.  This profile of SASL uses the
     service name "news" for Kerberos and GSSAPI mechanisms.

     If AUTHINFO is implemented, then AUTHINFO SASL and the DIGEST-MD5
     [DIGEST-MD5] mechanism MUST be implemented.  This is necessary to
     ensure that any two compliant clients and servers can be configured
     to authenticate without using unencrypted clear-text passwords.
     [NOTE:  CRAM-MD5 is an expedient alternative choice as it's already
     standards track.]

     The optional initial-response argument is a base64-encoded string
     of the initial client response for SASL mechanisms with no initial
     server challenge.

     The server MAY continue the authentication exchange with a 351
     response containing a base64-encoded server-challenge.  The client
(Continue reading)

Ken Murchison | 22 Oct 20:59 2002

Re: ietf-nntp AUTHINFO SASL protocol choices


Ken Murchison wrote:
> 
> Trying to revive an old thread.  Hopefully this will get to the list,
> since it appears to be dead from my end.
> 
> After just having implemented draft-newman-nntpext-auth-01 (Jeff's
> option 5) in a NNTP server that I'm writing for Cyrus IMAP, I figured

I misspoke.  Chris' draft outlines Jeff's option 4, although if the
command line length *really* scares people, then option 5 is a viable
alternative.

Ken
--

-- 
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
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp


Gmane