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

[Ken Murchison]

Charles Lindsey wrote:
> In <4048C2B8.9010409 at oceana.com> Ken Murchison <ken at oceana.com> writes:
> 
> 
>>Russ Allbery wrote:
>>
>>>We already had this discussion.  The solution is to use the built-in
>>>capabilities of TLS to negotiate down to no encryption after
>>>authentication if that's what one wants.
> 
> 
>>Or design a new SASL mechanism which doesn't expose the plaintext 
>>password during the exchange, but allows the plaintext password to be 
>>recovered by the server.  Chris Newman's old PASSDSS draft was one such 
>>mechanism as is Tony Hansen's proposed PKI mechanism, but neither of 
>>these has any deployment.
> 
> 
> Well such schemes seem to be widespread in SMTP servers AIUI.

Which schemes?  Shared secret schemes such as CRAM-MD5, or schemes like 
I mention above?  I believe the former, but not the latter.

 > Doubtless
> TLS is also available in such servers, but I doubt it is used to anything
> like the same extent.

I think you'd be surprised how many SMTP clients only support/use 
plaintext authentication with SSL/TLS protection.

> Hence my surprise that we are not proposing such a
> scheme here, and seem to be relying on TLS as the _only_ "respectable"
> method of authentication.

TLS isn't being proposed as a method of authentication (although you 
could use it for authentication with a client-side certificate and SASL 
EXTERNAL). Its being proposed as a readily available way of protecting 
plaintext authentication (such as AUTHINFO USER/PASS and SASL PLAIN) in 
the same fashion as has been done fro IMAP, POP3 and SMTP.

As I said before, the problem isn't that there aren't any secure 
authentication mechanisms available, the problem is that that the 
existing secure mechanisms aren't deployable in some installations 
(those that pass the password to a third party application for 
verification).  The only currently deployed auth mechs which are useful 
for these installations are the plaintext ones, which must be protected 
by security layer such as TLS (per the IETF).

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