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

From: [email-masked]
Date: Thu, 19 Nov 2015 05:43:20 -0800

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-10.txt
	Pages           : 17
	Date            : 2015-11-19

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 security concerns with HTTP Digest
   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 HTTP 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:
https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-10

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

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: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Nov 2015 13:46:16 +0000

> https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-10
This version fixes a few typos spotted by people, changes examples from 
using "host.com" to "example.com" (thank you Tony) and fixes more things 
in examples (again, thank you Tony).

---

From: Tony Hansen <[email-masked]>
Date: Thu, 19 Nov 2015 10:52:37 -0500

On 11/19/15 8:46 AM, Alexey Melnikov wrote:
> This version fixes a few typos spotted by people, changes examples
> from using "host.com" to "example.com" (thank you Tony) and fixes more
> things in examples (again, thank you Tony).

I've been thinking about re-authentication and the question about having
a counter that changes to make each sr= unique. Unless I'm mistaken, I
THINK without it, what is there now could allow replay attacks and MITM
attacks.

It might be better to make sr= a base64-encoded block that includes both
the s-nonce and the i value. The s-nonce would be what was in the
earlier response, but uses a higher i= value, such as 4097, 4098, etc.
The i value is ALREADY a counter that can be used to make things unique.
And this should be easy for both sides to calculate because it can use
the earlier result and just do another round of hashing.

More nits below.

    Tony

I keep spotting little things

s/RFC 3174/RFC 6234/

   An the final server response contains data
   attribute which base64 decodes as follows:
to
   >>And<< the final server response contains >>a<< data
   attribute which base64 decodes as follows:

or preferably
   >>The<< final server response contains >>a<< data
   attribute which base64 decodes as follows:

I saw another "earlies" that should be "earlier".

Note: I >really< dislike www-authenticate's overuse of list syntax and
its comma separators.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Nov 2015 13:21:14 +0000

Hi Tony,

> THINK without it, what is there now could allow replay attacks and MITM
Yes, until ttl expires. That is why I had this comment in the draft :-).
> the earlier result and just do another round of hashing.
I think I like your idea of reusing the "i" value as the starting 
counter. I am about to post a version of the draft with this change.