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

From: Brett Tate <[email-masked]>
Date: Mon, 5 Jan 2015 11:10:27 -0500

Hi,

Should draft-ietf-httpauth-digest-09 indicate how to remain interoperable
(backward compatible) with RFC 2617 compliant devices?  It seems like it
should.  For instance, isn’t that why RFC 7235 section 2.2 indicates the
following concerning the realm?

“For historical reasons, a sender MUST only generate the quoted-string
syntax.”

However if the working group doesn’t think that it is important, the
vendors are likely smart enough to look at RFC 2617 if experiencing
interoperability issues with older devices.

Thanks,

Brett

*From:* Rifaat Shekh-Yusef [mailto:[email-masked]]
*Sent:* Saturday, December 20, 2014 10:43 AM
*To:* Brett Tate
*Cc:* Julian Reschke; [email-masked]
*Subject:* Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt

Hi Brett,

Thanks for your review and comments.

Please, see my reply inline...

Regards,

 Rifaat

On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate <[email-masked]> wrote:

Hi,

Concerning the quoted-string ambiguity, I agree that the ambiguity still
exists.

Draft-ietf-httpauth-digest-09 did not address my quoted string general
comment.

http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html

Was it not addressed because of working group discussion at IETF 91?  If
so, I have the same comment.  The draft is not clear concerning when
quoted strings MUST/SHOULD/MAY be used.  For historical reasons, the
resolution from a sender perspective should be backward compatible with
RFC 2617 which used ABNF to clearly indicate the mandate.

Yes, it was discussed.

Here is a quote from the minutes:

-- Quoted Strings Issue:

   Julian: I think the slide is probably correctly. However, do we
know for sure if this is required for historical reasons?

           Better not to put edge cases into the spec if we don't need them

Additional comments inline.

>     qop
>        Indicates what "quality of protection" the client has applied to
>        the message. Its value MUST be one of the alternatives the server
>        indicated it supports in the WWW-Authenticate header field. These
>        values affect the computation of the response. Note that this is
a
>        single token, not a quoted list of alternatives as in WWW-
>        Authenticate.
>
> Can it use quoted-string nevertheless?

Not if the draft/device wants to remain backward compatible with RFC 2617.

Agree

---

From: Yoav Nir <[email-masked]>
Date: Mon, 5 Jan 2015 18:40:51 +0200

<no hats>

I think it’s obvious that backward compatibility is important. If you are deploying something new with no legacy implementations around, you are not going to pick Basic or Digest (I hope). The point of Digest is to keep implementations functioning when the crypto library removes MD5 and when the password database suddenly contains names and passwords with non-ASCII characters.

Yoav

> On Jan 5, 2015, at 6:10 PM, Brett Tate <[email-masked]> wrote:
> 
> Hi,
>  
> Should draft-ietf-httpauth-digest-09 indicate how to remain interoperable (backward compatible) with RFC 2617 compliant devices?  It seems like it should.  For instance, isn’t that why RFC 7235 section 2.2 indicates the following concerning the realm?
>  
> “For historical reasons, a sender MUST only generate the quoted-string syntax.”
>  
> However if the working group doesn’t think that it is important, the vendors are likely smart enough to look at RFC 2617 if experiencing interoperability issues with older devices.
>  
> Thanks,
> Brett
>  
> From: Rifaat Shekh-Yusef [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: Saturday, December 20, 2014 10:43 AM
> To: Brett Tate
> Cc: Julian Reschke; [email-masked] <mailto:[email-masked]>
> Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-09.txt
>  
> Hi Brett,
>  
> On Mon, Dec 15, 2014 at 8:56 AM, Brett Tate <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html <http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html>
> 
>    Julian: I think the slide is probably correctly. However, do we know for sure if this is required for historical reasons?
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 7 Jan 2015 19:41:44 -0500

Brett,

I am fine with the text you proposed here:
http://www.ietf.org/mail-archive/web/http-auth/current/msg01949.html

Julian,

The proposed text seems useful for backward compatibility reasons.
What is your concern exactly with that text?

Regards,
 Rifaat

On Mon, Jan 5, 2015 at 11:40 AM, Yoav Nir <[email-masked]> wrote:

> <no hats>
>
> I think it's obvious that backward compatibility is important. If you are
> deploying something new with no legacy implementations around, you are not
> going to pick Basic or Digest (I hope). The point of Digest is to keep
> implementations functioning when the crypto library removes MD5 and when
> the password database suddenly contains names and passwords with non-ASCII
> characters.
>
> Yoav
>
> should.  For instance, isn't that why RFC 7235 section 2.2 indicates the
> "For historical reasons, a sender MUST only generate the quoted-string
> syntax."
>
>
> However if the working group doesn't think that it is important, the

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Jan 2015 12:21:52 +0100

On 2015-01-08 01:41, Rifaat Shekh-Yusef wrote:
> ...

My concern was to put in requirements for backwards compat when we 
aren't sure that they are needed; if you Digest experts agree that they 
are needed, then yes, put them in.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jan 2015 14:53:48 +0100

Hi there,

I'm looking at 
<https://trac.tools.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-12.txt&url1=draft-ietf-httpauth-digest-09.txt> 
and how the feedback below was addressed...:

On 2014-12-14 17:26, Julian Reschke wrote:
> ...
>        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 web-origin. All URIs in this list
>        SHOULD use the same scheme (https or http); mixing them is a bad
>        idea.
>
> web_origin and canonical root need definitions.
> ...

This now reads:

>       A quoted, space-separated list of URIs, as specified in [RFC3986],
>       that define the protection space.  If a URI is an abs_path, it is
>       relative to the canonical root URL (See Section 2.2 of [RFC7235])
>       of the web-origin [RFC6454].  An absolute-URI in this list may
>       refer to a different server than the web-origin.  The client can

It's still not clear to me why we need both "canonical root URL" *and* 
web-origin here. Can you explain?

Also:

> Why is mixing them a "bad idea"? - maybe this could be explained better.

This text is still here.

> ...
>     stale
>        A case-insensitive flag indicating that the previous request from
>        the client was rejected because the nonce value was stale. If
>        stale is TRUE, the client MAY wish to simply retry the request
>
> "MAY wish" doesn't seem like a case for a BCP14 keyword.

This now says "may wish"; please avoid lowercase BCP14 keywords. Maybe 
"might wish"?

> 3.4 The Authorization Request Header
>
> s/header/header field/

There are still cases where the spec just says "header".

> ...
>     uri
>        The URI from request-target of the Request-Line; duplicated here
>        because proxies are allowed to change the Request-Line in transit.
>
> The request-target of the Request-Line isn't necessarily a URI...
> ...

This now says:

>       The Effective Request URI [RFC7230] from request-target of the
>       Request-Line; duplicated here because proxies are allowed to
>       change the Request-Line in transit.

I'd change the citation to "(Section 5.5 of [RFC7230])". Also change 
"from request-target of the Request-Line" to "of the HTTP request". 
Finally, "Request-Line" has been lowercased in 7230. Maybe say: "...to 
change the "request target ("request-target", Section 3.1.1 of 
[RFC7230]) in transit".

>        values affect the computation of the response. Note that this is a

?
> 3.4.6 Various Considerations
>
>     The "Method" value is the HTTP request method, in all-uppercase US-
>     ASCII letters, as specified in section 3.1.1 of [RFC7230]. The
>
> Hm, no. The registered methods happen to be all-uppercase, but method
> names are case-sensitive.
>
>     Implementers should be aware of how authenticated transactions
>
> ...need to be...
>
>     interact with shared caches. The HTTP/1.1 protocol specifies that
>
> s/The HTTP/1.1 protocol/HTTP/

Still says "HTTP protocol". The "P" in "HTTP" however already stands for 
"Protocol".

>     when a shared cache (see [RFC7234]) has received a request containing
>     an Authorization header field and a response from relaying that
>     request, it MUST NOT return that response as a reply to any other
>     request, unless one of two Cache-Control (see section 3.2 of
>     [RFC7234]) directive was present in the response. If the original
>     response included the "must-revalidate" Cache-Control directive, the
>     cache MAY use the entity of that response in replying to a subsequent
>     request, but MUST first revalidate it with the origin server, using
>     the request header fields from the new request to allow the origin
>     server to authenticate the new request. Alternatively, if the
>     original response included the "public" Cache-Control directive, the
>     response entity MAY be returned in reply to any subsequent request.
>
> Do we need to replicate this information here? (Asking because the Basic
> spec does not)

This test is still here.

> 3.5 The Authentication-Info Header
>
>     The Authentication-Info header field is a generic field that MAY be
>     used by a server to communicate some information regarding the
>     successful authentication of a client response. The following is the
>     syntax of the header:
>
>             Authentication-Info = auth-info
>
>             auth-info = *auth-param
>
> This needs to be "#auth-param" and invoke the list ABNF extension from
> RFC 7230.
>
>     The auth-param is defined in [RFC7235].
>
> (I still believe we should extract this into a separate spec)

See <https://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00>.

>     information. (Note that any such use can also be accomplished more
>     easily and safely by including the state in the nonce.) For example,
>     a server could be responsible for authenticating content that
>     actually sits on another server. It would achieve this by having the
>     first 401 response include a domain parameter whose value includes a
>     URI on the second server, and an opaque parameter whose value
>     contains the state information. The client will retry the request, at
>     which time the server might respond with a 301/302 redirection,
>
> Do not exclude 307/308. Just say "HTTP Redirection (Section 6.4 of
> [RFC7231])"

Now says:

>    at which time the server might respond with "HTTP Redirection
>    (Section 6.4 of [RFC7231]), pointing to the URI on the second server.

(double quote missing)

>     When the client receives the response it SHOULD use the topmost
>     header field that it supports, unless a local policy dictates
>
> First challenge.

Now reads:

>    When the client receives the first challenge it SHOULD use the
>    topmost header field that it supports, unless a local policy dictates
>    otherwise.  The client MUST ignore any challenge it does not
>    understand.

I believe this should be: "when the client received the response it 
SHOULD use the first challenge that it supports..."

>     otherwise. The client SHOULD ignore any challenge it does not
>     understand.
>
> MUST, I believe.
>
> Also, this sounds like requirements that are generic to WWW-A, not
> specific to Digest, no?

Again, this is something we should discuss? It IMHO does not belong 
here; this spec should not make any normative statements about how the 
framework works.

> 5.6 Weakness Created by Multiple Authentication Schemes
>
>     An HTTP/1.1 server MAY return multiple challenges with a 401
>     (Authenticate) response, and each challenge MAY use a different auth-
>     scheme. A user agent MUST choose to use the strongest auth- scheme it
>
> s/auth- scheme/auth-scheme/

Still there.

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 25 Jan 2015 10:34:07 -0500

Inline...

On Sun, Jan 25, 2015 at 8:53 AM, Julian Reschke <[email-masked]>
wrote:

> Hi there,
>
> I'm looking at <https://trac.tools.ietf.org/rfcdiff?url2=draft-ietf-
> httpauth-digest-12.txt&url1=draft-ietf-httpauth-digest-09.txt> and how
> the feedback below was addressed...:
>

After reading the definition of canonical root URL, it seems that the
mentioned of web-origin is somewhat redundant; I will remove that
web-origin.

>  Why is mixing them a "bad idea"? - maybe this could be explained better.

As I mentioned before, this text was copied from RFC2617, and I am not sure
why this was considered to be a bad idea, and nobody could provide an
explanation.

Should I remove that text?

> There are still cases where the spec just says "header".

ok

> I'd change the citation to "(Section 5.5 of [RFC7230])". Also change "from
> request-target of the Request-Line" to "of the HTTP request". Finally,
> "Request-Line" has been lowercased in 7230. Maybe say: "...to change the
> "request target ("request-target", Section 3.1.1 of [RFC7230]) in transit".
>
> ok

>> Can it use quoted-string nevertheless?

No; for backward compatibility.

> Still says "HTTP protocol". The "P" in "HTTP" however already stands for

ok

>> Do we need to replicate this information here? (Asking because the Basic

I will remove it.

> See <https://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00>.

I see the value of the new draft, but I am worried about about the delay
the new draft might cause to this document.
It is up to the WG to make a decision on how they want to proceed with this.

>>    (Section 6.4 of [RFC7231]), pointing to the URI on the second server.

ok

> I believe this should be: "when the client received the response it SHOULD
> use the first challenge that it supports..."

ok

> Again, this is something we should discuss? It IMHO does not belong here;
> this spec should not make any normative statements about how the framework
> works.
>
>
I could not find any mention of this in the framework document; can you
point to where it is mentioned?

>> s/auth- scheme/auth-scheme/
ok

Thanks,
 Rifaat

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Jan 2015 17:08:34 +0100

On 2015-01-25 16:34, Rifaat Shekh-Yusef wrote:
> Inline...
> ...
>     It's still not clear to me why we need both "canonical root URL"
>     *and* web-origin here. Can you explain?
>
>

Exactly. Thanks a lot!

> As I mentioned before, this text was copied from RFC2617, and I am not
> sure why this was considered to be a bad idea, and nobody could provide
> an explanation.

I can't see in in 2617.

> Should I remove that text?

If we don't know what it's about, then yes :-)

> No; for backward compatibility.

Then please say that more clearly.

>     See
>     <https://tools.ietf.org/html/__draft-reschke-httpauth-auth-__info-00
>     <https://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00>>.
>
>

Indeed.

If it decides not to, you may want to steal some text from my draft.

>     here; this spec should not make any normative statements about how
>     the framework works.
>
>

<http://greenbytes.de/tech/webdav/rfc7235.html#rfc.section.2.1.p.9>:

"Both the Authorization field value and the Proxy-Authorization field 
value contain the client's credentials for the realm of the resource 
being requested, based upon a challenge received in a response (possibly 
at some point in the past). When creating their values, the user agent 
ought to do so by selecting the challenge with what it considers to be 
the most secure auth-scheme that it understands, obtaining credentials 
from the user as appropriate. Transmission of credentials within header 
field values implies significant security considerations regarding the 
confidentiality of the underlying connection, as described in Section 6.1."

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 25 Jan 2015 12:34:24 -0500

>> sure why this was considered to be a bad idea, and nobody could provide
Sorry; it was based on a feedback from Stephen Farrell:
http://www.ietf.org/mail-archive/web/http-auth/current/msg01933.html

*Stephen,*

Can you please elaborate on your comment above?

> Then please say that more clearly.

It is already stated in section 3.4:

" For historical reasons, a sender MUST NOT generate the quoted-string
   syntax for the following parameters: algorithm, qop, and nc."

> If it decides not to, you may want to steal some text from my draft.

Sure.

> value contain the client's credentials for the realm of the resource being
> requested, based upon a challenge received in a response (possibly at some
> point in the past). When creating their values, the user agent ought to do
> so by selecting the challenge with what it considers to be the most secure
> auth-scheme that it understands, obtaining credentials from the user as
> appropriate. Transmission of credentials within header field values implies
> significant security considerations regarding the confidentiality of the
> underlying connection, as described in Section 6.1."
>
>
Although it is only implied, I think it is good enough; I will remove this
text from my draft.

Regards,
 Rifaat

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 25 Jan 2015 23:03:39 +0000

> Can you please elaborate on your comment above?

I didn't check much (can do tomorrow if it helps) but I think
the issue was a list that mixed http and https schemed URIs
would mean that a dictionary attackable authentication scheme
was sometimes being used over TLS and sometimes not, which I
think is a bad plan.

S.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 26 Jan 2015 07:46:59 +0100

> was sometimes being used over TLS and sometimes not, which I

Well, if there is a concern, it needs more explanation.

Best regards, Julian