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

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

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D964611E808A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jun 2011 15:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Level:
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 HAS1aknKB9dl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 7 Jun 2011 15:02:13 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id CE74E11E8071 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 7 Jun 2011 15:02:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1QU4Kz-0003NY-HE for ietf-http-wg-dist@listhub.w3.org; Tue, 07 Jun 2011 22:01:25 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <paulej@packetizer.com>) id 1QU4Jm-0002Bf-CD for ietf-http-wg@listhub.w3.org; Tue, 07 Jun 2011 22:00:10 +0000
Received: from dublin.packetizer.com ([75.101.130.125]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <paulej@packetizer.com>) id 1QU4Jk-0002Zo-Kn for ietf-http-wg@w3.org; Tue, 07 Jun 2011 22:00:10 +0000
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>
Cc: 'Eran Hammer-Lahav' <eran@hueniverse.com>, 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>
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, 07 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
Received-SPF: pass client-ip=75.101.130.125; envelope-from=paulej@packetizer.com; helo=dublin.packetizer.com
X-W3C-Hub-Spam-Status: No, score=-1.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: maggie.w3.org 1QU4Jk-0002Zo-Kn 4b266f9bf041a1a6839753b50bbb9e6b
X-Original-To: ietf-http-wg@w3.org
Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme
Archived-At: <http://www.w3.org/mid/00f101cc255e$2d426020$87c72060$@packetizer.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/10637
X-Loop: ietf-http-wg@w3.org
Sender: ietf-http-wg-request@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1QU4Kz-0003NY-HE@frink.w3.org>
Resent-Date: Tue, 07 Jun 2011 22:01:25 +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