Subject: Re: [http-auth] WGLC for draft-ietf-httpauth-scram-auth-08

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Nov 2015 09:39:50 +0900

Reminder…

Thanks to Simon for the review. We need more!

Thanks

Rifaat & Yoav

> On 21 Oct 2015, at 9:24 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> HTTPAuth WG,
> 
> We are starting a Work Group Last Call (WGLC) for the draft-ietf-httpauth-scram-auth-08 document:
> https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-08 <https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-08>
> 
> This will be a 3 week WGLC, because of the IETF week.
> 
> Please, review the document and provide your feedback, on the HTTPAuth mailing list, by November 11, 2015.
> 
> Regards,
>  Rifaat & Yoav

---

From: Tony Hansen <[email-masked]>
Date: Mon, 2 Nov 2015 23:57:37 -0500

On 10/21/15 8:24 AM, Rifaat Shekh-Yusef wrote:
> HTTPAuth WG,
>
> We are starting a Work Group Last Call (WGLC) for the
> draft-ietf-httpauth-scram-auth-08 document:
> https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-08
>

I read through this draft. I spotted one nit that I sent directly to
Alexey. Other than that, I did not see anything wrong.

There are two open issues that need to be resolved before this is
forwarded to IETF LC:

*) Regarding the open issue "Should "sid" directive be an attribute or a
new HTTP header field shared with other HTTP authentication
mechanisms?", I think the way it is specified in this document as part
of the WWW-Authenticate header is just fine.

*) As indicated in the draft, information from Precis needs to be
incorporated.

After these two open issues are resolved, this is ready for IETF LC.

Simon Joseffson suggested that SCRAM-SHA-1 be removed from the draft. I
support this position.

    Tony

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Nov 2015 12:10:30 +0000

Hi Tony,

> of the WWW-Authenticate header is just fine.
Ok. I wouldn't mind going the other way (a separate header field), but 
somebody else needs to ask for it.
> *) As indicated in the draft, information from Precis needs to be
Actually, I believe the document is correct as specified, but it would 
be good for somebody like Peter Saint-Andre to double check.
> After these two open issues are resolved, this is ready for IETF LC.
Thank you!

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Nov 2015 12:07:32 +0000

Hi Simon,
Thank you for your comments.

On 26/10/2015 14:06, Simon Josefsson wrote:
> Rifaat Shekh-Yusef <[email-masked]> writes:
>
>> HTTPAuth WG,
>>
> There appears to be some traces of channel binding support, for example
> the security consideration talks about how to the SCRAM channel binding
> mechanism can be used to twart some attacks, and there is a reference to
> the tls-server-end-point document.  Further, section 5 says that the
> channel binding flag is 'n', 'y' or 'p', which is unhelpful as this
> document only supports 'n' so it should say that instead.
Ah, good point. I will fix.
> I believe it would be useful to have support for channel bindings when
> used over HTTPS to have better security properties.  Given the status of
> SCRAM-PLUS (with having to require tls-session-hash to have tls-unique
> be secure) I think it is acceptable to publish this document without it.
> Someone can specify a SCRAM-SHA256-PLUS HTTP Authentication Mechanism in
> the future should the need arise.
Right.
> I suggest dropping SCRAM-SHA-1 and focusing solely on SCRAM-SHA-256.
> Specifying both seems like a recipie for poor interop, and I don't see a
> significant use-case for having both.
Ok. We should migrate from SHA-1 variant, but the use case is interop 
with IMAP/XMPP. One can't migrate database from SCRAM-SHA-1 to 
SCRAM-SHA-256 by just updating it on the server.

Best Regards,
Alexey

---

From: Tony Hansen <[email-masked]>
Date: Tue, 10 Nov 2015 08:25:47 -0500

> be good for somebody like Peter Saint-Andre to double check.

My point really is: I don't think we can go to IETF LC with a section
named "Open Issues". That means either resolving all of the items in
section 12 and then removing the section.

    Tony

---

From: Tony Hansen <[email-masked]>
Date: Tue, 10 Nov 2015 08:30:08 -0500

By the way, my scram-256 draft got published as 7677

    Tony

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 14:50:03 +0100

> SCRAM-SHA-256 by just updating it on the server.

That use-case isn't mentioned in the draft as far as I can tell.  If
database re-use between application protocol is a motivator, it would be
useful to state that.

Thinking about this, I'm not sure how good of an idea that is.  Best
established practice is generally to not re-use credentials for
different purposes, and it could be argued that HTTP authentication is
different from XMPP or IMAP authentication.  A security consideration
about this seems warranted, so that people are aware that deploying that
would introduce a cross-protocol attack vector.  It should probably have
been in the base SASL and SCRAM specs too.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Nov 2015 15:55:51 +0000

> On 10 Nov 2015, at 13:25, Tony Hansen <[email-masked]> wrote:
> 

Yes, I deleted it in my copy already.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Nov 2015 15:59:31 +0000

> On 10 Nov 2015, at 13:50, Simon Josefsson <[email-masked]> wrote:
> 

Ok. The "let's not change SCRAM itself" discussion assumed that being the case, IMHO.
> been in the base SASL and SCRAM specs too.

There are mail servers that can also talk some specialised HTTP protocol using the same backend.