Re: [apps-discuss] HTTP MAC Authentication Scheme

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 01 June 2011 15:02 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 60E75E06FD for <apps-discuss@ietfa.amsl.com>; Wed, 1 Jun 2011 08:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.615
X-Spam-Level:
X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 g-mTJCdNOzel for <apps-discuss@ietfa.amsl.com>; Wed, 1 Jun 2011 08:02:43 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A9667E07F8 for <apps-discuss@ietf.org>; Wed, 1 Jun 2011 08:02:23 -0700 (PDT)
Received: (qmail 25729 invoked from network); 1 Jun 2011 15:02:22 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Jun 2011 15:02:21 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 1 Jun 2011 08:00:40 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Mark Nottingham <mnot@mnot.net>
Date: Wed, 1 Jun 2011 08:00:12 -0700
Thread-Topic: [apps-discuss] HTTP MAC Authentication Scheme
Thread-Index: Acwf7oEQJBF82ilkT/6VDPS/ahDBDQAfEq6g
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723447583CA4CC@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <EF1DF135-708B-4244-AA3A-020761EDB290@mnot.net>
In-Reply-To: <EF1DF135-708B-4244-AA3A-020761EDB290@mnot.net>
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@ietf.org" <apps-discuss@ietf.org>, Ben Adida <ben@adida.net>, "'Adam Barth \(adam@adambarth.com\)'" <adam@adambarth.com>, "http-state@ietf.org" <http-state@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, OAuth WG <oauth@ietf.org>
Subject: Re: [apps-discuss] 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: Wed, 01 Jun 2011 15:02:45 -0000

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Tuesday, May 31, 2011 4:57 PM
> To: Eran Hammer-Lahav
> Cc: apps-discuss@ietf.org; Ben Adida; http-state@ietf.org; OAuth WG;
> 'Adam Barth (adam@adambarth.com)'#x27;; HTTP Working Group
> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme
> 
> Hi,
> 
> 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].

I'll take a look.

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

This was suggested before, but are there really attack vectors for this?

The problem is that content-type is a pretty flexible header, which means normalization of the header will be required (case, parameter order, white space, etc.).

I would argue that if you are using MAC with body hash and an attacker changing the media type can cause harm, you should use additional methods to secure the content-type (such as making the body self-describing).

> 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.

If someone comes up with a practical and secure way to normalize HTTP request headers, they can either define a new authentication scheme or use the 'ext' parameter to pass the additional values. I would vote for a new scheme. MAC is trivial to implement and interoperate. That simplicity comes at a significant lack of features, and limiting extensibility is a design goal.

EHL

> Regards,
> 
> 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-
> 4.1.2
> 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3
> 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00
> 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02
> 
> 
> On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote:
> 
> > (Please discuss this draft on the Apps-Discuss <apps-discuss@ietf.org>
> mailing list)
> >
> > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
> >
> > 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.
> >
> > EHL
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
>