Subject: draft-ietf-httpbis-http2-01, "4.2.3 Authentication"

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Mar 2013 21:36:19 +0100

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-http2-01.html#Authentication>:

"There are four options for proxy authentication, Basic, Digest, NTLM 
and Negotiate (SPNEGO). The first two options were defined in RFC2617 
[RFC2617], and are stateless. The second two options were developed by 
Microsoft and specified in RFC4559 [RFC4559], and are stateful; 
otherwise known as multi-round authentication, or connection 
authentication."

As far as I can tell, RFC4559 does not actually define an NTLM auth 
scheme. If it did, we'd need to add it to 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-authscheme-registrations-latest.html>.

(And yes, I know that there's a NTLM scheme used in practice, I just 
don't see it defined by RFC4559).

Later on:

"Unfortunately, the stateful authentication mechanisms were implemented 
and defined in a such a way that directly violates RFC2617 - they do not 
include a "realm" as part of the request. This is problematic in 
HTTP/2.0 because it makes it impossible for a client to disambiguate two 
concurrent server authentication challenges."

If these schemes need HTTP/2.0-specific fixes, these should be defined 
in a separate document, updating RFC4559. Optimally, we can get rid of 
the whole section.

Best regards, Julian

---

From: Nicolas Mailhot <[email-masked]>
Date: Wed, 6 Mar 2013 13:52:38 +0000 (UTC)

Hi,

Unless I've missed something, the draft as it stands does not answer the
following questions:

1. how an http/2 intermediary is supposed to communicate to the client it
requires authentification (regressing from http/1 and error 511), 

2. how gateway spoofing is supposed to be detected by the client (I'm ok to id
to my hotel wifi portal with the password provided on a card when booking in,
not to a random equipment that pretends to be my corp gateway to capture
credentials, even if my client is configured to send them automatically)

3. what entry-point is it supposed to provide for this auth (fishing for headers
in another data stream is no good)

4. how the authentication is conveyed to this entry-point securely (yes every
gateway credential is not a low-security hotel code), and nowhere else (not to
other intermediaries, not to the target, just to the entry-point the client
intends to reach)

5. how it works with https streams (the hotel may be ok with allowing outbond
https, and not wish to read this stream, it will still want you to authentify
before and renew auth when your credits have expired. Renewal is hard if you mix
separate communication in a single stream and assume that once you've set up a
tls tunnel you're done and nothing will change)

So by default the current proposal will continue to put everything in-band, as
headers that can be read by the wrong party, with no explicit equipment target.
Since that's not good enough in real life, if not fixed, it will produce new
generations of https MITM-ing & captive portals to force the clients to speak
with the authentification gateways.

The problem with intermediary auth is not the auth schemes but creating a
communication channel between the intermediary and the client to convey the
credentials.

Surely, HTTP2-FL can do better than this

Regards,

-- 
Nicolas Mailhot

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Mar 2013 15:31:33 +0100

On 2013-03-06 14:52, Nicolas Mailhot wrote:
> ...

It seems to me that all you said applies to HTTP/1.1 as well. My 
understanding was that how authentication works should be orthogonal to 
the HTTP message format, and thus whatever needs to be fixed should be 
fixed for both message formats. As such, I would expect this to be 
material for the new http-auth WG.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 6 Mar 2013 16:22:18 +0100

Le Mer 6 mars 2013 15:31, Julian Reschke a écrit :
> It seems to me that all you said applies to HTTP/1.1 as well.

Sure, however HTTP/1.1 does not include all the streaming/framing
infrastructure that begs to be used to resolve this issue. It seems to me
that it only arose because HTTP/1 was "too simple" to cope with such uses.

> My
> fixed for both message formats.

Actually, basic auth over ssl is good enough now for most uses. No need to
invent new auth schemes. What's not good enough is transporting the
credential to the intermediary. And that is more an HTTP transport problem
than an http-auth WG problem IMHO. Also, you need to keep some
relationship between the intermediated streams and the associated auth, so
it can't be solved without some protocol support (or, you end up
authorising client IPs, which sucks from a security point of view, and is
not reliable when clients connection to the network switches from wifi to
wire to whatever else is going to exist in the future)

> As such, I would expect this to be

Honestly, I think that at this point of time, fixing in HTTP/1 would be
nice but should not block fixing in HTTP/2. I doubt any fix in HTTP/1
would be picked up by HTTP/1 intermediary manufacturers without major
reving-up, which will make 'fixed HTTP/1 intermediary' as expensive as
'working-by-default HTTP/2'. So most intermediary users will go the HTTP/2
intermediary route anyway (as long as major browsers support HTTP/2 and
HTTP/2 allows HTTP/2-intermediary to HTTP/1 site use).

So the priority should be *not* to propagate this HTTP/1 problem to
HTTP/2, and have it just work in HTTP/2 by default.

(I know intermediary issues have been a pain to SPDY proponents, but
intermediaries would be enthusiastic adopters of HTTP/2 if it solved their
HTTP/1 problems. And since intermediaries are centralised by nature,
they're much easier to redeploy than changing countless web sites to use
HTTP/2)

Best regards,

-- 
Nicolas Mailhot