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

Robert Sayre <> Thu, 09 June 2011 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6EF611E8084; Wed, 8 Jun 2011 20:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lEMT+rGY9S1w; Wed, 8 Jun 2011 20:53:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 465C011E8078; Wed, 8 Jun 2011 20:53:11 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1219782vxg.31 for <multiple recipients>; Wed, 08 Jun 2011 20:53:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7+OuI7nMzSdOiI4TY2x7oxBl9Cr0FcxkduNdE1pceI4=; b=Ikf0HLeEhmJQMQYywovgv9WA94Klipy2XQ7vKKKReWeRQS6FFJQnfVgcn5QfdE2Y5I Ha9diz3mr1GajlvWyr1J/itE8luPFRHNUeVFb+zP0raryjOBBgzXxUbxNcNoQyViowKp BLTEpFbySq1PvNe8m5DTqdgsdtigBDqrtGW0g=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cH4Y3ug7EpA/Ig2xWO40p9Kh49NA+S6dCac/ZHKP/FVOKz/u3xUZvqbI+DxKFodiSh 7e+I1fOtwEA2QUXD8vdJioK1R+4gEg0Y2/kXIxu3YLPRMJ0A78ww7ZmCZ05XNvLFcLDU KMtUtAf8Cr46h7W61UBXxGpoYWKSbhIwT+irY=
MIME-Version: 1.0
Received: by with SMTP id g10mr310749vdw.252.1307591590090; Wed, 08 Jun 2011 20:53:10 -0700 (PDT)
Received: by with HTTP; Wed, 8 Jun 2011 20:53:10 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <09c801cc24c2$a05bae00$e1130a00$> <> <00f101cc255e$2d426020$87c72060$> <> <015801cc25ab$063a2150$12ae63f0$> <> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Wed, 8 Jun 2011 20:53:10 -0700
Message-ID: <>
From: Robert Sayre <>
To: Eran Hammer-Lahav <>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Thu, 09 Jun 2011 08:37:18 -0700
Cc: Tim <>, OAuth WG <>, "" <>
Subject: Re: [apps-discuss] [OAUTH-WG] [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: Thu, 09 Jun 2011 03:53:13 -0000

On Wed, Jun 8, 2011 at 10:32 AM, Eran Hammer-Lahav <> wrote:
>> -----Original Message-----
>> From: Tim []
>> Sent: Wednesday, June 08, 2011 8:32 AM
>> At risk of repeating myself: Why not just adapt HTTP Digest for OAuth?
>> That is not just rhetorical, it is a genuine question.  What is HTTP Digest
>> missing that you need?

Digest has a bunch of problems. See this document

for a short tour of them.

> The latest version of this draft:
> Includes a Design Constraints section which tries to explain this:
>   Unlike the HTTP Digest authentication scheme, this mechanism does not
>   require interacting with the server to prevent replay attacks.
>   Instead, the client provides both a nonce and a timestamp, which the
>   server can use to prevent replay attacks using a bounded amount of
>   storage.

It's not obvious to me why the mechanism in the draft is better than a
server-generated nonce and/or opaque string, as found in Digest. The
mechanism in the draft can be bitten by clock skew problems, and
having the server send a nonce doesn't necessarily require an
unbounded amount of storage. I'm sorry if I've missed previous
discussion on this issue, but could someone explain?

>   Also unlike Digest, this mechanism is not intended to
>   protect the user's password itself because the client and server both
>   have access to the key material in the clear.  Instead, servers
>   should issue a short-lived derivative credential for this mechanism
>   during the initial TLS setup phase.

That makes sense. I'm having trouble reconciling the Design
Constraints section (1.1) with the section on Entropy of MAC Keys
(7.5). How long are these keys supposed to be around in practice?
Also, Adam wrote "this mechanism is for folks who cannot or will not
deploy TLS". How does that statement fit here?

- Rob