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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 5 Nov 2014 09:21:46 -0500

Hi Alexey,

Thanks for the review and for your comments.
Sorry, for the late response on this; for some reason I completely missed
this email.

Please, see my reply inline...

Regards,
 Rifaat

On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov <[email-masked]>
wrote:

> Hi,
> Some notes/comments from reviewing the document.
>
> The definition of "stale" says:
>
>       The server should only set stale to
>       TRUE if it receives a request for which the nonce is invalid but
>       with a valid digest for that nonce (indicating that the client
>       knows the correct username/password).
>
> I think this is encouraging DoS on servers. I think it would be better if
> the check for staleness is done without computing the hash on the server
> side.
>

The text around that is not normative and uses "should" for the server's
operation.
Are you suggesting that we remove the "but with a valid digest for that
nonce (indicating that the client knows the correct username/password)"?

>       The notation unq(X) means the value of the quoted-string X without
>       the surrounding quotes.
>
> "Without the quotes" or "without the quotes and with quoting slashes
> removed"? I.e., what is used for a value "abc\"def"?
>

Sorry, I am not clear on this. Can you please elaborate on "quoting
slashes"?

> In 3.4.2 - is the definition of A1 for "MD5-sess" backward compatible with
> RFC 2617?
>

I believe it does; do you see anything to the contrary?

>
>
> Nonce-prime/cnonce-prime - are these limited to the same TCP connection?
>

I am not sure that I understand the question. Can you please elaborate?

>
>
> Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For
> example, it discourages use of Unicode Control characters.
>
> Is it Ok to fail authentication if a username is not in NFC? If yes, it
> would be good to mention how the server should respond in such case.
>

My character encoding knowledge is very limited, so I would have to defer
to the experts on this one.

Regards,
 Rifaat

>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Brett Tate <[email-masked]>
Date: Wed, 5 Nov 2014 10:23:43 -0500

>>> The notation unq(X) means the value of the
>>> quoted-string X without the surrounding quotes.
>>
>> "Without the quotes" or "without the quotes and with quoting
>> slashes removed"? I.e., what is used for a value "abc\"def"?
>
> Sorry, I am not clear on this. Can you please elaborate on
> "quoting slashes"?

He is attempting to understand how the following RFC 7230 section 3.2.6
snippet impacts the calculation.

"The backslash octet ("\") can be used as a single-octet quoting
 mechanism within quoted-string and comment constructs. "

I assume that calculations are performed with the backslashes removed (if
used for single-octet quoting).  Thus his example would use (abc"def)
within the calculation.

If the example was "abc\\def", I assume that "abc\def" would be used
within the calculation.

Thanks,
Brett

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 05 Nov 2014 18:55:04 +0000

Hi Rifaat,

On 05/11/2014 14:21, Rifaat Shekh-Yusef wrote:
> Sorry, for the late response on this; for some reason I completely 
> missed this email.
>
> On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>     I think this is encouraging DoS on servers. I think it would be
>     better if the check for staleness is done without computing the
>     hash on the server side.
>
>
> The text around that is not normative and uses "should" for the 
> server's operation.
> Are you suggesting that we remove the "but with a valid digest for 
> that nonce (indicating that the client knows the correct 
> username/password)"?
Yes.
> Sorry, I am not clear on this. Can you please elaborate on "quoting 
If you have a username with quote or slash character in it, do you add 
an extra slash to escape ("without the quotes") it or not ("without the 
quotes and with quoting slashes removed")? I think you want the latter, 
but the text is not very clear on that.
>
>
>     In 3.4.2 - is the definition of A1 for "MD5-sess" backward
>     compatible with RFC 2617?
>
>
Ok, it looks like. Never mind, I thought I saw some differences.
> I am not sure that I understand the question. Can you please elaborate?
The description says:

"It uses the server nonce from that challenge, herin called nonce-prime, 
and the first client nonce value to construct A1, herin called 
cnonce-prime as follows:"

The first where? On the same TCP connection? When used to authenticate 
as a particular user (whether on the same connection or not). I found 
the definition confusing.
>
>     Should RFC 5198 (Net Unicode) be recommended for use on top of
>     NFC? For example, it discourages use of Unicode Control characters.
>
>     Is it Ok to fail authentication if a username is not in NFC? If
>     yes, it would be good to mention how the server should respond in
>     such case.
>
>
> My character encoding knowledge is very limited, so I would have to 
> defer to the experts on this one.
I am not expert enough in this, but I believe the answer to both of 
these should be "yes".

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 5 Nov 2014 15:44:17 -0500

On Wed, Nov 5, 2014 at 1:55 PM, Alexey Melnikov <[email-masked]>
wrote:

> On Wed, Oct 22, 2014 at 9:34 AM, Alexey Melnikov <
> [email-masked]> wrote:
>
>> Hi,

I am ok with this. Any objection to this change?

> If you have a username with quote or slash character in it, do you add an
> extra slash to escape ("without the quotes") it or not ("without the quotes
> and with quoting slashes removed")? I think you want the latter, but the
> text is not very clear on that.
>

Ok. I will clarify that.

>
>
>> In 3.4.2 - is the definition of A1 for "MD5-sess" backward compatible
>> with RFC 2617?
>>
>
> and the first client nonce value to construct A1, herin called cnonce-prime
> as follows:"
>
> The first where? On the same TCP connection? When used to authenticate as
> a particular user (whether on the same connection or not). I found the
> definition confusing.
>

Yes, on the same TCP connection used by the first request and the following
challenge and response for a particular user.

The nonce-prime and cnonce-prime were introduced in one of the previous
versions of this document to try to clarify this A1 calculation.
I thought the original text was clear enough, but I guess it was not clear
enough for everybody.

We have few options here:
1. Revert back to the original text, without the nonce-prime/cnonce-prime
2. Keep the nonce-prime/cnonce-prime, but reword the current text.
3. Suggest new text

Do you have a preference?

> I am not expert enough in this, but I believe the answer to both of these
> should be "yes".
>

Ok. Let's discuss this next week in Honolulu.

Regards,
 Rifaat

---

From: Sophie Bremer <[email-masked]>
Date: Fri, 7 Nov 2014 20:14:26 +0100

Hello,

> Should RFC 5198 (Net Unicode) be recommended for use on top of NFC? For example, it discourages use of Unicode Control characters.
> 
> Is it Ok to fail authentication if a username is not in NFC? If yes, it would be good to mention how the server should respond in such case.

In my opinion it should be recommend, but fail should not be a requirement. If the server does not accept banished characters, the response should be HTTP status code 401.

The problem lies in hashed user names. In this case the server does not know automatically, if characters are Net Unicode. So for the sake of compatibility and interoperability it may be ignored.

Also RFC 5198 (3) says "... except in very unusual circumstances, all Net-Unicode strings be transmitted in normalized form. Recognition of the fact that some implementations of applications may rely on operating system libraries over which they have little control and adherence to the robustness principle suggests that receivers of such strings should be prepared to receive unnormalized ones and to not react to that in excessive ways."

Regards,
Sophie