Re: draft-williams-on-channel-binding-00.txt is in the I-D repository

Simon Josefsson <jas@extundo.com> Tue, 15 August 2006 16:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD258-0004J6-Qn; Tue, 15 Aug 2006 12:47:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GD257-0004Ix-Sk; Tue, 15 Aug 2006 12:47:57 -0400
Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD256-0007qG-Ew; Tue, 15 Aug 2006 12:47:57 -0400
Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7FGlZ35012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Aug 2006 18:47:36 +0200
From: Simon Josefsson <jas@extundo.com>
To: ietf-sasl@imc.org
References: <20060815150854.GM4099@binky.Central.Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:060815:kitten@ietf.org::j5mVpzD0l9CwuIj5:7kF
X-Hashcash: 1:22:060815:nfsv4@ietf.org::+nGneS3q6rPkYuDN:0U19
X-Hashcash: 1:22:060815:ietf-sasl@imc.org::2XXieVIurLh6z0z0:BKcp
Date: Tue, 15 Aug 2006 18:47:35 +0200
In-Reply-To: <20060815150854.GM4099@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 15 Aug 2006 10:08:54 -0500")
Message-ID: <87ac663pzs.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: kitten@ietf.org, nfsv4@ietf.org
Subject: Re: draft-williams-on-channel-binding-00.txt is in the I-D repository
X-BeenThere: kitten@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/kitten>
List-Post: <mailto:kitten@lists.ietf.org>
List-Help: <mailto:kitten-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@lists.ietf.org?subject=subscribe>
Errors-To: kitten-bounces@lists.ietf.org

Nicolas Williams <Nicolas.Williams@sun.com> writes:

> Folks, the replacement for draft-ietf-nfsv4-channel-bindings,
> draft-williams-on-channel-binding-00.txt, is now in the I-D repository.
>
> It has also been significantly expanded.  Please review.  I'd like to
> ask the security ADs for an IETF Last Call on this I-D soon.

Looks good in general.  A general design question:

What about SASL/GS2 over TLS over SSH over IPSEC?  What is the channel
bindings for that, is it only the TLS binding?  Consider if the
application regards the TLS layer as weak (export ciphers) but the SSH
layer as strong, would it be permitted to use the SSH channel binding?
This sounds to me like it may require negotiation in GS2.

Some specific comments:

Section 2.1:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM could not easily force the
      channel bindings of a given channel to match those of another.

I'd change this to:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM cannot influence the
      channel bindings.

This drops "easily", and makes the requirement a bit stronger; the
MITM should not have any influence over the channel bindings.

This:

   o  Unique channel bindings MUST bind not only the key exchange for
      the secure channel, but also any negotiations and authentication
      that may have taken place to establish the channel.

Sometimes negotiations/authentications are done by other protocols, or
even out-of-band over the phone, and the intention was not to cover
those things, right?  I'm not sure how to phrase it better, though.

/Simon

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten