Subject: The Hypertext Transfer Protocol (HTTP) Authentication-Info Header Field

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 09:56:44 +0100

Dear WG,

when we worked on RFC 7235, we extracted the authentication framework 
from RFC 2617, but failed to realize that the section about the DIGEST 
authentication scheme indeed added another pair of generic header 
fields: (Proxy-)Authentication-Info.

As a matter of fact, Alexey Melnikov noticed this in time, but back then 
we didn't have the time & energy to do the right thing.

Today, we have the DIGEST revision coming up in the HTTPAuth WG, and 
that still contains the header field definition 
(<https://trac.tools.ietf.org/html/draft-ietf-httpauth-digest-12#section-3.5>). 
Furthermore, Alexey's SCRAM draft uses it, but does not reference DIGEST 
(<https://trac.tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04#section-5>, 
although with a minor syntax variation).

Last weekend I sat down and wrote a tiny draft (5 pages incl. 
boilerplate, ToC, references, whatnot) that makes these header field 
definitions standalone:

<http://greenbytes.de/tech/webdav/draft-reschke-httpauth-auth-info-00.html> 
(*)

...with the purpose of

- allowing DIGEST refer to it instead of in-lining the definition,

- allowing Alexey to use it, and most importantly

- having a clear path for RFC 7235bis.

The last point makes it a candidate for this working group; to be useful 
for the work over in HTTPAuth we'd need to be quick, though; optimally 
IETF LC before the Dallas meeting; given the size of the draft this 
should be possible...

What do others think?

Best regards, Julian

(*) The boilerplate says to send feedback to HTTPAuth, please ignore 
this for now.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 28 Jan 2015 22:59:17 +1300

> IETF LC before the Dallas meeting; given the size of the draft this

I think its a good idea.

It is also worth noting at this point that those headers are already in
use in the wild (by Squid at least) for Negotiate scheme in a way that
does not match the ABNF. Instead they just echo back from the server the
accepted "Negotiate <token>" credentials received from the client.

I am not sure exactly why Squid does this, I've queried our dev team to
see if anyone knows.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Jan 2015 11:59:51 +0100

On 2015-01-28 10:59, Amos Jeffries wrote:
> ...
> ...

Thanks.

> ...

Well, Negotiate already is that weirdo (see RFC 7236).

We *could* define Authentication-Info without having an ABNF, but I'd 
prefer to stick to what RFC 2617 said (it's flexible enough).

> I am not sure exactly why Squid does this, I've queried our dev team to

Thanks. It's certainly not document in the RFC. In a quick search, I 
also found <http://curl.haxx.se/mail/archive-2009-02/0106.html>.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 01 Feb 2015 03:04:28 +1300

> also found <http://curl.haxx.se/mail/archive-2009-02/0106.html>.

After some investigation it seems there is no other software out there
doing this and we can find no clients making use of it. The curl
references all seem to be people operating curl through a Squid.

So FYI, I will be removing the odd syntax use from all the upcoming
Squid releases (3.5.2 and 3.4.12 onward).

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sat, 31 Jan 2015 15:25:28 +0100

> Squid releases (3.5.2 and 3.4.12 onward).

Awesome!