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

Simon Josefsson <simon@josefsson.org> Wed, 10 October 2007 16:38 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 1Ifea0-0002KC-TG; Wed, 10 Oct 2007 12:38:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifea0-0002Jw-0I for channel-binding@ietf.org; Wed, 10 Oct 2007 12:38:40 -0400
Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfeZt-0007y0-MH for channel-binding@ietf.org; Wed, 10 Oct 2007 12:38:39 -0400
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9AGcBWP015632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 18:38:12 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments
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>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:071010:ietf-sasl@imc.org::HXOy3oE/qDQZZ+DM:DgjO
X-Hashcash: 1:22:071010:channel-binding@ietf.org::UdAc5qnQJXGRSKf9:9RqS
X-Hashcash: 1:22:071010:hartmans-ietf@mit.edu::6mlc319qu60MjCVG:D5+Q
X-Hashcash: 1:22:071010:jhutz@cmu.edu::zQbc50Hs0RPLKiR1:kP83
Date: Wed, 10 Oct 2007 18:38:11 +0200
In-Reply-To: <20071010154115.GY24532@Sun.COM> (Nicolas Williams's message of "Wed, 10 Oct 2007 10:41:16 -0500")
Message-ID: <87hckz2ado.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled 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.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
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

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.

> Simon's issue, I thought, was about API slots.

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.

/Simon

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