Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt

From: [email-masked]
Date: Fri, 04 Jul 2014 09:31:22 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
        Author          : Alexey Melnikov
	Filename        : draft-ietf-httpauth-scram-auth-03.txt
	Pages           : 20
	Date            : 2014-07-04

Abstract:
   The secure authentication mechanism most widely deployed and used by
   Internet application protocols is the transmission of clear-text
   passwords over a channel protected by Transport Layer Security (TLS).
   There are some significant security concerns with that mechanism,
   which could be addressed by the use of a challenge response
   authentication mechanism protected by TLS.  Unfortunately, the HTTP
   Digest challenge response mechanism presently on the standards track
   failed widespread deployment, and have had success only in limited
   use.

   This specification describes a family of HTTP authentication
   mechanisms called the Salted Challenge Response Authentication
   Mechanism (SCRAM), which addresses the security concerns and meets
   the deployability requirements.  When used in combination with TLS or
   an equivalent security layer, a mechanism from this family could
   improve the status-quo for application protocol authentication.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Sweet <[email-masked]>
Date: Mon, 07 Jul 2014 10:15:29 -0400

Quick comments:

- Isn't SHA-1 broken?  
- Saying that the username and password MUST be UTF-8 is not sufficient, and I don't think you want to require that the client and server support and try all normalization forms (which the text on page 6 would seem to indicate)
- I'm confused by what section 4 (SCRAM Mechanism Names) and section 8 (IANA Considerations) are saying.  Section 4 seems to indicate you are registering a family of auth schemes starting with SCRAM-, but section 8 says each one has to be registered and defined separately.  If the latter, I would prefer to see a non-broken hash function be defined first and made mandatory.

On Jul 4, 2014, at 12:31 PM, [email-masked] wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Jul 2014 18:45:13 +0300

> - Isn't SHA-1 broken?  

Define “broken”.

There is a break of collision resistance of SHA-1. That has been known for over 5 years now, but for some reason, I don’t believe anyone’s published a pair of colliding buffers. I guess once the theoretical proof was there, the effort of actually creating colliding buffers wasn’t worth it.

Anyway, SCRAM-Auth doesn’t use straight SHA-1, but HMAC-SHA-1. AFAIK this is still considered safe. 

> - I'm confused by what section 4 (SCRAM Mechanism Names) and section 8 (IANA Considerations) are saying.  Section 4 seems to indicate you are registering a family of auth schemes starting with SCRA…

SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is widely implemented. But it’s not like HMAC-SHA1 is considered broken.

Yoav 
(with no hats)

---

From: Michael Sweet <[email-masked]>
Date: Mon, 07 Jul 2014 13:21:54 -0400

Yoav,

> On Jul 7, 2014, at 5:15 PM, Michael Sweet <[email-masked]> wrote:

As in deprecated by NIST and don't use for any new standards broken?

(I know the TLS guys are pulling it from TLS 1.3, and it is not included in the Digest update)

> Anyway, SCRAM-Auth doesn’t use straight SHA-1, but HMAC-SHA-1. AFAIK this is still considered safe. 

Well, as long as the security guys are happy.

> SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is widely implemented. But it’s not like HMAC-SHA1 is considered broken.

May I suggest, then, that we add HMAC-SHA2-256 to this document and make *both* required? At least then we start out with a little bit of algorithmic agility and don't need to immediately do a series of SCRAM drafts (the next one could add HMAC-SHA3-256 and HMAC-SHAKE-256, once that process is finished?)

Oh, and definitely clear up the wording so that sections 4 and 8 explicitly agree with each other. ("the intent is to define a family of SCRAM-xxx authentication schemes. This document defines SCRAM-SHA-1 and SCRAM-SHA2-256." or something like that in section 4...)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jul 2014 12:11:18 +0100

> SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is widely implemented. But it’s not like HMAC-SHA1 is considered broken.
Agreed.

SHA1 matches registered use in the SASL framework, but I don't mind 
making HMAC-SHA2-256 the default for HttpAuth.