Subject: SCRAM mechanism

From: Chris Newman <[email-masked]>
Date: Mon, 15 Sep 1997 14:32:28 -0700 (PDT)

I've put together an internet draft for a new SASL mechanism.  The draft
is 12 pages, and located at:

<ftp://ds.internic.net/internet-drafts/draft-newman-auth-scram-00.txt>

This is similar to CRAM-MD5 (RFC 2195), with a few additions:

(1) The verifier stored on the server is not plaintext-equivalent.

(2) It includes an authorization identity.

(3) It uses SHA1, which is believed to be better than MD5.

(4) It includes the service name and server name in the exchange to permit
the server to proxy to a remote authentication database.

(5) It adds a client nonce and mutual authentication step, to deal with
spoof servers.

Here are some issues I'd like to see discussion on:

(A) SCRAM-SHA1 differs from CRAM-MD5 in that it uses binary encodings
rather than textual encodings.  Since about half of the data (nonces, hash
results) is likely to be binary, I felt it was unnecessary complexity to
add something like the hex-encoding that CRAM-MD5 uses.  In addition, the
binary encoding allows user names to have spaces, unlike CRAM-MD5.
However, this makes debugging the textual portions of the protocol harder,
as with all binary encodings.  Anyone think I should go back to a more
textual format?

(B) I didn't bother adding an integrity layer because it would make the
document quite a bit longer and more confusing.  The dictionary attack and
stolen verifier attacks against SCRAM are powerful enough that I think
adding an integrity layer and pretending it's "secure from tampering" is
misleading.  Anyone think I should add an integrity option?

(C) I didn't add an encryption option since there's no forward secrecy (a
stolen verifier would expose all sessions encrypted with that password) so
it didn't seem like a big enough gain for the complexity.

(D) Tom Wu's "TWEKE" modification discussed in appendix B is probably safe
from undetectable tampering (an active attack could be detected after the
fact from logfiles on the machines).  It also adds a Diffie-Hellman key
exchange which is serious cryptography requiring a bignum math package
(although not much else).  I'd be willing to drop SCRAM in favor of TWEKE
if people felt it was likely to be deployed.  I think the bignum package
would be an undesirable barrier to most client authors as opposed to the
page or two of code for SCRAM, but I'm far from sure.  Thoughts?

(E) Should the server identifier also include a realm name?  It's
currently written so it would be easy to add later, but has no specific
semantics.  I don't want to add all the unnecessary complexity of 
Compuserve's RPA proposal, but I think its intended functionality is
important.

(F) CRAM-MD5 can use an authentication DB which doesn't include the
plaintext itself (although it's still plaintext-equivalent) -- it
basically involves saving the initialized HMAC-MD5 machinery.  I could
change SCRAM to use MD5 and HMAC on the first step so that it could share
a CRAM-MD5 authentication DB.  Would that be worthwhile? 

		- Chris

Date: Mon, 15 Sep 1997 14:32:28 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: SCRAM mechanism
To: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

I've put together an internet draft for a new SASL mechanism.  The draft
is 12 pages, and located at:

<ftp://ds.internic.net/internet-drafts/draft-newman-auth-scram-00.txt>

This is similar to CRAM-MD5 (RFC 2195), with a few additions:

(1) The verifier stored on the server is not plaintext-equivalent.

(2) It includes an authorization identity.

(3) It uses SHA1, which is believed to be better than MD5.

(4) It includes the service name and server name in the exchange to permit
the server to proxy to a remote authentication database.

(5) It adds a client nonce and mutual authentication step, to deal with
spoof servers.

Here are some issues I'd like to see discussion on:

(A) SCRAM-SHA1 differs from CRAM-MD5 in that it uses binary encodings
rather than textual encodings.  Since about half of the data (nonces, hash
results) is likely to be binary, I felt it was unnecessary complexity to
add something like the hex-encoding that CRAM-MD5 uses.  In addition, the
binary encoding allows user names to have spaces, unlike CRAM-MD5.
However, this makes debugging the textual portions of the protocol harder,
as with all binary encodings.  Anyone think I should go back to a more
textual format?

(B) I didn't bother adding an integrity layer because it would make the
document quite a bit longer and more confusing.  The dictionary attack and
stolen verifier attacks against SCRAM are powerful enough that I think
adding an integrity layer and pretending it's "secure from tampering" is
misleading.  Anyone think I should add an integrity option?

(C) I didn't add an encryption option since there's no forward secrecy (a
stolen verifier would expose all sessions encrypted with that password) so
it didn't seem like a big enough gain for the complexity.

(D) Tom Wu's "TWEKE" modification discussed in appendix B is probably safe
from undetectable tampering (an active attack could be detected after the
fact from logfiles on the machines).  It also adds a Diffie-Hellman key
exchange which is serious cryptography requiring a bignum math package
(although not much else).  I'd be willing to drop SCRAM in favor of TWEKE
if people felt it was likely to be deployed.  I think the bignum package
would be an undesirable barrier to most client authors as opposed to the
page or two of code for SCRAM, but I'm far from sure.  Thoughts?

(E) Should the server identifier also include a realm name?  It's
currently written so it would be easy to add later, but has no specific
semantics.  I don't want to add all the unnecessary complexity of 
Compuserve's RPA proposal, but I think its intended functionality is
important.

(F) CRAM-MD5 can use an authentication DB which doesn't include the
plaintext itself (although it's still plaintext-equivalent) -- it
basically involves saving the initialized HMAC-MD5 machinery.  I could
change SCRAM to use MD5 and HMAC on the first step so that it could share
a CRAM-MD5 authentication DB.  Would that be worthwhile? 

		- Chris