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

This is about http auth (and I'm glad to see the discussion) but can we keep it to just that list? 
Ta.
S

On 14 Jun 2011, at 17:17, Nico Williams <nico@cryptonector.com> wrote:

> 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.
> 
>> The only permitted auth.form should be a dynamic, cryptographic mutual auth.
>> that authenticates both the client and the server.  There are endless designs
>> for this sort of thing around so the precise form isn't too important, as long
>> as it's not hand-over-the-password.
> 
> +1, particularly with regard to mutual authentication.  It's important
> to understand that we need mutual authentication using something other
> than the TLS server cert PKI for authenticating the server.
> 
> 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.
> 
> - Shall we have just one authentication mechanism?
> 
> IMO: We can't pick a universal authentication mechanism that will work
> for everyone, but if it helps get momentum I'd be happy to specify
> something where we start with one mechanism but nothing prevents us
> from adding others later.
> 
> Here's an example showing how to use SCRAM (a successor to DIGEST-MD5,
> thus not terribly interesting, but pretend for a second that this is a
> ZKPP) at the application layer and in a RESTful way:
> 
> C->S: HTTP/1.1 POST /rest-gss-login
>      Host: A.example
>      Content-Type: application/rest-gss-login
>      Content-Length: nnn
> 
>      SCRAM-SHA-1,,MIC
>      n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
> 
> S->C: HTTP/1.1 201
>      Location http://A.example/rest-gss-session-9d0af5f680d4ff46
>      Content-Type: application/rest-gss-login
>      Content-Length: nnn
> 
>      C
>      r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
>      s=QSXCR+Q6sek8bf92,i=4096
> 
> C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46
>      Host: A.example
>      Content-Type: application/rest-gss-login
>      Content-Length: nnn
> 
>      c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
>      p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
> 
> S->C: HTTP/1.1 200
>      Content-Type: application/rest-gss-login
>      Content-Length: nnn
> 
>      A
>      v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
> 
> 
> Does that work for you?
> 
> Nico
> --
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec