MAC adds security if the initial secret exchange is secure, and it provides a
definition for signing payload as part of the request.
________________________________
From: Nico Williams <n...@cryptonector.com>
To: Paul E. Jones <pau...@packetizer.com>
Cc: apps-disc...@ietf.org; Ben Adida <b...@adida.net>; Adam Barth
<a...@adambarth.com>; http-st...@ietf.org; HTTP Working Group
<ietf-http...@w3.org>; OAuth WG <oauth@ietf.org>
Sent: Tuesday, June 7, 2011 3:35 PM
Subject: Re: [OAUTH-WG] [http-state] [apps-discuss] HTTP MAC Authentication
Scheme
On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones <pau...@packetizer.com> wrote:
> I fully agree with you that using TLS is usually preferred. That said, we
> encounter situations where there were a large number of client/server
> interactions and the data conveyed is not confidential information in any
> way. Using TLS can significantly decreases server performance, particularly
> when there are a number of separate connections that are established and
> broken.
>
> So, we were trying to find a non-TLS solution that still provides a way to
> ensure the server can identify the user and that both can verify that data
> has not been tampered in flight. (It would still be preferred to establish
> security relations with TLS, though we were open to other solutions.)
I don't see the point of having a MAC instead of a cookie for HTTP
requests sent without TLS, not unless you cover enough of the request
(and response). Of course, you'll want two different cookies -- one
for HTTP and one for HTTPS.
I think you've just convinced me that this MAC adds no value whatsoever.
Nico
--
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
