Re: [apps-discuss] HTTP MAC Authentication Scheme

Mark Nottingham <> Tue, 31 May 2011 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC96CE06E6; Tue, 31 May 2011 16:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.283
X-Spam-Status: No, score=-105.283 tagged_above=-999 required=5 tests=[AWL=-2.684, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wZ7Ti+QZDZ6F; Tue, 31 May 2011 16:57:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B361CE06A0; Tue, 31 May 2011 16:57:29 -0700 (PDT)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6CD2D509DB; Tue, 31 May 2011 19:57:22 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Mark Nottingham <>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 1 Jun 2011 09:57:19 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <>
X-Mailer: Apple Mail (2.1084)
Cc: "" <>, Ben Adida <>, "'Adam Barth \(\)'" <>, "" <>, HTTP Working Group <>, OAuth WG <>
Subject: Re: [apps-discuss] 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: Tue, 31 May 2011 23:57:30 -0000


Reading draft -05.

The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too).

It would be more robust to calculate an effective request URI, as in [2].

Also, if you include a hash of the request body, you really need to include a hash of the body media type.

Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it.



On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote:

> (Please discuss this draft on the Apps-Discuss <> mailing list)
> The draft includes:
> * An HTTP authentication scheme using a MAC algorithm to authenticate requests (via a pre-arranged MAC key).
> * An extension to the Set-Cookie header, providing a method for associating a MAC key with a session cookie.
> * An OAuth 2.0 binding, providing a method of returning MAC credentials as an access token.
> Some background: OAuth 1.0 introduced an HTTP authentication scheme using HMAC for authenticating an HTTP request with partial cryptographic protection of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 scheme was designed for delegation-based use cases, but is widely “abused” for simple client-server authentication (the poorly named ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 and has been reintroduced as a standalone, generally applicable HTTP authentication scheme called MAC.
> Comments and feedback is greatly appreciated.
> _______________________________________________
> apps-discuss mailing list

Mark Nottingham