Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Hi Amos,

On Sat, Feb 25, 2012 at 12:42:19AM +1300, Amos Jeffries wrote:
> On 24/02/2012 8:25 p.m., Willy Tarreau wrote:
> >On Thu, Feb 23, 2012 at 05:23:45PM -0800, Paul Hoffman wrote:
> >>If only it were that simple. If the answer is "design an HTTP auth 
> >>mechanism
> >>that is better than Digest", then this is a tractable goal. If it is "get
> >>IETF consensus on that auth mechanism", then it isn't. The latter has 
> >>proven
> >>to be impossible because people say (possibly rightly) that web developers
> >>don't want auth mechanisms that use the browser chrome: they want auth in
> >>HTML, and anything that relies on the browser chrome is insufficient.
> >Maybe but you still need HTTP-based auth for proxies anyway. Also, I
> >partially disagree with your point, seeing the number of applications
> >in enterprise which rely on the hated NTLM auth which is also HTTP-based ;
> >they're using it because it's transparent to the user, and enterprise
> >customers do ask for such transparent auth schemes.
> >
> >There would also be much less need for cookies if auth was carried by the
> >browser, and this would let the user log off. So I think there's a need
> >for this.
> 
> Keeping the focus for charter firmly on the transport area and away from 
> the "web"/resource/content area allows us to split the two auth models 
> HTTP currently supports (www-auth and proxy-auth) along those same lines.
> 
> www-auth is end-to-end and only in that single-hop scenario can it be 
> considered close to a transport authentication. For all other hop counts 
> it is an effective *message* authentication, with no bearing on the 
> transport. The proxy-auth layer is the only one which remains strictly 
> transport-related, since it explicitly stops and re-starts at every HTTP 
> hop.
> 
> So IMHO, we can (indeed must) acknowledge that HTTP transport uses a 
> relay hop model. Charter security as a per-hop thing in HTTP. Any 
> proposals can define something to adapt/extend/replace/erase proxy-auth 
> into a real transport-auth. Specific to the two communicating hops. With 
> the same semantics and viability whether they be client-proxy or 
> client-server hops.
>  Bonus: per-hop allows us to ignore 2.0->1.x->2.0 compatibility. This 
> auth requirement only applies on 2.0->2.0+ hops.
> 
> www-auth can be left as the message-oriented authentication it is today 
> for the "web auth" stuff. Either pushed off to somebody else (again) or 
> to ourselves some years in the future when messaging semantics are up 
> for change.
> 
> Looking a little forward to potential proposals. We have TLS, Kerberos, 
> PGP, maybe OAuth and others all available right now (meeting that "over 
> current infrastructure" charter requirement) as schemes to define 
> proposals around. Being a "new" transport-authentication mechanism all 
> we have to do is ensure that implementation is reasonably easy and any 
> management tools to generate tokens or whatever are readily/easily 
> available to even clueless junior admin.

I get your point. I totally agree on the hop-by-hop view. It's what is
built today despite not having been designed this way, and a number of
current issues comes from the fact that we try to insert intermediaries
by force and create hops where they're not expected (eg: setting a LB
between an NTLM client-based and server is a real pain).

My goal is not to define new auth schemes ; it's only to ensure that
what we define does not require awful hacks when auth needs to be added.

Best regards,
Willy

Received on Sunday, 26 February 2012 06:19:07 UTC