[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Ken Murchison]

Charles Lindsey wrote:

> Yes, I remember this all started when Andrew Gierth, with his server hat
> on, wanted the actual password so that he could submit it to some other
> (radius?) server.
> 
> But that is not the usual case with your average NNTP connection to some
> server. Hence the need for some additional but simpler scheme such as
> CRAM-MD5.

I agree completely.  If I don't need all of my traffic encrypted, but 
want secure authentication, I would choose CRAM-MD5 or DIGEST-MD5.  I 
don't *believe* anyone is arguing this point.  The upcoming AUTHINFO 
SASL draft will allow CRAM-MD5 and any other SASL mechanism to be used 
by NNTP.  The Cyrus NNTP server already supports all mechanism provided 
by the CMU SASL library.

This still doesn't prevent us from having to deal with protecting legacy 
plaintext authentication (AUTHINFO USER/PASS), which I presume has, and 
will continue to have, a lot of deployment.  For this, TLS would have to 
be done before authentication.

Allowing TLS after authentication, presumably for private groups, is an 
interesting problem, but I think this can be easily solved by a separate 
NNTP connection rather than straying from restrictions already present 
in the other deployed messaging protocols.

Andrew's problem is probably best solved by a new SASL mechanism which 
allows the clear text password to be recovered by the server (with 
downgrading the TLS cipher to NULL after authentication a distant second).

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