IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Fri, 20 May 2011 20:24 UTC

Return-Path: <nico@cryptonector.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 C105AE0758; Fri, 20 May 2011 13:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.29
X-Spam-Level:
X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 G2xdwSpYUxo9; Fri, 20 May 2011 13:24:47 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id E0E80E0710; Fri, 20 May 2011 13:24:47 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 55579594062; Fri, 20 May 2011 13:24:43 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=FQiafcjE6EoaINb7Dsj8n v+KqFhBY8X72n8fK2nfhbGqzZGubVW1S3UwIZZoH36V1/vH1BHIHQj3eeWC1Nup0 Jlg30DU1ZSXffceNHXdIVBzJbcI+hcIiD1/A8g1i+uJtvTP9OiAgl145JFvK2xTb xnB8Bj0XrApwp0kqDTQ0zE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ddX2s1YSRTkvGEZDzUsZ YMot7Bc=; b=SrpcK3ylsHGwZk+G8TER0bxRPcYZHJB1ORjYiXDCitosE5zCyQx1 9pa8dEOI75yusp6GxBt21VKCkLCA9VBSvFwxzzzlfFx0+xKjOcehgm/Oe8tbk8XP l79IIqsjEhCVY8UelMDIgJT6hdLrzhOJi61zqxWtyL9iN6HzvhMODGc=
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 04575594058; Fri, 20 May 2011 13:24:42 -0700 (PDT)
Received: by vws12 with SMTP id 12so3526669vws.31 for <multiple recipients>; Fri, 20 May 2011 13:24:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.106 with SMTP id cp10mr56945vdc.199.1305923082438; Fri, 20 May 2011 13:24:42 -0700 (PDT)
Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 13:24:42 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <AcwOfmxmPIi74XcpSTyynQcwm/I2bw==> <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 20 May 2011 15:24:42 -0500
Message-ID: <BANLkTikpQNyQdr9oWHhtJ7a7d-4ri0CNdA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Fri, 20 May 2011 13:50:27 -0700
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, Ben Adida <ben@adida.net>, "Adam Barth (adam@adambarth.com)" <adam@adambarth.com>, "http-state@ietf.org" <http-state@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, 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: Fri, 20 May 2011 20:24:48 -0000

Additional comments:

 - Using nonces for replay protection is heavy-duty.  It is difficult
to implement a reliable, secure, high-performance replay cache.  (It
is easy to implement just a high-performance replay cache: use
memcache.)

   I recommend an option to use sequence numbers at the server's
choice, understanding, of course, that requests will not be received
in sequence.  The use of a sliding sequence number window makes it
possible to do at least as well as when using nonce, and probably
faster while still being secure.

 - In an open wifi environment active attacks may not be very
difficult, thus an option to secure more than just a handful of bits
from the request, would be nice (all of the request and all of the
response, say).  The hard part is how to decide when to use one or the
other.  Ideally browsers can request more protection when the network
is reconfigured such that there's one or more clear wifi interfaces.

Nico
--

v2.23.0 | Report a Bug | By Email