Re: Authentication and TCP Connection State

I don't see any difference here between multiple TCP
connections and multiple streams within a single HTTP/2
TCP connection.

This typically works in practice because the user experience
starts by requesting a single URL, the web page. The user's
client doesn't know about other required requests until
after receiving the first page after authentication is
complete.

I would think a server would be able to mitigate the
issue by setting expiration/revalidate on the basic
page to some fraction of the authentication valid
interval.

I frequently encounter expired sessions in the real
world and have never had a case where the client/server
seemed lost and unable to sort out the re-authenticate
step.

As I stated at the top, I don't see how HTTP/2 streams
make this better or worse.

David Morris

On Fri, 3 Oct 2014, Michael B Allen wrote:

> 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 18:06:50 UTC