Subject: [http-auth] RFC5987 related feedback on draft-ietf-httpauth-digest-12

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 23:08:52 +0100

Hi there.

> ...
> 3.1. Overall Operation
>
>
>    The Digest scheme is based on a simple challenge-response paradigm.
>    The Digest scheme challenges using a nonce value, and might indicate
>    that username hashing is supported.  A valid response contains a
>    checksum of the username, the password, the given nonce value, the
>    HTTP method, and the requested URI.  In this way, the password is
>    never sent in the clear, and the username can be hashed, depending on
>    the indication received from the server.  The username and password
>    must be prearranged in some fashion not addressed by this document.
>
>    The security of this protocol is critically dependent on the
>    randomness of the randomly chosen parameters, such as client and
>    server nonces.  These should be generated by a strong random or
>    properly seeded pseudorandom source (see [RFC4086]).
>
>    For the following parameters, the value can be encoded using
>    [RFC5987] encoding: username.

At RFC 5987 encoding applies to exactly one parameter, it would be 
better to mention it where it's define (so drop this here).

> ...
> 3.4. The Authorization Request Header Field
>
>
>    The client is expected to retry the request, passing an Authorization
>    header field line with Digest scheme, which is defined according to
>    the framework above.  The values of the opaque and algorithm fields
>    must be those supplied in the WWW-Authenticate response header field
>    for the entity being requested.
>
>    The request can include parameters from the following list:
>
>    response
>
>       A string of the hex digits computed as defined below, which proves
>       that the user knows a password.
>
>    username
>
>       The user's name in the specified realm.
> ...

So here I would insert: "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]."

Maybe furthermore: "Sending both "username" and "username*" MUST be 
treated as error."

 > ...

 > ...
> 4. Internationalization

s/Internationalization/Internationalization Considerations/

>    In challenges, servers SHOULD use the "charset" authentication
>    parameter (case-insensitive) to express the character encoding they

The parameter *name* is matched case-intensively? Why?

>    expect the user agent to use when generating A1 (see Section 3.4.2)
>    and username hashing (see Section 3.4.4).
>
>    The only allowed value is "UTF-8", to be matched case-insensitively
>    (see [RFC2978], Section 2.3).  It indicates that the server expects
>    user name and password to be converted to Unicode Normalization Form
>    C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
>    using the UTF-8 character encoding scheme [RFC3629].
>
>    For the username, recipients MUST support all characters defined in
>    the "UsernameCasePreserved" profile defined in in Section 3.3 of
>    [PRECIS], with the exception of the colon (":") character.
>
>    For the password, recipients MUST support all characters defined in
>    the "OpaqueString" profile defined in in Section 4.2 of [PRECIS].
>
>    If the user agent does not support the encoding indicated by the
>    server, it can fail the request.

Add: "When usernames can not be sent hashed and include non-ASCII 
characters, clients can include the "username*" parameter instead (using 
the value encoding defined in [RFC598])."

(Q: does this work with existing servers? What is the *current* 
situation wrt non-ASCII?)

 > ...

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 29 Jan 2015 09:16:10 -0500

Inline...

On Wed, Jan 28, 2015 at 5:08 PM, Julian Reschke <[email-masked]>
wrote:

> At RFC 5987 encoding applies to exactly one parameter, it would be better
> to mention it where it's define (so drop this here).
>
>
Ok

> Maybe furthermore: "Sending both "username" and "username*" MUST be
Sure

> s/Internationalization/Internationalization Considerations/
Ok

> The parameter *name* is matched case-intensively? Why?
Not the parameter name, but the parameter value.
I see it is mentioned below that the value in case-insensitive, so I will
remove it from here.

> the value encoding defined in [RFC598])."

Sure.

>
> (Q: does this work with existing servers? What is the *current* situation
> wrt non-ASCII?)
>
>
I am not sure about what the current server implementations are doing with
non-ASCII.
Maybe some people that have server implementation can comment on this.

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

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Jan 2015 10:03:40 +0100

On 2015-01-31 09:48, Sophie Bremer wrote:
>> I am not sure about what the current server implementations are doing
>> with non-ASCII.
> We treat non-ASCII as UTF-8 and ignore the Authorization header option,
> if this fails.

So are there UAs sending UTF-8? Which?

(Asking in order to compare with the situation for Basic)

Best regards, Julian

---

From: Sophie Bremer <[email-masked]>
Date: Sat, 31 Jan 2015 10:39:58 +0100

> (Asking in order to compare with the situation for Basic)

I just made a technical statement for the server side. I do know, that some browsers send non-ASCII as UTF-8, for example Chrome and Safari. But for compatibility we actually use HTML forms with cookies to support UTF-8 logins - but like to switch to digest in the near future.

Regards,
Sophie