Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme

Nico,

Sorry for coming into this so late, but I just saw this message.

I don't have all of the background, but when I saw this message header and
some of the dialog, it seems there is a desire to provide some level of
authentication to requests and/or responses between the clients and servers.

Gonzalo and I worked on this:
https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04

This may not be entirely complete, but the idea was to allow a client and
server to establish an association so that requests and responses could be
authenticated.  Is this something along the lines of what you are
discussing, or is this an entirely different application?

Paul

> -----Original Message-----
> From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org]
> On Behalf Of Nico Williams
> Sent: Friday, May 20, 2011 4:25 PM
> To: Eran Hammer-Lahav
> Cc: apps-discuss@ietf.org; Ben Adida; Adam Barth (adam@adambarth.com);
> http-state@ietf.org; HTTP Working Group; OAuth WG
> Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
> 
> Additional comments:
> 
>  - Using nonces for replay protection is heavy-duty.  It is difficult to
> implement a reliable, secure, high-performance replay cache.  (It is
> easy to implement just a high-performance replay cache: use
> memcache.)
> 
>    I recommend an option to use sequence numbers at the server's choice,
> understanding, of course, that requests will not be received in
> sequence.  The use of a sliding sequence number window makes it possible
> to do at least as well as when using nonce, and probably faster while
> still being secure.
> 
>  - In an open wifi environment active attacks may not be very difficult,
> thus an option to secure more than just a handful of bits from the
> request, would be nice (all of the request and all of the response,
> say).  The hard part is how to decide when to use one or the other.
> Ideally browsers can request more protection when the network is
> reconfigured such that there's one or more clear wifi interfaces.
> 
> Nico
> --
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state