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

Tim <tim-projects@sentinelchicken.org> Wed, 08 June 2011 15:39 UTC

Return-Path: <tim-projects@sentinelchicken.org>
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 B365211E8158 for <apps-discuss@ietfa.amsl.com>; Wed, 8 Jun 2011 08:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.307
X-Spam-Level:
X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 afLrlkoAo-oi for <apps-discuss@ietfa.amsl.com>; Wed, 8 Jun 2011 08:39:07 -0700 (PDT)
Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 377C911E8142 for <apps-discuss@ietf.org>; Wed, 8 Jun 2011 08:39:07 -0700 (PDT)
Received: (qmail 18903 invoked from network); 8 Jun 2011 15:32:25 -0000
Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Jun 2011 15:32:25 -0000
Received: (qmail 4385 invoked from network); 8 Jun 2011 15:33:39 -0000
Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 8 Jun 2011 15:33:39 -0000
Received: (nullmailer pid 21338 invoked by uid 1000); Wed, 08 Jun 2011 15:32:25 -0000
Date: Wed, 8 Jun 2011 08:32:25 -0700
From: Tim <tim-projects@sentinelchicken.org>
To: "Paul E\. Jones" <paulej@packetizer.com>
Message-ID: <20110608153225.GL1565@sentinelchicken.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <015801cc25ab$063a2150$12ae63f0$@packetizer.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Wed, 08 Jun 2011 08:39:52 -0700
Cc: apps-discuss@ietf.org, http-state@ietf.org, 'HTTP Working Group' <ietf-http-wg@w3.org>, 'OAuth WG' <oauth@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 15:39:07 -0000

Hi Paul,

> That's the reason for the MAC.  Once we can ensure the integrity of
> the message exchange, then the existing cookie mechanism can provide
> us with the secure state management capability we need.

Maybe I'm missing something in the MAC authentication draft, but I
don't see how it provides integrity for the "exchange".  In
particular, the body of request messages may be optionally hashed to
protect their integrity, but no such facility seems to be provided for
responses from the server.  In many modern web applications, this
could be trivially exploited by an attacker to inject malicious script
into a server response. 

HTTP Digest authentication provides an option (auth-int) for integrity
protection of both requests and responses and for every
request/response after the initial authentication.  In fact if servers
change nonces each time, reuse of hashes becomes difficult.  Some
level of mutual authentication is also provided and the opaque string
can be used to pass arbitrary extra data between clients and servers.
IIRC, this value can be passed *cross domain* based on a defined white
list.

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?  

tim