RE: Authentication and TCP Connection State

sorry to mention that the link leads to 404.
here’s one copy
http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-00



Original Message
Sender:Matthew Coxmacox@microsoft.com
Recipient:Michael B Allenioplex@gmail.com; ietf-http-wg@w3.orgietf-http-wg@w3.org
Date:Saturday, Oct 4, 2014 00:22
Subject:RE: Authentication and TCP Connection State


It doesnt 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 clients 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 (lets call it a challenge) that the client must then transform using a shared secret and submit that to the server (lets 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 its ch allenge. Mike

Received on Friday, 3 October 2014 16:31:22 UTC