- From: Nico Williams <nico@cryptonector.com>
- Date: Tue, 14 Jun 2011 18:47:13 -0500
- To: Yutaka OIWA <y.oiwa@aist.go.jp>
- Cc: public-identity@w3.org, http-auth@ietf.org
On Tue, Jun 14, 2011 at 5:46 PM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote: > 2011/6/15 Nico Williams <nico@cryptonector.com>: >> On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann >> <pgut001@cs.auckland.ac.nz> wrote: >>> Phillip Hallam-Baker <hallam@gmail.com> writes: >>>>what would we want HTTP authentication to look like? >>> >>> I have a suggestion for what it shouldn't look like: Any method that hands >>> over the password (or a password-equivalent like a password in hashed form) as >>> current browsers do should be banned outright, and anyone who implements >>> hand-over-the-password should killed and eaten to prevent them from passing on >>> the genes. >> >> +1. > > +1, although the original statement is a bit too strong in wording for me :-) Why? >> - Is this to be done in TLS? HTTP? Or at the application-layer? >> >> IMO: TLS is too low a layer to do authentication in, and doing it in >> HTTP would require retrofitting too many HTTP stacks. Doing it at the >> application layer has a number of advantages. > > IMO, I agree that TLS is too low. > However, although the application layer use-case exists, > I believe that for general use cases HTTP-auth layer is more appropriate, > because the trust relationship becomes much simpler. Can you explain what you mean by "the trust relationship becomes much simpler"? > Backward-compatibility is important, and all intermediates *should* and > *in most cases will* work well with new http authentication > that completely complies with existing HTTP auth framework design. Compatibility with existing installed base of HTTP stacks is a huge plus. Application-layer authentication can be implemented using CGI on the server-side, if you want the lowest common denominator, and practically every HTTP server has CGI support (even IIS!). This is a critical feature. > All they've needed is just forward auth-related headers to the origin server. Application-layer authentication also works whether there's proxies in the path or not. It is end-to-end because it is implemented by the application-layer end-points. This is also a critical feature. > Required code modification is almost the same magnitude in both cases, > because we need to change the client, and to add some server-side thing. With application-layer authentication one could make a CGI reference implementation that can be trivially installed and used on the vast majority of existing servers. With HTTP-layer authentication one must modify the HTTP servers that one uses. That's a huge difference in favor of application-layer authentication. Sure, CGI isn't great, but fast CGI is quite decent, and the important thing is to get deployment momentum -- optimization for each HTTP server can come later. > we can keep all other intermediates as it is. > Some client-side change is necessary in both cases to make mutual > authentication trustful and unforgeable. > In server-side, http-layer authentication can be implemented in either > in the server or in the application. The same is true for application-layer authentication, oddly enough. There is a bit of a dualism between HTTP- and application-layer authentication as long as the HTTP stacks expose enough request/response header interfaces to the application. On the client-side this duality is more complete than on the server-side. There's no reason that the HTTP stack couldn't implement application-layer authentication, and there's no reason that the application couldn't implement HTTP-layer authentication. However, there's no way to implement HTTP-layer authentication with CGI, and that's a big issue. There are other reasons to want application-layer authentication. For example, the application-layer authentication process need not reveal any information about what resources the client wishes to access unless the client tries to access a protected resource before authenticating, whereas with HTTP-layer authentication the client must access a harmless resource to get the same effect. This is another case where the duality of HTTP- and application-layer authentication is not complete. But let's say that the semantics and implementation and deployment considerations authentication at either layer are fully equivalent to those of authentication at the other layer... Then why shouldn't we just flip a coin to pick which layer to add authentication to? It is precisely because the duality mentioned above is not complete that we have good reasons to pick one layer or the other. Nico --
Received on Tuesday, 14 June 2011 23:47:37 UTC