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

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Oct 2014 17:01:05 +0300

Hi

Just a reminder. We’ve had one good review from Stephen, but we would like to have more, especially with this being standards track.

We’ve had plenty of good discussion previously, so at this point a “looks good”, “stick a fork in it - it’s done”, or a “it’s ready” is welcome. 

Thanks

Yoav & Matt

On Oct 7, 2014, at 8:33 PM, Yoav Nir <[email-masked]> 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 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: Benjamin Kaduk <[email-masked]>
Date: Fri, 17 Oct 2014 15:23:57 -0400 (EDT)

On Tue, 14 Oct 2014, Yoav Nir wrote:

> We’ve had plenty of good discussion previously, so at this point a
> “looks good”, “stick a fork in it - it’s done”, or a “it’s ready” is
> welcome.

Here are some more comments.  (I tried to skip things that had already
been mentioned in previous messages.)

This specification gives a lot of implementation freedom for servers
generating the 'nonce' values, leaving it unspecified whether an explicit
list of valid nonces is retained or the validity/freshness of a nonce can
be verified in some other way.  It seems like it should be desirable for
it to be impossible for an attacker to guess values (not already observed)
that would be considered as valid 'nonce' values by the server.  I have
seen this "un-guessability" requirement explicitly stated in other
documents, so it may be appropriate here.  (The given example with a hash
of timestamp and private key satisfies the unguessability requirement.)

It seems like the existence of the 'stale' flag might give a little bit of
leverage to online attackers, who could observe a single nonce and
continue to use it to determine whether a trial password is valid, even
after that nonce's validity period ends.  That said, given that there's an
offline attack if the attacker can observe a successful exchange, worrying
about an online guessing attack may not be worthwhile...

The text about the qop and cnonce in the reply might be harder to
understand than is necessary.  My understanding just from reading the
document is that the flow is as follows: the server might send a list of
qops in its WWW-Authenticate response header.  If it does, the client MUST
reply with both a qop and a cnonce in its subsequent request, and the qop
must be one of the items from the server's list.  (Thus, if the server
sends a list with no entries that the client understands, the client can't
do anything.)  If the server does not send a list of qops, the client
sends neither a qop nor a cnonce.  On the other hand, maybe the bit at the
top about "the request includes some or all of the following parameters"
means that the client can omit the qop despite the normative language
("Its value MUST be").  Given that I'm still not sure, things could
probably be more clear.

The examples for 'nc' all are eight hex digits, with leading zeros.  Is it
a requirement that this field always has this field width?  If so, the
document should say that.  It may otherwise be worth some text about the
treatment of leading zeros.

Should the example use www.example.org instead of www.nowhere.org?

In 3.6, can you point me to some previous list traffic where the "easily
and safely" bit about putting state in 'nonce' instead of 'opaque' is
justified?  I don't think the explanatory text needs to be in the final
document, I just want to know that the text is in fact justified.

Can you give guidance on the length of nonce and cnonce?  The examples all
seem to be using hash output for the nonce field, which should be a
perfectly fine way to do it, but the hash construction is not required.
Furthermore, one of the examples has only an 8-character (hex) cnonce
whereas the other has 256 bits (?) worth.  The 32-bit one seems like it
might be a little too short for comfort....

More minor editorial issues:

In 3.4.2, I would move "herein called cnonce-prime" to be right after
"client nonce value" (that is, before "to construct A1"), to avoid
possible confusion.

In 3.5, isn't it the response (not the request) whose parameters are being
itemized?  (The text currently has "The request includes some or all of
the following parameters:".)

In 3.6, only MD5 is mentioned, but this document uses more hashes.

Also in 3.6, there's an internal reference to "3.6 below" which looks like
it should be 3.8 instead.

The third paragraph of 5.4 has an extra blank line in the middle of it.

5.6 is given the header "online dictionary attacks", but what is being
described seems more like an offline attack than an online one, to me.

In 5.9 and 5.10, if I was writing this, I'm not sure I'd use the phrase
"chosen plaintext attack" to describe something that seems to just be "the
attacker forces the client to use a particular nonce".  It's not exactly
wrong, though, so this is probably just a matter of taste where I should
not try to force my opinion onto everyone.

-Ben

---

From: Sophie Bremer <[email-masked]>
Date: Sat, 18 Oct 2014 17:12:35 +0200

Hello Benjamin,

wrong mail address. Again...

as I am responsible for the examples, let me answer the related points.

> Should the example use www.example.org instead of www.nowhere.org?

In there current state the examples are not correct. My plan for the correction is to use Mufasa and [email-masked] like in rfc2617. Would this be better?

> might be a little too short for comfort....

Actually the cnonce and nonce can be any character. So to point this out my suggestion would be some base64 values with 256 bit. Or maybe base64 for the MD5 and utf8 for SHAs to make the point clear?

Regards,
Sophie

---

From: Mike Sweet <[email-masked]>
Date: Sat, 18 Oct 2014 13:40:34 -0400

I think [email-masked] would be more in line with RFC guidelines...

Sent from my iPhone

> On Oct 18, 2014, at 11:12 AM, Sophie Bremer <[email-masked]> wrote:
> 
> Hello Benjamin,
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 18 Oct 2014 22:22:35 -0400 (EDT)

On Sat, 18 Oct 2014, Sophie Bremer wrote:

> In there current state the examples are not correct. My plan for the
> correction is to use Mufasa and [email-masked] like in rfc2617.
> Would this be better?

I agree with Mike Sweet that we should be using the RFC 2606 names.

> Actually the cnonce and nonce can be any character. So to point this out
> my suggestion would be some base64 values with 256 bit. Or maybe base64
> for the MD5 and utf8 for SHAs to make the point clear?

That would be helpful.

What I am really interested in is some discussion of, if not how the
nonces perform their cryptographic purpose(s), how long they need to be in
order to have the desired effect [of preventing chosen-plaintext attacks).
I'm not enough of a cryptographer to be able to say with any confidence
what the lengths should be.

-Ben

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 Oct 2014 02:33:32 -0400

Thanks Ben,

Please, see my reply inline...

Regards,
 Rifaat

On Fri, Oct 17, 2014 at 3:23 PM, Benjamin Kaduk <[email-masked]> wrote:

> > Just a reminder. We've had one good review from Stephen, but we would
> like to have more, especially with this being standards track.
> >
> > We've had plenty of good discussion previously, so at this point a
> > "looks good", "stick a fork in it - it's done", or a "it's ready" is
> > welcome.
>
I am not sure how to address this comment.
Yes, the text considers the 'nonce' values as implementation details; are
you suggesting that we make some normative text around that instead?

> qops in its WWW-Authenticate response header.

Actually, the text requires all servers to use this parameter:

qop
      This parameter MUST be used by all implementations compliant with
      this version of the Digest scheme.

>   If it does, the client MUST
No, the quoted text just means some of the parameters used by the client or
server are optional.
The details of the parameter will indicate which is required and which is
optional.

> document, I just want to know that the text is in fact justified.
That would have been done during the work on RFC2617, not this draft,
because this text was copied from RFC2617.

> More minor editorial issues:
I will address these in the next version of the draft.

Regards,
 Rifaat

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Oct 2014 12:02:06 -0400 (EDT)

> you suggesting that we make some normative text around that instead?

I don't think there needs to be anything normative.

The current version sort-of states the purpose of the nonces, noting that
the cnonce value is used to avoid chosen plaintext attacks, and I guess
it's implicit that the 'nonce' field is used to prove the freshness of the
client response.

I would like (but do not attempt to require) to see the document say
something more explicit, like "the cnonce value is used by both client and
server to avoid chosen plaintext attacks [...].  To fulfil this purpose,
the attacker must not be able to guess a cnonce value that will be chosen
by the client; a cnonce containing at least N bits of random input in each
cnonce is believed to be sufficient for this purpose." or "A server
specified data string which should be uniquely generated each time a 401
reponse is made.  This value is used to prove the freshness of the client
response; in order to fulfil this purpose, an attacker must not be able to
guess nonce values which will be accepted as valid by the server (that
have not actually been sent by the server).  Including at least M bits of
private random data in the generation of the nonce (such as from a private
key included in a hash calculation) is believed to be sufficient for this
purpose."  These forms give both the motivation for including the field,
and guidance on how much randomness must be used in order to succeed at
that purpose.

(Well, they would if values of 'N' and 'M' were given.  From an informal
survey of existing cryptographic usage, 160 and 128, respectively, ought
to be sufficient, but may (or may not) be overkill.)

>       this version of the Digest scheme.

Oh, right, my mistake.

> because this text was copied from RFC2617.

Hmm, that is fifteen years old already; perhaps it should be revisited in
case there were developments in the interim that affect its validity.

-Ben