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

"Paul E. Jones" <paulej@packetizer.com> Thu, 09 June 2011 05:13 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0B11E80A1; Wed, 8 Jun 2011 22:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 aWNlOPCX6C02; Wed, 8 Jun 2011 22:13:21 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE411E808D; Wed, 8 Jun 2011 22:13:20 -0700 (PDT)
Received: from sydney (rrcs-98-101-155-83.midsouth.biz.rr.com [98.101.155.83]) (authenticated bits=0) by dublin.packetizer.com (8.14.4/8.14.4) with ESMTP id p595DCHV024090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:13:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307596397; bh=slx2jdY6CfKAWo//nDtH0XhGc+XjcXkUrBdSyGAS4t4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LoFlQNxAfimVGF8/HQnsk92vMbGZdUSpuvjny1jNF8leCFTPBBMcoWbcoStQ7Pnf/ 5ZMMjdWHiCzeCHWWe8FbwAxbpMbWpNZyVAm1cO/urIT0UyikmqhmvBDJNuHSvBlqjH +osK1DrzqWwkUq7zHsQ4FRd1R+HN6lyhmjIW0RXY=
From: "Paul E. Jones" <paulej@packetizer.com>
To: 'Tim' <tim-projects@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> <20110608153225.GL1565@sentinelchicken.org>
In-Reply-To: <20110608153225.GL1565@sentinelchicken.org>
Date: Thu, 09 Jun 2011 01:13:04 -0400
Message-ID: <02d101cc2663$eceb6790$c6c236b0$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QFg30tslPNKqlA=
Content-Language: en-us
Cc: apps-discuss@ietf.org, 'Eran Hammer-Lahav' <eran@hueniverse.com>, http-state@ietf.org, 'HTTP Working Group' <ietf-http-wg@w3.org>, 'Nico Williams' <nico@cryptonector.com>, 'OAuth WG' <oauth@ietf.org>
Subject: Re: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 05:13:21 -0000

Tim,

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

You are referring to draft-salgueiro-secure-state-management-04?

In that document, Section 6 covers responses from the server.  The server
may hash any part of the message it wishes, including the body and selected
header.  It's possible to also have an empty body and including that in the
hash will ensure that no body is inserted where one shouldn't have been.
 
> 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?

We've not looked at HTTP Digest and we were not targeting OAuth with our
document.  Just so that I'm looking at the right "HTTP Digest" text, can you
tell me the document name?  I found several when I did a search.

Paul