Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 10 October 2007 17:53 UTC

Return-path: <channel-binding-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffkY-0001B5-6q; Wed, 10 Oct 2007 13:53:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IffkX-0000qV-H0 for channel-binding@ietf.org; Wed, 10 Oct 2007 13:53:37 -0400
Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IffkO-0002Wr-88 for channel-binding@ietf.org; Wed, 10 Oct 2007 13:53:33 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l9AHqKhX023337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 13:52:23 -0400 (EDT)
Date: Wed, 10 Oct 2007 13:52:20 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Simon Josefsson <simon@josefsson.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
Message-ID: <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu>
In-Reply-To: <87hckz2ado.fsf@mocca.josefsson.org>
References: <tslbqcf8eou.fsf@mit.edu> <871wc46umk.fsf@mocca.josefsson.org> <tsl4ph0vz30.fsf@mit.edu> <20071009203406.GL24532@Sun.COM> <tslk5pwugzz.fsf@mit.edu> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <tslmyurnhmv.fsf@mit.edu> <20071010154115.GY24532@Sun.COM> <87hckz2ado.fsf@mocca.josefsson.org>
Originator-Info: login-token=Mulberry:01risBqxiTdh/6dnks4akxGkWdONY1X3oboC8Q5Ks=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: channel-binding@ietf.org, ietf-sasl@imc.org
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of channel binding IANA registry requests and specifications <channel-binding.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
Errors-To: channel-binding-bounces@ietf.org


On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson 
<simon@josefsson.org> wrote:

> Nicolas Williams <Nicolas.Williams@Sun.COM> writes:
>
>> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman wrote:
>>>     Nicolas> I believe the text of the I-D is clear on the above.
>>>     Nicolas> Thus your protocol issues are taken care of.
>>>
>>> Well, my reading of the ID is that the protocol needs two slots--one
>>> for a prefix and one for a channel binding octec string.  Simon is
>>> arguing that we only want to have one slot.
>>> I'm fine with that if we want to make that change.
>>
>> I don't agree.  The I-D is clear on channel bindings being a single
>> octet string.  The prefix is a US-ASCII string prefixed to the raw
>> channel binding octet string.  After the prefix is added you still have
>> a single octet string.
>
> Right.  However, I think the document is unclear that the channel
> binding name and the unique prefix must be the same string.  The only
> reason I am fairly certain that they are actually intended to be the
> same has been this discussion, not the document.

I think section 7.1 makes it fairly clear that a channel binding is named 
by its prefix:

   o  Channel binding unique prefix (name):

> No, it wasn't about APIs, it was about what is sent in the
> "channel_binding_data" field over the wire.  If the current text in GS2
> is not sufficient to build interoperable implementations, I'd appreciate
> suggestions on what it has to say.

Well, you brought up the question of whether the channel binding data 
includes the prefix or not, and that's what we've been discussing.  So yes, 
the document is insufficiently clear.  But the length of the ensuing 
discussion does not mean that there is a major flaw; it just means that 
we've examined the issue carefully before determining what it should say. 
Now there will be additional discussion to determine how it should say it.

I don't think draft-williams-on-channel-binding needs to specifically 
provide advice to frameworks, as opposed to applications.  Any user of 
channel bindings is an "application" as far as this document is concerned, 
and there are quite a number of requirements on those.  As designer of a 
framework, or at least part of one, it is up to you to determine which of 
these requirements to help applications meet and how best to do so.  For 
example, for SASL it is probably best to provide integrity-protected 
transport of channel bindings and verify that both ends agree on what the 
bindings are, but leave it up to the application to verify that the channel 
binding data describes the channel that is actually in use.

Provided we clarify in draft-williams-on-channel-bindings that channel 
binding data includes the prefix, there is no problem with the protocol 
bits in GS2.  However, you are missing a requirement to check that the 
channel binding data sent by the client and server is actually the same. 
In fact, you provide virtually no information on what to do with the data 
elements related to channel binding.  I think this needs some work.

-- Jeff

_______________________________________________
CHANNEL-BINDING mailing list
CHANNEL-BINDING@ietf.org
https://www1.ietf.org/mailman/listinfo/channel-binding