Re: Authentication and TCP Connection State

On Fri, Oct 3, 2014 at 3:22 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Fri, Oct 03, 2014 at 12:10:55PM -0400, Michael B Allen wrote:
>> 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?
>
> Basically, most authentication methods are associated with the request,
> but some (the most well-known one is Negotiate) is associated with
> connection.
>
> Request-associated authentication work with both HTTP/1.1 and HTTP/2.

Really?

And what do you mean by "Request-associated authentication" exactly?

Like I said, there would be no way to lookup something and match it to
something the client supplied. So there would be no way for a server
to say "here's some random data, now do something to it that proves
you have the secret". This mechanism is elementary and it is found in
every authentication protocol worth it's weight in bytes.

Correct me if I'm wrong but it seems to me that HTTP/2 will
effectively *guarantee* that sites will submit non-challenged
credential information (probably plaintext) AND use a cookie to track
authentication state.

So can someone please explain to me precisely how proper
authentication could work with HTTP/2.

Mike

Received on Friday, 3 October 2014 23:59:26 UTC