Re: draft-montenegro-httpbis-multilegged-auth-01

Dear Jonathan,

for my understanding, your main purpose of proposing is to accept existing,
already deployed "connection-based" authentication schemes onto
possible HTTP/2.0.  Is it correct?

Then, my questions are twofold:
1. are there some specific reasons for implementations of
these authentication schemes to be strictly connection-based
(here the connection means TCP/IP)?  In other words,
are there some implementation restrictions which prevent
such authentication mechanisms from being used with
multiple underlying connections?
2. if the above answer is NO, is there strong intent to
keep them connection-based?  Or, if it can be deployed easily,
are you open to make it more friendly to HTTP/1.1 (and HTTP/2.0, likely)
message-based semantics?

Background of my questions is as follows:
Your proposal seems to be trying to keep them "connection-based" on HTTP/2.0
including proxy'ed requests.  Key-exchanges before successful authentication are
changed to be message-based by Auth-ID, but after successful authentication,
if original HTTP1 method is connection-based, it will be still connection-based.
This is typically expressed in Section 4.1 of your proposal as follows:
> [...] Proxies MUST bind
> the client-to-proxy and proxy-to-server connections.

However, at least Curl people already expressed concern with
connection-based authentication as follows:
 > The day we can clense connection-oriented authentications like NTLM
 > from the HTTP world will be a happy day, as it's state awareness is
 > a pain to deal with in a generic HTTP library and code.
And currently, your proposal seems not to solve their problem.

I will NOT say "we should cleanse out NTLM from Web", but
I want to explore possibilities for removing connection-dependency of
successfully-authenticated sessions of such schemes.
And I foresee that, if there are no implementation-dependent restrictions,
theoretically it is possible in a similar way as your proposal's style,
i.e. an amendment to existing HTTP/1.1 authentication schemes
when these are used with HTTP/2.0.  Even your framework of Auth-ID
can be reused for such changes.

Thanks,

Yutaka

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   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 Saturday, 14 July 2012 18:20:44 UTC