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

Tim <tim-projects@sentinelchicken.org> Thu, 09 June 2011 14:42 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 535E321F8477 for <apps-discuss@ietfa.amsl.com>; Thu, 9 Jun 2011 07:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.654
X-Spam-Level:
X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.389, 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 D5o-v2p4eIXC for <apps-discuss@ietfa.amsl.com>; Thu, 9 Jun 2011 07:42:25 -0700 (PDT)
Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46921F8476 for <apps-discuss@ietf.org>; Thu, 9 Jun 2011 07:42:25 -0700 (PDT)
Received: (qmail 24291 invoked from network); 9 Jun 2011 14:42:24 -0000
Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 9 Jun 2011 14:42:24 -0000
Received: (qmail 19503 invoked from network); 9 Jun 2011 14:43:35 -0000
Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 9 Jun 2011 14:43:35 -0000
Received: (nullmailer pid 28192 invoked by uid 1000); Thu, 09 Jun 2011 14:42:24 -0000
Date: Thu, 9 Jun 2011 07:42:24 -0700
From: Tim <tim-projects@sentinelchicken.org>
To: Robert Sayre <sayrer@gmail.com>
Message-ID: <20110609144224.GR1565@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> <90C41DD21FB7C64BB94121FBBC2E7234475E773C73@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTi=Qg=q066rAHkhFrsHBb3Yu4hWYFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTi=Qg=q066rAHkhFrsHBb3Yu4hWYFA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, OAuth WG <oauth@ietf.org>
Subject: Re: [apps-discuss] [OAUTH-WG] [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: Thu, 09 Jun 2011 14:42:29 -0000

> Digest has a bunch of problems. See this document
> 
> http://tools.ietf.org/html/draft-ietf-httpbis-security-properties-05#section-2.2.2
> 
> for a short tour of them.

Thanks for the link.  I totally agree with all of this, and in fact
there are more MitM attacks possible than are alluded to in that
document. This is one of the two reasons I brought up Digest
initially.  The MAC proposal does not appear to provide any additional
security over Digest, and yet Digest is still susceptible to MitM
attacks.  

We can pick and prod at the MAC proposal all we want from a security
perspective, but we'll probably end up at the same place that Digest
is at, security-wise.  We'll still have a protocol that can't defend
against MitM attacks.  So what is the point in providing integrity
again?

We need to use TLS.  Everywhere.

The more you look at advanced web attacks (MitM downgrade attacks, DNS
rebinding attacks, etc), the more you realize that most of these are
addressed by TLS if only it were used everywhere.

It's fine to bring out special-purpose authentication protocols.
Authentication can happen in a variety of ways either within TLS or
tunneled over it (hopefully with channel binding), but don't pretend
you'll be doing anyone favors by trying to provide partial integrity
protection that is ultimately ineffective.  Just focus on better
authentication and key/certificate management and let TLS do the rest.

tim