RE: Authentication and TCP Connection State

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.


Matthew

-----Original Message-----
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".

Mike

Received on Friday, 3 October 2014 16:23:18 UTC