Re: [apps-discuss] [saag] Fwd: HTTP MAC Authentication Scheme

Nico Williams <nico@cryptonector.com> Mon, 09 May 2011 20:03 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 090F8E08E5; Mon, 9 May 2011 13:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.083
X-Spam-Level:
X-Spam-Status: No, score=-3.083 tagged_above=-999 required=5 tests=[AWL=-1.106, 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 UNpf2rgjseBe; Mon, 9 May 2011 13:03:13 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 282DFE065A; Mon, 9 May 2011 13:03:13 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 93968598065; Mon, 9 May 2011 13:03:12 -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=v7b9UT5KM1oDyJl5C7u44 nBGuK+J66Y5iY5Bgx8h9HGZs4rEN7X5cKeGhMy1g0+xC3rcpSTsH3CzBxXKBdCM5 S3Zb4h9TBRee7QQyQQYrWq7B7h9z0ZgnoM16mAA5m6BqYRwZqORKScN7hxTEgzCH Z8kmBOchxHfSTG9JI7C1Cg=
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=867L0OFw+3JjQAnttm4g NxRjmTg=; b=SF2/Zg+EvyyE8SWgKbeJ6UuImTkjODJl+3DNcMcMyluoxRtOtxL7 6imhYs+/b/BpWJyZYl09qQBVFOXoF2TmUiyxDeZSSee+Ru4SZUZwOfhbNNxFQNDu qzyXvgmDS1uo54WgAXSArQWwpt1iDbojyFwciKetEzDkMew/QH26glg=
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 471C0598058; Mon, 9 May 2011 13:03:12 -0700 (PDT)
Received: by qwc23 with SMTP id 23so4209729qwc.31 for <multiple recipients>; Mon, 09 May 2011 13:03:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.170 with SMTP id m10mr387072vdv.160.1304971391490; Mon, 09 May 2011 13:03:11 -0700 (PDT)
Received: by 10.52.155.4 with HTTP; Mon, 9 May 2011 13:03:11 -0700 (PDT)
In-Reply-To: <B1968C5A-867C-4C7D-B3EF-A399AD626B60@vpnc.org>
References: <90C41DD21FB7C64BB94121FBBC2E723447581DA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <B1968C5A-867C-4C7D-B3EF-A399AD626B60@vpnc.org>
Date: Mon, 9 May 2011 15:03:11 -0500
Message-ID: <BANLkTinXPER5NaKxMFnbviMaX=CTSp81fg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Cc: saag@ietf.org, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [saag] Fwd: 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: Mon, 09 May 2011 20:03:14 -0000

On Mon, May 9, 2011 at 2:39 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> Of interest to some here.

Indeed.  My GSS-REST proposal uses something like this too.

Regarding the question of when to include a hash of the body in the
normalized request string that gets MACed... If one is using TLS, then
I suggest adding the TLS channel binding into the MAC input string and
drop the body hash.  This will speed up operation, since there's no
need to hash the body (think of the performance impact of hashing the
request body in an implementation that uses sendfile()!).

I don't see the point of attempting to provide only partial integrity
protection (e.g., the draft doesn't say to include ever request header
into the MAC input) if there's no TLS.  In fact, I don't see the point
of not using TLS, but if TLS avoidance is desired then all of the
request (minus the MAC) and response should be covered by the MAC.

The response headers also should get a MAC.

Using channel binding means that the MAC input string can be much
smaller -- it need only be fresh if the TLS CB type is
tls-server-end-point.  If the CB type is tls-unique then no nonce nor
credential age elements are needed to establish freshness.  And back
to the tls-server-end-point case, if the freshness element is a
sequence number then the MACs can be pre-computed, with a small
sliding window (implemented as a small bitmap and highest number seen
state elements).

Finally, presumably it's the application that generates and validates
the MACs, not HTTP itself.  Correct?

Nico
--