Subject: New SASL mech?

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Nov 2004 08:54:25 -0500

Continuing a conversation started during the IETF meeting...

I'm solitciting opinions for/against creating a new non-plaintext SASL 
mech which allows the plaintext password to be recovered by the server.

The rationale for such a mech is this:  While working on the NNTP SASL 
profile, it has been brought to my attention that many NNTP servers 
forward authentication off to another server such as a Radius server. 
In this case, the server MUST have access to the plaintext password, 
which eliminates shared secret mechs such as CRAM-MD5, DIGEST-MD5, etc. 
  Currently, the only way to do this is to use a plaintext mechanism in 
conjunction with TLS.  However, several of the NNTP folks have told me 
that TLS protecting an entire NNTP session (which is almost always 
public data) just to protect the password is overkill and in some cases 
unreasonable given the sheer volume of traffic.  I have tried arguing 
for the use of TLS+PLAIN, but I continually get shot down as an outsider 
who "doesn't understand NNTP".

I see two solutions to this problem:

1.  Use TLS+PLAIN but allow the server to either shutdown the TLS 
session or renegotiate the session down to the NULL cipher.  Both 
options are already allowed in TLS and can be done without killing the 
NNTP connection.  As a test, I have implemented both in Cyrus nntpd and 
the Cyrus test client and with a little tweaking of the code they do work.

What I don't know about these techniques is what the security 
implications are.  Obviously, the TLS shutdown or renegotiation MUST NOT 
be allowed prior to completion of the authentication.  In the case of 
renegotiating down to the NULL cipher, this session MUST NOT be allowed 
to be resumed as an initial session.

2. Create a new SASL mech in which the plaintext password is not sent in 
the clear, but is recoverable by the server.  Tony Hansen hinted at such 
a mech with his strawman draft last year:

http://www.watersprings.org/pub/id/draft-hansen-sasl-pki-00.txt

and Chris Newman fully documented such a mech back in 1998:

http://www.watersprings.org/pub/id/draft-newman-sasl-passdss-01.txt

Both the PKI and PASSDSS mechs are similiar in that they do a DH key 
exchange and then encrypt the password.  Chris' mech is actually an 
SSH2-style negotiation in which the privacy/integrity protection MAY be 
used to protect the entire session.  The PASSDSS mech is pretty straight 
forward as I implemented a plugin for Cyrus SASL in about a day using 
OpenSSL libcrypto.

So, is a niche market like NNTP worth creating a new SASL mech for, or 
should we find a way to either force them to use TLS or make it more 
palatable (as described above)?  The advantage of using TLS is that 
we're not reinventing the wheel (since any new SASL mech would probably 
look a lot like TLS or SSH) and we gain the ability to negotiate 
compression for the session.  The advantage of a new SASL mech is that 
its a lot cleaner IMO and we eliminate any potential security problems 
  by using fiddling with the TLS session.

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