IETF Logo Mail Archive

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

Eran Hammer-Lahav <eran@hueniverse.com> Wed, 08 June 2011 17:33 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 41E6311E8104 for <apps-discuss@ietfa.amsl.com>; Wed, 8 Jun 2011 10:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2C4ZuTMQhwlL for <apps-discuss@ietfa.amsl.com>; Wed, 8 Jun 2011 10:33:03 -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 DEA5311E8076 for <apps-discuss@ietf.org>; Wed, 8 Jun 2011 10:33:02 -0700 (PDT)
Received: (qmail 11392 invoked from network); 8 Jun 2011 17:33:02 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Jun 2011 17:33:01 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 8 Jun 2011 10:32:56 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Tim <tim-projects@sentinelchicken.org>, "Paul E. Jones" <paulej@packetizer.com>
Date: Wed, 08 Jun 2011 10:32:50 -0700
Thread-Topic: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
Thread-Index: Acwl8UxVsvuTiAXMQdeQ4L4C/3sh6QAEDGxg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTikpQNyQdr9oWHhtJ7a7d-4ri0CNdA@mail.gmail.com> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <BANLkTin30NVzYVV1m4gmyh42DWs-nSQpAg@mail.gmail.com> <00f101cc255e$2d426020$87c72060$@packetizer.com> <BANLkTimn8c72p5bjwHNapW9kVCVBmNbC4w@mail.gmail.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <20110608153225.GL1565@sentinelchicken.org>
In-Reply-To: <20110608153225.GL1565@sentinelchicken.org>
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: 'OAuth WG' <oauth@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [http-state] 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, 08 Jun 2011 17:33:04 -0000

> -----Original Message-----
> From: Tim [mailto:tim-projects@sentinelchicken.org]
> 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?

The latest version of this draft:

http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00

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

EHL

v2.23.0 | Report a Bug | By Email