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

[Kathleen Moriarty <[e-mail]>]

Hi Alexey,

Thanks for your quick response!  Inline.

Sent from my iPhone

> On Nov 28, 2015, at 8:02 AM, Alexey Melnikov <[e-mail]> wrote:
> 
> Hi Kathleen,
> Thank you for your review comments.
> 
>> On 27 Nov 2015, at 23:55, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> 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.
> 
> Ok.
> 
>> 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).
> 
> Yes, I will change.
> 
>> 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.
> 
> SCRAM was created in response to Digest, so some text is appropriate.

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

> 
>> 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 .
> 
> Probably because of comments in XML. I think these would be stripped by RFC Editor.

Sounds good.
> 
>> 3. Security Considerations
>> 
>> The first sentence should be a bit more explicit on what "security
>> layer" is being referred to, although the example helps.
> 
> Right, this is a SASL term.
> 
>> 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), "
> 
> Yes, something like this works.

Thanks.
> 
>> 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."
> 
> 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!

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

Thank you,
Kathleen 

> 
> Best Regards,
> Alexey
>