Re: Authentication and TCP Connection State

Dear Michael,

> Really?

Yes.

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

Short answer is "all non-broken authentication on HTTP/1.1", but
it will not answer your true question, I guess.

As HTTP/1.1 has already required that each request/response pair are
independent regardless of how it is carried on an underlying stream
(TLS or TCP), "properly-designed" authentication schemes
caries its own "session" identifiers on a HTTP header.
Examples are Digest authentication (1.5 hops, server-generated
nonce serves for it), currently-proposed Mutual (2 hops, "sid" parameter)
and SCRAM (multi hops, "sid" parameter) authentication schemes too.

Unfortunately, NTLM is widely used,
and it's designed as "session-associated".
It depends on Keep-alive connection of HTTP/1.1 and
ties its authentication state with the TCP connection
without any explicit session identifiers on HTTP headers.
Such design is not allowed in HTTP/1.1 spec.

So, all your questions should be directed to NTLM and
other "special" designs of HTTP authentications,
not to generic HTTP authentications.

Of course, most of us are aware that some existing
deployment of "so-called HTTP authentication" will be
completely broken in HTTP/2, although it was actually
already broken on HTTP/1.1.
All authentication schemes which strictly comply to
HTTP/1.1 will probably work on HTTP/2 without any
modifications (at least on session management aspects).

2014-10-04 8:58 GMT+09:00 Michael B Allen <ioplex@gmail.com>:
> 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
>



-- 
Yutaka OIWA, Ph.D.
          Planning Officer, Research Planning office for IT and Electronics
           (also: Senior Researcher, Research Institute for Secure Systems)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Sunday, 5 October 2014 04:27:33 UTC