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

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

Received on Wednesday, 6 March 2013 13:53:24 UTC