Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 09 May 2011 21:30 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E1DE0969 for <apps-discuss@ietfa.amsl.com>; Mon, 9 May 2011 14:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level:
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wu4cvYF7Wo7 for <apps-discuss@ietfa.amsl.com>; Mon, 9 May 2011 14:30:00 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A6228E0946 for <apps-discuss@ietf.org>; Mon, 9 May 2011 14:30:00 -0700 (PDT)
Received: (qmail 27835 invoked from network); 9 May 2011 20:29:59 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 May 2011 20:29:59 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 May 2011 13:29:40 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 9 May 2011 13:29:36 -0700
Thread-Topic: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme
Thread-Index: AcwOhEsKVvl9Wqa3Tu6lCSXcEMcV6wAAecww
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447581DA933@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B1968C5A-867C-4C7D-B3EF-A399AD626B60@vpnc.org> <BANLkTinXPER5NaKxMFnbviMaX=CTSp81fg@mail.gmail.com>
In-Reply-To: <BANLkTinXPER5NaKxMFnbviMaX=CTSp81fg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 21:30:01 -0000

Hi Nico,

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Nico Williams
> Sent: Monday, May 09, 2011 1:03 PM

> Regarding the question of when to include a hash of the body in the
> normalized request string that gets MACed... If one is using TLS, then I
> suggest adding the TLS channel binding into the MAC input string and drop
> the body hash.  This will speed up operation, since there's no need to hash
> the body (think of the performance impact of hashing the request body in an
> implementation that uses sendfile()!).

It is still not clear when hashing the body is really important, and if this should be just an optional feature or something that is required. If it is optional, it is not clear how the server should indicate to the client that it is required for any particular protected resource. We're still debating that and waiting for some deployment experience to guide us.

> I don't see the point of attempting to provide only partial integrity protection
> (e.g., the draft doesn't say to include ever request header into the MAC
> input) if there's no TLS.  In fact, I don't see the point of not using TLS, but if
> TLS avoidance is desired then all of the request (minus the MAC) and
> response should be covered by the MAC.

The point is to be practical given the target audience and use cases we have for this: web developers.

We have 3 years of experience asking web developers to perform request normalization and the results are pretty sad. OAuth 1.0 includes a pretty simple normalization of the request URI which ended up being a huge problem for many developers. If someone can come up with a simple way to canonicalize an HTTP request in a way that works with proxies and other intermediaries, and is easy to implement and debug, I'm happy to reconsider.
 
> The response headers also should get a MAC.

We're considering adding response verification, but not sure where to put it.

> Using channel binding means that the MAC input string can be much smaller -
> - it need only be fresh if the TLS CB type is tls-server-end-point.  If the CB
> type is tls-unique then no nonce nor credential age elements are needed to
> establish freshness.  And back to the tls-server-end-point case, if the
> freshness element is a sequence number then the MACs can be pre-
> computed, with a small sliding window (implemented as a small bitmap and
> highest number seen state elements).

Channel binding is hard to implement the way most web frameworks are used, as well as how browsers manage their stack. Also, lack of TLS is the main driver behind this proposal.

> Finally, presumably it's the application that generates and validates the
> MACs, not HTTP itself.  Correct?

Not sure what you mean, but this operates just like HTTP Basic and Digest in terms of its relation to HTTP.

EHL