Subject: [http-auth] New Here, Seeking Feedback

From: Nicholas Shanks <[email-masked]>
Date: Tue, 27 Nov 2012 14:42:07 +0000

Hello folks, I am rather inexperienced in matters pertaining to
security. Yesterday I had a brainwave. Why it has not occurred to me
or apparently anyone else before remains a mystery, but I wrote up my
idea as an Internet-Draft (my first) and would like some expert
feedback on it, including anything about the I-D process I may have
gotten wrong.

The -00 version is at
http://tools.ietf.org/html/draft-shanks-http-form-authentication
but my working copy already clarifies a few things in the introduction
relating to TLS and is available at
http://web.nickshanks.com/drafts/draft-shanks-http-form-authentication-01
(though only in XML format).

-- 
Nicholas.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 28 Nov 2012 06:05:25 +0200

> feedback on it, including anything about the I-D process I may have

Comparing with digest:
- This thing doesn't seem send username or realm except implicitly inside
hash.
- Doesn't seem to allow storing just a hash (yeah, pretty weak) serverside
if there are more fields than just username, realm and password.
- And then there's perennial problem with HTTP-level auth: Logout. :-)

> (though only in XML format).

The working copy seems to have XML parse error.

-Ilari

---

From: Nicholas Shanks <[email-masked]>
Date: Wed, 28 Nov 2012 09:58:31 +0000

> - This thing doesn't seem send username or realm except implicitly inside

I thought that's all Digest did. Did I miss something from the spec? Please enlighten me!
Is the purpose of Digest, vs Basic, not to obscure the username and password, so that it doesn't get sent except implicitly inside the hash?
My goal is to have the client app (web browser) compute the hash so that it doesn't have to be computed in JavaScript, and is standardised.

> if there are more fields than just username, realm and password.

Why not? The intent was to specify a strict method for the client to generate the hash so that it matched what the server would have cached or could generate.

> - And then there's perennial problem with HTTP-level auth: Logout. :-)

Covered by draft-oiwa-http-auth-extension which is cited as an informational reference in the working copy. (Section 4 of that draft covers log out) That document specifies the poorly-named "logout-timeout" parameter which when sent by the server with a value of 0, instructs the client not to send future Authorization headers for this authentication space. I think better name would be auth-timeout, since it is not the "logout" that is timing out, but the authentication.

I have appended ", such as a means to log out" to my citation of that draft.

> The working copy seems to have XML parse error.

Thanks, fixed missing </t> tag in the change log.

― Nicholas.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 29 Nov 2012 06:08:40 +0200

>From a real-world special-purpose app:

Authorization: Digest username="Ilari", realm="TASVideos Channel Uploader", nonce="are2UAAAAABi9zoOcRZWDrFGAsZktt/2", uri="https://encoders.tasvideos.org/secure/upload.exe", response=<...>, algorithm="md5-sess", cnonce="dGrBZZUOxHo9yuZv/ehVIk", qop="auth", nc="00000005"

> Why not? The intent was to specify a strict method for the client to generate the hash so that it matched what the server would have cached or could generate.

Sometimes these login forms have additional fields (the most common seems to be
"login for session only" (or somesuch) or its opposite).

-Ilari

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 30 Nov 2012 09:32:14 +0000

> Authorization: Digest username="Ilari", realm="TASVideos Channel Uploader", nonce="are2UAAAAABi9zoOcRZWDrFGAsZktt/2", uri="https://encoders.tasvideos.org/secure/upload.exe", response=<...>, algorit…

I am not sure what you were trying to demonstrate by including that. Could you elaborate?

> "login for session only" (or somesuch) or its opposite).

That specific case ought to be handled by the client setting the auth-expire parameter of the proposed Authentication-Control header in each subsequent authenticated request (the current Oiwa draft calls this "logout-timeout" but I have recommend that they change that as it's quite a misnomer). The server would then echo that back to the client, resetting the client's timer. (Is that necessary, or should we just define that the state of the input upon submission affects the client directly and is not sent to the server?)
I think it would be a good idea then to define that inputs with a name matching the pattern /_.*_/ are to be excluded from being used to compute the hash. Cue there taken from IE's _charset_ automatic input, which needs to be excluded anyway. We could then define that any form input named _auth_expire_ have an integer value representing how long the user wants to keep the auth alive for (HTML authors can provide a checkbox with value of 900 (=15 mins) or a set of radios or a popup, etc.) and we can define that if there are two inputs with reserved names, only the first (last?) has an effect. This will allow a hidden input and a checkbox to work in tandem to give a low default auth-expire but allow the user to override it with a huge number (e.g. 20 years). Perhaps a value of “never” could explicitly mean don't generate the parameter at all.

― Nicholas.