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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 14 Nov 2004 09:50:17 -0500

At 08:54 AM 11/14/2004, Ken Murchison wrote:
>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".

While the news itself may not be sensitive information, many
users likely consider their choice of what news they read to
be sensitive information.

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

This option introduces significant complexity into implementations.
In our LDAP implementation, we simply refuse to allow downgrade as
it is too difficult to properly manage all the security associations
(e.g., ensuring responses for operations sent in the protected
channel are not sent in the unprotected channel, managing authorization
state, etc.).

Note that in our LDAP implementation (if we did allow this, we'd
likely move the authorization state to anonymous status upon downgrade
to NULL) as without the integrity protection the session is open to
hijack attack.

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

The market may not be limited to NNTP.

I note that SASL mechanisms are free to provide compression services
in addition to data security services.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2004 15:02:30 -0500

I think having this SASL mech would generally be a good idea.  I think
any such mech should provide security layers as an option.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 14 Nov 2004 12:16:45 -0800

> be sensitive information.

Yeah, like most security decisions, it's a tradeoff.  It would clearly be
better to continue to encrypt the entire session, from a security
standpoint, to prevent session hijacking and to keep user transactions
confidential.

However, NNTP sessions frequently involve *huge* amounts of data.  (Unlike
e-mail services, the significant majority of NNTP reader traffic these
days is centralized at a few widely used NNTP providers, who are used as
outsourcing providers by ISPs, and also unlike e-mail, the vast majority
of Usenet traffic by volume is large encoded binaries.)  What I've heard
from admins at such providers is that supporting TLS for every session
would involve significant new hardware purchases, and the potential attack
vectors just don't seem to justify that right now.  Customers aren't
demanding TLS to protect their reading data; quite to the contrary, they
don't want anything that makes their news sessions slower.

I could go on about how much RADIUS annoys me (I've run into this
cleartext password problem in a whole host of other places as well), but
it does seem to be what people use at the moment.  Right now, most news
providers are just using cleartext passwords without TLS protection at
all, despite the fact that this is known to be insecure, because there
aren't any other alternatives that are fast enough for their purposes and
widely supported by news readers.  Of course, any new authentication
mechanism also won't be widely supported by news readers at first, but I
can hope that something obviously useful for NNTP will be picked up.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Nov 2004 17:33:18 -0500

> any such mech should provide security layers as an option.

Chris' PASSDSS allows integrity and/or privacy to be negotiated for the 
entire session.

My biggest question about PASSDSS is should it allow for multiple 
ciphers and other types of public keys (e.g. RSA)?

Sam, as a Security Area Director, can you have someone look at PASSDSS 
from a security standpoint?  Especially 3DES CBC mode.  My guess is that 
if SSH2 gets published then PASSDSS wouldn't have any problems.

---

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Nov 2004 17:34:39 -0500

> to NULL) as without the integrity protection the session is open to

Actually with OpenSSL, it doesn't let you remove the integrity layer (at 
least not that I could find).

---

From: Tony Hansen <[email-masked]>
Date: Mon, 15 Nov 2004 12:14:16 -0500

Both Chris and I saw the need for such a SASL mechanism. His proposal 
was definitely more fleshed out than mine; I didn't want to go into all 
the work of fleshing mine out until I got support from the community.

However, neither of us got much support as to the need, and both 
proposals withered and died.

But I still feel that the need is there.

	Tony Hansen
	[email-masked]

Ken Murchison wrote:

> ...

---

From: Ken Murchison <[email-masked]>
Date: Mon, 15 Nov 2004 14:33:33 -0500

> But I still feel that the need is there.

Did/do you envision something different from what Chris had come up 
with?  I assume you must otherwise you would've just revived the PASSDSS 
draft.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Nov 2004 13:26:22 +0000

Tony Hansen wrote:

> was definitely more fleshed out than mine; I didn't want to go into 
> all the work of fleshing mine out until I got support from the community.
>

This seems to suggest that we need to find an energetic editor (and I am 
not volunteering).

---

From: Ken Murchison <[email-masked]>
Date: Tue, 16 Nov 2004 09:53:13 -0500

> This seems to suggest that we need to find an energetic editor (and I am 

I'll volunteer.  I'd probably start by respinning Chris' draft, if 
people feel its a good starting place.  Since I've already written a 
plugin based on this spec, I have an obvious bias towards it.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 16 Nov 2004 16:30:18 -0500

You're assuming that I remembered Chris' document when I wrote mine. 
Remember that there were 5 years between the two drafts. :-)

I would be very happy with what Chris proposed.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Tue, 16 Nov 2004 16:53:42 -0500

Go for it. I hope there's enough support this go around.

	Tony Hansen
	[email-masked]

Ken Murchison wrote:

>> This seems to suggest that we need to find an energetic editor (and I 
>> am not volunteering).
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 14 Nov 2004 09:50:17 -0500

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2004 15:02:30 -0500

---

From: Russ Allbery <[email-masked]>
Date: Sun, 14 Nov 2004 12:16:45 -0800

---

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Nov 2004 17:33:18 -0500

---

From: Ken Murchison <[email-masked]>
Date: Sun, 14 Nov 2004 17:34:39 -0500

---

From: Tony Hansen <[email-masked]>
Date: Mon, 15 Nov 2004 12:14:16 -0500

Tony Hansen
	[email-masked]

---

From: Ken Murchison <[email-masked]>
Date: Mon, 15 Nov 2004 14:33:33 -0500

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 16 Nov 2004 13:26:22 +0000

---

From: Ken Murchison <[email-masked]>
Date: Tue, 16 Nov 2004 09:53:13 -0500

---

From: Tony Hansen <[email-masked]>
Date: Tue, 16 Nov 2004 16:30:18 -0500

Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Tue, 16 Nov 2004 16:53:42 -0500

Tony Hansen
	[email-masked]