Re: [websec] [saag] [http-auth] re-call for IETF http-auth BoF

[Thomas Fossati <[e-mail]>]

On Jun 14, 2011, at 6:17 PM, Nico Williams wrote:
> Some aspects of the designs are important.
> 
> For example:
> 
> - 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.

I've tried to figure out how to get something similar to your REST GSS -- which I like -- at the HTTP level and, yes, you need to hammer HTTP clients a bit to teach them how to do the challange-response on a specially crafted cookie, but then it seems you can switch from stateless to stateful HTTP (and viceversa) quite robustly.

Still there's the related bootstrap problem to solve, i.e. the authentication phase and implied key agreement.  

In this respect I've only been able to sketch a TLS-based mechanism, with a) explicit HTTP redirection, or b) a-priori knowledge of the authentication URI via .well-known or DNS-SD, which then uses RFC 5705 to feed both parties with the needed crypto material.

Anyway, I still have hazy thoughts about the whole matter, basically from an architectural standpoint, i.e. about where (which layer) the secure state management component must be placed.

My unanswered (taboo?) question being: would the core HTTP protocol benefit from introducing secure state handling capabilities ?  Or should HTTP remain stateless ?