Re: Authentication and TCP Connection State

On Fri, Oct 3, 2014 at 12:22 PM, Matthew Cox <macox@microsoft.com> wrote:
> It doesn't work, but we had a proposal a couple years ago to address this: http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Rats. This is absolutely going to block HTTP/2 in the enterprise. And
even after clients are updated (and we're not just talking about
browsers), how will the client even know it needs to serialize
requests?

Only the server knows if authentication is required. I think the
server should provide a TCP-level option that makes the server
serialize until the first 200 status is reached. I can imagine there
are numerous instances where it logically and conceptually should
block to the first 20x to "negotiate" something. I suspect it already
does (TLS/SSL).

This whole "HTTP is stateless" business is just false. HTTP is NOT
stateless. Cookies and sessions are hacks to work-around this fact.

Mike

> From: Michael B Allen [mailto:ioplex@gmail.com]
> Sent: Friday, October 03, 2014 9:11 AM
> To: ietf-http-wg@w3.org
> Subject: Authentication and TCP Connection State
>
> An HTTP authentication sequence looks something like:
>
>     C: GET /some/thing/6678
>     S: 401 Unauthorized
>        WWW-Authenticate: MyAwsomeAuth XlwYXNzd29yZA...
>
>     C: GET /some/thing/6678
>        Authorization: NTLM MyAwsomeAuth bGxXwYXbxXlYX...
>     S: 200 OK
>
> The way this is implemented on the server is to create some authentication state and associate it with the client TCP connection using the client's IP and remote port as an index into a map of ongoing authentication state objects.
>
> My question is, can HTTP/2 clients submit multiple requests on the same TCP connection without waiting for responses?
>
> If yes, how could HTTP authentication possibly work when there would be no way to lookup the correct authentication state object associated with the submitted auth token?
>
> To be more specific, authentication almost always involves sending the client some random data (let's call it a "challenge") that the client must then transform using a shared secret and submit that to the server (let's call it a "response"). So if the server gets two authentication "response" tokens in sequence, how can the server know which authentication state object matches the supplied response.
> Meaning it is not possible to match the "response" with it's "ch allenge".

Received on Friday, 3 October 2014 17:31:42 UTC