Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.txt

From: Gary Mort <[email-masked]>
Date: Mon, 12 May 2014 15:03:18 -0400

3.3
      <http://tools.ietf.org/html/draft-ietf-httpauth-digest-07#section-3.3>
      The WWW-Authenticate Response Header

" domain
       A quoted, space-separated list of URIs, as specified inRFC 3986  <http://tools.ietf.org/html/rfc3986>

       [RFC3986  <http://tools.ietf.org/html/rfc3986>], that define the protection space.  If a URI is an
       abs_path, it is relative to the canonical root URL of the server
       being accessed. An absolute-URI in this list may refer to a
       different server than the one being accessed. The client can use
       this list to determine the set of URIs for which the same
       authentication information may be sent: any URI that has a URI in
       this list as a prefix (after both have been made absolute) may be
       assumed to be in the same protection space. If this parameter is
       omitted or its value is empty, the client should assume that the
       protection space consists of all URIs on the responding server."

Looking at the source code for both Firefox and Google Chrome - I find 
that this header is ignored by both browsers.  There is an outstanding 
issue for Chrome mentioning that they have assigned this low priority 
since Firefox never supported it.

Are there any browsers which support this feature?  If not, it would be 
better to deprecate the feature entirely then document a feature no one 
will support.

If the feature is worthwhile[and I happen to think it is] it should be 
placed as an independent RFC.  Moreover, I would recommend that in a 
seperate RFC, the "Domains" option should remain deprecated and be 
replaced with some more explicit options.

As currently written, "Domains" has the same security issues as session 
cookies and cross domain usage.  IE just as allowing one domain to set a 
cookie value for another unrelated domain is a security issue - allowing 
one domain to set an http authentication header for other domains is an 
issue.

-Gary A Mort

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 13 May 2014 09:00:04 -0400

Hi Gary,

This is an optional parameter, so systems are not obliged to support it.
Browsers might not support it, but there might be some web services out
there that use it.

So, I am not sure that it would be a good idea to deprecate it.

Regards,
 Rifaat

On Mon, May 12, 2014 at 3:03 PM, Gary Mort <[email-masked]> wrote:

>  3.3 <http://tools.ietf.org/html/draft-ietf-httpauth-digest-07#section-3.3> The WWW-Authenticate Response Header
>
>
>   " domain
>       A quoted, space-separated list of URIs, as specified in RFC 3986 <http://tools.ietf.org/html/rfc3986>
>
> issue for Chrome mentioning that they have assigned this low priority since
> Firefox never supported it.
>
>
> seperate RFC, the "Domains" option should remain deprecated and be replaced
> with some more explicit options.
>

---

From: Gary Mort <[email-masked]>
Date: Tue, 13 May 2014 12:39:55 -0400

On 05/13/2014 09:00 AM, Rifaat Shekh-Yusef wrote:
> Browsers might not support it, but there might be some web services 
> out there that use it.
>

Personally, I feel if it is not actively being used, it is better not to 
have it listed in the spec - especially since there are security 
implications to it. While the digest spec is theoretically used for 
transmission of passwords and possibly usernames, in implementation 
nothing restricts the use to passwords and possibly usernames.  For 
example, it can be used to store session id's by redirecting first time 
visitors to sessionid@uri and then responding with a 401 code.   Most 
clients will skip prompting the user for credentials and instead attempt 
to use the designated password as the credentials - creating a session 
id in the header without the use of cookies.

Implementations which support the domain option would then be vulnrible 
to session hi-jacking as other domains can set their session id.

I would tend towards deprecating a feature that is potentially used that 
has a potential security issue.  If there was actual usage of this 
feature, then I would say actual usage trumps potential security issues.

I don't know of any active usage of the Domain feature, so I would 
rather see it removed entirely.  At the very least, by deprecating it in 
a draft you can find out if anyone is using it when they complain.  
Additionally, even if removed, it could be brought back as a seperate 
RFC - especially since the Domain feature is generic enough to be used 
in any of the authentication schemes - there is no reason to limit it to 
only digest mode.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 13 May 2014 12:55:49 -0400

I do not have a strong opinion on this issue.
Do other people have an opinion on this?

Regards,
 Rifaat

On Tue, May 13, 2014 at 12:39 PM, Gary Mort <[email-masked]> wrote:

> transmission of passwords and possibly usernames, in implementation nothing
> restricts the use to passwords and possibly usernames.  For example, it can
> be used to store session id's by redirecting first time visitors to
> sessionid@uri and then responding with a 401 code.   Most clients will
> skip prompting the user for credentials and instead attempt to use the
> designated password as the credentials - creating a session id in the
> header without the use of cookies.
>
> Implementations which support the domain option would then be vulnrible to
> session hi-jacking as other domains can set their session id.
>
> has a potential security issue.  If there was actual usage of this feature,
> then I would say actual usage trumps potential security issues.
>
> I don't know of any active usage of the Domain feature, so I would rather
> see it removed entirely.  At the very least, by deprecating it in a draft
> you can find out if anyone is using it when they complain.  Additionally,
> even if removed, it could be brought back as a seperate RFC - especially
> since the Domain feature is generic enough to be used in any of the
> authentication schemes - there is no reason to limit it to only digest mode.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>