From channel-binding-bounces@ietf.org Tue Oct 09 15:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLEu-0000D5-9v; Tue, 09 Oct 2007 15:59:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLEs-0000BA-8C for channel-binding@ietf.org; Tue, 09 Oct 2007 15:59:34 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfLEp-0004wf-T4 for channel-binding@ietf.org; Tue, 09 Oct 2007 15:59:32 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 198E848C4; Tue, 9 Oct 2007 15:59:31 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <871wc46umk.fsf@mocca.josefsson.org> Date: Tue, 09 Oct 2007 15:59:31 -0400 In-Reply-To: <871wc46umk.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 09 Oct 2007 19:54:59 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: channel-binding@ietf.org, ietf-sasl@imc.org Subject: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >> The draft looks quite good, but there are a few things that >> need to be resolved before I can last call it. Simon> Thanks for your review! Your proposed fixes look good except for the following: >> It also appears to violate the requirement that the name of the >> channel type be used in the channel binding data. Simon> I believe you are referring to this requirement: Simon> * The name of the type of channel binding MUST be Simon> used by the application and/or authentication protocol to Simon> avoid ambiguity about which of several possible types of Simon> channels is being bound. If nested instances of the same Simon> type of channel are available then the innermost channel Simon> MUST be used. Simon> I thought that channel binding data had to contain a unique Simon> prefix which would appears to solve that problem, without Simon> having to require that protocols encode the channel binding Simon> type too. If my assumption is correct, it would be useful Simon> to clarify this in d-w-on-channel-binding. No change in Simon> GS2 seems necessary. Nico? I thought it was the responsibility of the application|framework to add the unique prefix. The channel binding base draft provides a registry for this prefix, but I thought that the channel binding description did not include this prefix and left it up to the application. If the channel binding format must include the prefix then I think we need to change the channel binding base draft. Comments? _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 16:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLcV-0003mt-NF; Tue, 09 Oct 2007 16:23:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLcU-0003lQ-SN for channel-binding@ietf.org; Tue, 09 Oct 2007 16:23:58 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfLcU-0005ef-7f for channel-binding@ietf.org; Tue, 09 Oct 2007 16:23:58 -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 l99KNols004071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 22:23:51 +0200 From: Simon Josefsson To: Sam Hartman References: <871wc46umk.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071009:nicolas.williams@sun.com::WGeInLxRCkIewTqY:2A1s X-Hashcash: 1:22:071009:ietf-sasl@imc.org::VJf1XVkxh3XKRIzR:7r1s X-Hashcash: 1:22:071009:channel-binding@ietf.org::MqUJA0MWfluTPRX/:IDJG X-Hashcash: 1:22:071009:hartmans-ietf@mit.edu::FiAABoknHHVS1qQ0:Pjbc Date: Tue, 09 Oct 2007 22:23:50 +0200 In-Reply-To: (Sam Hartman's message of "Tue, 09 Oct 2007 15:59:31 -0400") Message-ID: <873awk3ull.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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: channel-binding@ietf.org, ietf-sasl@imc.org Subject: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Sam Hartman writes: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Sam Hartman writes: > >> The draft looks quite good, but there are a few things that > >> need to be resolved before I can last call it. > > Simon> Thanks for your review! > > Your proposed fixes look good except for the following: > >> It also appears to violate the requirement that the name of the > >> channel type be used in the channel binding data. > > Simon> I believe you are referring to this requirement: > > Simon> * The name of the type of channel binding MUST be > Simon> used by the application and/or authentication protocol to > Simon> avoid ambiguity about which of several possible types of > Simon> channels is being bound. If nested instances of the same > Simon> type of channel are available then the innermost channel > Simon> MUST be used. > > Simon> I thought that channel binding data had to contain a unique > Simon> prefix which would appears to solve that problem, without > Simon> having to require that protocols encode the channel binding > Simon> type too. If my assumption is correct, it would be useful > Simon> to clarify this in d-w-on-channel-binding. No change in > Simon> GS2 seems necessary. Nico? > > I thought it was the responsibility of the application|framework to > add the unique prefix. The channel binding base draft provides a > registry for this prefix, but I thought that the channel binding > description did not include this prefix and left it up to the > application. If the channel binding format must include the prefix > then I think we need to change the channel binding base draft. > > Comments? It appears simpler to me if channel binding data would always contain the unique prefix, properly delimited. Otherwise each protocol using channel binding need to have one slot for the "name of the type of channel binding" and one for the channel binding data. That is difficult to do properly if there are no guidance on the properties of these fields in williams-on-channel-binding. It is not clear to me what "name of the type of channel binding" refers to. Is it the unique prefix? Or the binding type? Or the channel type? All three fields are present in the channel binding IANA section. For example, would concatenating the unique prefix with channel binding data be sufficient? How can unique prefixes look like, [a-zA-Z0-9]? I couldn't find anything in williams-on-channel-binding that discuss this. /Simon _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 16:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLh3-0005TY-3u; Tue, 09 Oct 2007 16:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLh1-0005TS-9Q for channel-binding@ietf.org; Tue, 09 Oct 2007 16:28:39 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfLgu-0002c5-W3 for channel-binding@ietf.org; Tue, 09 Oct 2007 16:28:39 -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 l99KSC7E022811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 16:28:12 -0400 (EDT) Date: Tue, 09 Oct 2007 16:26:59 -0400 From: Jeffrey Hutzelman To: Sam Hartman , Simon Josefsson Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <60E8559BF5690B813666CABD@sirius.fac.cs.cmu.edu> In-Reply-To: References: <871wc46umk.fsf@mocca.josefsson.org> Originator-Info: login-token=Mulberry:01g2bmP+3OW7PPsV7AtuQWrhrYHWoKml/w2xSkueY=; 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: 6cca30437e2d04f45110f2ff8dc1b1d5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tuesday, October 09, 2007 03:59:31 PM -0400 Sam Hartman wrote: >>>>>> "Simon" == Simon Josefsson writes: > > Simon> Sam Hartman writes: > >> The draft looks quite good, but there are a few things that > >> need to be resolved before I can last call it. > > Simon> Thanks for your review! > > Your proposed fixes look good except for the following: > >> It also appears to violate the requirement that the name of the > >> channel type be used in the channel binding data. > > Simon> I believe you are referring to this requirement: > > Simon> * The name of the type of channel binding MUST be > Simon> used by the application and/or authentication protocol to > Simon> avoid ambiguity about which of several possible types of > Simon> channels is being bound. If nested instances of the same > Simon> type of channel are available then the innermost channel > Simon> MUST be used. > > Simon> I thought that channel binding data had to contain a unique > Simon> prefix which would appears to solve that problem, without > Simon> having to require that protocols encode the channel binding > Simon> type too. If my assumption is correct, it would be useful > Simon> to clarify this in d-w-on-channel-binding. No change in > Simon> GS2 seems necessary. Nico? > > I thought it was the responsibility of the application|framework to > add the unique prefix. The channel binding base draft provides a > registry for this prefix, but I thought that the channel binding > description did not include this prefix and left it up to the > application. If the channel binding format must include the prefix > then I think we need to change the channel binding base draft. > > Comments? I think the base draft is almost perfectly unclear on this issue. The requirement Simon quotes makes it clear that the channel type must be communicated and that the application must use it to determine which channel's bindings are acutally in use, but says nothing about whether the communication is up to the application or by virtue of the channel binding data being self-identifying. Another listed requirements is this: 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. On the one hand, this suggests that channel bindings are _not_ inherently self-identifying, but at the same time, it imposes a requirement that is most easily met by making them so. In addition, there are many places where the base document refers to the channel type name as a "prefix", implying that all channel bindings would start with a channel type name. So, I think we need to update the base document to be clear on what should happen here. I believe that correct behavior requires that channel types be identified in a consistent way for all channels, so this cannot be up to the individual channel type specifications. It could be done on a per-application basis, but I see no benefit to doing so rather than using the same method for all applications. -- Jeff PS: IIRC, draft-williams-on-channel-bindings has already been approved and is awaiting publication as an RFC. If it needs to change in order to address this issue, maybe someone should give the RFC Editor a heads up? _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 16:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLmT-0008Vb-Ds; Tue, 09 Oct 2007 16:34:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLmM-0008GE-OL for channel-binding@ietf.org; Tue, 09 Oct 2007 16:34:10 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfLmL-0005yx-Pa for channel-binding@ietf.org; Tue, 09 Oct 2007 16:34:10 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l99KY8dZ004135 for ; Tue, 9 Oct 2007 20:34:09 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l99KY8KR000085 for ; Tue, 9 Oct 2007 14:34:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l99KY8ck025201; Tue, 9 Oct 2007 15:34:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l99KY6xG025200; Tue, 9 Oct 2007 15:34:06 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 9 Oct 2007 15:34:06 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20071009203406.GL24532@Sun.COM> Mail-Followup-To: Sam Hartman , Simon Josefsson , ietf-sasl@imc.org, channel-binding@ietf.org References: <871wc46umk.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: channel-binding@ietf.org, ietf-sasl@imc.org Subject: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman wrote: > Simon> I thought that channel binding data had to contain a unique > Simon> prefix which would appears to solve that problem, without > Simon> having to require that protocols encode the channel binding > Simon> type too. If my assumption is correct, it would be useful > Simon> to clarify this in d-w-on-channel-binding. No change in > Simon> GS2 seems necessary. Nico? > > I thought it was the responsibility of the application|framework to > add the unique prefix. The channel binding base draft provides a > registry for this prefix, but I thought that the channel binding > description did not include this prefix and left it up to the > application. If the channel binding format must include the prefix > then I think we need to change the channel binding base draft. Sam is correct. In any case, I don't think the channel providing the bindings should be providing the prefix. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 16:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLpv-0004gC-G2; Tue, 09 Oct 2007 16:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfLpt-0004ar-TQ for channel-binding@ietf.org; Tue, 09 Oct 2007 16:37:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfLpn-0002rM-LP for channel-binding@ietf.org; Tue, 09 Oct 2007 16:37:49 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l99KbXT6004636 for ; Tue, 9 Oct 2007 20:37:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l99KbWKP000881 for ; Tue, 9 Oct 2007 14:37:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l99KbW66025210; Tue, 9 Oct 2007 15:37:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l99KbVhZ025209; Tue, 9 Oct 2007 15:37:31 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 9 Oct 2007 15:37:31 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071009203731.GM24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , Simon Josefsson , channel-binding@ietf.org, ietf-sasl@imc.org References: <871wc46umk.fsf@mocca.josefsson.org> <60E8559BF5690B813666CABD@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60E8559BF5690B813666CABD@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: channel-binding@ietf.org, Sam Hartman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tue, Oct 09, 2007 at 04:26:59PM -0400, Jeffrey Hutzelman wrote: > I think the base draft is almost perfectly unclear on this issue. The :( > requirement Simon quotes makes it clear that the channel type must be > communicated and that the application must use it to determine which > channel's bindings are acutally in use, but says nothing about whether the > communication is up to the application or by virtue of the channel binding > data being self-identifying. > > Another listed requirements is this: > > 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. > > On the one hand, this suggests that channel bindings are _not_ inherently > self-identifying, but at the same time, it imposes a requirement that is > most easily met by making them so. In addition, there are many places > where the base document refers to the channel type name as a "prefix", > implying that all channel bindings would start with a channel type name. The intention was for the applications to add the prefix (channel bindings being an octet string there's no need for an additional "slot"). > So, I think we need to update the base document to be clear on what should > happen here. I believe that correct behavior requires that channel types > be identified in a consistent way for all channels, so this cannot be up to > the individual channel type specifications. It could be done on a > per-application basis, but I see no benefit to doing so rather than using > the same method for all applications. Hmmm, OK, I could go either way. But in some cases the application may be in charge of constructing the channel binding from things like end-point identities, so the application will be responsible, at least in some cases, for knowing the prefix and adding it in. > -- Jeff > > PS: IIRC, draft-williams-on-channel-bindings has already been approved and > is awaiting publication as an RFC. If it needs to change in order to > address this issue, maybe someone should give the RFC Editor a heads up? We're not in AUTH48 yet, so we can still make a clarification here. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 16:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM3W-0007oX-FK; Tue, 09 Oct 2007 16:51:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM3U-0007iB-Qw for channel-binding@ietf.org; Tue, 09 Oct 2007 16:51:52 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfM3U-0006YD-2D for channel-binding@ietf.org; Tue, 09 Oct 2007 16:51:52 -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 l99KpiBA011783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 22:51:45 +0200 From: Simon Josefsson To: Sam Hartman References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071009:ietf-sasl@imc.org::gWNXqVjMnXDRiNkf:WxHY X-Hashcash: 1:22:071009:hartmans-ietf@mit.edu::WkHu1AmaPHL7Vry0:MGS9 X-Hashcash: 1:22:071009:channel-binding@ietf.org::M59V2kxQtiU6Xos5:SH0M Date: Tue, 09 Oct 2007 22:51:44 +0200 In-Reply-To: <20071009203406.GL24532@Sun.COM> (Nicolas Williams's message of "Tue, 9 Oct 2007 15:34:06 -0500") Message-ID: <87tzp02eqn.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: channel-binding@ietf.org, ietf-sasl@imc.org Subject: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Nicolas Williams writes: > On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman wrote: >> Simon> I thought that channel binding data had to contain a unique >> Simon> prefix which would appears to solve that problem, without >> Simon> having to require that protocols encode the channel binding >> Simon> type too. If my assumption is correct, it would be useful >> Simon> to clarify this in d-w-on-channel-binding. No change in >> Simon> GS2 seems necessary. Nico? >> >> I thought it was the responsibility of the application|framework to >> add the unique prefix. The channel binding base draft provides a >> registry for this prefix, but I thought that the channel binding >> description did not include this prefix and left it up to the >> application. If the channel binding format must include the prefix >> then I think we need to change the channel binding base draft. > > Sam is correct. In any case, I don't think the channel providing the > bindings should be providing the prefix. Could you suggest some text that would be appropriate in GS2 section 5? It would help if on-channel-binding discussed its interface to authentication protocols. For example, what should GS2 say about channel bindings that need confidentiality protection? Can GS2 use such a channel binding at all? /Simon _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 17:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMQR-0005Fl-E5; Tue, 09 Oct 2007 17:15:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMQP-0005AY-IL for channel-binding@ietf.org; Tue, 09 Oct 2007 17:15:33 -0400 Received: from dhcp-18-188-10-61.dyn.mit.edu ([18.188.10.61] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfMQL-000744-7x for channel-binding@ietf.org; Tue, 09 Oct 2007 17:15:29 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 669ED4A3E; Tue, 9 Oct 2007 17:15:28 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> Date: Tue, 09 Oct 2007 17:15:28 -0400 In-Reply-To: <20071009203406.GL24532@Sun.COM> (Nicolas Williams's message of "Tue, 9 Oct 2007 15:34:06 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: channel-binding@ietf.org, ietf-sasl@imc.org Subject: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Oct 09, 2007 at 03:59:31PM -0400, Sam Hartman Nicolas> wrote: Simon> I thought that channel binding data had to contain a unique Simon> prefix which would appears to solve that problem, without Simon> having to require that protocols encode the channel binding Simon> type too. If my assumption is correct, it would be useful Simon> to clarify this in d-w-on-channel-binding. No change in Simon> GS2 seems necessary. Nico? >> I thought it was the responsibility of the >> application|framework to add the unique prefix. The channel >> binding base draft provides a registry for this prefix, but I >> thought that the channel binding description did not include >> this prefix and left it up to the application. If the channel >> binding format must include the prefix then I think we need to >> change the channel binding base draft. Nicolas> Sam is correct. Ah, good. It's always reassuring when I understand drafts I sponsor. Nicolas> In any case, I don't think the channel Nicolas> providing the bindings should be providing the prefix. I don't see why this is true. I'm with Nico; could go either way. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 17:25:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMa6-0004sD-MY; Tue, 09 Oct 2007 17:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMa5-0004s8-6N for channel-binding@ietf.org; Tue, 09 Oct 2007 17:25:33 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfMZz-0004Cf-Su for channel-binding@ietf.org; Tue, 09 Oct 2007 17:25:33 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l99LPHFK016065 for ; Tue, 9 Oct 2007 21:25:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l99LPH27006448 for ; Tue, 9 Oct 2007 15:25:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l99LPHt7025239; Tue, 9 Oct 2007 16:25:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l99LPGBU025238; Tue, 9 Oct 2007 16:25:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 9 Oct 2007 16:25:16 -0500 From: Nicolas Williams To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071009212516.GP24532@Sun.COM> Mail-Followup-To: Sam Hartman , Simon Josefsson , channel-binding@ietf.org, ietf-sasl@imc.org References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tue, Oct 09, 2007 at 05:15:28PM -0400, Sam Hartman wrote: > Nicolas> In any case, I don't think the channel > Nicolas> providing the bindings should be providing the prefix. > > I don't see why this is true. I'm with Nico; could go either way. Heh! OK, let's decide either way, shall we? Because in some cases apps will be responsible for constructing the channel binding in the first place, and to minimize API impact on secure channels, I'd rather make the app responsible for adding the prefix. The primary consequence of doing so is: apps must know what type of channel they are binding to, and if they don't know then the implication is that some channel abstraction layer exists which does know and can be made responsible for adding the prefix. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 17:45:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMtD-0008Pb-Nt; Tue, 09 Oct 2007 17:45:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfMtB-0007iC-Lu for channel-binding@ietf.org; Tue, 09 Oct 2007 17:45:17 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfMsp-0007zR-3V for channel-binding@ietf.org; Tue, 09 Oct 2007 17:44:55 -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 l99LildD022837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Oct 2007 17:44:51 -0400 (EDT) Date: Tue, 09 Oct 2007 17:44:47 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> In-Reply-To: <20071009212516.GP24532@Sun.COM> References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> Originator-Info: login-token=Mulberry:01556goFEGFRQz6RghGhzQD34Q18tu0hlUE84FHR4=; 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: bb8f917bb6b8da28fc948aeffb74aa17 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas Williams wrote: > On Tue, Oct 09, 2007 at 05:15:28PM -0400, Sam Hartman wrote: >> Nicolas> In any case, I don't think the channel >> Nicolas> providing the bindings should be providing the prefix. >> >> I don't see why this is true. I'm with Nico; could go either way. > > Heh! > > OK, let's decide either way, shall we? Because in some cases apps will > be responsible for constructing the channel binding in the first place, > and to minimize API impact on secure channels, I'd rather make the app > responsible for adding the prefix. > > The primary consequence of doing so is: apps must know what type of > channel they are binding to, and if they don't know then the implication > is that some channel abstraction layer exists which does know and can be > made responsible for adding the prefix. Really, I don't care what the API looks like or what part of the implementation is responsible for adding the prefix. What I care about is who is responsible for specifying how the prefix is encoded and transported. Does the application protocol specification do this, possibly by transporting two protocol fields (a name and an octet string)? Or is the prefix part of the octet-string channel binding data? I'm inclined to specify that all protocols should work the same way, transporting a single octet string which consists of the prefix, followed by a NUL octet, followed by the actual binding data. -- Jeff _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 20:48:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPk4-0001vb-R2; Tue, 09 Oct 2007 20:48:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfPk3-0001sx-Rr for channel-binding@ietf.org; Tue, 09 Oct 2007 20:48:03 -0400 Received: from stratton-five-seventy-one.mit.edu ([18.187.7.60] helo=carter-zimmerman.suchdamage.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfPk1-0006Ne-JR for channel-binding@ietf.org; Tue, 09 Oct 2007 20:48:01 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 140864A3E; Tue, 9 Oct 2007 20:48:01 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> Date: Tue, 09 Oct 2007 20:48:01 -0400 In-Reply-To: <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 09 Oct 2007 17:44:47 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas Jeffrey> I'm inclined to specify that all protocols should work Jeffrey> the same way, transporting a single octet string which Jeffrey> consists of the prefix, followed by a NUL octet, followed Jeffrey> by the actual binding data. Please don't use nul; use : or something like that and forbid that character from prefixes. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 09 21:07:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQ2b-0006Iv-4i; Tue, 09 Oct 2007 21:07:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfQ2Z-0006GI-EC for channel-binding@ietf.org; Tue, 09 Oct 2007 21:07:11 -0400 Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfQ2Z-0006ys-41 for channel-binding@ietf.org; Tue, 09 Oct 2007 21:07:11 -0400 Received: from [68.247.78.113] (000-217-534.area3.spcsdns.net [68.247.78.113]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l9A15vhb000881 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Oct 2007 21:06:21 -0400 (EDT) From: "Jeffrey Hutzelman" Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Date: 09 Oct 2007 21:07:00 -0400 To: X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.8) Message-ID: <3274808827.15922136@smtp.srv.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas.Williams@sun.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Fine; I don't have any particular reason to prefer nul. But, why not; what problem are you concerned about? -----Original Message----- From: Sam Hartman Date: Tuesday, Oct 9, 2007 8:48 pm Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments To: Jeffrey Hutzelman CC: Nicolas Williams , channel-binding@ietf.org, ietf-sasl@imc.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: > > Jeffrey> On Tuesday, October 09, 2007 04:25:16 PM -0500 Nicolas > > Jeffrey> I'm inclined to specify that all protocols should work > Jeffrey> the same way, transporting a single octet string which > Jeffrey> consists of the prefix, followed by a NUL octet, followed > Jeffrey> by the actual binding data. > >Please don't use nul; use : or something like that and forbid that >character from prefixes. > > > _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 09:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbEK-0000nj-IH; Wed, 10 Oct 2007 09:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfbEJ-0000hO-8h for channel-binding@ietf.org; Wed, 10 Oct 2007 09:04:03 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfbE9-0000DK-49 for channel-binding@ietf.org; Wed, 10 Oct 2007 09:03:59 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 723CA48C4; Wed, 10 Oct 2007 09:03:34 -0400 (EDT) From: Sam Hartman To: "Jeffrey Hutzelman" Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <3274808827.15922136@smtp.srv.cs.cmu.edu> Date: Wed, 10 Oct 2007 09:03:34 -0400 In-Reply-To: <3274808827.15922136@smtp.srv.cs.cmu.edu> (Jeffrey Hutzelman's message of "09 Oct 2007 21:07:00 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas.Williams@sun.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> Fine; I don't have any particular reason to prefer nul. Jeffrey> But, why not; what problem are you concerned about? C strings. Yes, a correct implementation will not have this problem. I see no reason to make it harder though. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 10:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcgZ-0001Oz-MZ; Wed, 10 Oct 2007 10:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfcgY-0001Lp-3y for channel-binding@ietf.org; Wed, 10 Oct 2007 10:37:18 -0400 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfcgI-0003rt-8W for channel-binding@ietf.org; Wed, 10 Oct 2007 10:37:03 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9AEaqmD022460 for ; Wed, 10 Oct 2007 14:36:52 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9AEaphd024210 for ; Wed, 10 Oct 2007 08:36:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9AEap5p025909; Wed, 10 Oct 2007 09:36:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9AEaol4025908; Wed, 10 Oct 2007 09:36:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Oct 2007 09:36:50 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071010143650.GT24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , channel-binding@ietf.org, ietf-sasl@imc.org References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Tue, Oct 09, 2007 at 05:44:47PM -0400, Jeffrey Hutzelman wrote: > Really, I don't care what the API looks like or what part of the > implementation is responsible for adding the prefix. What I care > about is who is responsible for specifying how the prefix is encoded > and transported. Does the application protocol specification do this, > possibly by transporting two protocol fields (a name and an octet > string)? Or is the prefix part of the octet-string channel binding > data? The channel binding octet string and the prefix US-ASCII string are both *just* that. Prefixing the latter to the former is feasible without ambiguity provided that: the prefixes are unique and that they are always used. No separator character is needed (but if one was needed I'd prefer ':' over NUL). I believe the text of the I-D is clear on the above. Thus your protocol issues are taken care of. The more I think about the who's-responsible-for-prefixing issue the more I realize that the I-D shouldn't speak to that issue. I could see an operating system where all channels report channel bindings with the prefix already included, another where only some do, and another where none do -- but in all cases the applications can deal and interop provided that the applications know which channels include the prefix when and which don't. Thus, I'm inclined to believe that the issue in question requires no clarfication beyond saying that the ambiguity is intentional. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 10:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifcyd-00076t-4I; Wed, 10 Oct 2007 10:55:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifcyb-0006r8-Fo for channel-binding@ietf.org; Wed, 10 Oct 2007 10:55:57 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfcyX-0007F8-21 for channel-binding@ietf.org; Wed, 10 Oct 2007 10:55:53 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C66648C4; Wed, 10 Oct 2007 10:55:52 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> Date: Wed, 10 Oct 2007 10:55:52 -0400 In-Reply-To: <20071010143650.GT24532@Sun.COM> (Nicolas Williams's message of "Wed, 10 Oct 2007 09:36:50 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Tue, Oct 09, 2007 at 05:44:47PM -0400, Jeffrey Nicolas> Hutzelman wrote: >> Really, I don't care what the API looks like or what part of >> the implementation is responsible for adding the prefix. What >> I care about is who is responsible for specifying how the >> prefix is encoded and transported. Does the application >> protocol specification do this, possibly by transporting two >> protocol fields (a name and an octet string)? Or is the prefix >> part of the octet-string channel binding data? Nicolas> The channel binding octet string and the prefix US-ASCII Nicolas> string are both *just* that. Prefixing the latter to the Nicolas> former is feasible without ambiguity provided that: the Nicolas> prefixes are unique and that they are always used. Well, if I have a prefix tls and a prefix t with a channel binding starting ls I may have a problem. Nicolas> No Nicolas> separator character is needed (but if one was needed I'd Nicolas> prefer ':' over NUL). 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 think Jeff is arguing for the same. I think you ande I don't care much. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifd8c-0001bm-A9; Wed, 10 Oct 2007 11:06:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifd8b-0001bb-Hm for channel-binding@ietf.org; Wed, 10 Oct 2007 11:06:17 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ifd8b-0007ay-8i for channel-binding@ietf.org; Wed, 10 Oct 2007 11:06:17 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa08076; 10 Oct 2007 11:05 EDT Date: Wed, 10 Oct 2007 11:05:34 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, 10 Oct 2007, Sam Hartman wrote: > Well, if I have a prefix tls and a prefix t with a channel binding > starting ls I may have a problem. Right; that's why you need an unambiguous separator if they're going to go in the same slot. > 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 think Jeff is arguing for the same. I think you ande I don't care > much. I don't much care; I'm fine with requiring two separate slots. As far as I'm concerned, the document as it stands right now is not sufficiently clear; it could be interpreted in either way. As evidence of this I offer the existance of the present discussion. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:16:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdIR-0003Hq-Fb; Wed, 10 Oct 2007 11:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdIP-0003Hl-W9 for channel-binding@ietf.org; Wed, 10 Oct 2007 11:16:25 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IfdIJ-00056q-Ro for channel-binding@ietf.org; Wed, 10 Oct 2007 11:16:25 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa08085; 10 Oct 2007 11:16 EDT Date: Wed, 10 Oct 2007 11:16:00 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: <20071010143650.GT24532@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, 10 Oct 2007, Nicolas Williams wrote: > The more I think about the who's-responsible-for-prefixing issue the > more I realize that the I-D shouldn't speak to that issue. I could see > an operating system where all channels report channel bindings with the > prefix already included, another where only some do, and another where > none do -- but in all cases the applications can deal and interop > provided that the applications know which channels include the prefix > when and which don't. Again, I don't care what the operating system or the library does. Of course the document should not speak to that; focusing on API issues rather than protocol issues misses the point, which is that independent implementations be able to interoperate. What I _do_ care about is that it's clear in every case what the bits are supposed to look like on the wire and what the application protocol specification is responsible for doing. If the application protocol is supposed to provide a single slot which will contain the prefix followed by the channel binding data, then say so, and specify exactly how they are combined. If the application protocol is responsible for separately transporting the prefix and channel binding data, then say _that_, and make it clear that you need integrity protection for both. Otherwise you're going to get into a situation where the base document expects the app to transport the two elements separately, but the author of an application protocol thinks he only gets one blob which contains both, and then you have a mess because implementors don't know what to do with the prefix (ignore it? prepend it to the data? how?) and either nothing interoperates or you end up with an application protocol that you can't implement correctly without making undocumented assumptions. BTW, an environment in which some channels report data without a prefix, others report it with the prefix followed by ':', and still others report it with the prefix followed by NUL is about the worst thing I can think of. Anyone actually designing an API for this should define a consistent way of doing it. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdey-0000HN-FQ; Wed, 10 Oct 2007 11:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdex-0000HH-I1 for channel-binding@ietf.org; Wed, 10 Oct 2007 11:39:43 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifdew-00060S-Ad for channel-binding@ietf.org; Wed, 10 Oct 2007 11:39:43 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AFdNjh000035 for ; Wed, 10 Oct 2007 15:39:23 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9AFdNTK000449 for ; Wed, 10 Oct 2007 09:39:23 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9AFdJRK025958; Wed, 10 Oct 2007 10:39:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9AFdJq6025957; Wed, 10 Oct 2007 10:39:19 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Oct 2007 10:39:18 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071010153918.GX24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman References: <20071010143650.GT24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Sam Hartman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, Oct 10, 2007 at 11:16:00AM -0400, Jeffrey Hutzelman wrote: > On Wed, 10 Oct 2007, Nicolas Williams wrote: > > > The more I think about the who's-responsible-for-prefixing issue the > > more I realize that the I-D shouldn't speak to that issue. I could see > > an operating system where all channels report channel bindings with the > > prefix already included, another where only some do, and another where > > none do -- but in all cases the applications can deal and interop > > provided that the applications know which channels include the prefix > > when and which don't. > > Again, I don't care what the operating system or the library does. Of > course the document should not speak to that; focusing on API issues > rather than protocol issues misses the point, which is that independent > implementations be able to interoperate. Part of the point of the e-mail to which you're replying was to take the focus off APIs. > What I _do_ care about is that it's clear in every case what the bits are > supposed to look like on the wire and what the application protocol > specification is responsible for doing. If the application protocol is > supposed to provide a single slot which will contain the prefix followed > by the channel binding data, then say so, and specify exactly how they are > combined. If the application protocol is responsible for separately > transporting the prefix and channel binding data, then say _that_, and > make it clear that you need integrity protection for both. Please re-read the bits you didn't quote. I believe there's a guarantee of non-ambiguity. > Otherwise you're going to get into a situation where the base document > expects the app to transport the two elements separately, but the author > of an application protocol thinks he only gets one blob which contains > both, and then you have a mess because implementors don't know what to do > with the prefix (ignore it? prepend it to the data? how?) and either > nothing interoperates or you end up with an application protocol that you > can't implement correctly without making undocumented assumptions. > > > > > > BTW, an environment in which some channels report data without a prefix, > others report it with the prefix followed by ':', and still others report > it with the prefix followed by NUL is about the worst thing I can think > of. Anyone actually designing an API for this should define a consistent > way of doing it. I wrote nothing about the separator being variable or the prefix being optional. The text about operating systems was to illustrate that we need not say who is responsible, API-wise, for adding the prefix, as long as it is added. Please re-read carefully. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:41:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdgd-0001JL-Bw; Wed, 10 Oct 2007 11:41:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdgb-00019V-P3 for channel-binding@ietf.org; Wed, 10 Oct 2007 11:41:25 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfdgU-0000Dj-5T for channel-binding@ietf.org; Wed, 10 Oct 2007 11:41:18 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AFfHEo015698 for ; Wed, 10 Oct 2007 15:41:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9AFfGcn000973 for ; Wed, 10 Oct 2007 09:41:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9AFfGgU025965; Wed, 10 Oct 2007 10:41:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9AFfG7S025964; Wed, 10 Oct 2007 10:41:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Oct 2007 10:41:16 -0500 From: Nicolas Williams To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071010154115.GY24532@Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , channel-binding@ietf.org, ietf-sasl@imc.org References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org 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. Simon's issue, I thought, was about API slots. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:51:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdq5-0003se-Gf; Wed, 10 Oct 2007 11:51:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdq3-0003mO-LC for channel-binding@ietf.org; Wed, 10 Oct 2007 11:51:11 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ifdq3-0000dH-8S for channel-binding@ietf.org; Wed, 10 Oct 2007 11:51:11 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa08138; 10 Oct 2007 11:51 EDT Date: Wed, 10 Oct 2007 11:51:03 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: <20071010154115.GY24532@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, 10 Oct 2007, Nicolas Williams wrote: > 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. Ah, but the spec doesn't actually _say_ that. It doesn't actually say anywhere that the prefix is prepended to the channel-specific binding data, resulting in a single octet string for the application to transport. On the other hand, it _does_ say that the application needs to distinguish channel types based on the prefix, which suggests (but only suggests) that they are treated as separate items. If it's a single string, then you need a separator, for two reasons: - Without it, it's not good enough for prefixes to be unique; it must be the case that no prefix is an initial substring of another. - Without a separator, it is difficult for the application (or library) to separate the prefix from the data, which it must do in order to determine the channel type, which affects interpretation of the data. Of course, one could use another approach, like a counted string, or a fixed-width field, or a fixed-size integer. I don't care much. > Simon's issue, I thought, was about API slots. I suppose we should let Simon speak for himself, but I believe his issue was about supporting channel bindings in SASL-GS2. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdsY-0001DO-28; Wed, 10 Oct 2007 11:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfdsX-0001DC-6Y for channel-binding@ietf.org; Wed, 10 Oct 2007 11:53:45 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfdsR-0006ZI-JM for channel-binding@ietf.org; Wed, 10 Oct 2007 11:53:45 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9AFrSUO001356 for ; Wed, 10 Oct 2007 15:53:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9AFrSx6005181 for ; Wed, 10 Oct 2007 09:53:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9AFrRxj026013; Wed, 10 Oct 2007 10:53:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9AFrRnc026012; Wed, 10 Oct 2007 10:53:27 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Oct 2007 10:53:27 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071010155327.GC24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071010154115.GY24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, Oct 10, 2007 at 11:51:03AM -0400, Jeffrey Hutzelman wrote: > On Wed, 10 Oct 2007, Nicolas Williams wrote: > > 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. > > Ah, but the spec doesn't actually _say_ that. It doesn't actually say > anywhere that the prefix is prepended to the channel-specific binding > data, resulting in a single octet string for the application to transport. > On the other hand, it _does_ say that the application needs to distinguish > channel types based on the prefix, which suggests (but only suggests) that > they are treated as separate items. Well, OK, we can clarify that. > If it's a single string, then you need a separator, for two reasons: > > - Without it, it's not good enough for prefixes to be unique; it must be > the case that no prefix is an initial substring of another. > > - Without a separator, it is difficult for the application (or library) > to separate the prefix from the data, which it must do in order to > determine the channel type, which affects interpretation of the data. > > Of course, one could use another approach, like a counted string, or a > fixed-width field, or a fixed-size integer. I don't care much. Sure. I'll send text this afternoon. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdsu-0001Wa-Km; Wed, 10 Oct 2007 11:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdss-0001TV-V3 for channel-binding@ietf.org; Wed, 10 Oct 2007 11:54:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifdsm-0006Zj-PD for channel-binding@ietf.org; Wed, 10 Oct 2007 11:54:06 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 32D9E48C4; Wed, 10 Oct 2007 11:53:50 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> Date: Wed, 10 Oct 2007 11:53:50 -0400 In-Reply-To: <20071010154115.GY24532@Sun.COM> (Nicolas Williams's message of "Wed, 10 Oct 2007 10:41:16 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman Nicolas> wrote: I believe the text of the I-D is clear on the Nicolas> above. 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. Nicolas> I don't agree. The I-D is clear on channel bindings Nicolas> being a single octet string. The prefix is a US-ASCII Nicolas> string prefixed to the raw channel binding octet string. Nicolas> After the prefix is added you still have a single octet Nicolas> string. O, I think Simon and I thought it was called a prefix because we expected it to be prefixed in a lot of protocols. I don't read the current text that way at all. I think Simon, Jeff and I would be happy if the draft did actually say that. Simon, would you be willing to propose a change? _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 11:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdwt-0004SP-Bl; Wed, 10 Oct 2007 11:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifdwq-0004Rn-4G for channel-binding@ietf.org; Wed, 10 Oct 2007 11:58:12 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifdwo-0006jE-WF for channel-binding@ietf.org; Wed, 10 Oct 2007 11:58:12 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B2CF48C4; Wed, 10 Oct 2007 11:58:10 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071010154115.GY24532@Sun.COM> <20071010155327.GC24532@Sun.COM> Date: Wed, 10 Oct 2007 11:58:10 -0400 In-Reply-To: <20071010155327.GC24532@Sun.COM> (Nicolas Williams's message of "Wed, 10 Oct 2007 10:53:27 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org If you want to send text that's fine. I was asking Simon because I thought you were relatively busy. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 12:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife1W-0001R1-PR; Wed, 10 Oct 2007 12:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife1W-0001QJ-GD for channel-binding@ietf.org; Wed, 10 Oct 2007 12:03:02 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ife1W-0000zm-3y for channel-binding@ietf.org; Wed, 10 Oct 2007 12:03:02 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9AG31IN008314 for ; Wed, 10 Oct 2007 16:03:01 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9AG30JA007793 for ; Wed, 10 Oct 2007 10:03:01 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9AG30rK026041; Wed, 10 Oct 2007 11:03:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9AG30YO026040; Wed, 10 Oct 2007 11:03:00 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 10 Oct 2007 11:03:00 -0500 From: Nicolas Williams To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071010160300.GE24532@Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071010154115.GY24532@Sun.COM> <20071010155327.GC24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, Oct 10, 2007 at 11:58:10AM -0400, Sam Hartman wrote: > If you want to send text that's fine. I was asking Simon because I > thought you were relatively busy. True. Yes, Simon, do suggest text please :) _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 12:38:40 2007 Return-path: 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 To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Nicolas Williams 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 From channel-binding-bounces@ietf.org Wed Oct 10 12:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifetm-0001fE-Bs; Wed, 10 Oct 2007 12:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifetk-0001ei-VX for channel-binding@ietf.org; Wed, 10 Oct 2007 12:59:05 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifetj-0002oV-T7 for channel-binding@ietf.org; Wed, 10 Oct 2007 12:59:04 -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 l9AGwj3i018948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Oct 2007 18:58:48 +0200 From: Simon Josefsson To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071010:jhutz@cmu.edu::vnokl4MnxsusWht9:0oOP X-Hashcash: 1:22:071010:hartmans-ietf@mit.edu::RkCAJi4/qNs4KeOK:6rms X-Hashcash: 1:22:071010:ietf-sasl@imc.org::5EiEJDCYb4RDn7UH:B8OB X-Hashcash: 1:22:071010:channel-binding@ietf.org::xKLs1mylcJrcSxf2:WVf0 Date: Wed, 10 Oct 2007 18:58:45 +0200 In-Reply-To: (Sam Hartman's message of "Wed, 10 Oct 2007 11:53:50 -0400") Message-ID: <87d4vm3nzu.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: 4adaf050708fb13be3316a9eee889caa 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Sam Hartman writes: >>>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Oct 10, 2007 at 10:55:52AM -0400, Sam Hartman > Nicolas> wrote: I believe the text of the I-D is clear on the > Nicolas> above. 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. > > Nicolas> I don't agree. The I-D is clear on channel bindings > Nicolas> being a single octet string. The prefix is a US-ASCII > Nicolas> string prefixed to the raw channel binding octet string. > Nicolas> After the prefix is added you still have a single octet > Nicolas> string. > > O, I think Simon and I thought it was called a prefix because we > expected it to be prefixed in a lot of protocols. I don't read the > current text that way at all. > > I think Simon, Jeff and I would be happy if the draft did actually say > that. > Simon, would you be willing to propose a change? I'm confused by the on-channel-binding document and I'm not convinced any minor change would have made the document clearer to me. What I'm looking for is a recipe to reference on-channel-binding in an authentication protocol like GS2. GS2 wants to bind authentication to a secure channel such as TLS. That seems to be a fairly simple and common way to use the on-channel-binding document (or?) so the length of this discussion, and the lack of specific suggestions for GS2, suggest to me that something is missing from the channel binding document. What I'm looking for is something like this: X. Requirements On Frameworks That Use Channel Bindings Frameworks that wish to utilize a channel binding mechanism by referencing this document MUST transfer both the channel binding name (the unique prefix) and the channel binding data. This MAY be done by concatenating the two strings. /Simon _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Oct 10 13:53:38 2007 Return-path: 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 To: Simon Josefsson , Sam Hartman 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: <871wc46umk.fsf@mocca.josefsson.org> <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson wrote: > Nicolas Williams 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 From channel-binding-bounces@ietf.org Thu Oct 11 11:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzgJ-0003Eo-IB; Thu, 11 Oct 2007 11:10:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzgJ-0003EV-0S for channel-binding@ietf.org; Thu, 11 Oct 2007 11:10:35 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifzg5-0001Gr-Lv for channel-binding@ietf.org; Thu, 11 Oct 2007 11:10:34 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9BFALO7019016 for ; Thu, 11 Oct 2007 15:10:21 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BFAKaB012591 for ; Thu, 11 Oct 2007 09:10:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BFAGTq027018; Thu, 11 Oct 2007 10:10:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BFAFGG027017; Thu, 11 Oct 2007 10:10:15 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 10:10:15 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071011151015.GN24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Simon Josefsson , Sam Hartman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> <87hckz2ado.fsf@mocca.josefsson.org> <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: channel-binding@ietf.org, Sam Hartman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Wed, Oct 10, 2007 at 01:52:20PM -0400, Jeffrey Hutzelman wrote: > On Wednesday, October 10, 2007 06:38:11 PM +0200 Simon Josefsson > wrote: > >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. The on-channel-binding I-D doesn't say that the channel binding data is sent -- there is not "channel_binding_data field" as such. The authentication mechanism must verify that the channel bindings match on both ends, but that need not mean sending the channel binding data. > 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'm not sure that there's any ambiguity: * The name of the type of channel binding MUST be used by the application and/or authentication protocol to avoid ambiguity about which of several possible types of channels is being bound. If nested instances of the same type of channel are available then the innermost channel MUST be used. Now, GS2 *could* have a separate "slot" in the protocol for "channel binding type name" and "channel binding data." The GSS-API, OTOH, does not provide such a slot, so GSS applications MUST prefix the channel binding type name to the channel binding data in order to obtain a single octet string that can be passed to GSS_Init_sec_context() or GSS_Accept_sec_context(). So I think we really don't want to make any changes here. Simon and the SASL WG need to decide whether GS2 needs such a separate slot. The on-channel-bindings I-D is neutral on that issue. Also, GS2 need not say who is responsible for determining the channel binding data and type. You could have a fully integrated channel and authentication API that hides all these details from the application, but you could also have disparate and unrelated channel and authentication APIs, in which case the application is responsible for determining the channel binding data and type. Both are equally acceptable, so on-channel-binding says nothing about them. > 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. I now believe that no such clarification is needed. We may want to clarify that application protocols using channel binding must specify how the prefix is used, and we may want to suggest using it as, well, a prefix (with a separator character), in those cases where a single string is accepted by the authentication framework/mechanism. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Thu Oct 11 12:33:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0ya-0007I7-R1; Thu, 11 Oct 2007 12:33:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0yZ-00070M-45 for channel-binding@ietf.org; Thu, 11 Oct 2007 12:33:31 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig0yT-00050r-5r for channel-binding@ietf.org; Thu, 11 Oct 2007 12:33:26 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9853B4A45; Thu, 11 Oct 2007 12:33:21 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> <87hckz2ado.fsf@mocca.josefsson.org> <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu> <20071011151015.GN24532@Sun.COM> Date: Thu, 11 Oct 2007 12:33:21 -0400 In-Reply-To: <20071011151015.GN24532@Sun.COM> (Nicolas Williams's message of "Thu, 11 Oct 2007 10:10:15 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >> 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. To: Jeffrey Hutzelman Cc: Simon Josefsson , channel-binding@ietf.org, ietf-sasl@imc.org Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071009203406.GL24532@Sun.COM> <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> <87hckz2ado.fsf@mocca.josefsson.org> <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu> <20071011151015.GN24532@Sun.COM> X-Draft-From: ("inbox.ietf.personal" 24575) Nicolas> I now believe that no such clarification is needed. We Nicolas> may want to clarify that application protocols using Nicolas> channel binding must specify how the prefix is used, and Nicolas> we may want to suggest using it as, well, a prefix (with Nicolas> a separator character), in those cases where a single Nicolas> string is accepted by the authentication Nicolas> framework/mechanism. I've become convinced that clarification is needed. I'll note that it's simpler if we say there is always one slot and that the challeng binding data includes the prefix and the separator. I think that option is most likely to be interoperable. One down side of that option is that there may be people using channel bindings with GSS today in a manner that differs from that. It probably is not a big deal since any given application will either use this framework or not. However we could be neutral on whether applications need one slot or two. If so, we need to at least say that we're neutral on this. I think we need to at least define a separator to use when you only have one slot. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Thu Oct 11 13:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Y9-0001VE-Qj; Thu, 11 Oct 2007 13:10:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1Y7-0001U9-G6 for channel-binding@ietf.org; Thu, 11 Oct 2007 13:10:15 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig1Y6-0006hF-Pv for channel-binding@ietf.org; Thu, 11 Oct 2007 13:10:15 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BHAErs005418 for ; Thu, 11 Oct 2007 17:10:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BHADFd008588 for ; Thu, 11 Oct 2007 11:10:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BHADf7027065; Thu, 11 Oct 2007 12:10:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BHACPo027064; Thu, 11 Oct 2007 12:10:13 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 12:10:12 -0500 From: Nicolas Williams To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071011171012.GP24532@Sun.COM> Mail-Followup-To: Sam Hartman , Jeffrey Hutzelman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071009212516.GP24532@Sun.COM> <73A1D8BFF0B322B71283BF6B@sirius.fac.cs.cmu.edu> <20071010143650.GT24532@Sun.COM> <20071010154115.GY24532@Sun.COM> <87hckz2ado.fsf@mocca.josefsson.org> <5A6B5081F6ECBC610E6C2C12@sirius.fac.cs.cmu.edu> <20071011151015.GN24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Thu, Oct 11, 2007 at 12:33:21PM -0400, Sam Hartman wrote: > I've become convinced that clarification is needed. > I'll note that it's simpler if we say there is always one slot and that the > challeng binding data includes the prefix and the separator. Sure. There already is a requirement that the name of the channel binding type must be used to avoid ambiguity (3rd bullet, page 7). I propose the following addition to that requirement: "Where the authentication interfaces provide a slot for channel binding data but no slot for channel binfing type, then the application MUST prefix the US-ASCII name of the channel binding type ("prefix"), and a separator character, ':', to the channel binding data an octet string." > I think that option is most likely to be interoperable. The risk in not giving this guidance is that some apps/frameworks will get this wrong. I'm not sure that there's risk to interoperability, but there's no need to argue about that. > One down side of that option is that there may be people using channel > bindings with GSS today in a manner that differs from that. Tough. But then, there aren't many of them. Also, the ambiguity is extremely unlikely to cause any problems, except in nested channel circumstances. > It probably is not a big deal since any given application will either > use this framework or not. Right. > However we could be neutral on whether applications need one slot or > two. If so, we need to at least say that we're neutral on this. I > think we need to at least define a separator to use when you only have > one slot. That's my position. However, if the consensus is that we should take a less neutral position on this then I would propose this text: o In the interests of simplicity it is RECOMMENDED that authentication framework/mechanism APIs provide a single slot for channel binding data, and none for the name of channel binding type. If we want to stay neutral on this issue we can always add this text: o Authentication framework/mechanism APIs MAY provide a slot for name of channel binding type that is distinct from a slot for channel binding data. In that case applications MUST NOT prefix the name of the channel binding type to the channel binding data and MUST instead provide the name of the channel binding type as an input in the correct slot. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Thu Oct 11 13:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1ps-0002F5-3i; Thu, 11 Oct 2007 13:28:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1pq-0002DD-U0 for channel-binding@ietf.org; Thu, 11 Oct 2007 13:28:34 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ig1pq-0007In-ET for channel-binding@ietf.org; Thu, 11 Oct 2007 13:28:34 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10879; 11 Oct 2007 13:28 EDT Date: Thu, 11 Oct 2007 13:28:07 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: <20071011171012.GP24532@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Thu, 11 Oct 2007, Nicolas Williams wrote: > > However we could be neutral on whether applications need one slot or > > two. If so, we need to at least say that we're neutral on this. I > > think we need to at least define a separator to use when you only have > > one slot. > > That's my position. However, if the consensus is that we should take a > less neutral position on this then I would propose this text: I'm fine with taking a neutral position, just not an unclear one. The problem I see today is that an application protocol designer may assume that the channel bindign data is self-identifying; that is, that the base channel binding document describes a single octet string containing the prefix. But the present document does _not_ describe a single octet string; it describes a prefix and an octet string separately, and does not specify how to combine them, except by calling the one a "prefix", which is just vague enough to convince the casual reader that it's obvious what to do. After all, we didn't notice the problem until Simon tried to define an application, and he's probably more aware of the issue than most. So, I think we need to do one of three things: (1) Require that the prefix and data always be combined in a particular way, resulting in a single octet string for the application to work with(*). (2) Specify a particular way of combining the prefix and data, for use when the application wants or needs to work with a single octet string. Indicate that it is up to the application whether to use this method or treat the prefix and data separately. (3) Clearly indicate that the prefix and data are separate, and that it is up to the application whether to handle them separately or together. Especially in case (3), I think a lot of the ambiguity can be removed by not using the word "prefix", which implies a particular approach to combining what are really two separate protocol elements. This usage seems to be an artifact of how channel bindings are expected to be transported in GSS-API and not really something that belongs in a generic document. > o In the interests of simplicity it is RECOMMENDED that > authentication framework/mechanism APIs provide a single slot for > channel binding data, and none for the name of channel binding > type. > > If we want to stay neutral on this issue we can always add this text: > > o Authentication framework/mechanism APIs MAY provide a slot for name > of channel binding type that is distinct from a slot for channel > binding data. In that case applications MUST NOT prefix the name > of the channel binding type to the channel binding data and MUST > instead provide the name of the channel binding type as an input in > the correct slot. This sort of assumes that the "obvious" thing to do is prfix the name to the data, rather than treating them separately. That sssumption seems flawed to me, and the source of much confusion. -- Jeff _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Thu Oct 11 13:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1tS-0007cB-5y; Thu, 11 Oct 2007 13:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1tQ-0007bA-HE for channel-binding@ietf.org; Thu, 11 Oct 2007 13:32:16 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig1tK-0004Jv-M7 for channel-binding@ietf.org; Thu, 11 Oct 2007 13:32:16 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BHVs8W015793 for ; Thu, 11 Oct 2007 17:31:54 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BHVsEL014666 for ; Thu, 11 Oct 2007 11:31:54 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BHVsn9027087; Thu, 11 Oct 2007 12:31:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BHVrh4027086; Thu, 11 Oct 2007 12:31:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 11 Oct 2007 12:31:53 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071011173152.GR24532@Sun.COM> Mail-Followup-To: Jeffrey Hutzelman , Sam Hartman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071011171012.GP24532@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote: > This sort of assumes that the "obvious" thing to do is prfix the name to > the data, rather than treating them separately. That sssumption seems > flawed to me, and the source of much confusion. Did you miss this part of my reply to Sam: Nico> I propose the following addition to that requirement: "Where the Nico> authentication interfaces provide a slot for channel binding data but no Nico> slot for channel binfing type, then the application MUST prefix the Nico> US-ASCII name of the channel binding type ("prefix"), and a separator Nico> character, ':', to the channel binding data an octet string." ? _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Thu Oct 11 13:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2Co-0005ez-Ly; Thu, 11 Oct 2007 13:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2Cn-0005e1-3y for channel-binding@ietf.org; Thu, 11 Oct 2007 13:52:17 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ig2Cb-00058x-Od for channel-binding@ietf.org; Thu, 11 Oct 2007 13:52:17 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10976; 11 Oct 2007 13:51 EDT Date: Thu, 11 Oct 2007 13:51:23 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: <20071011173152.GR24532@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Thu, 11 Oct 2007, Nicolas Williams wrote: > On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote: > > This sort of assumes that the "obvious" thing to do is prfix the name to > > the data, rather than treating them separately. That sssumption seems > > flawed to me, and the source of much confusion. > > Did you miss this part of my reply to Sam: > > Nico> I propose the following addition to that requirement: "Where the > Nico> authentication interfaces provide a slot for channel binding data but no > Nico> slot for channel binfing type, then the application MUST prefix the > Nico> US-ASCII name of the channel binding type ("prefix"), and a separator > Nico> character, ':', to the channel binding data an octet string." I saw that; I just forgot to say anything. That basically sounds like my option (2). I think that's probably sufficient. Simon? -- Jeff _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Fri Oct 12 06:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHQS-0006Cu-3Q; Fri, 12 Oct 2007 06:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHQQ-0006Cl-7E for channel-binding@ietf.org; Fri, 12 Oct 2007 06:07:22 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgHQJ-0005cQ-Oe for channel-binding@ietf.org; Fri, 12 Oct 2007 06:07:22 -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 l9CA6dhE002000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2007 12:06:39 +0200 From: Simon Josefsson To: Jeffrey Hutzelman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071011173152.GR24532@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071012:hartmans-ietf@mit.edu::1QdMJq718yOg+nf6:2UM9 X-Hashcash: 1:22:071012:jhutz@cmu.edu::hIiITGZ2/zMVBZhB:HVsR X-Hashcash: 1:22:071012:ietf-sasl@imc.org::b1KIyuHzJbQaAU3S:LSFF X-Hashcash: 1:22:071012:channel-binding@ietf.org::9GgcQNLlmSGy/ICI:GISb X-Hashcash: 1:22:071012:nicolas.williams@sun.com::jwZ83TlTy23U2SwO:RHdO Date: Fri, 12 Oct 2007 12:06:38 +0200 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 11 Oct 2007 13:51:23 -0400 (EDT)") Message-ID: <87ir5cy7dd.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: 082a9cbf4d599f360ac7f815372a6a15 Cc: ietf-sasl@imc.org, channel-binding@ietf.org, Sam Hartman , Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Jeffrey Hutzelman writes: > On Thu, 11 Oct 2007, Nicolas Williams wrote: > >> On Thu, Oct 11, 2007 at 01:28:07PM -0400, Jeffrey Hutzelman wrote: >> > This sort of assumes that the "obvious" thing to do is prfix the name to >> > the data, rather than treating them separately. That sssumption seems >> > flawed to me, and the source of much confusion. >> >> Did you miss this part of my reply to Sam: >> >> Nico> I propose the following addition to that requirement: "Where the >> Nico> authentication interfaces provide a slot for channel binding data but no >> Nico> slot for channel binfing type, then the application MUST prefix the >> Nico> US-ASCII name of the channel binding type ("prefix"), and a separator >> Nico> character, ':', to the channel binding data an octet string." > > I saw that; I just forgot to say anything. That basically sounds like my > option (2). I think that's probably sufficient. Simon? It is a starting point, but the proposed text appears to use incorrect terminology. Section 7.1 in on-channel-binding says: o Subject: Registration of channel binding X o Channel binding unique prefix (name): o Channel binding type: (One of "unique" or "end-point") o Channel type: (E.g., TLS, IPsec, SSH, etc...) >From that I infer that: channel binding unique prefix = channel binding name channel binding type = either 'unqiue' or 'end-point' channel type = not an octet string, but a reference to other authentication protocols (e.g., TLS RFC 4346). The proposed text above seem to claim that the channel binding type is the prefix, which seems incorrect. I also wonder whether it doesn't mean 'channel binding unique prefix' rather than 'channel binfing type'. There is also a spurious 'an' at the end. I suggest modified text: Where the authentication interfaces provide a slot for channel binding data but no slot for the channel binding name (i.e., the unique prefix), then the application MUST prefix the US-ASCII name of the channel binding name (i.e., the unique prefix), and a separator character, ':', to the channel binding data octet string. However, I continue to doubt that anyone that did not read mailing list discussions about these fine points will be able to do the right thing when reading the on-channel-bindings document. The terminology definitions we are basing this discussion is in the IANA Considerations! They aren't used earlier in the document. I think they should be in section 2, and used throughout the document. That may be sufficient to make things understandable. /Simon _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Mon Oct 22 19:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6fS-0001s0-Tt; Mon, 22 Oct 2007 19:26:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6fQ-0001hg-AG for channel-binding@ietf.org; Mon, 22 Oct 2007 19:26:41 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik6fL-0004az-US for channel-binding@ietf.org; Mon, 22 Oct 2007 19:26:36 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EDFA64A45; Mon, 22 Oct 2007 19:26:04 -0400 (EDT) From: Sam Hartman To: Simon Josefsson Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071011173152.GR24532@Sun.COM> <87ir5cy7dd.fsf@mocca.josefsson.org> Date: Mon, 22 Oct 2007 19:26:04 -0400 In-Reply-To: <87ir5cy7dd.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 12 Oct 2007 12:06:38 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org I just had a quick phone call with Nico. He's still been thinking about this from the API standpoint. I was asking him why we wanted to support separate slots in the protocol for channel binding type and channel binding data.I didn't understand the complexity. During the conversation it became clear that Nico believed that at the end of the day you want to end up with a channel binding type, a colon and some stuff. I like that too. I don't care how it works in the API at all. I propose we accomplish this by adding the following requirement: "Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII 0x3A). " _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Mon Oct 22 19:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6lG-0003qT-Sb; Mon, 22 Oct 2007 19:32:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik6lF-0003pU-Tn for channel-binding@ietf.org; Mon, 22 Oct 2007 19:32:41 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik6lF-0004sa-Gu for channel-binding@ietf.org; Mon, 22 Oct 2007 19:32:41 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9MNVp1I020473 for ; Mon, 22 Oct 2007 23:31:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9MNVpdj002240 for ; Mon, 22 Oct 2007 17:31:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9MNVo5b006249; Mon, 22 Oct 2007 18:31:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9MNVoev006248; Mon, 22 Oct 2007 18:31:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 22 Oct 2007 18:31:50 -0500 From: Nicolas Williams To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments Message-ID: <20071022233149.GI3722@Sun.COM> Mail-Followup-To: Sam Hartman , Simon Josefsson , Jeffrey Hutzelman , channel-binding@ietf.org, ietf-sasl@imc.org References: <20071011173152.GR24532@Sun.COM> <87ir5cy7dd.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Mon, Oct 22, 2007 at 07:26:04PM -0400, Sam Hartman wrote: > I just had a quick phone call with Nico. > > > He's still been thinking about this from the API standpoint. I was > asking him why we wanted to support separate slots in the protocol for > channel binding type and channel binding data.I didn't understand the > complexity. During the conversation it became clear that Nico > believed that at the end of the day you want to end up with a channel > binding type, a colon and some stuff. I like that too. I don't care > how it works in the API at all. > > > I propose we accomplish this by adding the following requirement: > > "Under this framework, channel bindings MUST start with the channel > binding unique prefix followed by a colon (ASCII 0x3A). > " I second this. Note: Sam's text should be added to either the third bullet item in page 7, or as a separate item below it. NOTE: draft-williams-on-channel-binding is now in AUTH48. Nico -- _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 23 04:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFRP-0008EI-N8; Tue, 23 Oct 2007 04:48:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkFRO-0008DR-7u for channel-binding@ietf.org; Tue, 23 Oct 2007 04:48:46 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkFRH-0004S0-UG for channel-binding@ietf.org; Tue, 23 Oct 2007 04:48:46 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Oct 2007 09:48:38 +0100 Message-ID: <471DB564.5080805@isode.com> Date: Tue, 23 Oct 2007 09:48:36 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071011173152.GR24532@Sun.COM> <87ir5cy7dd.fsf@mocca.josefsson.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Sam Hartman wrote: >I just had a quick phone call with Nico. > > >He's still been thinking about this from the API standpoint. I was >asking him why we wanted to support separate slots in the protocol for >channel binding type and channel binding data.I didn't understand the >complexity. During the conversation it became clear that Nico >believed that at the end of the day you want to end up with a channel >binding type, a colon and some stuff. I like that too. I don't care >how it works in the API at all. > > >I propose we accomplish this by adding the following requirement: > >"Under this framework, channel bindings MUST start with the channel >binding unique prefix followed by a colon (ASCII 0x3A). >" > > I like this. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 23 05:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGGH-0006at-Cs; Tue, 23 Oct 2007 05:41:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkGGG-0006NS-6N for channel-binding@ietf.org; Tue, 23 Oct 2007 05:41:20 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkGFz-0006r7-6L for channel-binding@ietf.org; Tue, 23 Oct 2007 05:41:03 -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 l9N9eWTR026706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 11:40:32 +0200 From: Simon Josefsson To: Sam Hartman Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071011173152.GR24532@Sun.COM> <87ir5cy7dd.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071023:ietf-sasl@imc.org::07p0R2eoZvgSnqcT:E1wx X-Hashcash: 1:22:071023:nicolas.williams@sun.com::R5JsyuZDRvH2wyqK:7hpB X-Hashcash: 1:22:071023:channel-binding@ietf.org::/fF5dXZ5mXjYlqMf:OaH8 X-Hashcash: 1:22:071023:hartmans-ietf@mit.edu::VRLYxm1V2LVgheEA:JPmT X-Hashcash: 1:22:071023:jhutz@cmu.edu::ujYG4IKG6zZlp64o:0AAxt Date: Tue, 23 Oct 2007 11:40:32 +0200 In-Reply-To: (Sam Hartman's message of "Mon, 22 Oct 2007 19:26:04 -0400") Message-ID: <87ve8y2mpb.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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org Sam Hartman writes: > I just had a quick phone call with Nico. > > > He's still been thinking about this from the API standpoint. I was > asking him why we wanted to support separate slots in the protocol for > channel binding type and channel binding data.I didn't understand the > complexity. During the conversation it became clear that Nico > believed that at the end of the day you want to end up with a channel > binding type, a colon and some stuff. I like that too. I don't care > how it works in the API at all. > > > I propose we accomplish this by adding the following requirement: > > "Under this framework, channel bindings MUST start with the channel > binding unique prefix followed by a colon (ASCII 0x3A). > " I like it. Is it specified that the channel binding unique prefix cannot contain ASCII 0x3a? /Simon _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 23 09:17:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJdT-0000Yf-QB; Tue, 23 Oct 2007 09:17:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkJdS-0000Mh-L5 for channel-binding@ietf.org; Tue, 23 Oct 2007 09:17:30 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkJdM-0005sL-Mf for channel-binding@ietf.org; Tue, 23 Oct 2007 09:17:25 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C7CEC4A45; Tue, 23 Oct 2007 09:17:22 -0400 (EDT) From: Sam Hartman To: Simon Josefsson Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments References: <20071011173152.GR24532@Sun.COM> <87ir5cy7dd.fsf@mocca.josefsson.org> <87ve8y2mpb.fsf@mocca.josefsson.org> Date: Tue, 23 Oct 2007 09:17:22 -0400 In-Reply-To: <87ve8y2mpb.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 23 Oct 2007 11:40:32 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: channel-binding@ietf.org, ietf-sasl@imc.org, Nicolas Williams 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >> I just had a quick phone call with Nico. >> >> >> He's still been thinking about this from the API standpoint. I >> was asking him why we wanted to support separate slots in the >> protocol for channel binding type and channel binding data.I >> didn't understand the complexity. During the conversation it >> became clear that Nico believed that at the end of the day you >> want to end up with a channel binding type, a colon and some >> stuff. I like that too. I don't care how it works in the API >> at all. >> >> >> I propose we accomplish this by adding the following >> requirement: >> >> "Under this framework, channel bindings MUST start with the >> channel binding unique prefix followed by a colon (ASCII 0x3A). >> " Simon> I like it. Simon> Is it specified that the channel binding unique prefix Simon> cannot contain ASCII 0x3a? Yes. alphanum plus '.' and '-' _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Tue Oct 23 11:08:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLNK-0008Pi-UP; Tue, 23 Oct 2007 11:08:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkLNG-0008MP-9h for channel-binding@ietf.org; Tue, 23 Oct 2007 11:08:54 -0400 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IkLNG-0002kM-0T for channel-binding@ietf.org; Tue, 23 Oct 2007 11:08:54 -0400 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa27188; 23 Oct 2007 11:08 EDT Date: Tue, 23 Oct 2007 11:08:01 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams Subject: Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments In-Reply-To: <20071022233149.GI3722@Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: channel-binding@ietf.org, Sam Hartman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: channel-binding-bounces@ietf.org On Mon, 22 Oct 2007, Nicolas Williams wrote: > On Mon, Oct 22, 2007 at 07:26:04PM -0400, Sam Hartman wrote: > > I just had a quick phone call with Nico. > > > > > > He's still been thinking about this from the API standpoint. I was > > asking him why we wanted to support separate slots in the protocol for > > channel binding type and channel binding data.I didn't understand the > > complexity. During the conversation it became clear that Nico > > believed that at the end of the day you want to end up with a channel > > binding type, a colon and some stuff. I like that too. I don't care > > how it works in the API at all. > > > > > > I propose we accomplish this by adding the following requirement: > > > > "Under this framework, channel bindings MUST start with the channel > > binding unique prefix followed by a colon (ASCII 0x3A). > > " > > I second this. Note: Sam's text should be added to either the third > bullet item in page 7, or as a separate item below it. Works for me. _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www1.ietf.org/mailman/listinfo/channel-binding