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

"Paul E. Jones" <> Wed, 08 June 2011 07:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60C4F11E809F; Wed, 8 Jun 2011 00:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BUcKNzOTuoWw; Wed, 8 Jun 2011 00:09:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C668F11E80B6; Wed, 8 Jun 2011 00:09:48 -0700 (PDT)
Received: from sydney ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id p5879Zvs026255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2011 03:09:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=dublin; t=1307516981; bh=EqA8sObHvgjD2JNx49j1AwimuPqnmf948JUMPiOdJ4w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HeYerh+ds7j3Bquz1AhEPWr47ADnZ3Mr5/baHDx0CJHBvy+QAQRFX9hZlsygDUdQ/ WJ4obHlhlGjjky7KWtRK+hb/oVxc/ckCLKsow96uWg1Z3grWMNRBA+ZE5LaCvKKgFU KQWHrjiX/Bi57G/cyjaSt6C6zKTlMMLY8qIWV0ac=
From: "Paul E. Jones" <>
To: "'Nico Williams'" <>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <09c801cc24c2$a05bae00$e1130a00$> <> <00f101cc255e$2d426020$87c72060$> <>
In-Reply-To: <>
Date: Wed, 8 Jun 2011 03:09:29 -0400
Message-ID: <015801cc25ab$063a2150$12ae63f0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDCVCDS9sA==
Content-Language: en-us
Cc:, 'Ben Adida' <>, 'Adam Barth' <>,, 'HTTP Working Group' <>, 'OAuth WG' <>
Subject: Re: [apps-discuss] [http-state] HTTP MAC Authentication Scheme
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jun 2011 07:09:56 -0000


Cookies would still be employed.  A cookie would be used to identify the particular user, for example.  However, it's important to make sure that the cookie provided by the client to the server is not stolen.  It's important to ensure that the client provided by the server to the client is not modified.  That's the reason for the MAC.  Once we can ensure the integrity of the message exchange, then the existing cookie mechanism can provide us with the secure state management capability we need.


> -----Original Message-----
> From: Nico Williams []
> Sent: Tuesday, June 07, 2011 6:36 PM
> To: Paul E. Jones
> Cc: Eran Hammer-Lahav;; Ben Adida; Adam Barth;
>; HTTP Working Group; OAuth WG
> Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
> On Tue, Jun 7, 2011 at 4:59 PM, Paul E. Jones <>
> 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
> --