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

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Oct 2014 20:34:22 +0300

Hi all

Rifaat, David and Sophie have submitted version -08 in August.  The authors are of the opinion that the document is ready for publication, and it’s time for the group to weigh in on this subject.

This mail begins working group last call for this document. Please take the time to read the draft and send comments to the list about its security, applicability, clarity, and any other aspect you wish to discuss. Keep in mind that unlike the HOBA document, the intended status of this document is standards track, and it describes slight modifications to a protocol that is widely implemented and deployed.

The WGLC is two weeks long, and ends on October 21st. Please send your reviews as replies to this message.

Thanks,

Yoav & Matt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2014 22:52:28 +0100

Since I got such good reviews for HOBA I thought I'd try
reciprocate:-)

I think this is basically ready to go forward. There're
some things could be improved but nothing fatal.

Cheers,
S.

things that might be worth chatting about:
-----------------------------------------

- 3.3: domain parameter - is there a security
consideration or even a MUST needed about use
of TLS being consistent across all these
off-host URIs?

- 3.3, "domain": Is "responding server" not a
bit ambiguous?  That might be better to refer
to the web origin or maybe be specific about
the host/port/scheme bits you do mean if 2617
dictates that.

- 3.3, "nonce": the example given will repeat
within the same second with a 1-second
granularity time-stamp so seems like a bad
example to me. A better example could easily be
generated I bet, e.g. using HMAC-SHA256 maybe.

- 3.4: login failure being logged - is there
text saying to be careful in what you log so
that you won't put a cleartext password (e.g.
entered into the username field) into the log?

- 3.4.4: What is "H" here - is it the same as
something else or what? I think you need to say
which hash alg to use there. The same point
comes up elsewhere too, I've noted some below.

- 3.4.6: Do you need to say if Method is upper
case or what?

- 3.5, "rspauth": Same "What is H?" question
applies here I think.

- 5.12: I think this should be much more
prominent since this section describes what
actually happens - this is the threat to be
most worried about.

- 5.13: I didn't see it stated that users often
re-use passwords over >1 site (on average 8
apparently) so even if someone does a great job
with their implementation they remain
vulnerable to all the other crappy sites out
there using passwords.

minor things and nits:
---------------------

- 3.3, para 1: s/and include/and includes/

- 3.3, "nonce": is the should be unique there
sufficient? It's always nice to say when its ok
to not do what a SHOULD says but you don't.
(Not a big deal though.)

- 3.3, "nonce": "private-key" is a bad term to
use there, "secret-data" would be better.  You
also don't say what "H" might be - yes, it is
obvious but sure that's the kind of comment you
expect here right:-)

- 3,3, "stale": I think TRUE and FALSE here are
case insensitive, is that right? Would it be
good to say?

- 3.3, "algorithm": is the text at end starting
with "i.e., the digest..." misplaced? Should it
come before the example?

- 3,3, "userhash": s/Valid value/Valid values/
and I note you use lowercase for true and false
here but earlier used uppercase - why?

- 3.4, cnonce: ".in 3" before this is some kind
of nroff glitch I guess,

- 3.4.2, s/herin/herein/

- 5.2, 2nd para, maybe s/it is intended/it was
intended/ would be better?

- 5.2, referring to SHTTP seems silly, its dead
as a do-do isn't it?

- 5.8, the MD5 specific point is no longer
quote correct given the other hash functions
added here

On 07/10/14 18:34, Yoav Nir wrote:
> Hi all
> 
> Rifaat, David and Sophie have submitted version -08 in August.  The
> authors are of the opinion that the document is ready for
> publication, and it’s time for the group to weigh in on this
> subject.
> 
> This mail begins working group last call for this document. Please
> take the time to read the draft and send comments to the list about
> its security, applicability, clarity, and any other aspect you wish
> to discuss. Keep in mind that unlike the HOBA document, the intended
> status of this document is standards track, and it describes slight
> modifications to a protocol that is widely implemented and deployed.
> 
> Yoav & Matt _______________________________________________ http-auth
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 11 Oct 2014 14:12:10 -0400

Thanks for your review and comments, Stephen.

Please, see my reply inline...

Regards,
 Rifaat

> things that might be worth chatting about:
See section 5.1

> the host/port/scheme bits you do mean if 2617
The term "server being accessed" was used earlier in that same paragraph. I
will replace "responding server" with "server being accessed"; are you ok
with that?

> generated I bet, e.g. using HMAC-SHA256 maybe.
You are assuming that the time-stamp does not include milliseconds; right?

> entered into the username field) into the log?
Can you propose some text?

> comes up elsewhere too, I've noted some below.
This should be the same algorithm used to protect the credentials. I will
clarify that.
The H() notation is defined in section 3.3 under the 'algorithm" parameter
definition.

> - 3.4.6: Do you need to say if Method is upper
Ok.

> actually happens - this is the threat to be
What do you mean by "more prominent"?
If I move this section to be section 5.2, would that be prominent enough
for you?

> vulnerable to all the other crappy sites out
I can add some text around that.

> Ok

> Ok

> case insensitive, is that right? Would it be
The parameter is already defined as "A case-insensitive flag,"

> with "i.e., the digest..." misplaced? Should it
No. This text should be more generic, and aligned with the text above the
example; I will fix that.

> here but earlier used uppercase - why?
Lowercase values are consistently used for this parameter already.

> Yes

> - 3.4.2, s/herin/herein/
Ok

> intended/ would be better?
Ok

> - 5.2, referring to SHTTP seems silly, its dead
Ok

> quote correct given the other hash functions
Ok

Regards,
 Rifaat

> > publication, and it's time for the group to weigh in on this
> > subject.
> >
> _______________________________________________
> http-auth mailing list
> [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 11 Oct 2014 20:30:17 +0100

> Thanks for your review and comments, Stephen.

No probs.

>> of TLS being consistent across all these

I don't think its there. What you might want to say is
that all URIs in the domain param list SHOULD all use
the same scheme (https or http), but that mixing them
is a bad idea

> will replace "responding server" with "server being accessed"; are you ok

I'm ok either way, but it's a bit ambiguous compared
to the web-origin maybe - since 2617 pre-dates the SOP
I'm not sure if they're totally consistent

> You are assuming that the time-stamp does not include milliseconds; right?

Right. As is often the case. And 1ms is still relatively
long or maybe will be considered so in future. Maybe just
say that a timestamp with micro- or nano-seconds is good.

> Can you propose some text?

How about:

"Be careful in what you log so that you won't put
a cleartext password (e.g. entered into the username
field) into the log."

:-)

> If I move this section to be section 5.2, would that be prominent enough

Right. Were it me I'd say it in the abstract and intro
as well.

I think the rest is fine. (And to be clear I think the draft is
good enough already, we're just polishing here I reckon.)

Cheers,
S.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 11 Oct 2014 15:42:25 -0400

Ok.

Ok

Ok

> a cleartext password (e.g. entered into the username
Sure :)

> Right. Were it me I'd say it in the abstract and intro
I will move it to section 5.2

> good enough already, we're just polishing here I reckon.)
Great. Thanks again for your careful review; I appreciate that.

Regards,
 Rifaat

---

From: Michael Sweet <[email-masked]>
Date: Tue, 14 Oct 2014 10:53:30 -0400

Some quick (editorial) feedback:

- Section 3.1 (Overall Operation) mentions the password being hashed and never sent in the clear, but never says anything about the new optional username hashing support - might be worth a short mention that the server can advertise support for and the client can send hashes instead of plain text usernames as well.

- Section 3.2 (Representation of Digest Values) uses "not recommended" at the end of the first paragraph. Is this a RFC 2119 "NOT RECOMMENDED"? Probably also want a reference to RFC 2617 for backwards compatibility?

- Also in Section 3.2, editorial issue at end of second paragraph; suggest rewording as "MD5 digests are represented as 32 hexadecimal characters while SHA-256 and SHA-512/256 are represented as 64 hexadecimal characters."

- Section 3.3 editorial, suggest: '... the server responds with a "401 Unauthorized" status code and a WWW-Authenticate header with Digest scheme as per the framework defined above. The value of the header includes some or all of the following parameters:'

- Section 3.3 (domain): "should" should be "SHOULD" in the second paragraph about proxies.

- Section 3.3 (none): Break out note: as a separate paragraph instead of burying it in parenthesis?

- Section 3.3 (opaque): Both "should" and "recommended" are 2119 terms...

- Section 3.3 (stale): Drop comma after "flag"

- Section 3.3 (stale): "may", "should", "must" are all 2119 terms...

- Section 3.3 (charset): "optional" should be "OPTIONAL"

- Section 3.3 (userhash): "optional" should be "OPTIONAL", "Valid values" (plural)

- Section 3.3: Can we sort the list of parameters?

- Section 3.4 (The Authorization Request Header): How many times is the client expected to retry the request? At least once? Might be good to say something here.

- Section 3.4 (between qop and nc): Looks like a bad 'roff command (".in 3")???

- Section 3.4 (userhash): "optional" should be "OPTIONAL", "Valid values" (plural)

- Section 3.4.6 (Various Considerations): "must" and "may" used in second paragraph.

- Section 3.4.6 (Various Considerations): "should" used in third paragraph. Maybe reword the first sentence as "Authenticated transactions can interact with shared caches."

- Section 3.5 (nextnonce): "may", "should", and "must" used.

- Section 3.6 (Digest Operation): "may", "must", and "should" used.

- Section 3.7 and later: Search for "may", "must", "optional", "recommended", and "should".

> The WGLC is two weeks long, and ends on October 21st. Please send your reviews as replies to this message.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 Oct 2014 00:55:16 -0400

Thanks Michael,

I will address these comments in the next version of the draft.

Regards,
 Rifaat

On Tue, Oct 14, 2014 at 10:53 AM, Michael Sweet <[email-masked]> wrote:

> - Section 3.1 (Overall Operation) mentions the password being hashed and
> never sent in the clear, but never says anything about the new optional
> username hashing support - might be worth a short mention that the server
> can advertise support for and the client can send hashes instead of plain
> text usernames as well.
>
> - Section 3.2 (Representation of Digest Values) uses "not recommended" at
> the end of the first paragraph. Is this a RFC 2119 "NOT RECOMMENDED"?
> Probably also want a reference to RFC 2617 for backwards compatibility?
>
> - Also in Section 3.2, editorial issue at end of second paragraph; suggest
> rewording as "MD5 digests are represented as 32 hexadecimal characters
> while SHA-256 and SHA-512/256 are represented as 64 hexadecimal characters."
>
> - Section 3.3 editorial, suggest: '... the server responds with a "401
> Unauthorized" status code and a WWW-Authenticate header with Digest scheme
> as per the framework defined above. The value of the header includes some
> or all of the following parameters:'
>
> - Section 3.4 (The Authorization Request Header): How many times is the
> client expected to retry the request? At least once? Might be good to say
> something here.
>
> - Section 3.4.6 (Various Considerations): "should" used in third
> paragraph. Maybe reword the first sentence as "Authenticated transactions
> can interact with shared caches."
>
> authors are of the opinion that the document is ready for publication, and
> it's time for the group to weigh in on this subject.
> >
> > This mail begins working group last call for this document. Please take
> the time to read the draft and send comments to the list about its
> security, applicability, clarity, and any other aspect you wish to discuss.
> Keep in mind that unlike the HOBA document, the intended status of this
> document is standards track, and it describes slight modifications to a
> protocol that is widely implemented and deployed.
> >