IETF Logo Mail Archive

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

"Paul E. Jones" <paulej@packetizer.com> Thu, 09 June 2011 05:04 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 0A96811E8074; Wed, 8 Jun 2011 22:04:00 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 tQF-pv-jrl7m; Wed, 8 Jun 2011 22:03:58 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7407111E80A1; Wed, 8 Jun 2011 22:03:57 -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 p5953hAL023650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2011 01:03:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1307595829; bh=bHUS1hrduBOhmVFiZU6VBRq2kMVBuAuYbE74ZGGRx8c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=epqzw1+fBL5v7YSl+6SHpNmcKgiGq3AQOac3v7bKnxDPSEGp4mHZZBtr6efZD+RmO SeV3yDxMFF4LJdc8W1BW3lQm6AumAdv24K+FvL5ZjN1jEkArFJW5B1LnYLOH2F/5zf ndZukHsMv+FSYo9RMrLVSodAa4GA+s4566kvYYSI=
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> <00f101cc255e$2d426020$87c72060$@packetizer.com> <BANLkTimn8c72p5bjwHNapW9kVCVBmNbC4w@mail.gmail.com> <015801cc25ab$063a2150$12ae63f0$@packetizer.com> <BANLkTimsKgozsADnA1+yccvKmg1Pa2mPng@mail.gmail.com>
In-Reply-To: <BANLkTimsKgozsADnA1+yccvKmg1Pa2mPng@mail.gmail.com>
Date: Thu, 09 Jun 2011 01:03:35 -0400
Message-ID: <02c401cc2662$9a21d220$ce657660$@packetizer.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C5_01CC2641.13103220"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFyB4gcQBia34uJQdRCExMgck4H0AKYdFzaAoZRr8EBlD5mpAL1HuqcAjoReDABal05/QI7UtjxlOx2sXA=
Content-Language: en-us
Cc: apps-discuss@ietf.org, 'Ben Adida' <ben@adida.net>, http-state@ietf.org, 'Adam Barth' <adam@adambarth.com>, 'OAuth WG' <oauth@ietf.org>, 'HTTP Working Group' <ietf-http-wg@w3.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: Thu, 09 Jun 2011 05:04:00 -0000

What issues, specifically.  (Messages are all over the place and I don’t know exactly what issues you’re raising.  Is it with the approach we’re proposing or something else?)

 

Paul

 

From: Nico Williams [mailto:nico@cryptonector.com] 
Sent: Wednesday, June 08, 2011 10:55 AM
To: Paul E. Jones
Cc: apps-discuss@ietf.org; Nico Williams; OAuth WG; HTTP Working Group; Ben Adida; Adam Barth; Eran Hammer-Lahav; http-state@ietf.org
Subject: RE: [http-state] [apps-discuss] HTTP MAC Authentication Scheme

 


On Jun 8, 2011 2:09 AM, "Paul E. Jones" <paulej@packetizer.com> wrote:
>
> Nico,
>
> Cookies would still be employed.  A cookie would be used to identify the particular user, for example.  However, it's important to make sure that the cookie provided by the client to the server is not stolen.  It's important to ensure that the client provided by the server to the client is not modified.  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.

You're still not addressing the issues raised.

Nico
--

v2.23.0 | Report a Bug | By Email