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

"Paul E. Jones" <paulej@packetizer.com> Tue, 07 June 2011 21:59 UTC

Return-Path: <paulej@packetizer.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 87EC311E817D; Tue, 7 Jun 2011 14:59:43 -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 XuUYpWUCu7Bd; Tue, 7 Jun 2011 14:59:42 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A98E411E8071; Tue, 7 Jun 2011 14:59:42 -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 p57LxSSU026304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 17:59:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307483975; bh=vAymWHB3vMQrUVrj09s12KmZ5xj9/zFu66TKvHefjnc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=P2Ly20UN2MnQdVu9fxOgahTjEqfr4w9UM967g3OJzK+yeQB44k5sgOeKeTIDDtLNO bvywhKoLntceXy9npodJTLIPDUjiNkA7Geib65yX/I7rd+4+Qc3Y3zCP37jrGJbCGX iV6cB7agKi1Q4amxLwBj/qo3iEU//lFk0yLkpZBU=
From: "Paul E. Jones" <paulej@packetizer.com>
To: "'Nico Williams'" <nico@cryptonector.com>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTikpQNyQdr9oWHhtJ7a7d-4ri0CNdA@mail.gmail.com> <09c801cc24c2$a05bae00$e1130a00$@packetizer.com> <BANLkTin30NVzYVV1m4gmyh42DWs-nSQpAg@mail.gmail.com>
In-Reply-To: <BANLkTin30NVzYVV1m4gmyh42DWs-nSQpAg@mail.gmail.com>
Date: Tue, 7 Jun 2011 17:59:23 -0400
Message-ID: <00f101cc255e$2d426020$87c72060$@packetizer.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpJUw+Lnw
Content-Language: en-us
Cc: apps-discuss@ietf.org, 'Ben Adida' <ben@adida.net>, 'Adam Barth' <adam@adambarth.com>, 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: Tue, 07 Jun 2011 21:59:43 -0000

Nico,

> > Gonzalo and I worked on this:
> > https://tools.ietf.org/html/draft-salgueiro-secure-state-management-04
> >
> > This may not be entirely complete, but the idea was to allow a client
> > and server to establish an association so that requests and responses
> > could be authenticated.  Is this something along the lines of what you
> > are discussing, or is this an entirely different application?
> 
> I'm completely on-board with session state[*].  My comments were
> particularly in regards to threat models.  I believe that eavesdroppers
> and active attackers both need to be considered, particularly as we have
> so many open wifi networks.
> 
> To me the simplest way to address the Internet threat model is to always
> use TLS (except, maybe, for images and such elements that have little or
> no security value, though one must be careful when making that
> determination) and to use channel binding.  See the I-D referenced
> below.
> 
> [*]  See, for example: http://www.ietf.org/id/draft-williams-rest-gss-
> 00.txt

I fully agree with you that using TLS is usually preferred.  That said, we encounter situations where there were a large number of client/server interactions and the data conveyed is not confidential information in any way.  Using TLS can significantly decreases server performance, particularly when there are a number of separate connections that are established and broken.

So, we were trying to find a non-TLS solution that still provides a way to ensure the server can identify the user and that both can verify that data has not been tampered in flight.  (It would still be preferred to establish security relations with TLS, though we were open to other solutions.)

Paul