Subject: [http-auth] draft-ietf-httpauth-digest-13: comments

From: Brett Tate <[email-masked]>
Date: Wed, 4 Feb 2015 11:00:56 -0500

Hi,

The following are some comments concerning draft-ietf-httpauth-digest-13.

Thanks,
Brett

-----

Section 3.4 username: Does sending "username*" instead of "username"
introduce a relevant backward compatibility issue with RFC 2617 devices
(such as proxies)?

Section 3.4.5: The realm example is missing the mandatory quotes.

Section 3.9.1 paragraph 1: The http://www.example.org/dir/index.html is
shown with close quote without open quote.

Section 3.9.1 first Authorization header: As mentioned within section 3.4,
the URI must be within quotes.

Section 3.9.2 WWW-Authenticate header: As mentioned within section 3.3,
the qop value must be within quotes.

---

From: Sophie Bremer <[email-masked]>
Date: Wed, 4 Feb 2015 19:18:33 +0100

Hi Brett,

> introduce a relevant backward compatibility issue with RFC 2617 devices

Yes, but no. A proxy sends an Authentication Response, it can serve. And the client sends "username*" only, if the proxy indicates support of UTF-8 username without userhash.

> the URI must be within quotes.

Please further specify, where it is mentioned. Maybe this is mistaken with the domain parameter in the Authentication Response?

> the qop value must be within quotes.

Thanks, will be fixed.

Best Regards,
Sophie

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Feb 2015 19:31:41 +0100

> Yes, but no. A proxy sends an Authentication Response, it can serve. And the client sends "username*" only, if the proxy indicates support of UTF-8 username without userhash.

How does it indicate that? By adding the charset parameter? It might be 
a good idea to make that clearer...

Best regards, Julian

---

From: Brett Tate <[email-masked]>
Date: Wed, 4 Feb 2015 13:53:57 -0500

Hi,

Thanks for the response; reply is inline.

> > Section 3.4 username: Does sending "username*" instead
> > of "username" introduce a relevant backward compatibility
> > issue with RFC 2617 devices (such as proxies)?
>
> Yes, but no. A proxy sends an Authentication Response, it can
> serve. And the client sends "username*" only, if the proxy
> indicates support of UTF-8 username without userhash.

Consider client->proxy1->proxy2->server situation where all except proxy1
is draft compliant.  If proxy1 parses the Authorization and/or
Proxy-Authorization header, it may consider the header to be malformed.

> > Section 3.9.1 first Authorization header: As mentioned
> > within section 3.4, the URI must be within quotes.
>
> Please further specify, where it is mentioned. Maybe this
> is mistaken with the domain parameter in the Authentication
> Response?

If you were asking about section 3.4 reference...

"For historical reasons, a sender MUST only generate the quoted-string
syntax for the following parameters: username, realm, nonce, uri,
response, cnonce, and opaque."

If were asking about RFC 2617 reference to make above true, see RFC 2617
errata 2600.

If you were asking about Authorization header's URI reference missing
quoted value, the uri=/dir/index.html should be uri="/dir/index.html".

---

From: Sophie Bremer <[email-masked]>
Date: Wed, 4 Feb 2015 20:35:25 +0100

> Proxy-Authorization header, it may consider the header to be malformed.

Which nodes add Authentication options in the header? If proxy1 does not add an Authentication option, why does it parses Authorization headers?

> quoted value, the uri=/dir/index.html should be uri="/dir/index.html".

Thank you, got it.

---

From: Brett Tate <[email-masked]>
Date: Wed, 4 Feb 2015 15:11:11 -0500

Hi,

> >> Yes, but no. A proxy sends an Authentication Response, it
> >> can serve. And the client sends "username*" only, if the
> >> proxy indicates support of UTF-8 username without userhash.
> >
> > Consider client->proxy1->proxy2->server situation where all
> > except proxy1 is draft compliant.  If proxy1 parses the
> > Authorization and/or Proxy-Authorization header, it may
> > consider the header to be malformed.
>
> Which nodes add Authentication options in the header?

Proxy-Authenticate was added by proxy1 and proxy2; WWW-Authenticate was
added by the server.

> If proxy1 does not add an Authentication option, why does it
> parses Authorization headers?

It would parse Proxy-Authorization headers.  It may or may not attempt to
parse Authorization header.

I'm not familiar enough with the http RFCs to know if there is a
recommendation concerning if a malformed header should cause 1) rejecting
request, 2) removing header, 3) removing malformed portion of the header,
or 4) relaying header.

---

From: Sophie Bremer <[email-masked]>
Date: Thu, 5 Feb 2015 19:32:11 +0100

> Proxy-Authenticate was added by proxy1 and proxy2; WWW-Authenticate was

Thanks, now it is clear.

> request, 2) removing header, 3) removing malformed portion of the header,

The draft describes in "3.7. Security Protocol Negotiation" the hash negotiation of the server with the help of multiple WWW-Authenticate header options.
Your case is in some way the opposite. A client sends multiple Proxy-Authorization header options and involved proxies have to pick the right one.

In your example the first proxy has to expect picking up the wrong Proxy-Authorization option, so for me it is likely that proxy1 ignores the "malformed" ones.
Nevertheless it is possible, that the proxy rejects the request as a security feature. I agree that this is something the draft has to deal with.

How should this be covered? In "3.8. Proxy-Authenticate and Proxy-Authorization" it could be mentioned as a side note at the end, but is this enough? What do you think?

Best Regards,
Sophie

---

From: Sophie Bremer <[email-masked]>
Date: Thu, 5 Feb 2015 19:42:22 +0100

Hi Julian,

On 2015-02-04 19:31, Julian Reschke wrote:

> How does it indicate that? By adding the charset parameter? It might be a good idea to make that clearer...

3.4. says

   username

      The user's name in the specified realm.  If the username contains
      characters not allowed inside the ABNF token or quoted-string
      forms, it can be sent in a "username*" parameter instead, using
      the encoding defined in [RFC5987].  Sending both "username" and
      "username*" MUST be treated as error.

Is this not clear? How about:

   username

      The user's name in the specified realm. If the charset parameter
      is set and userhash is not possible, the username MAY contain
      characters not allowed inside the ABNF token or quoted-string.
      In this case it can be sent as "username*" parameter instead, using
      the encoding defined in [RFC5987].  Sending both "username" and
      "username*" MUST be treated as error.

Best Regards,
Sophie

---

From: Brett Tate <[email-masked]>
Date: Thu, 5 Feb 2015 14:08:07 -0500

> How should this be covered? In "3.8. Proxy-Authenticate
> and Proxy-Authorization" it could be mentioned as a side
> note at the end, but is this enough? What do you think?

A potential option would be to modify section 3.4 username paragraph to
allow both "username" and "username*".  If both are present, the
"username*" is used.  The "username" parameter is present for historical
reasons and would be ignored by draft compliant devices.  I guess based
upon the realm (maybe something else), the client assumes acceptable to
send/use "username*".  Since the draft doesn't really discuss "third party
authentication service", I'll assume that there is no related issue.

---

From: Sophie Bremer <[email-masked]>
Date: Sun, 8 Feb 2015 08:26:59 +0100

Hi Brett,

text below.

> authentication service", I'll assume that there is no related issue.

This is not possible, because "username* is not always in use. For example, if "userhash=true" and "charset=utf-8" are set, username contains a hash token in base64 without any hint of character encoding.

There is also a difference between "charset=utf-8" and the "username*" parameter itself. "username*" contains the encoding for the header notation, whereas "charset=utf-8" describes the encoding for hash calculations. So it is possible to use a different encoding for "username*" and convert this into UTF-8 for calculations.

The whole problem with "username*" has to be made clear in the draft, so we will cover this in some way.

Thank you for the comments!

Regards,
Sophie