Subject: [http-auth] Proposal: unonce

From: Sophie Bremer <[email-masked]>
Date: Sun, 1 Dec 2013 09:23:56 +0100

Hello,

I like to share one proposal that is the result of a discussion with Rifaat.

Best Regards
Sophie

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Proposal: unonce

1 Introduction

   Today most large scale login systems use email addresses to identify
   there users. Email addresses have become a global identity, that
   requires protection. HTTP Digest Authentication allows only usernames 
   in plain text that can be intercepted easily in connections without
   TLS layer or "Man in the Middle" attacks. The unonce value changes
   this behavior and allows to hash the username with changing salts.

2 Implementation

   The proposal describes the extension of the draft from October 7,
   2013.

2.1 The WWW-Authentication Response Header

   If the server supports unonce for the identification of usernames,
   the server sends an unonce value to the client.

         digest-challenge  = ... | [unonce]
         unonce            = "unonce" "=" unonce-value
         unonce-value      = quoted-string

   unonce
      A server-specified data string which should be uniquely generated
      each time a 401 response is made. It shares the limitations
      of the nonce string.

2.2 The Authorization Request Header

   The client may use the unonce value but does not need to. If the
   client sends the unonce value in the request, the username has to be
   hashed.

         digest-response  = 1#( username | ... | [unonce] )
         username         = "username" "=" username-value
         username-value   = quoted-string
         unonce           = "unonce" "=" unonce-value
         unonce-value     = quoted-string

2.3 Username-Digest

   If the unonce value will be send back by the client, the hash
   calculation for the username value is required. This occurs AFTER the
   calculation of the request-digest. 

   If the "gop" value is "auth" or "auth-int":

         username-value  = <"> H(     unq(username-value)
                                  ":" unq(realm-value)
                                  ":" unq(unonce-value)
                                  ":" nc-value
                                  ":" unq(cnonce-value)
                                ) <">

2.4 Example

   In this example the value of username and user password is "Test".

   WWW-Authenticate: Digest realm="Example",
                            nonce="1cf499263274b5774361c4b29a65a845",
                            algorithm=SHA2-512-256,
                            opaque="c6b0919c7fe628ae9056992c4a917e5d",
                            qop="auth",
                            charset="UTF-8",
                            unonce="2244be5013ea7922a66fd60f73447524"

   Authorization: Digest username="c5ba39e9c6f86ec48fa99db168ef020a",
                         realm="Example",
                         nonce="f13f0978ca01d3bd5c461fd322bffa06",
                         uri="/Example.php",
                         response="0d7fdeed43cae8b2baf535bf306afa76",
                         opaque="c6b0919c7fe628ae9056992c4a917e5d",
                         qop=auth,
                         nc=00000001,
                         cnonce="b3cdac97866e00ec",
                         unonce="2244be5013ea7922a66fd60f73447524"

3 Security

3.1 Benefits

   - The username is protected in a similar way as the user password.

3.2 Drawbacks

   - The server has to calculate the hashes of all users, at least for
     the first request. For following requests the server can cash
     the valid user of the previous request.

   - The server has to know the plain username.

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 1 Dec 2013 17:29:56 -0500

Hi Sophie,

How about the following:

*Client*:
Calculate H( H(username) ":" unonce )

*Server*:
Store the username hash, hashed_username = H(username), once the username
is created.
When the server receives the above request from the client, the server
needs to concatenate the hashed_username with the unonce and then hash the
result and compare it to the hash it receives from the client.

Would that not address the second drawback (Server storing plain username)?
The only drawback of this is that you might need to store multiple hashes
based on the algorithms that you want to support.

Regards,
 Rifaat

On Sun, Dec 1, 2013 at 3:23 AM, Sophie Bremer
<[email-masked]>wrote:

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