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

From: Brett Tate <[email-masked]>
Date: Tue, 14 Oct 2014 13:49:27 -0400

Hi,

The following are a few comments concerning draft-ietf-httpauth-digest-08.

Thanks,
Brett

----

General comment: The draft is vague concerning quoted strings and the
related backward compatibility with RFC 2617.  The draft occasionally uses
non normative statements to indicate that something is a quoted string;
however it isn't clear in relation to RFC 7235 and RFC 2617 what the
normative syntax actually is.  For backward compatibility reasons, the
draft should likely normatively comply with RFC 2617 concerning when to
add quotes.  However from a RFC 7235 perspective, the draft potentially
could recommend leniency during receive (concerning extraneous or missing
quotes) if that is the intent.

Section 3.4: Extraneous ".in 3".

Section 3.4: "cnonce" does not align with the other parameters.

Section 3.4.1: There is an opening '<' before KD without closing '>' after
KD's closing parenthesis.

Section 3.4.5: To comply with RFC 7235 section 2.2 (and RFC 2617), the
first example should have the realm value within quoted string:
realm="[email-masked]".

Section 4: Should the draft mention what the default character set is if
the parameter is not present?  Excluding simplicity, is there a reason why
charset was not defined as a quoted list within WWW-Authenticate and a
single entry within Authorization?

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 19 Oct 2014 00:53:29 -0400

Thanks Brett,

Please, see my reply inline...

Regards,
 Rifaat

> quotes) if that is the intent.
Would you be able to propose some text?

> single entry within Authorization?
I will defer this to the i18n experts that suggested UTF-8 as the only
value to be supported.

Regards,
 Rifaat

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

---

From: Brett Tate <[email-masked]>
Date: Wed, 22 Oct 2014 13:31:40 -0400

Hi Rifaat,

Reply is line.

> Would you be able to propose some text?

The following two paragraphs can be added to section 3.3.

"For historical reasons, a sender MUST only generate the quoted-string
syntax values for the following parameters: realm, domain, nonce, opaque,
and qop.

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

The following two paragraphs can be added to section 3.4.

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

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

The following two paragraphs can be added to section 3.5.

"For historical reasons, a sender MUST only generate the quoted-string
syntax for the following parameters: nextnonce, rspauth, and cnonce.

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

The following is a related comments.

Concerning the "nc" definition, should mention that it MUST be exactly 8
hexidecimal digits (for historical reasons).

value to be supported.

Based upon RFC 2831 which originally attempted to add charset as a digest
auth parameter, it looks like they interpetted things as ISO 8859-1 was
the default.  Even if draft-ietf-httpauth-digest wants to declare UTF-8 as
being the default, it should potentially declare and discuss since it is
potentially a backward compatibility issue.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 26 Oct 2014 14:40:36 +0200

> hexidecimal digits (for historical reasons).
I am fine with the above proposed text.
If I do not see any objection to these changes, I will add it to the next
version of the draft.

> potentially a backward compatibility issue.
Julian,

Do you have any thoughts on this?

Regards,
 Rifaat

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Oct 2014 18:24:26 +0100

On 2014-10-26 13:40, Rifaat Shekh-Yusef wrote:
> ...
> ...

There was no default in RFC 2617, and thus we can't pretend there is one.

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 27 Oct 2014 06:59:34 +0200

Thanks Julian,

I also could not find any mention of ISO 8859-1 in RFC2069.

I am not sure how RFC2831 came to the following conclusion in the
definition of the charset parameter:
"The directive is needed for backwards compatibility with HTTP Digest,
which only supports ISO 8859-1."

I am not planning on changing the definition of charset to mention ISO
8859-1 in this draft.

Regards,
 Rifaat

On Sun, Oct 26, 2014 at 7:24 PM, Julian Reschke <[email-masked]>
wrote:

>>     > > Section 4: Should the draft mention what the default character
>> set is
>>     if
>>     > > the parameter is not present?  Excluding simplicity, is there a
>> reason
>>     why

---

From: Brett Tate <[email-masked]>
Date: Mon, 27 Oct 2014 06:36:41 -0400

> >>> Section 4: Should the draft mention what the default character set
is
> >>> if the parameter is not present?  Excluding simplicity, is there a
reason
> >>> why charset was not defined as a quoted list within WWW-Authenticate
> >>> and a single entry within Authorization?
> > >

I assume RFC 2831 mentioned a default of ISO-8859-1 because of RFC 2616.

Thanks,
Brett

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 11:48:23 +0100

> I assume RFC 2831 mentioned a default of ISO-8859-1 because of RFC 2616.

RFC 2616 and 2617 do not have a default encoding -- that's part of the 
problem.

Best regards, Julian

---

From: Brett Tate <[email-masked]>
Date: Mon, 27 Oct 2014 07:07:22 -0400

> RFC 2616 and 2617 do not have a default encoding -- that's part of the

They may have used the TEXT rule since quoted-string contained TEXT.

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of RFC 2047
   [14].

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Oct 2014 12:16:50 +0100

> They may have used the TEXT rule since quoted-string contained TEXT.

I'm aware of that text (and it was removed in RFC 7230).

I don't believe it covers Basic authentication, and even if it did, it 
wasn't implemented that way.

Best regards, Julian

---

From: Brett Tate <[email-masked]>
Date: Mon, 27 Oct 2014 07:26:27 -0400

> >> RFC 2616 and 2617 do not have a default encoding -- that's part of
> >> the problem.
> >

If it matters, RFC 7230 section 3.2.4 indicates the following.

"Historically, HTTP has allowed field content with text in the
  ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
  through use of [RFC2047] encoding.  In practice, most HTTP header
  field values use only a subset of the US-ASCII charset [USASCII].
  Newly defined header fields SHOULD limit their field values to
  US-ASCII octets.  A recipient SHOULD treat other octets in field
  content (obs-text) as opaque data."

Thanks,
Brett