Re: [apps-discuss] HTTP MAC Authentication Scheme

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

Return-Path: <nico@cryptonector.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 19F52E06CD; Fri, 20 May 2011 14:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level:
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 dxbVXMBeC4C3; Fri, 20 May 2011 14:31:54 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 54A13E06AD; Fri, 20 May 2011 14:31:54 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id ABE045406F; Fri, 20 May 2011 14:31:53 -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:content-transfer-encoding; q=dns; s= cryptonector.com; b=HbUh7udovQq+tRDqIt4xyHJwdFdJnh0hgbSUdAYXG933 +pvqZetq4T0/VBbFCbfcOPtedQem4ONpMc7iDRtrl38CSouoMAVQlBQMlHVw/2fA Al71SJDj6efTHVNQg6CFGf+E7wHK6KqYvWqXd2TrCKDd27tu+3fW+yGMtGx+guo=
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:content-transfer-encoding; s= cryptonector.com; bh=wRXDvM0zQrr3JzT7Xuq7tUvW91Q=; b=F/55JvrnwNI 4xHL4O+WKGEwjX8NcGgriBYxgAcbReEAG/x63bbH7Q/YYnbSJNF46i/C1H3zpyM+ Dt0yhCEeKIZKmtoXifnfvxO3de1uDy3ITTp+Xe6EtYENcqq9wiwUq1uAIiZZZnVE ZyOWMqjCeeFeeSWnGJXaMMLEKRHSsCF4=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 4EDC054057; Fri, 20 May 2011 14:31:53 -0700 (PDT)
Received: by vxg33 with SMTP id 33so3540948vxg.31 for <multiple recipients>; Fri, 20 May 2011 14:31:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.177.196 with SMTP id cs4mr117174vdc.279.1305927112714; Fri, 20 May 2011 14:31:52 -0700 (PDT)
Received: by 10.52.110.228 with HTTP; Fri, 20 May 2011 14:31:52 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <BANLkTikpQNyQdr9oWHhtJ7a7d-4ri0CNdA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723447582E46A9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Fri, 20 May 2011 16:31:52 -0500
Message-ID: <BANLkTin8-8LitkBoyUp+YFDYw5ohx4JyAQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: [apps-discuss] 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: Fri, 20 May 2011 21:31:55 -0000

On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>> 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.
>
> We switched to use time since credentials were issued. This should be pretty easy to implement if you really need reply protection by using a small window (clock sync is no longer a problem, just the delay in getting the credentials to the client, which should be a small window).

Kerberos has had an option to use time or sequence numbers for a long
time.  We've learned a few things from this experience.

For a memcache-type implementation, timestamps are probably best
because maintaining a sequence number window in memcache,
synchronized, would be a pain, if not impossible.

Other replay cache implementations would likely do better using
sequence numbers, especially when they have a small sequence number
window per-session.

And, of course, memcache isn't going to be durable (but probably it
will be good enough in many cases).  If you set a skew window to be
tight on the future side, then you can compensate for this if you can
detect loss of replay data (hmmm, not likely with memcache, eh?).

One big gotcha to be aware of:

 - Some clocks have lousy resolution, leading to easily repeated
values in high-rate environments.  One fix is to add resolution on the
wire and use random numbers for the unused precision bits.  Another
solution is to not use time.

My advice is that you allow the server to select which of timestamps
or sequence numbers to use.

Also, I strongly recommend that you specify replay cache semantics in
some detail.  Think of the Kerberos V5 replay cache semantics.

>>  - 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.
>
> There is just no easy way to do that. If you need more, use TLS.

But even then you need to know when to use TLS.  TLS doesn't solve the
problem when you're trying to solve problems without introducing TLS
in the first place.  This is a serious problem.  You think you're
fixing one problem (cookie theft by passive attackers on open
networks) and you're very likely only making things somewhat harder
for the attacker -- we need to be very careful that the attacker can't
just automate active attacks and still win.

Nico
--