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

From: [email-masked]
Date: Sat, 18 Jan 2014 05:27:12 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : HTTP Digest Access Authentication
        Authors         : Rifaat Shekh-Yusef
                          David Ahrens
                          Sophie Bremer
	Filename        : draft-ietf-httpauth-digest-02.txt
	Pages           : 28
	Date            : 2014-01-18

Abstract:
   HTTP provides a simple challenge-response authentication mechanism
   that may be used by a server to challenge a client request and by a
   client to provide authentication information. This document defines
   the HTTP Digest Authentication scheme that may be used with the
   authentication mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 08:30:37 -0500

Hi,

With this new version, I think that I have addressed all the comments that
I received on the mailing list.
I also made some changes to the IANA registry section.

Please, let us know if you have any comments.

Regards,
 Rifaat

On Sat, Jan 18, 2014 at 8:27 AM, <[email-masked]> wrote:

>  This draft is a work item of the Hypertext Transfer Protocol
> Authentication Working Group of the IETF.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Jan 2014 16:34:43 +0100

On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote:
> Hi,
>
> With this new version, I think that I have addressed all the comments
> that I received on the mailing list.

1) Again: there shouldn't be an ABNF for challenge or credentials.

The syntax is fully defined by HTTPbis, Part 7.

What you should define is the set of individual auth-params defined in 
challenges and credentials.

2) There shouldn't be any references to 2616 (or 2617) except for 
discussions of history.

3) Your reference section is empty.

4) In the IANA considerations, the registration of the scheme in the 
auth scheme registry is missing.

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 15:18:13 -0500

> challenges and credentials.
Just to make sure I understand your point, what you are looking for is, for
example, to replace what I have in section 3.3 with the following

      auth-scheme    =  "Digest"

      domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
      URI                 = absoluteURI | abs_path
      nonce              = "nonce" "=" nonce-value
      nonce-value      = quoted-string
      opaque            = "opaque" "=" quoted-string
      stale               = "stale" "=" ( "true" | "false" )
      algorithm         = "algorithm" "=" (
                          "MD5" | "MD5-sess" |
                          "SHA2-256" | "SHA2-256-sess" |
                          "SHA2-512-256" | "SHA2-512-256-sess" |
                          token)
      qop-options    = "qop" "=" <"> 1#qop-value <">
      qop-value       = "auth" | "auth-int" | token
      charset          = "charset" "=" ("UTF-8" | token)
      userhash       = "userhash" "=" ( "true" | "false" )

Is that correct?

> 4) In the IANA considerations, the registration of the scheme in the auth
> scheme registry is missing.
>
>
> Best regards, Julian
>
>

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 18 Jan 2014 22:23:40 +0100 (CET)

> Please, let us know if you have any comments.

I have a question about chapter 4:

    If the user agent does not support the encoding indicated by the
    server, it MAY add the "charset" parameter to the Proxy-Authenticate
    or WWW-Authenticate header fields it sends back to the server, but
    the value in the parameter should be preceded by an exclamation point
    (!).

What's the purpose of the exclamation point? Surely a server will have to 
check the charset if it is supported no matter if this symbol is there or not? 
I don't see how it helps anyone.

-- 

  / daniel.haxx.se

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 16:56:34 -0500

It would allow the server to fail the request without any further
processing, as it knows that the authentication will fail.

Regards,
 Rifaat

On Sat, Jan 18, 2014 at 4:23 PM, Daniel Stenberg <[email-masked]> wrote:

> check the charset if it is supported no matter if this symbol is there or
> not? I don't see how it helps anyone.
>
> --
>
>  / daniel.haxx.se
>

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 18 Jan 2014 23:38:03 +0100 (CET)

> processing, as it knows that the authentication will fail.

Why would a client want to send a request that includes an instruction to the 
server to fail it?

Also, you seem to imply then that a server will blindly accept the exclamation 
point and not check for itself that the charset is indeed not supported?

-- 

  / daniel.haxx.se

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 17:50:02 -0500

On Sat, Jan 18, 2014 at 5:38 PM, Daniel Stenberg <[email-masked]> wrote:

> Why would a client want to send a request that includes an instruction to
> the server to fail it?
>
>
I see your point. How about changing the last paragraph to say:

   If the user agent does not support the encoding indicated by the
server, the user agent MUST fail the request.

Regards,

 Rifaat

> Also, you seem to imply then that a server will blindly accept the
> exclamation point and not check for itself that the charset is indeed not
> supported?
>
> --
>
>  / daniel.haxx.se
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 17:55:36 -0500

I think that was introduced back when we considered allowing the server to
indicate multiple encoding schemes to the client.
I agree with you that it does not add any value with current approach.

Regards,
 Rifaat

On Sat, Jan 18, 2014 at 5:50 PM, Rifaat Shekh-Yusef
<[email-masked]>wrote:

>    If the user agent does not support the encoding indicated by the server, the user agent MUST fail the request.
>
>
> Regards,
>
>  Rifaat
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Jan 2014 23:56:14 +0100

On 2014-01-18 21:18, Rifaat Shekh-Yusef wrote:
> On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     What you should define is the set of individual auth-params defined
>     in challenges and credentials.
>
>
> Just to make sure I understand your point, what you are looking for is,
> for example, to replace what I have in section 3.3 with the following
>
>        auth-scheme    =  "Digest"
>

Nope. Just enumerate the parameters and state what the syntax of their 
values is.

For instance: "algorithm - the algorithm parameter represents the name 
of the digest algorithm; supported values are ... (to be matched 
case-insensitively)"

> ...

Best regards, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 19 Jan 2014 00:09:11 +0100 (CET)

> user agent MUST fail the request.

Much better!

-- 

  / daniel.haxx.se

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 18:11:04 -0500

Thanks Daniel!

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 18 Jan 2014 18:35:25 -0500

Julian,

The following is from the *draft-ietf-httpbis-p7-auth-25* draft, section
2.1 Challenge and Response:

  auth-scheme    = token
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>

  auth-param     = token
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
BWS <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
"=" BWS <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
( token <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
/ quoted-string
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
)

Then the auth-scheme will defined in the IANA section, and the auth-param
for all the parameters will be defined in the header's section; correct?

I do not see Authentication-Info in the above draft; is it defined
somewhere else?

Regards,
 Rifaat

On Sat, Jan 18, 2014 at 5:56 PM, Julian Reschke <[email-masked]>wrote:

> For instance: "algorithm - the algorithm parameter represents the name of
> the digest algorithm; supported values are ... (to be matched
> case-insensitively)"
>
>  ...
>>
>
> Best regards, Julian
>

---

From: Sophie Bremer <[email-masked]>
Date: Sun, 19 Jan 2014 07:36:22 +0100

On 2014-01-18 23:56, Julian Reschke <[email-masked]> wrote:

> Nope. Just enumerate the parameters and state what the syntax of their values is.
> 
> For instance: "algorithm - the algorithm parameter represents the name of the digest algorithm; supported values are ... (to be matched case-insensitively)"
> 
>> ...
> 
> Best regards, Julian
Hello Julian,

In my opinion this would not help to reach clarity.
The BNF form gives a complete and short overview of what is expected in each parameter, without reading any sentence.

Best regards,
Sophie

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Jan 2014 11:59:20 +0100

On 2014-01-19 00:35, Rifaat Shekh-Yusef wrote:
>    auth-scheme    =token  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>
>
>    auth-param     =token  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>  BWS  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>  "="BWS  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>  (token  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>  /quoted-string  <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#imported.abnf>  )
>
>
> Then the auth-scheme will defined in the IANA section, and the
> auth-param for all the parameters will be defined in the header's
> section; correct?

Something like that, yes.

> I do not see Authentication-Info in the above draft; is it defined

No, that header field is not part of the framework, thus needs to be 
defined by the Digest spec.

Best regards, Julian

---

From: Sophie Bremer <[email-masked]>
Date: Sun, 19 Jan 2014 13:42:06 +0100

For complement the discussion with Julian...

On 2014-01-19 12:03, Julian Reschke <[email-masked]> wrote:

> On 2014-01-19 07:35, Sophie Bremer wrote:
>> ...
>> Hello Julian,
>> 
> Complete, short, and incorrect :-).
> 
> A conforming recipient needs to use a *generic* parser (that handles even unknown authentication schemes). The ABNF that describes this process is in HTTPbis Part 7. The result of this parsing is a set of (scheme name + name/value pairs); and that's why each scheme specification should only define the name of the scheme, the name of their parameters, and their syntax.
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Jan 2014 15:47:43 +0100

>> A conforming recipient needs to use a *generic* parser (that handles even unknown authentication schemes). The ABNF that describes this process is in HTTPbis Part 7. The result of this parsing is…

A few examples:

a)          domain            = "domain" "=" <"> URI ( 1*SP URI ) <">

- is whitespace allowed between "domain", "=", and the value?

- the prose syntax should only be used as "last resort" (RFC 5234)

- what happens if the field value contains a "\"? So is the field value 
to be parsed as quoted-string or not?

b)          algorithm         = "algorithm" "=" (
                              "MD5" | "MD5-sess" |
                              "SHA2-256" | "SHA2-256-sess" |
                              "SHA2-512-256" | "SHA2-512-256-sess" |
                              token)

So according to the ABNF the field value can not be a quoted-string, and 
is case-insensitive. A later example shows it using quoted-string syntax.

Etc.

Summary: don't try mix parsing of the HTTP header field value with the 
parsing of the individual parameter values; these are different layers.

Best regards, Julian

PS: URI               = absoluteURI | abs_path

- these are not defined in the document