Subject: [http-auth] AD review of draft-ietf-httpauth-scram-auth-11

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Nov 2015 18:55:58 -0500

Hi Alexey,

Thank you for your work on this draft!

Question/Request:

I'd lie to see more text in the security considerations section on
SHA-1, limiting it's use and warning against it unless necessary.  The
Section 5, note on why SCRAM-SHA-1 is registered is helpful, but I
don't think it's enough.  It looks like this comment (recommendation
to not support SHA-1) came up in WGLC as well.  Additional text in the
security considerations on why it should not be used and that it is
here only in support of a couple of specific use cases will help.  I'm
sure this will come up again in IETF last call unless addressed.

Nits:
Abstract:
Up to you, but removing the word secure might be good since the only
thing secure about it is the session encryption protecting the
authentication:

Change from:

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

To:

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

In the abstract, digest method has it's issues too that are well
documented in the RFC published by this WG.  I'll let that go though.

2. In a few places, a sentence ends, but there is a space before the
ending period.  I'm sure the RFC editor would catch this, but it would
be better to resolve before it gets that far.  Her is an example from
section 5:

   *  a header consisting of a flag indicating whether channel
         binding is supported-but-not-used, not supported, or used .

3. Security Considerations

The first sentence should be a bit more explicit on what "security
layer" is being referred to, although the example helps.  How about a
change from:
  "If the authentication exchange is performed without a strong security
   layer (such as TLS with data confidentiality),"
To: "If the authentication exchange is performed without strong
session encryption (such as TLS with data confidentiality), "

4. Security Considerations:
It's safe to remove the last instance of the word "negotiation" in the
following sentence:
  "SCRAM does not negotiate a hash function to use. Hash function
   negotiation is left to the HTTP authentication mechanism negotiation."

Thanks!

-- 

Best regards,
Kathleen

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 28 Nov 2015 13:02:36 +0000

Hi Kathleen,
Thank you for your review comments.

> On 27 Nov 2015, at 23:55, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Alexey,
> 

Ok.

>   passwords over a channel protected by Transport Layer Security (TLS).

Yes, I will change.

> documented in the RFC published by this WG.  I'll let that go though.

SCRAM was created in response to Digest, so some text is appropriate.

>         binding is supported-but-not-used, not supported, or used .

Probably because of comments in XML. I think these would be stripped by RFC Editor.

> layer" is being referred to, although the example helps.

Right, this is a SASL term.

> How about a

Yes, something like this works.

>   negotiation is left to the HTTP authentication mechanism negotiation."

This is saying that SCRAM itself doesn't negotiate a hash function to use, each SCRAM mechanism is tied to a specific hash function, as the hash function is encoded in the HTTP authentication mechanism name. I don't have a strong preference, but I think your suggested version is slightly less clear on that. Either way, I expect RFC Editor to pick up on this!

Best Regards,
Alexey

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 28 Nov 2015 08:07:53 -0500

Hi Alexey,

Thanks for your quick response!  Inline.

Sent from my iPhone

> On Nov 28, 2015, at 8:02 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Kathleen,

Yes, I thought it sounded to rosie for digest in the abstract.

> Probably because of comments in XML. I think these would be stripped by RFC Editor.

Sounds good.
> Yes, something like this works.

Thanks.
> This is saying that SCRAM itself doesn't negotiate a hash function to use, each SCRAM mechanism is tied to a specific hash function, as the hash function is encoded in the HTTP authentication mecha…

It's just a nit, so either way is fine.

Thank you,
Kathleen