Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)

[Kurt Zeilenga <[e-mail]>]

On May 30, 2009, at 11:12 AM, Nicolas Williams wrote:
> On Sat, May 30, 2009 at 10:09:43AM -0700, Kurt Zeilenga wrote:
>>
>> On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
>>> Perhaps we can have a consensus call made now.  Perhaps we'll only  
>>> be
>>> close, but that may help us figure out how to get there.
>>>
>>> Tom?  Kurt?  What do you think?
>>
>> While I do appreciate your desire to conclude on these issues sooner
>> than later, I am reluctant to attempt to close the poll early
>> especially when consideration of the poll also involves consideration
>> of multiple proposals.  I am also reluctant to offer a statement of
>> where the chairs might think we currently stand during the course of
>> the poll, as this might discourage participants who have yet to speak
>> up from speaking up.
>
> There seems to be consensus on a single proposal, even though the poll
> was about multiple proposals.
>
> Given your deep involvment as a participant in this poll, and the fact
> that this WG has a co-chair who has not been deeply involved with this
> poll, I'd much rather that your co-chair (Tom) make any and all
> decisions that WG chairs can make regarding such polls.  If Tom is not
> available then let's find out when he might be -- that might make a
> reasonable deadline, else we might have a process problem.

It is Tom and my usual practice to work together to form "the chairs  
opinion" of consensus of contentious issues such as this.  I suspect  
we'll do the same in this case.

-- Kurt


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIwtb0068703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:58:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UIwttf068702; Sat, 30 May 2009 11:58:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIwsBk068695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 11:58:55 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UIwnMf084832; Sat, 30 May 2009 18:58:50 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 11:58:49 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 30, 2009, at 11:12 AM, Nicolas Williams wrote:
> On Sat, May 30, 2009 at 10:09:43AM -0700, Kurt Zeilenga wrote:
>>
>> On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
>>> Perhaps we can have a consensus call made now.  Perhaps we'll only  
>>> be
>>> close, but that may help us figure out how to get there.
>>>
>>> Tom?  Kurt?  What do you think?
>>
>> While I do appreciate your desire to conclude on these issues sooner
>> than later, I am reluctant to attempt to close the poll early
>> especially when consideration of the poll also involves consideration
>> of multiple proposals.  I am also reluctant to offer a statement of
>> where the chairs might think we currently stand during the course of
>> the poll, as this might discourage participants who have yet to speak
>> up from speaking up.
>
> There seems to be consensus on a single proposal, even though the poll
> was about multiple proposals.
>
> Given your deep involvment as a participant in this poll, and the fact
> that this WG has a co-chair who has not been deeply involved with this
> poll, I'd much rather that your co-chair (Tom) make any and all
> decisions that WG chairs can make regarding such polls.  If Tom is not
> available then let's find out when he might be -- that might make a
> reasonable deadline, else we might have a process problem.

It is Tom and my usual practice to work together to form "the chairs  
opinion" of consensus of contentious issues such as this.  I suspect  
we'll do the same in this case.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIpYfQ068180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:51:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UIpY7j068179; Sat, 30 May 2009 11:51:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIpSTx068151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 11:51:34 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UIpNWl084718; Sat, 30 May 2009 18:51:23 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 11:51:22 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 30, 2009, at 11:06 AM, Nicolas Williams wrote:
> By the way, I think you've convinced me that your concerns derive from
> the YAP's violation of the channel binding abstraction, and that
> therefore we need to consider the possibility that YAP is harmful.

I'd really like to keep YAP out of this.  As I said before, I do not  
believe any text that we are likely to agree on for SCRAM and GS2 will  
hinder my desire to eventually publish YAP as experimental.  And to go  
beyond that, I don't think the introduce of ANY of the schemes being  
discussed for negotiating channel binding types will hinder me  
pursuing YAP.  The only think I can think of that would hinder YAP and  
similar mechanisms if RFC 4422 were to be revised to place what I  
consider to be undue restrictions on the design of mechanisms.   
However, I would argue (at the appropriate time) against these  
restrictions on the general principles that SASL was intended to allow  
a wide range of mechanisms and we should be careful not to place undue  
restrictions on the design of future mechanisms, using YAP as only an  
example of why I think such restrictions are undue.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIVilq066720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:31:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UIViU5066719; Sat, 30 May 2009 11:31:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIViZt066712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 11:31:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UIVdkb084462; Sat, 30 May 2009 18:31:39 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 11:31:38 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 30, 2009, at 8:49 AM, Jeffrey Hutzelman wrote:
> At the moment, I cannot think of anything that could be accomplished  
> using a multi-level scheme that could not be done using at least one  
> of your M*N mechanism scheme, Nico's M+N independent-negotiation  
> scheme, or my negotiation pseudo-mechanism scheme.  Can you?

Your scheme is interesting in that it could be viewed as a multi-level  
negotiation scheme.  A more interesting question with regard to it  
might be whether the interoperability problems found in in-the- 
mechanism negotiation schemes can be avoided within your scheme.

So long as the client is allowed in the pseudo-mechanism exchange to  
select any mechanism, including possibly ones not advertised as part  
of the pseudo-mechanism exchange or the application-level mechanism  
advertisement, then I think the interoperability problems found in  
multiple-level negotiation schemes can be avoided in this scheme.   
However, if one restricts the choice of mechanism in the pseudo- 
mechanism exchange to only those listed in the pseudo-mechanism, the  
scheme would suffer the interoperability problems we seen with in-the- 
mechanism multi-level negotiation schemes.

But to respond directly to your question, at present, I cannot think  
of anything that cannot be accomplished by multi-level scheme that  
cannot be accomplished by one schemes you listed.  However, certainly  
some listed schemes cannot accomplish everything that could be done in  
a multi-level scheme.  For instance, Nico's scheme doesn't accomplish  
per-mechanism negotiation of channel binding types.  And your scheme  
doesn't accomplish negotiation without introduction of any additional  
round trips, and various other schemes suffer other problems not found  
in an in-the-mechanism negation approach.  But with this noted, I  
might support a proposal which precludes (or significantly hinders) an  
in-the-mechanism negotiation approach.  I have a couple of other  
concerns to think through before I revise my stand (do not take my  
"might support" as a "do support") on the poll and various proposals.

> I agree that we should defer attempting to reach a consensus on a  
> negotiation solution.  I think at some point that means we stop  
> talking about it, because if we don't, aren't we still trying?

>
> That said, I don't think we need to stop talking about it NOW until  
> we finish SCRAM/GS2, as long as we treat it as a mostly-independent  
> discussion and not something that blocks those documents.  I _think_  
> we've mostly been doing that, except for the multi-level issue above.

I think we basically agree here.  It's a matter of objectives of the  
discussions.   At present, I see the primary objective as reaching  
consensus on text of the SCRAM and GS2 I-Ds.  Other issues are  
secondary.  I and others would be ecstatic if in addressing the  
primary objective we also resolved secondary objectives.  So while I  
continue to think it good to defer attempts to reach consensus on a  
negotiation solution, I'm don't object to discussions of solutions so  
long as these discussions do not unduly impede our ability to reach  
consensus on SCRAM and GS2 I-Ds.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIUKft066649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:30:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UIUKlv066648; Sat, 30 May 2009 11:30:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIU8PA066633 for <[e-mail]>; Sat, 30 May 2009 11:30:19 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4UIU8ol020772 for <[e-mail]>; Sat, 30 May 2009 18:30:08 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4UIU81b022658 for <[e-mail]>; Sat, 30 May 2009 12:30:08 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4UICkwS016674; Sat, 30 May 2009 13:12:46 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4UICirV016673; Sat, 30 May 2009 13:12:44 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 30 May 2009 13:12:44 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, May 30, 2009 at 10:09:43AM -0700, Kurt Zeilenga wrote:
> 
> On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
> >Perhaps we can have a consensus call made now.  Perhaps we'll only be
> >close, but that may help us figure out how to get there.
> >
> >Tom?  Kurt?  What do you think?
> 
> While I do appreciate your desire to conclude on these issues sooner  
> than later, I am reluctant to attempt to close the poll early  
> especially when consideration of the poll also involves consideration  
> of multiple proposals.  I am also reluctant to offer a statement of  
> where the chairs might think we currently stand during the course of  
> the poll, as this might discourage participants who have yet to speak  
> up from speaking up.

There seems to be consensus on a single proposal, even though the poll
was about multiple proposals.

Given your deep involvment as a participant in this poll, and the fact
that this WG has a co-chair who has not been deeply involved with this
poll, I'd much rather that your co-chair (Tom) make any and all
decisions that WG chairs can make regarding such polls.  If Tom is not
available then let's find out when he might be -- that might make a
reasonable deadline, else we might have a process problem.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UIO0Y2066373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:24:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UIO0nb066372; Sat, 30 May 2009 11:24:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UINo4n066358 for <[e-mail]>; Sat, 30 May 2009 11:24:00 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4UINoL3029750 for <[e-mail]>; Sat, 30 May 2009 18:23:50 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4UINnpc020745 for <[e-mail]>; Sat, 30 May 2009 12:23:49 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4UI6R7r016668; Sat, 30 May 2009 13:06:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4UI6QJj016667; Sat, 30 May 2009 13:06:26 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 30 May 2009 13:06:26 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Responding slightly out of order.]

On Sat, May 30, 2009 at 09:26:22AM -0700, Kurt Zeilenga wrote:
> Well, while I would agree that your proposal doesn't preclude my  
> approach, I wouldn't say it "only defers the addition ...".  I do  
> think your proposal does place my approach at a slight disadvantage in  
> subsequent engineering discussions.  To illustrate this point,  
> consider whether you would agree to changing SCRAM-*-PLUS to SCRAM-*- 
> TLS-END-POINT now.  I suspect you would object to this, because the  
> negotiation solutions you favor would no need for this.  But likewise,  
> my negotiation approach has no need for SCRAM-*-PLUS.

This is an argument about aesthetics, not a technical argument.

> But as I noted in my comments, I consider this to be quite a minor  
> disadvantage.  While I certainly will consider this impact, I don't  
> think it will be a major deciding factor on what stand I take in the  
> end.

Given what you say I think it'd be quite reasonable to conclude that
you're on the rough side of consensus, as you say.

> On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
> >Kurt has not told us where he stands on our proposal.
> 
> While I have stated a number of concerns, but in general and  
> specifically in response to your proposal, I have yet decided whether  
> I support your proposal.  As I noted in Jeffrey's message, I am  
> currently considering the impacts of your proposal on possible  
> negotiation solutions.  I do plan on making a stand before the poll  
> expires.

By the way, I think you've convinced me that your concerns derive from
the YAP's violation of the channel binding abstraction, and that
therefore we need to consider the possibility that YAP is harmful.

To that end I've been thinking about the possible ways in which weak
mechanisms and weak channel binding types can combine to create weaker
combinations such that one might then want per-mechanism policy w.r.t.
channel binding type.  I've thought up some interesting such mechanisms
and channel binding types (some with Sam's help), but so far the worst
weaknesses of such combinations are easily worked around by, for
example, requiring the use of confidentiality protection in the
underlying channel (somthing which, incidentally, password-based
mechanisms like SCRAM and YAP need anyways to protect against off-line
dictionary attacks).

My tentative conclusion so far is that YAP is more trouble than it's
worth, and that the IESG would do well to consider requesting that the
RFC-Editor not publish any RFC, even experimental, describing mechanisms
like YAP.  But that conclusion does not stem so much from the weaknesses
of YAP+<imagined weak channel binding types> as those seem far from
fatal so far, but from the complexity that YAP adds to discussions of
channel binding type negotiation.

I don't worship at the altar of round-trip reduction so much that I'm
willing to deal with abstraction violations that so complicate other
work, though clearly I'm willing to seek round-trip reductions in
general (see, for example, draft-williams-tls-app-sasl-opt-03).  And
the funny thing is that YAP is particularly intended as a round-trip
optimization on TLS, to provide privacy protection to the client
identity with only one round-trip beyond the TLS handshake (well, TLS +
SASL mech nego, + YAP half-round-trip + the SASL outome of auth
message), but draft-williams-tls-app-sasl-opt-03 would result in
TLS+SASL/SCRAM having the same number of round-trips!  Now,
draft-williams-tls-app-sasl-opt-03, like YAP, does something that one
might consider bad, but the former strikes me as much more acceptable
than the latter.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UHA139062491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 10:10:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UHA1GD062490; Sat, 30 May 2009 10:10:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UH9nik062462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 10:09:59 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UH9iRk082745; Sat, 30 May 2009 17:09:45 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 10:09:43 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
> Perhaps we can have a consensus call made now.  Perhaps we'll only be
> close, but that may help us figure out how to get there.
>
> Tom?  Kurt?  What do you think?

While I do appreciate your desire to conclude on these issues sooner  
than later, I am reluctant to attempt to close the poll early  
especially when consideration of the poll also involves consideration  
of multiple proposals.  I am also reluctant to offer a statement of  
where the chairs might think we currently stand during the course of  
the poll, as this might discourage participants who have yet to speak  
up from speaking up.

I do note (to those who have not yet spoken up) that when determining  
consensus for this poll, silence will be regarded as apathy, not as  
agreement with any particular preference or proposal.

-- Kurt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UGQUe1060359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 09:26:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UGQUF7060358; Sat, 30 May 2009 09:26:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UGQTfC060352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 09:26:29 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UGQMFw081270; Sat, 30 May 2009 16:26:23 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 09:26:22 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 10:29 PM, Nicolas Williams wrote:
> Kurt has not told us where he stands on our proposal.

While I have stated a number of concerns, but in general and  
specifically in response to your proposal, I have yet decided whether  
I support your proposal.  As I noted in Jeffrey's message, I am  
currently considering the impacts of your proposal on possible  
negotiation solutions.  I do plan on making a stand before the poll  
expires.

> Kurt has told us where he stands on the poll: a variant of option 3 is
> his preferred approach.  Specifically Kurt prefers (preferred?) a
> solution where we do channel binding type negotiation now, and we do  
> it
> via SASL mechanism names that incorporate both, an actual mechanism
> name, and the name of a single channel binding type.  That was before
> Jeff and I made our proposal.

I also plan on revising my poll response, primarily in response to  
various proposals (including but not limited to yours).

> Our proposal does not, in fact, preclude Kurt's preferred approach  
> -- it
> only defers the addition of channel binding type negotiation to some
> future time.  Kurt has aknowledged this.

Well, while I would agree that your proposal doesn't preclude my  
approach, I wouldn't say it "only defers the addition ...".  I do  
think your proposal does place my approach at a slight disadvantage in  
subsequent engineering discussions.  To illustrate this point,  
consider whether you would agree to changing SCRAM-*-PLUS to SCRAM-*- 
TLS-END-POINT now.  I suspect you would object to this, because the  
negotiation solutions you favor would no need for this.  But likewise,  
my negotiation approach has no need for SCRAM-*-PLUS.

But as I noted in my comments, I consider this to be quite a minor  
disadvantage.  While I certainly will consider this impact, I don't  
think it will be a major deciding factor on what stand I take in the  
end.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFnius058065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 08:49:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UFni4w058064; Sat, 30 May 2009 08:49:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFnh3G058040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 30 May 2009 08:49:44 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4UFnfsu014511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:49:41 -0400 (EDT)
Date: Sat, 30 May 2009 11:49:41 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Saturday, May 30, 2009 08:06:41 AM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> On May 29, 2009, at 10:46 PM, Jeffrey Hutzelman wrote:
>> Have you missed that part?
>>
>> We're NOT TRYING TO DECIDE HOW NEGOTIATION SHOULD WORK.
>
> Yes, but we are trying to decide what SCRAM I-D says about channel
> bindings.  I have tried to point out that what the SCRAM I-D says about
> channel bindings have an impact upon on possible negotiation solutions,
> and hence feel it reasonable to discuss these impacts.
>
>>
>> Unfortunately, despite the fact that we've shown that a variety of
>> approaches can work with GS2 modified as we've described, including
>> several very different approaches proposed by different people, we
>> keep finding ourselves arguing about which of those proposals is the
>> right one instead of finishing the documents that don't depend on
>> the outcome of that discussion.
>
> I have tried hard not to argue about the suitability of negotiation
> approaches, instead trying to focus on how changes we might make in the
> SCRAM I-D might impact possible solutions.  However, at times it might
> well be appropriate to discuss the suitability of possible solutions in
> order to reach consensus on what changes we make to SCRAM.
>
>> I believe we all understand that multi-level negotiation is a bad
>> idea.
>
> And this is a case in point.  When I raised concerned that the proposal
> seemed to preclude a particular possible solution, I think it quite
> reasonable for you and others to engage me in questions of the
> suitability of such a solution, so that we can determine whether this is
> something we think is "okay" to preclude (or hinder or disadvantage).

OK, so let's talk about that.  I believe that we all think multi-level 
negotiation is a bad idea, and want to avoid it if possible.  So then the 
question becomes, given the current proposed changes to GS2/SCRAM, is there 
some desirable we could achieve via a multi-level negotiation scheme that 
could _not_ be accomplished using one or more of the other schemes?

If no such goal exists, then we should be able to easily reach consensus 
that it is OK to preclude such approaches.

If there is such a goal, then we need to consider whether that goal can be 
achieved by some change to one of the other schemes or by inventing some 
new scheme, and/or whether the goal is so important that it is worth the 
trouble that multi-level negotiation causes _and_ worth the time and effort 
of holding up GS2 and SCRAM to make multi-level negotation possible.


At the moment, I cannot think of anything that could be accomplished using 
a multi-level scheme that could not be done using at least one of your M*N 
mechanism scheme, Nico's M+N independent-negotiation scheme, or my 
negotiation pseudo-mechanism scheme.  Can you?



> I am more making sure we consider now the impacts of what we do now on
> our subsequent work to develop a negotiation solution.  This naturally
> involves some discussion of possible negotiation solutions.  In my
> opinion, we should defer attempting to reach consensus on a negotiation
> solution, however we should continue to discuss possible negotiation
> solutions, especially in the context of how proposed changes to SCRAM and
> GS2 impact possible negotiation solutions.

I think the multi-level issue discussed above is the only one currently 
open that materially affects SCRAM and GS2.  So we certainly should resolve 
that.

I agree that we should defer attempting to reach a consensus on a 
negotiation solution.  I think at some point that means we stop talking 
about it, because if we don't, aren't we still trying?

That said, I don't think we need to stop talking about it NOW until we 
finish SCRAM/GS2, as long as we treat it as a mostly-independent discussion 
and not something that blocks those documents.  I _think_ we've mostly been 
doing that, except for the multi-level issue above.


>> Why in the world would you want to hold up a document because it
>> doesn't allow for doing something that no one wants to do anyway?
>
> I'm trying to understand all the impacts of the proposals for this
> document, so that I can decide whether which of the proposals I might
> support.  I am not trying to hold up the document.  The poll doesn't
> expire until the 7th.  I am sure I will be able to decide before the
> conclusion of the poll as which proposals I support.  It may well that
> I'll end up being in the rough.

So, the poll isn't really proposals so much as a taxonomy of the choices 
that Nico and Alexey could think of.  It really offers a couple of 
questions...

- Should negotiation be (1) added later, (2) added never,
  (3) added now and mandatory, (4) added now and optional
- If there is a need for a default, should it be unique or endpoint or...?

Depending on your interpretation, Alexey's (2) could really be (1c); 
allowing for the possibility of future negotiation but making the default 
be a fallback model.

I think it highly unlikely at this point that the answer to the second 
question will be anything other than "tls-unique".  But it doesn't much 
affect any of the other issues.

I believe we have all agreed that we don't want to preclude the possibility 
of adding negotiation later, if we don't do it now.

I believe there is only one actual proposal on the table, which is to 
modify the definition of GS2 and SCRAM to carry information about which CB 
type was used, if CB is used, and about which CB types the client supports, 
if the client supports CB but believes it has no type in common with the 
server (that's about preventing downgrades; the only decision the server is 
intended to use it for is to fail authentication if the client lists a type 
that the server actually _does_ support).

The point of this proposal is to make irrelevant the question of whether we 
add negotiation now, later, or not at all, and of how the negotiation works 
(an issue the poll deliberately avoided), by agreeing that negotiation must 
happen outside the mechanism (which is not the same as saying it must not 
take the mech into account), and insuring that GS2/SCRAM provides the 
needed protocol slot to carry the results of that negotiation.


BTW, I believe it's very much appropriate to wait until the poll expires 
before doing anything.  However, I don't think that means we can't build a 
consensus before then on exactly what to do to GS2/SCRAM, at which point 
the outcome of the poll mostly determines whether we continue to discuss 
negotiation, and if so, whether we WGLC GS2/SCRAM and then sit on them 
until we have negotiation done, so they can have a mandatory-to-implement 
reference to the negotiation scheme (option (3) would require that).

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFdg88057518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 08:39:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UFdgLa057517; Sat, 30 May 2009 08:39:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFdgN2057511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 08:39:42 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UFddDp079852; Sat, 30 May 2009 15:39:40 GMT (envelope-from [e-mail])
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: SCRAM/GS2 deadline/consquences (Was: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 08:39:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 30, 2009, at 3:17 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
>
>> On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
>>
>>> I would ask chairs to put a deadline for reaching the consensus  
>>> on  channel bindings, somewhere around 1 month, 2 months max.
>>
>> With what consequences if the deadline is not met?
>
> A default action is applied. It is of course up to the chairs to  
> determine what the default should be.
> My personal preference would be to initiate WGLC for SCRAM/GS2 as  
> they would be at the time, instead of just abandoning the documents.


My plans are to try to get SCRAM and GS2 back into WGLC in a matter of  
weeks.

As far as a deadline goes, here what I'm willing to impose at this  
time, and do now impose the following:

If these documents are not in WGLC by IETF#75, the WG should consider  
at IETF#75 possible consequences to be immediately implemented.  Those  
consequences could include (but not limited to) 1) immediately issuing  
the WGLC on the documents with no further changes, 2) issuing a WGLC  
on the documents within days of the meeting, allowing the Editor to  
implement an agreed upon set of changes, 3) abandoning the work.
If for some reason the WG is not able to reach consensus on  
consequences, the chairs will issue a WGLC on the document with any  
further changes immediately after IETF#75.

I ask the WG to defer discussion of possible consequences until  
IETF#75.  The issue is not ripe yet, and would only distract the WG  
from making progress towards the goal of getting these documents into  
WGLC before IETF#75.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFFh5p056549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 08:15:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UFFhZu056548; Sat, 30 May 2009 08:15:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UFFV6L056536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 30 May 2009 08:15:42 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4UFFTIM011923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 11:15:30 -0400 (EDT)
Date: Sat, 30 May 2009 11:15:29 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Saturday, May 30, 2009 06:53:30 AM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> On May 29, 2009, at 10:46 PM, Jeffrey Hutzelman wrote:
>
>>
>> --On Friday, May 29, 2009 07:44:05 PM -0700 Kurt Zeilenga
>> <[e-mail]
>> > wrote:
>>
>>>
>>>
>>> On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
>>>> I would ask chairs to put a deadline for reaching the consensus on
>>>> channel bindings, somewhere around 1 month, 2 months max.
>>>
>>> With what consequences if the deadline is not met?
>>>
>>>> I don't intend to participate in discussions in this document for 6
>>>> more months.
>>>
>>> I don't intend to discuss participate in discussions any longer than
>>> necessary.  While I hope consensus can be reached quickly and am
>>> encouraged by the list discussions, I'm not holding my breath.
>>>
>>> My current goal is to try to close on the channel binding type
>>> negotiation issue within the next 2-3 weeks, and have I-D back in
>>> WGLC by
>>> end of June.
>>
>> That's funny, because I think the rest of us have agreed that, with
>> a small change to SCRAM and GS2, we can conclude those documents
>> _without_ resolving the question of how negotiation should be
>> performed, because we've left the door open for a variety of
>> negotiation techniques to be added later, if/when we reach a
>> consensus that such negotiation is needed and on how it should work.
>>
>> Have you missed that part?
>
> No, I think you just read too much into my statement.
>
> By "channel binding type negotiation issue", I was referring to the
> subject of this poll.  A poll which closes in about a week.  Allowing for
> some time to determination of consensus, and WG discussion of that
> determination, and editor time, I hope to have another I-D in another
> week.  And then last call that.  About 2-3 weeks in today.
>
> By "channel binding type negotiation issue", I don't mean we have to
> reach consensus on a channel binding type solution.  On what the SCRAM-ID
> says about channel binding while considering the impact of what it says
> on possible channeling type solutions.

Ah, OK.  That seems entirely reasonable.  Of course, I'm still optimistic 
that my 24-hour goal can be realized.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UF6m8w055983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 08:06:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UF6mZc055982; Sat, 30 May 2009 08:06:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UF6lwt055976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 08:06:47 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UF6gqt079056; Sat, 30 May 2009 15:06:42 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 08:06:41 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 10:46 PM, Jeffrey Hutzelman wrote:
> Have you missed that part?
>
> We're NOT TRYING TO DECIDE HOW NEGOTIATION SHOULD WORK.

Yes, but we are trying to decide what SCRAM I-D says about channel  
bindings.  I have tried to point out that what the SCRAM I-D says  
about channel bindings have an impact upon on possible negotiation  
solutions, and hence feel it reasonable to discuss these impacts.

>
> Unfortunately, despite the fact that we've shown that a variety of  
> approaches can work with GS2 modified as we've described, including  
> several very different approaches proposed by different people, we  
> keep finding ourselves arguing about which of those proposals is the  
> right one instead of finishing the documents that don't depend on  
> the outcome of that discussion.

I have tried hard not to argue about the suitability of negotiation  
approaches, instead trying to focus on how changes we might make in  
the SCRAM I-D might impact possible solutions.  However, at times it  
might well be appropriate to discuss the suitability of possible  
solutions in order to reach consensus on what changes we make to SCRAM.

> I believe we all understand that multi-level negotiation is a bad  
> idea.

And this is a case in point.  When I raised concerned that the  
proposal seemed to preclude a particular possible solution, I think it  
quite reasonable for you and others to engage me in questions of the  
suitability of such a solution, so that we can determine whether this  
is something we think is "okay" to preclude (or hinder or disadvantage).

> But you seem to be saying that you don't want to move forward with  
> GS2 and SCRAM because in their current form they might preclude an  
> approach involving multi-level negotiation, which we all agree is a  
> bad idea.

I am more making sure we consider now the impacts of what we do now on  
our subsequent work to develop a negotiation solution.  This naturally  
involves some discussion of possible negotiation solutions.  In my  
opinion, we should defer attempting to reach consensus on a  
negotiation solution, however we should continue to discuss possible  
negotiation solutions, especially in the context of how proposed  
changes to SCRAM and GS2 impact possible negotiation solutions.

> Why in the world would you want to hold up a document because it  
> doesn't allow for doing something that no one wants to do anyway?

I'm trying to understand all the impacts of the proposals for this  
document, so that I can decide whether which of the proposals I might  
support.  I am not trying to hold up the document.  The poll doesn't  
expire until the 7th.  I am sure I will be able to decide before the  
conclusion of the poll as which proposals I support.  It may well that  
I'll end up being in the rough.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UDrlBB050750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 06:53:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UDrluR050749; Sat, 30 May 2009 06:53:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UDraSE050730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 30 May 2009 06:53:46 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4UDrUn8077026; Sat, 30 May 2009 13:53:31 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 06:53:30 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 10:46 PM, Jeffrey Hutzelman wrote:

>
> --On Friday, May 29, 2009 07:44:05 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>>
>>
>> On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
>>> I would ask chairs to put a deadline for reaching the consensus on
>>> channel bindings, somewhere around 1 month, 2 months max.
>>
>> With what consequences if the deadline is not met?
>>
>>> I don't intend to participate in discussions in this document for 6
>>> more months.
>>
>> I don't intend to discuss participate in discussions any longer than
>> necessary.  While I hope consensus can be reached quickly and am
>> encouraged by the list discussions, I'm not holding my breath.
>>
>> My current goal is to try to close on the channel binding type
>> negotiation issue within the next 2-3 weeks, and have I-D back in  
>> WGLC by
>> end of June.
>
> That's funny, because I think the rest of us have agreed that, with  
> a small change to SCRAM and GS2, we can conclude those documents  
> _without_ resolving the question of how negotiation should be  
> performed, because we've left the door open for a variety of  
> negotiation techniques to be added later, if/when we reach a  
> consensus that such negotiation is needed and on how it should work.
>
> Have you missed that part?

No, I think you just read too much into my statement.

By "channel binding type negotiation issue", I was referring to the  
subject of this poll.  A poll which closes in about a week.  Allowing  
for some time to determination of consensus, and WG discussion of that  
determination, and editor time, I hope to have another I-D in another  
week.  And then last call that.  About 2-3 weeks in today.

By "channel binding type negotiation issue", I don't mean we have to  
reach consensus on a channel binding type solution.  On what the SCRAM- 
ID says about channel binding while considering the impact of what it  
says on possible channeling type solutions.

-- Kurt, as chair.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UAHkfN036991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 03:17:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4UAHk2v036990; Sat, 30 May 2009 03:17:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4UAHZpi036974 for <[e-mail]>; Sat, 30 May 2009 03:17:45 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.63.51] (92.40.63.51.sub.mbb.three.co.uk [92.40.63.51])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 30 May 2009 11:17:33 +0100
Message-ID: <[e-mail]>
Date: Sat, 30 May 2009 11:17:01 +0100
From: Alexey Melnikov <[e-mail]>
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: Kurt Zeilenga <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
>
>> I would ask chairs to put a deadline for reaching the consensus on  
>> channel bindings, somewhere around 1 month, 2 months max.
>
> With what consequences if the deadline is not met?

A default action is applied. It is of course up to the chairs to 
determine what the default should be.
My personal preference would be to initiate WGLC for SCRAM/GS2 as they 
would be at the time, instead of just abandoning the documents.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5l8Wl023362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 22:47:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U5l8cA023361; Fri, 29 May 2009 22:47:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5kve1023354 for <[e-mail]>; Fri, 29 May 2009 22:47:08 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4U5kvOK007724 for <[e-mail]>; Sat, 30 May 2009 05:46:57 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4U5kvSD047869 for <[e-mail]>; Fri, 29 May 2009 23:46:57 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4U5Taws016134; Sat, 30 May 2009 00:29:36 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4U5TaG5016133; Sat, 30 May 2009 00:29:36 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 30 May 2009 00:29:36 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt has not told us where he stands on our proposal.

Kurt has told us where he stands on the poll: a variant of option 3 is
his preferred approach.  Specifically Kurt prefers (preferred?) a
solution where we do channel binding type negotiation now, and we do it
via SASL mechanism names that incorporate both, an actual mechanism
name, and the name of a single channel binding type.  That was before
Jeff and I made our proposal.

Our proposal does not, in fact, preclude Kurt's preferred approach -- it
only defers the addition of channel binding type negotiation to some
future time.  Kurt has aknowledged this.

Therefore I wonder where we actually stand on this poll at this time?

I count at least three, probably five participants (including Sam) in
favor of the proposal that Jeff and I made, and which Simon helped us
refine.  I don't know where Kurt stands -- his comments w.r.t.
in-mechanism negotiation have me confused as to his actual position.
Other participants have not been heard from in a while.

Perhaps we can have a consensus call made now.  Perhaps we'll only be
close, but that may help us figure out how to get there.

Tom?  Kurt?  What do you think?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5kf6o023349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 22:46:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U5kfZG023348; Fri, 29 May 2009 22:46:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5kTdW023340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 22:46:40 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4U5kP9n024624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 May 2009 01:46:28 -0400 (EDT)
Date: Sat, 30 May 2009 01:46:25 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 07:44:05 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
>
> On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
>> I would ask chairs to put a deadline for reaching the consensus on
>> channel bindings, somewhere around 1 month, 2 months max.
>
> With what consequences if the deadline is not met?
>
>> I don't intend to participate in discussions in this document for 6
>> more months.
>
> I don't intend to discuss participate in discussions any longer than
> necessary.  While I hope consensus can be reached quickly and am
> encouraged by the list discussions, I'm not holding my breath.
>
> My current goal is to try to close on the channel binding type
> negotiation issue within the next 2-3 weeks, and have I-D back in WGLC by
> end of June.

That's funny, because I think the rest of us have agreed that, with a small 
change to SCRAM and GS2, we can conclude those documents _without_ 
resolving the question of how negotiation should be performed, because 
we've left the door open for a variety of negotiation techniques to be 
added later, if/when we reach a consensus that such negotiation is needed 
and on how it should work.

Have you missed that part?

We're NOT TRYING TO DECIDE HOW NEGOTIATION SHOULD WORK.

In fact, the rest of us would really like to stop talking about that 
alogether, until we can get SCRAM and GS2 finished.

Unfortunately, despite the fact that we've shown that a variety of 
approaches can work with GS2 modified as we've described, including several 
very different approaches proposed by different people, we keep finding 
ourselves arguing about which of those proposals is the right one instead 
of finishing the documents that don't depend on the outcome of that 
discussion.


I believe we all understand that multi-level negotiation is a bad idea.
But you seem to be saying that you don't want to move forward with GS2 and 
SCRAM because in their current form they might preclude an approach 
involving multi-level negotiation, which we all agree is a bad idea.  Why 
in the world would you want to hold up a document because it doesn't allow 
for doing something that no one wants to do anyway?

The only explanation I've seen from you on this seems to be of the form 
"well, while there are several neogtiation models to choose from, the one I 
prefer might not win, and if that happens, then I want to be free to 
propose something _NO ONE_ wants to do and which is a horribly bad idea, 
rather than accept that I am in the rough and live with a model that 
doesn't have all of the properties I want".  I think that's ludicrous -- 
we've shown that it's possible to have a negotiation model with the 
properties you want; in fact, I believe we've shown two such models.  If we 
decide we don't want that, it'll be because we don't want that, not because 
we want to go off and do something everyone agrees is even worse.

Oh, and just in case you've forgotten...
The negotiation model I described involves inventing a single new 
pseudo-mechanism which, when selected, allows the server to provide a 
complete list of {mechanism,channel-binding} combinations it is willing to 
support.  The client then selects a combination and informs the server of 
which mechanism it has chosen, and then procedes to exchange the tokens of 
the new mechanism as if the negotiation-pseudo-mechanism had never been 
there.  This allows you to have full control over the permitted 
combinations, allows Nico and I to avoid N*M registrations, and even 
resolves the name-length problems, since the information advertised via the 
pseudo-mechanism is just part of that mechanism's token as far as the SASL 
application protocol is concerned.  The expense is mostly an extra round 
trip.

I don't want to argue the merits of this idea right now.  I just want to 
point out that it's an example of something that gives you the control you 
want _and_ it's an example of something that works with GS2 as we've 
proposed modifying it.



_MY_ goal is to try and close on the present discussion within the next 24 
hours, and _without_ choosing a negotation mechanism, because we don't have 
to do that to get the document done.  Once that's done, I'll try to review 
the GS2 and SCRAM documents over the next week, and certainly by the end of 
their respective WGLC.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5JmCm022381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 22:19:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U5JlfI022380; Fri, 29 May 2009 22:19:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U5Ja0x022362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 May 2009 22:19:46 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4U5JVDp024232 for <[e-mail]>; Sat, 30 May 2009 05:19:36 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4U5JVfl037479 for <[e-mail]>; Fri, 29 May 2009 23:19:31 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4U526C8016120; Sat, 30 May 2009 00:02:10 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4U51v6B016119; Sat, 30 May 2009 00:01:57 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Sat, 30 May 2009 00:01:57 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 06:56:04PM -0700, Kurt Zeilenga wrote:
> 
> On May 29, 2009, at 5:22 PM, Nicolas Williams wrote:
> >I believe that making GS2 support in-mechanism negotiation of channel
> >binding type now or in the future would require _significant_  
> >surgery on
> >GS2.
> 
> So your proposal does preclude one possible negotiation approach that  
> could be used in SCRAM and GS2.

I never claimed that there were no schemes that were not precluded.
We've shown that three future channel binding negotiation schemes, one
of them your personal favorite, are not precluded by our proposal.  We
can't and should not seek to make all possible schemes remain feasible
-- I shouldn't have to point out how silly it would be to try.

Also, to be perfectly fair: I misspoke.  It is not the case that our
proposal precludes GS2/SCRAM having in-mechanism CB type negotiation!
It's GS2's design itself.

> >It's too late to be doing major changes to GS2.  Moreover, where
> 
> >is the justification for requiring that GS2 support such a thing?  If
> >you believe that GS2 should support that, then please explain why, and
> >then let's have a poll on that.
> 
> 
> You asserted:
>   Notice too that we are left in a position where we can actually add  
> channel binding type negotiation later.

And that was and remains true.  Why are you trying to play gotcha?  What
purpose does it serve?

> My assertion is that while certainly we might be able to to add  
> channel binding type negotiation, the particulars of the SCRAM and GS2  
> specifications will have a significant impact on the engineering of  
> solutions.   Hence, I believe it appropriate to discuss the impact  
> upon possible solutions during the consideration of the particulars of  
> the SCRAM and GS2 specification.

Nonsense.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U2i9Pw016088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 19:44:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U2i9db016087; Fri, 29 May 2009 19:44:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U2i8rj016081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 19:44:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4U2i5kj052742; Sat, 30 May 2009 02:44:06 GMT (envelope-from [e-mail])
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 19:44:05 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 2:36 AM, Alexey Melnikov wrote:
> I would ask chairs to put a deadline for reaching the consensus on  
> channel bindings, somewhere around 1 month, 2 months max.

With what consequences if the deadline is not met?

> I don't intend to participate in discussions in this document for 6  
> more months.

I don't intend to discuss participate in discussions any longer than  
necessary.  While I hope consensus can be reached quickly and am  
encouraged by the list discussions, I'm not holding my breath.

My current goal is to try to close on the channel binding type  
negotiation issue within the next 2-3 weeks, and have I-D back in WGLC  
by end of June.

> If that happens, you will have my resignation as the editor of the  
> document.


Individuals are of course free to set individual deadlines with  
individual consequences (some of which obviously might have an impact  
on the WG), and if they so desire, announce them to the WG.

-- Kurt, as co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U2SnLo015540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 19:28:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U2SmRU015539; Fri, 29 May 2009 19:28:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U2SlhT015533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 19:28:48 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4U2SheZ052335; Sat, 30 May 2009 02:28:43 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 19:28:42 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 3:02 PM, Jeffrey Hutzelman wrote:

> So, you'd rather pick YAP and then discover that only tls-unique is  
> supported but you can't use a unique binding for your TLS session  
> (and thus authentication fails) than be able to detect this  
> situation in advannce and fall back to SCRAM?

I see this situation to be the same as that caused by your proposal.

If a server administrator desires to offer tls-unique with SCRAM but  
not tls-x-unique, yet the server desires to offer tls-x-unique for  
some other mechanism, your approach has the server advertising both  
tls-unique and tls-x-unique.  The client hence might choose to use tls- 
x-unique with SCRAM, only to have a failure.  Obviously, your proposal  
was not designed to accommodate this situation.

I argue that not only should mechanism designers consider the  
applicability of each channel binding type with the mechanism,  
application protocol developers need to consider the applicability of  
each mechanism/channel bind type combination when implementing (as  
mechanisms are specified in a application-neutral manner and channel  
binding types are specified (typically) in a mechanism specific  
manner, the developer cannot assume the application protocol,  
mechanism and channel binding type designers have not considered all  
of the issues the developer needs to consider).  And deployers will  
consider the applicability of a mechanism/channel binding type to each  
application protocol system they deploy.  Just as we've seen deployers  
demand methods, especially server side methods, for restricting which  
mechanisms are used in application protocol deployments, I believe  
we'll see deployers demand methods for restricting use of channeling  
binding types on a per mechanism basis.

Hence, when I consider your proposal with a in-the-mechanism exchange  
approach, I conclude they will fail in similar ways in face of  
administrative-set/implementor-set per-mechanism channel binding  
restrictions.  When I consider other aspects of these solutions, I  
find that that in-the-mechanism sucks less.

I continue to think negotiating channel binding type using the  
mechanism name, as we do for hash algorithms, as we done for channel  
binding on/off, is the best approach.

Simon said:
> I believe there is some point in having
> a manual process to register each and every SCRAM-IPSEC-FOO,
> SCRAM-TLS-BAR combination: it makes us have to think about the  
> security
> properties of each particular combination of mechanism with channel
> binding.


+1.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U1uAW5013890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 18:56:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U1uAI7013889; Fri, 29 May 2009 18:56:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U1u9k0013883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 18:56:09 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4U1u4WC051663; Sat, 30 May 2009 01:56:05 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 18:56:04 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 5:22 PM, Nicolas Williams wrote:
> I believe that making GS2 support in-mechanism negotiation of channel
> binding type now or in the future would require _significant_  
> surgery on
> GS2.

So your proposal does preclude one possible negotiation approach that  
could be used in SCRAM and GS2.

> It's too late to be doing major changes to GS2.  Moreover, where

> is the justification for requiring that GS2 support such a thing?  If
> you believe that GS2 should support that, then please explain why, and
> then let's have a poll on that.


You asserted:
   Notice too that we are left in a position where we can actually add  
channel binding type negotiation later.

My assertion is that while certainly we might be able to to add  
channel binding type negotiation, the particulars of the SCRAM and GS2  
specifications will have a significant impact on the engineering of  
solutions.   Hence, I believe it appropriate to discuss the impact  
upon possible solutions during the consideration of the particulars of  
the SCRAM and GS2 specification.

I will discuss the suitability of in-the-mechanism exchange in the  
response to another list message.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0eW7J009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:40:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U0eWq5009873; Fri, 29 May 2009 17:40:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0eLDA009867 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 May 2009 17:40:32 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4U0eL9k023549 for <[e-mail]>; Sat, 30 May 2009 00:40:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4U0eKDE054943 for <[e-mail]>; Fri, 29 May 2009 18:40:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4U0MxUl015916; Fri, 29 May 2009 19:22:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4U0MxkC015915; Fri, 29 May 2009 19:22:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 19:22:58 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 05:18:49PM -0700, Kurt Zeilenga wrote:
> On May 29, 2009, at 3:05 PM, Nicolas Williams wrote:
> >That's not quite my interpretation of what Kurt wants.  Kurt is not
> >being terribly clear.
> 
> I am trying my best to offer clarification.
> 
> >His primary goal is clearly to allow for YAP and
> >its dependence on unique channel binding types.
> 
> If it wasn't for you and others occasionally bringing up YAP in the  
> context of SCRAM and GS2 discussions, I doubt I would see much (if  
> any) need to comment on it.  At present, I don't see anything in  
> recent discussions (aside from suggested changes to RFC 4422) that  
> would preclude publication of YAP (as it now specified, or how I might  
> revise the I-D).  [If someone does see something that would interfere  
> with the publication of YAP (as now specified, or how they think I  
> might revise the I-D), I hope they would bring this to my attention  
> (off-list please).]

OK, good, we're done with that.

> While certainly I have, do, and will oppose any change to RFC 4422  
> which unduly restrict the design of mechanisms, my concerns apply  
> generally.  I have and will use YAP as well as existing mechanisms as  
> examples of how such changes might unduly restrict the design of  
> particular mechanisms in hopes that folks might see how changes might  
> impact future mechanisms.
> 
> I've tried to focus on negotiation solutions suitable for SCRAM and  
> GS2, while considering the possible optional reuse of the solution in  
> future mechanisms.  What I like is a solution for SCRAM which could be  
> reused by other mechanisms.

I believe nothing in our proposal precludes in-mechanism negotiation of
channel binding type for any mechanisms that are NOT GS2 mechanisms
(remember, SCRAM is a GS2 mechanism).

I believe that making GS2 support in-mechanism negotiation of channel
binding type now or in the future would require _significant_ surgery on
GS2.  It's too late to be doing major changes to GS2.  Moreover, where
is the justification for requiring that GS2 support such a thing?  If
you believe that GS2 should support that, then please explain why, and
then let's have a poll on that.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0OJHq009327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:24:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U0OJ1n009326; Fri, 29 May 2009 17:24:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0OJBO009319 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 May 2009 17:24:19 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4U0OIqp010091 for <[e-mail]>; Sat, 30 May 2009 00:24:18 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4U0OIwe046968 for <[e-mail]>; Fri, 29 May 2009 18:24:18 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4U0EQeN015896; Fri, 29 May 2009 19:14:26 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4U0ENHS015895; Fri, 29 May 2009 19:14:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 19:14:23 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 05:00:31PM -0700, Kurt Zeilenga wrote:
> From my initial review of your proposal:
> 
> 1) Jeffrey's message  
> <[e-mail]>) suggests your  
> proposal does preclude in-the-mechanism negotiation.  However, I  
> wonder if the SCRAM extension mechanism could be used to provide  
> such.  Your assessment of the possibility to subsequently extend SCRAM  
> and GS2 to support in-the-the mechanism exchange negotiation would be  
> of interest to me.  I think debate over the suitability of such  
> negotiation could be deferred.

It does not preclude in-the-mechanism negotiation, but SCRAM and GS2
will never do that.

You're still not addressing the issue that I believe you must address.
I believe that your primary goal here is to make YAP feasible, so I'm
going to ask point blank:

1) Am I correct to believe that your one requirement is that we do not
   preclude YAP?

   If so, please stop distracting us with in-the-mechanism negotiation
   and what not and instead answer the next question.  If not then
   please state your requirements clearly, then we can have a separate
   poll on the question of whether we should meet those.

   (I think we're not so opposed to YAP that we'd want to preclude it,
   thus we probably don't need a poll on the question of whether we
   should avoid precluding YAP.)

2) Does our proposal preclude YAP?

> 2) it appears to hinder the subsequent adoption of the negotiation  
> solution as it uses SCRAM mechanism names to select whether channel  
> binding is to be used or not instead of for channeling binding is to  
> be used, and if which, or not.  That is, it registers a -PLUS  
> mechanism.  My solution has no use or need for a -PLUS mechanism, but  
> I'd be forced to deal with the existence of the -PLUS mechanism and  
> hence placing the subsequent adoption of my solution at disadvantage  
> albeit quite a minor one.

Our proposal does fit your N*M scheme: The -PLUS mechanism names
correspond to the -TLS-UNIQUE mechanism names in your scheme.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0Iums008839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:19:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U0Iu2a008838; Fri, 29 May 2009 17:18:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U0ItB4008832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 17:18:56 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4U0Ini2049918; Sat, 30 May 2009 00:18:49 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 17:18:49 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 3:05 PM, Nicolas Williams wrote:

>
> On Fri, May 29, 2009 at 06:02:39PM -0400, Jeffrey Hutzelman wrote:
>> --On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga
>> <[e-mail]> wrote:
>>> I am a bit concerned that that current proposal might preclude  
>>> certain
>>> negotiation strategies from consideration as they would be  
>>> difficult to
>>> retrofit in.   In particular, I am concerned that the current  
>>> proposal
>>> might preclude purely in-the-mechanism-exchange negotiation of  
>>> channel
>>> binding types.
>>
>> You mean, a strategy in which each mechanism is responsible for  
>> managing
>> negotiation of channel binding types, and we don't get to do that
>> negotiation until after we've selected a mechanism?
>
> That's not quite my interpretation of what Kurt wants.  Kurt is not
> being terribly clear.

I am trying my best to offer clarification.

> His primary goal is clearly to allow for YAP and
> its dependence on unique channel binding types.

If it wasn't for you and others occasionally bringing up YAP in the  
context of SCRAM and GS2 discussions, I doubt I would see much (if  
any) need to comment on it.  At present, I don't see anything in  
recent discussions (aside from suggested changes to RFC 4422) that  
would preclude publication of YAP (as it now specified, or how I might  
revise the I-D).  [If someone does see something that would interfere  
with the publication of YAP (as now specified, or how they think I  
might revise the I-D), I hope they would bring this to my attention  
(off-list please).]

While certainly I have, do, and will oppose any change to RFC 4422  
which unduly restrict the design of mechanisms, my concerns apply  
generally.  I have and will use YAP as well as existing mechanisms as  
examples of how such changes might unduly restrict the design of  
particular mechanisms in hopes that folks might see how changes might  
impact future mechanisms.

I've tried to focus on negotiation solutions suitable for SCRAM and  
GS2, while considering the possible optional reuse of the solution in  
future mechanisms.  What I like is a solution for SCRAM which could be  
reused by other mechanisms.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U00jgd007582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:00:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4U00jOG007581; Fri, 29 May 2009 17:00:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4U00YsV007568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 17:00:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4U00VP9049467; Sat, 30 May 2009 00:00:32 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 17:00:31 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 3:20 PM, Nicolas Williams wrote:

>>>
>>> If you don't agree with this approach to reaching consensus, please
>>> say so.
>>
>> I am fine with this approach so long as what we do and say now  
>> doesn't
>> preclude, hinder, or disadvantage any of the obvious and/or suggested
>> (though possibly not broadly supported) negotiation solutions from
>> being subsequent chosen as the solution.
>
> You must review the proposal and tell us whether it meets your  
> requirement

 From my initial review of your proposal:

1) Jeffrey's message  
<[e-mail]>) suggests your  
proposal does preclude in-the-mechanism negotiation.  However, I  
wonder if the SCRAM extension mechanism could be used to provide  
such.  Your assessment of the possibility to subsequently extend SCRAM  
and GS2 to support in-the-the mechanism exchange negotiation would be  
of interest to me.  I think debate over the suitability of such  
negotiation could be deferred.

2) it appears to hinder the subsequent adoption of the negotiation  
solution as it uses SCRAM mechanism names to select whether channel  
binding is to be used or not instead of for channeling binding is to  
be used, and if which, or not.  That is, it registers a -PLUS  
mechanism.  My solution has no use or need for a -PLUS mechanism, but  
I'd be forced to deal with the existence of the -PLUS mechanism and  
hence placing the subsequent adoption of my solution at disadvantage  
albeit quite a minor one.

-- Kurt





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMUsXa002339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:30:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TMUsG1002338; Fri, 29 May 2009 15:30:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMUhUt002330 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 May 2009 15:30:53 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4TMUgmr021076 for <[e-mail]>; Fri, 29 May 2009 22:30:43 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TMUguB002169 for <[e-mail]>; Fri, 29 May 2009 16:30:42 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TMKp5B015706; Fri, 29 May 2009 17:20:51 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TMKpLo015705; Fri, 29 May 2009 17:20:51 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 17:20:51 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 03:08:13PM -0700, Kurt Zeilenga wrote:
> 
> On May 29, 2009, at 1:47 PM, Nicolas Williams wrote:
> 
> >
> >On Fri, May 29, 2009 at 01:02:53PM -0700, Kurt Zeilenga wrote:
> >>What I don't find acceptable is any assumption that applicability of
> >>any particular channel binding type is the same for all mechanisms
> >>used within a particular application layer protocol.  Hence, I want
> >>negotiation which allows the server to say which channel binding  
> >>types
> >>it willing to support on a per mechanism basis.
> >
> >My M+N negotiation scheme does NOT make "any assumption that
> >applicability of any particular channel binding type is the same for  
> >all
> >mechanisms..."
> 
> I guess I should clarify, what I want is the ability for implementors  
> and deployers to choose which binding types they support on a per  
> mechanism basis.

Our proposal does not preclude that for mechanisms other than SCRAM
(since it doesn't need that ability) or other than GS2 (since GSS-API
mechanisms shouldn't be like YAP).

And for SCRAM/GS2 it will allow what you want *when* we add channel
binding type negotiation, but that negotiation will have to be done
outside SCRAM/GS2 (as in, for example, your N*M proposal).

My N+M scheme has the same feature.  BUT AGAIN, we don't need to discuss
it!

> >If you don't agree with this approach to reaching consensus, please
> >say so.
> 
> I am fine with this approach so long as what we do and say now doesn't  
> preclude, hinder, or disadvantage any of the obvious and/or suggested  
> (though possibly not broadly supported) negotiation solutions from  
> being subsequent chosen as the solution.

You must do better than that.  You must review the proposal and tell us
whether it meets your requirement, NOT keep sending e-mails arguing
other things that we're all trying to avoid, and which wastes enormous
amounts of my and others' time.  Respect my time, review the proposal.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMNeOH001882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:23:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TMNeAt001881; Fri, 29 May 2009 15:23:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMNdkA001875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 15:23:40 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4TMNZAg047258; Fri, 29 May 2009 22:23:35 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 15:23:34 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 3:02 PM, Jeffrey Hutzelman wrote:

> Multi-level negotiation is a bad idea.

I agree it's bad.  But I think that assuming that channel-binding-type  
acceptable for one mechanism implies that it's acceptable for another  
mechanism for each of parties (server implementor/deployer, client  
implementor/deployer, protocol designer, etc.) which might care to  
make decision of acceptability is even worse.

My solution attempts to address both of these concerns.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMNDlD001856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:23:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TMNDrw001855; Fri, 29 May 2009 15:23:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMN3OU001848 for <[e-mail]>; Fri, 29 May 2009 15:23:13 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4TMN3Vd009425 for <[e-mail]>; Fri, 29 May 2009 22:23:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TMN2H9063453 for <[e-mail]>; Fri, 29 May 2009 16:23:03 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TM5f4f015698; Fri, 29 May 2009 17:05:41 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TM5e2t015697; Fri, 29 May 2009 17:05:40 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 17:05:40 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 06:02:39PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga 
> <[e-mail]> wrote:
> >I am a bit concerned that that current proposal might preclude certain
> >negotiation strategies from consideration as they would be difficult to
> >retrofit in.   In particular, I am concerned that the current proposal
> >might preclude purely in-the-mechanism-exchange negotiation of channel
> >binding types.
> 
> You mean, a strategy in which each mechanism is responsible for managing 
> negotiation of channel binding types, and we don't get to do that 
> negotiation until after we've selected a mechanism?

That's not quite my interpretation of what Kurt wants.  Kurt is not
being terribly clear.  His primary goal is clearly to allow for YAP and
its dependence on unique channel binding types.

> It does preclude it for GS2/SCRAM, short of modifying the mechanism, but I 

No, it doesn't -- I think you misinterpreted Kurt's comment.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMMuhu001846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:22:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TMMuv7001845; Fri, 29 May 2009 15:22:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMMsps001839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 15:22:55 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TMMn1U007140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 18:22:51 -0400 (EDT)
Date: Fri, 29 May 2009 18:22:49 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>
cc: Kurt Zeilenga <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 05:05:40 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

> On Fri, May 29, 2009 at 06:02:39PM -0400, Jeffrey Hutzelman wrote:
>> --On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga
>> <[e-mail]> wrote:
>> > I am a bit concerned that that current proposal might preclude certain
>> > negotiation strategies from consideration as they would be difficult to
>> > retrofit in.   In particular, I am concerned that the current proposal
>> > might preclude purely in-the-mechanism-exchange negotiation of channel
>> > binding types.
>>
>> You mean, a strategy in which each mechanism is responsible for managing
>> negotiation of channel binding types, and we don't get to do that
>> negotiation until after we've selected a mechanism?
>
> That's not quite my interpretation of what Kurt wants.  Kurt is not
> being terribly clear.  His primary goal is clearly to allow for YAP and
> its dependence on unique channel binding types.
>
>> It does preclude it for GS2/SCRAM, short of modifying the mechanism, but
>> I
>
> No, it doesn't -- I think you misinterpreted Kurt's comment.

It precludes a multi-level model in which on-the-wire negotiation of 
channel binding types is done within the mechanism's protocol elements, and 
the client does not find out what channel binding types the server is 
willing to support until the client has already committed to a mechanism.

It does not preclude a model in which the set of supported channel binding 
types depends on which mechanism is used, or alternately in which the set 
of mechanisms available depends on which channel binding type is to be 
used, provided that such information is made available before the client 
commits to a GS2 mechanism.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMERMe001410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:14:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TMERqp001409; Fri, 29 May 2009 15:14:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TMEQcT001403 for <[e-mail]>; Fri, 29 May 2009 15:14:27 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4TMEQeC024899 for <[e-mail]>; Fri, 29 May 2009 22:14:26 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TMEQoo057304 for <[e-mail]>; Fri, 29 May 2009 16:14:26 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TLv47Y015687; Fri, 29 May 2009 16:57:04 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TLv4Om015686; Fri, 29 May 2009 16:57:04 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 16:57:04 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 02:47:39PM -0700, Kurt Zeilenga wrote:
> I am a bit concerned that that current proposal might preclude certain  
> negotiation strategies from consideration as they would be difficult  
> to retrofit in.   In particular, I am concerned that the current  
> proposal might preclude purely in-the-mechanism-exchange negotiation  
> of channel binding types.

Can you elaborate on how our approach might do that?  I don't see it,
but perhaps I'm biased.

> I would like SCRAM and GS2 not to preclude a particular negotiation  
> model, including per-mechanism negotiation approaches such as what I  
> propose and/or in-the-mechanism negotiation.

The current proposal is designed precisely to make all three of the cb
type negotiation schemes proposed thus far feasible:

 - your and Simon's N*M proposals
 - Jeff's pseudo-mechanism to negotiate cb type
 - my N+M proposal

I don't see how our proposal precludes any one of them.

(I also don't see how my N+M proposal makes it difficult or impossible
to have mechanisms like YAP.  I've posted an algorithm that shows how it
does, in fact, allow for YAP.  But I don't want to get into that
discussion.  I want to stop at: does our concrete proposal allow or
preclude any of the proposed, future cb type negotiation schemes?  I
believe the answer is that it allows all of them and precludes none.)

> So long as SCRAM and GW are adequately extensible, this shouldn't be a  
> problem.

That's the point of our proposal.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TM8IC5001029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:08:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TM8IBo001028; Fri, 29 May 2009 15:08:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TM8Gga001022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 15:08:18 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4TM8D4K046870; Fri, 29 May 2009 22:08:14 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 15:08:13 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 1:47 PM, Nicolas Williams wrote:

>
> On Fri, May 29, 2009 at 01:02:53PM -0700, Kurt Zeilenga wrote:
>> What I don't find acceptable is any assumption that applicability of
>> any particular channel binding type is the same for all mechanisms
>> used within a particular application layer protocol.  Hence, I want
>> negotiation which allows the server to say which channel binding  
>> types
>> it willing to support on a per mechanism basis.
>
> My M+N negotiation scheme does NOT make "any assumption that
> applicability of any particular channel binding type is the same for  
> all
> mechanisms..."

I guess I should clarify, what I want is the ability for implementors  
and deployers to choose which binding types they support on a per  
mechanism basis.

> It does, however, require local knowledge of the applicability of any
> server-advertised, client-supported channel binding type to any  
> server-
> advertised, client-supported SASL mechanism.  And it requires applying
> that knowledge via a simple (but by no means trivial) algorithm.

The problem I see is that what the server developer/implementor thinks  
is applicable may be quite different from what the client developer/ 
implementor thinks is applicable.


> BUT, the point of Jeff's and my proposal is this: we don't need to  
> argue
> about the merits of M*M, M+N, or a pseudo-mechanism to negotiate cb
> types -- we can stop at making it possible to add a secure cb type
> negotiation later.
>
> By deferring discussion of a feature where we don't have consensus
> (multiple proposals, each with their set of problems, and their
> champions) to when we ever end up needing it, we make it easier to  
> reach
> consensus _now_ on the minimum that we need to get SCRAM/GS2 out the
> door.
>
> If you don't agree with this approach to reaching consensus, please  
> say
> so.


I am fine with this approach so long as what we do and say now doesn't  
preclude, hinder, or disadvantage any of the obvious and/or suggested  
(though possibly not broadly supported) negotiation solutions from  
being subsequent chosen as the solution.

I'll comment on this later.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TM2jRC000758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 15:02:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TM2jk2000749; Fri, 29 May 2009 15:02:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TM2hbc000743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 15:02:44 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TM2dTP006826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 18:02:41 -0400 (EDT)
Date: Fri, 29 May 2009 18:02:39 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> On May 29, 2009, at 1:49 PM, Jeffrey Hutzelman wrote:
>
>>
>> --On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga
>> <[e-mail]
>> > wrote:
>>
>>> What I don't find acceptable is any assumption that applicability
>>> of any
>>> particular channel binding type is the same for all mechanisms used
>>> within a particular application layer protocol.  Hence, I want
>>> negotiation which allows the server to say which channel binding
>>> types it
>>> willing to support on a per mechanism basis.
>>
>> Yup, I think we all understand that; we just don't all agree with
>> it, or think it's compelling enough to override the M*N concern.
>> However, the beauty of the current proposal is that it doesn't
>> require us to select a negotiation strategy now; instead it gives
>> us, or application protocol designers, or users, the flexiblity to
>> select from among a variety of strategies.
>
> I am a bit concerned that that current proposal might preclude certain
> negotiation strategies from consideration as they would be difficult to
> retrofit in.   In particular, I am concerned that the current proposal
> might preclude purely in-the-mechanism-exchange negotiation of channel
> binding types.

You mean, a strategy in which each mechanism is responsible for managing 
negotiation of channel binding types, and we don't get to do that 
negotiation until after we've selected a mechanism?

It does preclude it for GS2/SCRAM, short of modifying the mechanism, but I 
don't think there's anything we can do about that if we want to finish 
those mechanisms any time soon.  I don't think it precludes it for other 
mechanisms.

However, I also don't think it matters, because I believe we're all in 
agreement that multi-level negotation brings nothing but trouble and should 
be ignored.


> While I dislike multiple levels of negotiation, I would rather have
> multiple levels of negotiation than channel binding type negotiation
> which is not done on a per mechanism basis.

So, you'd rather pick YAP and then discover that only tls-unique is 
supported but you can't use a unique binding for your TLS session (and thus 
authentication fails) than be able to detect this situation in advannce and 
fall back to SCRAM?

Multi-level negotiation is a bad idea.  We know this is true.  We have 
numerous examples of why it is true.  I see no reason to go out of our way 
to allow for it here when we have a variety of negotiation strategies to 
choose from that are not multi-level, and there is nothing you get from a 
multi-level strategy that cannot be obtained from the others, aside from a 
major interoperability headache.

Letting each mechanism decide how to negotiate CB is also a bad idea.  It's 
not up to the mechanism what channel to use, or how to describe it.  That's 
a massive violation of modularity.  I've been trying to explain that to you 
for months now.  I've been trying to explain why modularity is important 
for months now.  Apparently I have utterly failed.  I cannot understand how 
you can be so active in the development of SASL and not understand the 
importance of the concept that is SASL's entire reason for existance.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLuaSC000385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:56:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLuaU2000384; Fri, 29 May 2009 14:56:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLuN5n000369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 14:56:35 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4TLuIXq001823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 23:56:20 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090529:[e-mail]::PrgaynEg0D11jfKc:cZ
X-Hashcash: 1:22:090529:[e-mail]::gchUP9FJvm6vF+qO:2ix
X-Hashcash: 1:22:090529:[e-mail]::vjCgiad2b+HJK5A0:2Qw6
X-Hashcash: 1:22:090529:[e-mail]::lblGefL7QFu2SbQg:2s3o
X-Hashcash: 1:22:090529:[e-mail]::ttjcTNvAw/yEzipu:4bR0
Date: Fri, 29 May 2009 23:56:18 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Fri, 29 May 2009 14:47:39 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> I would like SCRAM and GS2 not to preclude a particular negotiation
> model, including per-mechanism negotiation approaches such as what I
> propose and/or in-the-mechanism negotiation.

I agree, and I believe the new proposal meets these goals.  Do you see
any problem with it?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLlkXl099871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:47:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLlkEl099870; Fri, 29 May 2009 14:47:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLljIh099864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 14:47:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4TLldsL046346; Fri, 29 May 2009 21:47:39 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 14:47:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 1:49 PM, Jeffrey Hutzelman wrote:

>
> --On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>> What I don't find acceptable is any assumption that applicability  
>> of any
>> particular channel binding type is the same for all mechanisms used
>> within a particular application layer protocol.  Hence, I want
>> negotiation which allows the server to say which channel binding  
>> types it
>> willing to support on a per mechanism basis.
>
> Yup, I think we all understand that; we just don't all agree with  
> it, or think it's compelling enough to override the M*N concern.   
> However, the beauty of the current proposal is that it doesn't  
> require us to select a negotiation strategy now; instead it gives  
> us, or application protocol designers, or users, the flexiblity to  
> select from among a variety of strategies.

I am a bit concerned that that current proposal might preclude certain  
negotiation strategies from consideration as they would be difficult  
to retrofit in.   In particular, I am concerned that the current  
proposal might preclude purely in-the-mechanism-exchange negotiation  
of channel binding types.

>> As for as the N*M problem, I think N and M are relatively small  
>> numbers
>> and hence N*M doesn't concern me significantly.
>
> Yeah, the problem is that you believe that N and M are small numbers  
> today, and assume that therefore they always will be.  Let's look at  
> that assumption...

I note that since not all channel binding types are applicable to  
every which supports channel bindings, the total possible mechanisms  
that could be advertised is less than N*(M+1).

And as I would design it, only N+(M+1) would need to be registered  
(assuming every type was used in every mechanism): N in the SASL  
table, M+1 in the channel binding type.

>
>> Also, I don't this as creating an N*M registration issue.  N and M  
>> values
>> can be registered separately.
>
> Right up until the point where you realize that SASL allows N names  
> to be up to 20 characters long, and RFC5056 places _no_ limit on  
> names (but the existing registrations are 10, 20, and 21 characters  
> long), and yet SASL application protocols may only allow for  
> mechanism names up to 20 characters long, because SASL says they  
> won't be any longer.

And if you advertise the channel binding types as a mechanisms,  
presumedly prefixed with some short string so as to reserve a portion  
of the SASL name space for channel binding types, you are also going  
to run into 20 character problem.

For instance, C-TLS-SERVER-END-POINT is too long.  And even without a  
prefix, there's the RFC 5056 no limit problem.

> I suppose you could hash both the SASL mech name and channel binding  
> name, and come up with a combined string that's not longer than 20  
> characters, but then you will get pushback from the same people who  
> complained about hash-based names in GS2.

Yes, but my solution is not the only one which suffers from this  
problem.

>  Weren't you one of those?

I recall supporting "meaningful" names for SCRAM.  For GS2, I don't  
care all that much (except for how it impacts SCRAM).

>> Though I dislike multiple levels of negotiation, I rather have  
>> multiple
>> levels of negotiation which was not per mechanism.
>
> I'm afraid I can't parse this.  Can you try again?

While I dislike multiple levels of negotiation, I would rather have  
multiple levels of negotiation than channel binding type negotiation  
which is not done on a per mechanism basis.

> In any case, I strongly prefer that GS2 and SCRAM not lock us into a  
> particular negotiation model, and instead allow the flexibility to  
> choose from among a variety of models later, if/when we determine  
> thet negotiation is actually needed, and in the meantime allow users  
> and SASL application protocol designers the flexibility to choose  
> the meechanisms and channel binding types they need.

I would like SCRAM and GS2 not to preclude a particular negotiation  
model, including per-mechanism negotiation approaches such as what I  
propose and/or in-the-mechanism negotiation.

So long as SCRAM and GW are adequately extensible, this shouldn't be a  
problem.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLT1UW098951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:29:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLT1LS098950; Fri, 29 May 2009 14:29:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLT04s098942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 14:29:00 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TLStXv006204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:28:57 -0400 (EDT)
Date: Fri, 29 May 2009 17:28:55 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>
cc: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 11:13:47 PM +0200 Simon Josefsson 
<[e-mail]> wrote:

> I think there is something critically missing from this elaboration:
> Even though there can be theoretically up to 36 names, or possibly
> hundreds, or thousands, I believe that does not matter in practice.
>
> In practice, for any particular server, only a few set of combinations
> will be useful.  The set of practically useful combinations are much
> more limited than the N*M figure suggests.

That's true.  This means that if we can make the N*M registration problem 
go away, then the n*m negotiation problem may actually be tractable.


> There is a one step in getting a combination of a SASL mechanism and a
> channel binding type approved: the IANA allocation of the SCRAM-CB-FOO
> name.

Too hard.  Users shouldn't have to do that; they shouldn't have to have 
even heard of IANA.  Inventing a new CB type shouldn't involve enumerating 
all of the existing mechanisms and registering new names; the CB type 
designer may not even know what SASL is.  Inventing a new mechanism 
shouldn't involve enumerating all of the existing CB types, either.

> it makes us have to think about the security
> properties of each particular combination of mechanism with channel
> binding.
>
> We have already seen that YAP have different properties than SCRAM when
> used with tls-server-end-point.  That can be true generally.  It seems
> like a mistake to not think about each particular combination.

The more I think about this, the more I believe this is because YAP's 
handling of channel bindings is fundamentally broken.  Channel bindings are 
supposed to be opaque to the mechanism that carries them; the security 
properties of a mechanism should not depend on channel bindings, and they 
should not affect the security properties of channel bindings, let alone 
the channel itself.




> A much better strategy is the manual registration step I mentioned
> above.

No, that's not better.  It doesn't scale.  It requires coordination and 
binding between components that should be orthogonal and independent.


>> In any case, I strongly prefer that GS2 and SCRAM not lock us into a
>> particular negotiation model, and instead allow the flexibility to
>> choose from among a variety of models later, if/when we determine thet
>> negotiation is actually needed, and in the meantime allow users and
>> SASL application protocol designers the flexibility to choose the
>> meechanisms and channel binding types they need.
>
> Hear, hear.

And so, at least for now, I think I'm going to give up on this aspect of 
the discussion as well.  I don't think we're going to converge soon, and 
for the moment, I don't think trying is worth our collective time and 
effort.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLHCvL098253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:17:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLHCIi098252; Fri, 29 May 2009 14:17:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLHB3f098246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 14:17:11 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TLH6b0006044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 17:17:08 -0400 (EDT)
Date: Fri, 29 May 2009 17:17:06 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 10:59:17 PM +0200 Simon Josefsson 
<[e-mail]> wrote:

> I've changed the first paragraph to:
>
> 	      <t>A default channel binding type agreement process for
> 		all SASL application protocols that do not provide
> 		their own channel binding type agreement is provided
> 		as follows.</t>
>
> However this seems somewhat restrictive, since it may be read to suggest
> that negotiation cannot happen at other levels.  But I can't come up
> with better text.  Suggestions?

Until we define a negotiation strategy, there _are_ no other levels.  Of 
course a user could choose a particular CB type, but I think the language 
we agreed on will handle that.


> I'm glad you like it.  I'm not entirely happy with it: you can't parse
> it using a var[=value] parser, you need to inspect the string character
> by character in the beginning.  One alternative would be (compare with
> the examples in the document):

I see a couple of problems with the grammar.  One is that in the 'p' and 
'y' cases, you get two consecutive commas if there is no authzid.  The 
other is that in the 'n' case, you get no comma before the authzid, if 
there is one.  I think it would be better to always have a comma after the 
[pny] field, and another after the a=authzid iff it is present.

I have no objection to the [py]= syntax you suggest; that might make 
parsing easier, and we're changing the format of that field anyway.

I see no reason to include a comma after the 'F' prefix.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLE2vh097993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:14:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLE238097992; Fri, 29 May 2009 14:14:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLDurU097984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 14:14:00 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4TLDlMr000943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 23:13:49 +0200
From: Simon Josefsson <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090529:[e-mail]::92X9NsHAgcsFwWLA:2HzM
X-Hashcash: 1:22:090529:[e-mail]::gUn3iBJdfk60UJmy:5nhA
X-Hashcash: 1:22:090529:[e-mail]::6ucmPMGX0DDVH+FO:9P0r
X-Hashcash: 1:22:090529:[e-mail]::fypKUJSrYlHnR+6U:LKi+
X-Hashcash: 1:22:090529:[e-mail]::aSFkLl7HgUCynaHE:PKh3
Date: Fri, 29 May 2009 23:13:47 +0200
In-Reply-To: <[e-mail]> (Jeffrey Hutzelman's message of "Fri, 29 May 2009 16:49:57 -0400")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey Hutzelman <[e-mail]> writes:

> --On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga
> <[e-mail]> wrote:
>
>> What I don't find acceptable is any assumption that applicability of any
>> particular channel binding type is the same for all mechanisms used
>> within a particular application layer protocol.  Hence, I want
>> negotiation which allows the server to say which channel binding types it
>> willing to support on a per mechanism basis.
>
> Yup, I think we all understand that; we just don't all agree with it,
> or think it's compelling enough to override the M*N concern.  However,
> the beauty of the current proposal is that it doesn't require us to
> select a negotiation strategy now; instead it gives us, or application
> protocol designers, or users, the flexiblity to select from among a
> variety of strategies.

Indeed.  I'll not discuss cb nego more, since my hope is that we won't
have to solve that particular problem (thanks to the recent compromise
proposal!), and that this part of the discussion will have only been a
large rat hole.  But one comment.

>> As for as the N*M problem, I think N and M are relatively small numbers
>> and hence N*M doesn't concern me significantly.
>
> Yeah, the problem is that you believe that N and M are small numbers
> today, and assume that therefore they always will be.  Let's look at
> that assumption...
>
> Assume N is the number of mechanisms, and M is the number of CB types.
>
> With a strategy like Nico's, every mechanism needs 2 names (and maybe
> a third, depending on when we add negotiation and how we signal
> support for it).  Every CB type needs one name.  So you end up with
> 2N+M names.
>
> With a strategy like mine, every mechanism needs 2 names (possibly
> only one, but adding negotiation later requires that two exist), every
> CB type needs one name, and you need one for the negotiation
> pseudo-mechanism.  So, you end up with 2N+M+1 names.
>
> With a strategy like yours, every mechanism needs M+1 names (including
> one for "no channel bindings"), so you end up with N*(M+1) or N*M+N
> names.
>
> Now, let's look at what N and M are.
>
> Today, we're talking about SCRAM, and maybe GS2-KRB5, and maybe YAP.
> So for the moment we have N=3.
>
> Today, we're talking about tls-unique and tls-server-end-point.  We'll
> ignore tls-unique-for-telnet, which has limited applicability, and the
> mythical tls-client-end-point and tls-dual-end-point bindings, which I
> think we all agree are not that interesting to SASL.  So suppose M=2.
>
> Fine.  Then we have these numbers:
> Nico: 2N+M   = 6+2   = 8
> Jeff: 2N+M+1 = 6+2+1 = 9
> Kurt: N*M+N  = 6+3   = 9
>
> So it's not so bad, when N and M are both small.  However, as you
> know, as those parameters grow, the _order_ of complexity is much more
> important than the constant factors.  Let's see what happens in a
> couple of years...
>
> - Instead of considering just SCRAM, GS2-KRB5, and YAP, let's also consider
>  GS2-SPKM3, GS2-PKU2U, and GS2-IAKERB, all of which are likely to see
>  deployment in the next few years.  Now N=6.
>
> - Instead of considering just tls-unique and tls-server-end-point, let's
>  consider some other channel types that are not terribly unlikely, such
>  as ipsec-dual-end-point (certs from both sides, or whatever), ssh-unique
>  (based on the exchange hash), and ssh-server-end-point (using the server
>  host key).  Now M=5.
>
> Nico: 2N+M   = 12+5   = 17
> Jeff: 2N+M+1 = 12+5+1 = 18
> Kurt: N*M+N  = 30+6   = 36
>
> Worse, the first user who wants to use SCRAM with ssh-unique is going
> to have to figure out enough about our process to register it.
>
> Even worse, these are _very_ conservative estimates for N.  With GS2,
> we can use virtually any GSS-API mechanism.  Many of those are
> proprietary and will never be seen outside the enterprise(s) in which
> they are used.  Ask Martin Rex someday about the number of GSS-API
> mechanisms he's seen; he has plenty of experience helping customers
> build GSS-API mechanisms so they can use their enterprise
> authentication infrastructure with his product.
>
> With M=5, every new mechanism adds 6 new mechanism names.

I think there is something critically missing from this elaboration:
Even though there can be theoretically up to 36 names, or possibly
hundreds, or thousands, I believe that does not matter in practice.

In practice, for any particular server, only a few set of combinations
will be useful.  The set of practically useful combinations are much
more limited than the N*M figure suggests.

There is a one step in getting a combination of a SASL mechanism and a
channel binding type approved: the IANA allocation of the SCRAM-CB-FOO
name.  The naming scheme could be implemented to happen automatically
(like the hashed GS2 names), but I believe there is some point in having
a manual process to register each and every SCRAM-IPSEC-FOO,
SCRAM-TLS-BAR combination: it makes us have to think about the security
properties of each particular combination of mechanism with channel
binding.

We have already seen that YAP have different properties than SCRAM when
used with tls-server-end-point.  That can be true generally.  It seems
like a mistake to not think about each particular combination.

>> Also, I don't this as creating an N*M registration issue.  N and M values
>> can be registered separately.
>
> Right up until the point where you realize that SASL allows N names to
> be up to 20 characters long, and RFC5056 places _no_ limit on names
> (but the existing registrations are 10, 20, and 21 characters long),
> and yet SASL application protocols may only allow for mechanism names
> up to 20 characters long, because SASL says they won't be any longer.
>
> I suppose you could hash both the SASL mech name and channel binding
> name, and come up with a combined string that's not longer than 20
> characters, but then you will get pushback from the same people who
> complained about hash-based names in GS2.  Weren't you one of those?

A much better strategy is the manual registration step I mentioned
above.  So let's say there is SCRAM and some new channel binding called
ipsec-verylongword-anotherlongword-certificate-foobar.  The combination
of those two can be registered as SCRAM-FOOBAR in the IANA registry,
after having considered whether that combination of SASL mechanism and
channel binding is a reasonable one.

> In any case, I strongly prefer that GS2 and SCRAM not lock us into a
> particular negotiation model, and instead allow the flexibility to
> choose from among a variety of models later, if/when we determine thet
> negotiation is actually needed, and in the meantime allow users and
> SASL application protocol designers the flexibility to choose the
> meechanisms and channel binding types they need.

Hear, hear.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLAnXY097687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:10:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TLAng3097686; Fri, 29 May 2009 14:10:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TLAcR5097639 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 29 May 2009 14:10:49 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4TLAb4c004566 for <[e-mail]>; Fri, 29 May 2009 21:10:38 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TLAbcH034955 for <[e-mail]>; Fri, 29 May 2009 15:10:37 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TL0kOK015578; Fri, 29 May 2009 16:00:46 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TL0kk3015577; Fri, 29 May 2009 16:00:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 16:00:46 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 10:59:17PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > Both, 1 and 2 refer to that new GS2 header field that I mentioned.  And
> > both 1 and 2 are there to:
> 
> Right.  This isn't explicit in the GS2 document now, but I'm not sure it
> has to be.

Right -- I just wanted to clarify for the WG.

> I've changed the first paragraph to:
> 
> 	      <t>A default channel binding type agreement process for
> 		all SASL application protocols that do not provide
> 		their own channel binding type agreement is provided
> 		as follows.</t>

Perfect.

> However this seems somewhat restrictive, since it may be read to suggest
> that negotiation cannot happen at other levels.  But I can't come up
> with better text.  Suggestions?

No, I think the above is fine.

> > Also, I like your ABNF.  I had in mind using something like t=<type> and
> > t=<type>[:<type>[:...]], but your approach strikes me as better.
> 
> I'm glad you like it.  I'm not entirely happy with it: you can't parse
> it using a var[=value] parser, you need to inspect the string character
> by character in the beginning.  One alternative would be (compare with
> the examples in the document):
> 
> Example #1: n,a=someuser,...
> Example #2: n,...
> Example #3: F,n,...
> Example #4: p=tls-unique,a=someuser,...
> Example #5: p=tls-unique,...
> Example #6: p=tls-server-end-point,...
> Example #7: y=tls-unique:tls-server-end-point,a=someuser,...

That's fine too.

> Also, that SCRAM uses var[=value] doesn't mean GS2 needs to.

True, but GS2 already does (a=<authzid>).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKxOPd096715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 13:59:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TKxNh4096714; Fri, 29 May 2009 13:59:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKxL6r096703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 13:59:23 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4TKxH5d000691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 22:59:19 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090529:[e-mail]::jsv22umoEuG2zWdt:Sdz
X-Hashcash: 1:22:090529:[e-mail]::E/NFE64PvNCfJY5I:Eq6c
X-Hashcash: 1:22:090529:[e-mail]::RrZE21KJR+Myh+Na:FWPS
Date: Fri, 29 May 2009 22:59:17 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Fri, 29 May 2009 15:22:32 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Fri, May 29, 2009 at 08:29:42PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > After much discussion with Jeff H. and, separately, Sam H., I think the
>> > following proposal is likely to be simple enough to garner consensus and
>> > yet flexible enough to let us adapt to future conditions.  The proposal:
>> 
>> Nico convinced me about this proposal in jabber, and we fleshed out the
>> changes that will be needed in GS2 to implement this.  This has to be
>> reflected in SCRAM as well.  The changes can be summarized into:
>> 
>> 1) Add text to say that with 'p' one cb type name is included (normally
>> tls-unique)
>> 
>> 2) Add text to say that with 'y' a list of cb type names supported by
>> the client is included
>
> Both, 1 and 2 refer to that new GS2 header field that I mentioned.  And
> both 1 and 2 are there to:
>
> a) facilitate the future addition of channel binding type negotiation
>    using any one of the three sketches so far (Jeff's pseudo-mech,
>    Simon/Kurt's N*M mech names, or my N+M mech names),
>
> and
>
> b) provide for downgrade detection should we ever add channel binding
>    type negotiation.

Right.  This isn't explicit in the GS2 document now, but I'm not sure it
has to be.

>> 3) Add text to say that if a server doesn't understand the cb type,
>> authentication fails.
>
> That's not strictly needed: whatever the server does at that point
> authentication necessarily must fail :)

Well, some guidance what should happen is needed.  Server's certainly
shouldn't accept the authentication attempt.

>> 4) The text from Nico's e-mail (clients and servers MUST support
>> tls-unique, clients SHOULD choose tls-unique, ...)
>
> Yup, as modified by Jeff's reply to my post.

Yes.

>> I have converted the above into text changes for GS2, and you can review
>> the result in:
>> 
>> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html
>> 
>> The diff against -13 is in:
>> 
>> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--13.diff.html
>
> The main comment I have is that section 5.1 needs to claim the default
> channel binding type agreement as being the default for _SASL application
> protocols_, and explicitly allow SASL app protocols to specify a
> different agreement.

I've changed the first paragraph to:

	      <t>A default channel binding type agreement process for
		all SASL application protocols that do not provide
		their own channel binding type agreement is provided
		as follows.</t>

However this seems somewhat restrictive, since it may be read to suggest
that negotiation cannot happen at other levels.  But I can't come up
with better text.  Suggestions?

> Also, I like your ABNF.  I had in mind using something like t=<type> and
> t=<type>[:<type>[:...]], but your approach strikes me as better.

I'm glad you like it.  I'm not entirely happy with it: you can't parse
it using a var[=value] parser, you need to inspect the string character
by character in the beginning.  One alternative would be (compare with
the examples in the document):

Example #1: n,a=someuser,...
Example #2: n,...
Example #3: F,n,...
Example #4: p=tls-unique,a=someuser,...
Example #5: p=tls-unique,...
Example #6: p=tls-server-end-point,...
Example #7: y=tls-unique:tls-server-end-point,a=someuser,...

However I didn't want to make unrelated changes at this point.

Also, that SCRAM uses var[=value] doesn't mean GS2 needs to.

I'm not sure.

Thoughts?

> Finally, you need to add references to the channel binding type
> registrations.

Done.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKvpR2096649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 13:57:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TKvpM6096648; Fri, 29 May 2009 13:57:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKvfdi096636 for <[e-mail]>; Fri, 29 May 2009 13:57:51 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4TKveIx007201 for <[e-mail]>; Fri, 29 May 2009 20:57:40 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TKveSk042114 for <[e-mail]>; Fri, 29 May 2009 14:57:40 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TKlnlf015555; Fri, 29 May 2009 15:47:49 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TKlmbP015554; Fri, 29 May 2009 15:47:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 15:47:48 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 01:02:53PM -0700, Kurt Zeilenga wrote:
> What I don't find acceptable is any assumption that applicability of  
> any particular channel binding type is the same for all mechanisms  
> used within a particular application layer protocol.  Hence, I want  
> negotiation which allows the server to say which channel binding types  
> it willing to support on a per mechanism basis.

My M+N negotiation scheme does NOT make "any assumption that
applicability of any particular channel binding type is the same for all
mechanisms..."

It does, however, require local knowledge of the applicability of any
server-advertised, client-supported channel binding type to any server-
advertised, client-supported SASL mechanism.  And it requires applying
that knowledge via a simple (but by no means trivial) algorithm.

BUT, the point of Jeff's and my proposal is this: we don't need to argue
about the merits of M*M, M+N, or a pseudo-mechanism to negotiate cb
types -- we can stop at making it possible to add a secure cb type
negotiation later.

By deferring discussion of a feature where we don't have consensus
(multiple proposals, each with their set of problems, and their
champions) to when we ever end up needing it, we make it easier to reach
consensus _now_ on the minimum that we need to get SCRAM/GS2 out the
door.

If you don't agree with this approach to reaching consensus, please say
so.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKoEfh096299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 13:50:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TKoEwH096298; Fri, 29 May 2009 13:50:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKo2Ha096273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 13:50:13 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TKnvK0005623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 16:49:59 -0400 (EDT)
Date: Fri, 29 May 2009 16:49:57 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

> What I don't find acceptable is any assumption that applicability of any
> particular channel binding type is the same for all mechanisms used
> within a particular application layer protocol.  Hence, I want
> negotiation which allows the server to say which channel binding types it
> willing to support on a per mechanism basis.

Yup, I think we all understand that; we just don't all agree with it, or 
think it's compelling enough to override the M*N concern.  However, the 
beauty of the current proposal is that it doesn't require us to select a 
negotiation strategy now; instead it gives us, or application protocol 
designers, or users, the flexiblity to select from among a variety of 
strategies.

> As for as the N*M problem, I think N and M are relatively small numbers
> and hence N*M doesn't concern me significantly.

Yeah, the problem is that you believe that N and M are small numbers today, 
and assume that therefore they always will be.  Let's look at that 
assumption...

Assume N is the number of mechanisms, and M is the number of CB types.

With a strategy like Nico's, every mechanism needs 2 names (and maybe a 
third, depending on when we add negotiation and how we signal support for 
it).  Every CB type needs one name.  So you end up with 2N+M names.

With a strategy like mine, every mechanism needs 2 names (possibly only 
one, but adding negotiation later requires that two exist), every CB type 
needs one name, and you need one for the negotiation pseudo-mechanism.  So, 
you end up with 2N+M+1 names.

With a strategy like yours, every mechanism needs M+1 names (including one 
for "no channel bindings"), so you end up with N*(M+1) or N*M+N names.

Now, let's look at what N and M are.

Today, we're talking about SCRAM, and maybe GS2-KRB5, and maybe YAP.
So for the moment we have N=3.

Today, we're talking about tls-unique and tls-server-end-point.  We'll 
ignore tls-unique-for-telnet, which has limited applicability, and the 
mythical tls-client-end-point and tls-dual-end-point bindings, which I 
think we all agree are not that interesting to SASL.  So suppose M=2.

Fine.  Then we have these numbers:
Nico: 2N+M   = 6+2   = 8
Jeff: 2N+M+1 = 6+2+1 = 9
Kurt: N*M+N  = 6+3   = 9

So it's not so bad, when N and M are both small.  However, as you know, as 
those parameters grow, the _order_ of complexity is much more important 
than the constant factors.  Let's see what happens in a couple of years...

- Instead of considering just SCRAM, GS2-KRB5, and YAP, let's also consider
  GS2-SPKM3, GS2-PKU2U, and GS2-IAKERB, all of which are likely to see
  deployment in the next few years.  Now N=6.

- Instead of considering just tls-unique and tls-server-end-point, let's
  consider some other channel types that are not terribly unlikely, such
  as ipsec-dual-end-point (certs from both sides, or whatever), ssh-unique
  (based on the exchange hash), and ssh-server-end-point (using the server
  host key).  Now M=5.

Nico: 2N+M   = 12+5   = 17
Jeff: 2N+M+1 = 12+5+1 = 18
Kurt: N*M+N  = 30+6   = 36

Worse, the first user who wants to use SCRAM with ssh-unique is going to 
have to figure out enough about our process to register it.

Even worse, these are _very_ conservative estimates for N.  With GS2, we 
can use virtually any GSS-API mechanism.  Many of those are proprietary and 
will never be seen outside the enterprise(s) in which they are used.  Ask 
Martin Rex someday about the number of GSS-API mechanisms he's seen; he has 
plenty of experience helping customers build GSS-API mechanisms so they can 
use their enterprise authentication infrastructure with his product.

With M=5, every new mechanism adds 6 new mechanism names.


> Also, I don't this as creating an N*M registration issue.  N and M values
> can be registered separately.

Right up until the point where you realize that SASL allows N names to be 
up to 20 characters long, and RFC5056 places _no_ limit on names (but the 
existing registrations are 10, 20, and 21 characters long), and yet SASL 
application protocols may only allow for mechanism names up to 20 
characters long, because SASL says they won't be any longer.

I suppose you could hash both the SASL mech name and channel binding name, 
and come up with a combined string that's not longer than 20 characters, 
but then you will get pushback from the same people who complained about 
hash-based names in GS2.  Weren't you one of those?


> Though I dislike multiple levels of negotiation, I rather have multiple
> levels of negotiation which was not per mechanism.

I'm afraid I can't parse this.  Can you try again?




In any case, I strongly prefer that GS2 and SCRAM not lock us into a 
particular negotiation model, and instead allow the flexibility to choose 
from among a variety of models later, if/when we determine thet negotiation 
is actually needed, and in the meantime allow users and SASL application 
protocol designers the flexibility to choose the meechanisms and channel 
binding types they need.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKWbcZ095550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 13:32:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TKWbMp095549; Fri, 29 May 2009 13:32:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TKWRVp095529 for <[e-mail]>; Fri, 29 May 2009 13:32:37 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4TKWQS3003292 for <[e-mail]>; Fri, 29 May 2009 20:32:26 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TKWQ3Y008549 for <[e-mail]>; Fri, 29 May 2009 14:32:26 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TKMZJm015519; Fri, 29 May 2009 15:22:35 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TKMWoN015518; Fri, 29 May 2009 15:22:32 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 15:22:32 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 08:29:42PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > After much discussion with Jeff H. and, separately, Sam H., I think the
> > following proposal is likely to be simple enough to garner consensus and
> > yet flexible enough to let us adapt to future conditions.  The proposal:
> 
> Nico convinced me about this proposal in jabber, and we fleshed out the
> changes that will be needed in GS2 to implement this.  This has to be
> reflected in SCRAM as well.  The changes can be summarized into:
> 
> 1) Add text to say that with 'p' one cb type name is included (normally
> tls-unique)
> 
> 2) Add text to say that with 'y' a list of cb type names supported by
> the client is included

Both, 1 and 2 refer to that new GS2 header field that I mentioned.  And
both 1 and 2 are there to:

a) facilitate the future addition of channel binding type negotiation
   using any one of the three sketches so far (Jeff's pseudo-mech,
   Simon/Kurt's N*M mech names, or my N+M mech names),

and

b) provide for downgrade detection should we ever add channel binding
   type negotiation.

> 3) Add text to say that if a server doesn't understand the cb type,
> authentication fails.

That's not strictly needed: whatever the server does at that point
authentication necessarily must fail :)

> 4) The text from Nico's e-mail (clients and servers MUST support
> tls-unique, clients SHOULD choose tls-unique, ...)

Yup, as modified by Jeff's reply to my post.

> I have converted the above into text changes for GS2, and you can review
> the result in:
> 
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html
> 
> The diff against -13 is in:
> 
> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--13.diff.html

The main comment I have is that section 5.1 needs to claim the default
channel binding type agreement as being the default for _SASL application
protocols_, and explicitly allow SASL app protocols to specify a
different agreement.

Also, I like your ABNF.  I had in mind using something like t=<type> and
t=<type>[:<type>[:...]], but your approach strikes me as better.

Finally, you need to add references to the channel binding type
registrations.

> Check the examples, they are updated and hopefully give you a quick idea
> of how the protocol will look like.
> 
> Thoughts?

Awesome.  Thanks!

Alexey, can you adapt Simon's changes to GS2 to SCRAM?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TK38rh093983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 13:03:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TK38VA093982; Fri, 29 May 2009 13:03:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TK2veu093958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 29 May 2009 13:03:08 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4TK2r2v042235; Fri, 29 May 2009 20:02:54 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 13:02:53 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 29, 2009, at 8:42 AM, Nicolas Williams wrote:

>
> On Fri, May 29, 2009 at 09:21:27AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>>> Note that there's no reference to tls-server-end-point in the above
>>> proposal.  And notice that the server knows what channel binding  
>>> type
>>> the client chose.
>>
>> That would work, but I'm not sure it is required.  I don't see what
>> advantage that gives over the current situation of not sending the
>> channel binding type and specifying that tls-unique (or
>> tls-server-end-point) should be used?
>
> First, we do send the channel binding type _now_, just not on the
> "outside" (from the GSS-API perspective), where we actually need it.
>
> The reason we need the channel binding type on the "outside" is this:
> suppose we've added channel binding type negotiation and a server
> supports multiple channel binding types, then how is the server to  
> know
> which channel binding type the client chose?  One answer would be:
> through the name of the mechanism that the client chose -- but this  
> gets
> us into the N*M mechanism name registration issue.  A better answer is
> to just put the channel binding type in the GS2 header, then the  
> server
> can just inspect that.
>
>>> The sum total changes to SCRAM/GS2 would be:
>>>
>>> - New text to describe the default channel binding type agreement
>>>   process.
>>>
>>> - New text and ABNF to describe the new GS2 header field.
>>>
>>> Comments?
>>
>> For the negotiation, I prefer the scheme with explicit channel  
>> binding
>> type negotiation in the mechanism name:
>>
>> 	SCRAM-SHA-1  (no channel binding)
>> 	SCRAM-SHA-1-TLS-UNIQUE
>> 	SCRAM-SHA-1-TLS-SERVER-END-POINT
>
> I will not agree to that.  I've already explained that an N*M  
> mechanism
> name registration problem is unacceptable.  I can't imagine why you'd
> find it acceptable.  Perhaps you think that M will never exceed 2?

What I don't find acceptable is any assumption that applicability of  
any particular channel binding type is the same for all mechanisms  
used within a particular application layer protocol.  Hence, I want  
negotiation which allows the server to say which channel binding types  
it willing to support on a per mechanism basis.

As for as the N*M problem, I think N and M are relatively small  
numbers and hence N*M doesn't concern me significantly.

Also, I don't this as creating an N*M registration issue.  N and M  
values can be registered separately.  All a mechanism spec needs to do  
is register SCRAM-SHA-1-* and state that * is to replaced by a value  
from the channel binding table, mapped to upper case, etc. (see below).

>> (of course the names have to be changed to fit within the 20  
>> character
>> limits)
>
> That's an exceedingly obnoxious aspect of this problem.

Yes, I had once suggested to grow the limit but was in the rough.  TLS- 
SERVER-END-POINT by itself is 20 characters.  One might use instead  
TSEP (we could register "short names" in the IANA table) or use a hash  
(which nobody is terribly fond of).  The etc. above needs to deal with  
this.

Though I dislike multiple levels of negotiation, I rather have  
multiple levels of negotiation which was not per mechanism.

So, I guess my second preference might be some in-the-mechanism  
exchange negotiation mechanism.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TIsZH4090239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 11:54:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TIsZCE090238; Fri, 29 May 2009 11:54:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TIsYUc090232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 11:54:35 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TIsVWf018605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 14:54:31 -0400 (EDT)
Date: Fri, 29 May 2009 14:54:31 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 08:29:42 PM +0200 Simon Josefsson 
<[e-mail]> wrote:

> http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html

This is good in principle, but in reading it I found I have a number of 
minor comments which I'll try to write up soon.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TITxuf088967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 11:30:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TITxSO088966; Fri, 29 May 2009 11:29:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TITlEC088955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 11:29:58 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4TITg6a029711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 20:29:45 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090529:[e-mail]::moZa4ayAKPZzGBsJ:39Wr
X-Hashcash: 1:22:090529:[e-mail]::GOOnIuh8s8ApJKmk:R9hp
X-Hashcash: 1:22:090529:[e-mail]::BlcLwQvC2LOVMsE1:R40k
Date: Fri, 29 May 2009 20:29:42 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Fri, 29 May 2009 00:13:17 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> After much discussion with Jeff H. and, separately, Sam H., I think the
> following proposal is likely to be simple enough to garner consensus and
> yet flexible enough to let us adapt to future conditions.  The proposal:

Nico convinced me about this proposal in jabber, and we fleshed out the
changes that will be needed in GS2 to implement this.  This has to be
reflected in SCRAM as well.  The changes can be summarized into:

1) Add text to say that with 'p' one cb type name is included (normally
tls-unique)

2) Add text to say that with 'y' a list of cb type names supported by
the client is included

3) Add text to say that if a server doesn't understand the cb type,
authentication fails.

4) The text from Nico's e-mail (clients and servers MUST support
tls-unique, clients SHOULD choose tls-unique, ...)

I have converted the above into text changes for GS2, and you can review
the result in:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.html

The diff against -13 is in:

http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--13.diff.html

Check the examples, they are updated and hopefully give you a quick idea
of how the protocol will look like.

Thoughts?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TGJkGn078424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 09:19:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TGJkTG078423; Fri, 29 May 2009 09:19:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TGJZIm078409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 09:19:46 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4TGJVCw019499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 12:19:32 -0400 (EDT)
Date: Fri, 29 May 2009 12:19:31 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 10:42:09 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Fri, May 29, 2009 at 09:21:27AM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > Note that there's no reference to tls-server-end-point in the above
>> > proposal.  And notice that the server knows what channel binding type
>> > the client chose.
>>
>> That would work, but I'm not sure it is required.  I don't see what
>> advantage that gives over the current situation of not sending the
>> channel binding type and specifying that tls-unique (or
>> tls-server-end-point) should be used?
>
> First, we do send the channel binding type _now_, just not on the
> "outside" (from the GSS-API perspective), where we actually need it.
>
> The reason we need the channel binding type on the "outside" is this:
> suppose we've added channel binding type negotiation and a server
> supports multiple channel binding types, then how is the server to know
> which channel binding type the client chose?  One answer would be:
> through the name of the mechanism that the client chose -- but this gets
> us into the N*M mechanism name registration issue.

That is, it _locks_ us into the N*M registration issue, forcing a 
particular negotiation strategy, instead of letting us decide later or 
allowing a user to decide on a whim that he wants to bind to an ssh channel.

> A better answer is
> to just put the channel binding type in the GS2 header, then the server
> can just inspect that.

Which allows us to defer indefinitely the question of exactly how 
negotiation should be done, if at all.




>> For the negotiation, I prefer the scheme with explicit channel binding
>> type negotiation in the mechanism name:
>>
>> 	SCRAM-SHA-1  (no channel binding)
>> 	SCRAM-SHA-1-TLS-UNIQUE
>> 	SCRAM-SHA-1-TLS-SERVER-END-POINT
>
> I will not agree to that.  I've already explained that an N*M mechanism
> name registration problem is unacceptable.  I can't imagine why you'd
> find it acceptable.  Perhaps you think that M will never exceed 2?

Nor will I.

A negotiation scheme involving separately registering every combination of 
choices from multiple levels is not acceptable to me.  It breaks modularity 
and restricts users to using supposedly orthogonal pieces only in 
combinations which someone else has decided are acceptable, and that is not 
OK.  As an operator, I believe that the right to set policy, including what 
mechanisms and what channel bindings are used, belongs entirely to me, and 
not to some implementor or protocol designer or IANA.  SASL is designed to 
make it possible for application implementers to give me that flexibility 
with respect to mechanisms; why would I want it to tie my hands with 
respect to choice of channel bindings?


> You mischaracterize my scheme for the future addition of cbinding type
> nego.  It gives the client all the information it needs to select a
> suitable {mechanism, channel binding type}, without any additional
> round-trips.  Given that information it is possible to pick a
> {mechanism, channel binding type} in a way that takes into account a)
> availability of user credentials for the mechanism, b) client/user
> mechanism preference, c) mechanism dependence/ non-dependence on unique
> channel bindings.

What it doesn't give the client is information about what combinations of 
mechanisms and channel bindings can be used.  But that's OK, because these 
components are not used "in combination" they are orghogonal.  The 
interface between them is about as simple as it gets -- channel bindings 
are opaque data, and the mechanism carries and integrity-protects that data 
without making any assumptions about what is inside it.  Any mechanism can 
carry any opaque blob of binary data; the security of the mechanism is not 
affected by what that data is, and the security of the channel binding is 
affected only by the mechanism's ability to provide integrity protection on 
that blob of data.  Neither is affected by any interactions between the 
mechanism and channel binding type, because neither of those makes any 
assuptions about the other.



That said, I'm really not interested in debating the merits of various 
possible negotiation schemes.  The entire point of the small change we're 
proposing to GS2/SCRAM is to avoid having to hold up those mechanisms for 
that debate, when in reality the debate is mostly moot because we're 
unlikely to see enough widespread use of binding types other than 
TLS-UNIQUE to make defining a negotiation mechanism worthwhile, especially 
given that users and administrators are already used to configuring 
everything manually if they want any behavior other than PLAIN over TLS 
without server certificate validation.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TFqVf6076199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 08:52:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4TFqVE8076198; Fri, 29 May 2009 08:52:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4TFqAF0076150 for <[e-mail]>; Fri, 29 May 2009 08:52:20 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4TFq4Kr017421 for <[e-mail]>; Fri, 29 May 2009 15:52:09 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4TFq45S047691 for <[e-mail]>; Fri, 29 May 2009 09:52:04 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4TFgAg9015300; Fri, 29 May 2009 10:42:10 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4TFg90J015299; Fri, 29 May 2009 10:42:09 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 10:42:09 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 09:21:27AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > Note that there's no reference to tls-server-end-point in the above
> > proposal.  And notice that the server knows what channel binding type
> > the client chose.
> 
> That would work, but I'm not sure it is required.  I don't see what
> advantage that gives over the current situation of not sending the
> channel binding type and specifying that tls-unique (or
> tls-server-end-point) should be used?

First, we do send the channel binding type _now_, just not on the
"outside" (from the GSS-API perspective), where we actually need it.

The reason we need the channel binding type on the "outside" is this:
suppose we've added channel binding type negotiation and a server
supports multiple channel binding types, then how is the server to know
which channel binding type the client chose?  One answer would be:
through the name of the mechanism that the client chose -- but this gets
us into the N*M mechanism name registration issue.  A better answer is
to just put the channel binding type in the GS2 header, then the server
can just inspect that.

> > The sum total changes to SCRAM/GS2 would be:
> >
> >  - New text to describe the default channel binding type agreement
> >    process.
> >
> >  - New text and ABNF to describe the new GS2 header field.
> >
> > Comments?
> 
> For the negotiation, I prefer the scheme with explicit channel binding
> type negotiation in the mechanism name:
> 
> 	SCRAM-SHA-1  (no channel binding)
> 	SCRAM-SHA-1-TLS-UNIQUE
> 	SCRAM-SHA-1-TLS-SERVER-END-POINT

I will not agree to that.  I've already explained that an N*M mechanism
name registration problem is unacceptable.  I can't imagine why you'd
find it acceptable.  Perhaps you think that M will never exceed 2?

> (of course the names have to be changed to fit within the 20 character
> limits)

That's an exceedingly obnoxious aspect of this problem.

> This approach appears simpler and more robust than either yours or
> Jeff's schemes, if I understand them all correctly.

I don't agree.

> My reasons against Jeff's scheme is that an additional round-trip is
> performance costly and adds implementation complexity, and it is easily
> avoidable.  Your scheme assumes that all mechanisms wants to use the
> same channel binding negotiation approach, which I think can't be
> assumed at this point.  I also think your approach fits badly with how
> SASL mechanism negotiation are handled in some implementations, which is
> a subjective opinion.

You mischaracterize my scheme for the future addition of cbinding type
nego.  It gives the client all the information it needs to select a
suitable {mechanism, channel binding type}, without any additional
round-trips.  Given that information it is possible to pick a
{mechanism, channel binding type} in a way that takes into account a)
availability of user credentials for the mechanism, b) client/user
mechanism preference, c) mechanism dependence/ non-dependence on unique
channel bindings.

The only problem with my scheme is that applications that don't use a
SASL framework have to implement the {mechanism, channel binding type}
selection algorithm themselves -- a bit of pain, but nowadays there's a
variety of SASL framework implementations, and most apps that I'm aware
of use one.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T9bG4W041233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 02:37:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T9bGcT041232; Fri, 29 May 2009 02:37:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T9b5pr041214 for <[e-mail]>; Fri, 29 May 2009 02:37:16 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.60.66] (92.40.60.66.sub.mbb.three.co.uk [92.40.60.66])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 29 May 2009 10:37:04 +0100
Message-ID: <[e-mail]>
Date: Fri, 29 May 2009 10:36:27 +0100
From: Alexey Melnikov <[e-mail]>
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: Kurt Zeilenga <[e-mail]>
CC: SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> I hereby cancel the WGLC on this document as it is reasonably clear  
> that a lack of consensus exists as to the publication of the I-D as 
> it  currently reads.  I also intend to defer the WGLC on the GS2 
> document.
>
> I encourage the WG to respond to this poll.  The chairs will 
> determine  WG consensus of responses, including comments, including 
> discussions  not restricted to the variants listed.  The chairs will 
> also consider  off-list comments.  (Participants are of course free to 
> reach  independent conclusions of the responses they are aware of, 
> however  the chairs have not and will not delegated their RFC 2418  
> responsibilities in this area.)

Very well.

I would ask chairs to put a deadline for reaching the consensus on 
channel bindings, somewhere around 1 month, 2 months max.
I don't intend to participate in discussions in this document for 6 more 
months. If that happens, you will have my resignation as the editor of 
the document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T7LisG029825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 00:21:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T7LiLY029824; Fri, 29 May 2009 00:21:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T7LVxD029810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 29 May 2009 00:21:43 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4T7LREK011746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 09:21:29 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090529:[e-mail]::N3j4TcEGqGJeQeZ7:Tvy
X-Hashcash: 1:22:090529:[e-mail]::/V12N/JB+8rz3XpA:4f0G
X-Hashcash: 1:22:090529:[e-mail]::X5fXx6QKQQAz6rRQ:hJp/
Date: Fri, 29 May 2009 09:21:27 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Fri, 29 May 2009 00:13:17 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Fri, May 29, 2009 at 12:06:51AM +0200, Simon Josefsson wrote:
>> 1a
>> 4a
>> 3
>> 4b (I'm assuming it refers to tls-server-end-point)
>> 1b
>> 2
>> 5 use YAP
>
> Mostly the same for me, as you can see from my other post, but I need to
> add some details.
>
> After much discussion with Jeff H. and, separately, Sam H., I think the
> following proposal is likely to be simple enough to garner consensus and
> yet flexible enough to let us adapt to future conditions.  The proposal:
>
>  - GS2 (and, therefore, SCRAM) will provide a DEFAULT channel binding
>    type agreement process for all SASL application protocols that do not
>    provide their own channel binding type agreement.
>
>    This default would be:
>
>     - Servers MUST implement tls-unique;
>     - Clients MUST implement tls-unique;
>     - Clients MUST choose the highest-layer/innermost end-to-end TLS
>       channel as the channel to bind to;
>     - Clients SHOULD choose the tls-unique channel binding type.
>
>       Conversely, clients MAY choose a different channel binding type
>       though: user input, configuration, or a future, as-yet undefined
>       channel binding type negotiation protocol.
>
>     - clients MUST convey to the server, through GS2, which channel
>       binding type it chose.
>
>  - The GS2 header needs a to gain a field by which the client can tell
>    the server what channel binding type it chose (see above).
>
>    This header should either always be present, or it should be present
>    only when the client chooses a channel binding type other than the
>    default.  If it's easier for the WG to accept this new GS2 header
>    field by making it not present in the default case, then so be it.
>
> Note that there's no reference to tls-server-end-point in the above
> proposal.  And notice that the server knows what channel binding type
> the client chose.

That would work, but I'm not sure it is required.  I don't see what
advantage that gives over the current situation of not sending the
channel binding type and specifying that tls-unique (or
tls-server-end-point) should be used?

> Notice too that we are left in a position where we can actually add
> channel binding type negotiation later.  Jeff has one sketch of such an
> extension, and I have another.  Both rely on the fact that we have
> mechanism negotiation to begin with.  Jeff's is an pseudo-mechanism for
> negotiation (think of SPNEGO), and adds a round-trip.  Mine adds no
> round trips, and does not have the N*M mechanism name registration
> problem -- it adds new affixes like SCRAM/GS2's -PLUS suffix to indicate
> the need for channel binding type negotiation, and uses the mechanism
> negotiation to negotiate both: mechanism and channel binding type.
> Details of these sketches should be discussed only to establish that we
> will be able to add channel binding type negotiation later if we ever
> need it, and, crucially, to show that the GS2 header field mentioned
> above makes that possible.
>
> The sum total changes to SCRAM/GS2 would be:
>
>  - New text to describe the default channel binding type agreement
>    process.
>
>  - New text and ABNF to describe the new GS2 header field.
>
> Comments?

For the negotiation, I prefer the scheme with explicit channel binding
type negotiation in the mechanism name:

	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE
	SCRAM-SHA-1-TLS-SERVER-END-POINT

(of course the names have to be changed to fit within the 20 character
limits)

This approach appears simpler and more robust than either yours or
Jeff's schemes, if I understand them all correctly.

My reasons against Jeff's scheme is that an additional round-trip is
performance costly and adds implementation complexity, and it is easily
avoidable.  Your scheme assumes that all mechanisms wants to use the
same channel binding negotiation approach, which I think can't be
assumed at this point.  I also think your approach fits badly with how
SASL mechanism negotiation are handled in some implementations, which is
a subjective opinion.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5sJ04023887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:54:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5sJke023886; Thu, 28 May 2009 22:54:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5sJ0g023880 for <[e-mail]>; Thu, 28 May 2009 22:54:19 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4T5sJsW009356 for <[e-mail]>; Fri, 29 May 2009 05:54:19 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4T5sJRt035448 for <[e-mail]>; Thu, 28 May 2009 23:54:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4T5awCf015114; Fri, 29 May 2009 00:36:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4T5awBm015113; Fri, 29 May 2009 00:36:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 00:36:58 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 01:36:07AM -0400, Jeffrey Hutzelman wrote:
> Yup, that's it.  Except...
> 
>  - Clients SHOULD choose the highest-layer/innermost end-to-end TLS
>    channel as the channel to bind to;
> 
> That is, s/MUST/SHOULD/, to avoid inadvertently prohibiting clients from 
> binding to a channel type other than TLS.

Ah, yes, I wasn't sure about that.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5n66L023618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:49:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5n659023617; Thu, 28 May 2009 22:49:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5mu4F023607 for <[e-mail]>; Thu, 28 May 2009 22:49:06 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4T5mu7B013959 for <[e-mail]>; Fri, 29 May 2009 05:48:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4T5mtH5033116 for <[e-mail]>; Thu, 28 May 2009 23:48:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4T5d5ww015120; Fri, 29 May 2009 00:39:05 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4T5d5t3015119; Fri, 29 May 2009 00:39:05 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 00:39:05 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 28, 2009 at 06:25:03PM -0700, Kurt Zeilenga wrote:
> I hereby cancel the WGLC on this document as it is reasonably clear  
> that a lack of consensus exists as to the publication of the I-D as it  
> currently reads.  I also intend to defer the WGLC on the GS2 document.

We're probably very close to achieving consensus, in great part thanks
to Alexey's efforts (thanks Alexey!).  So I think cancelling the WGLC
was premature (I know, I know, I had wanted the poll to precede the
WGLC).  I figure the WGLC will restart very soon.

Thanks,

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5ck8a023167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:38:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5ckUU023166; Thu, 28 May 2009 22:38:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5cjZh023156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 22:38:46 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4T5chtD016833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 01:38:43 -0400 (EDT)
Date: Fri, 29 May 2009 01:38:43 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, May 27, 2009 02:02:15 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
>
> On May 27, 2009, at 1:05 PM, Jeffrey Hutzelman wrote:
>
>>
>> NB: I hate SASL's use of the word "protocol" to mean "something
>> built on top of SASL", for which the word "application" would be
>> much more useful. One of the reasons I hate it is that it means that
>> about 50% of the audience gets confused when I use the word
>> "protocol" in its usual sense, as I do in this document.
>
> The problem with "application" is that it often used, as Nico used it in
> this thread, to refer to a component of an implementation as opposed
> what's happening on wire within a particular layer of the protocol stack.

Yeah.  From now on I will use a phrase like "SASL application protocol", to 
avoid ambiguity.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5aBE6023047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:36:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5aBWH023046; Thu, 28 May 2009 22:36:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5a9wd023036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 22:36:10 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4T5a7oc016801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 01:36:07 -0400 (EDT)
Date: Fri, 29 May 2009 01:36:07 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>
cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, May 29, 2009 12:13:17 AM -0500 Nicolas Williams 
<[e-mail]> wrote:

>  - GS2 (and, therefore, SCRAM) will provide a DEFAULT channel binding
>    type agreement process for all SASL application protocols that do not
>    provide their own channel binding type agreement.
>
>    This default would be:
>
>     - Servers MUST implement tls-unique;
>     - Clients MUST implement tls-unique;
>     - Clients MUST choose the highest-layer/innermost end-to-end TLS
>       channel as the channel to bind to;
>     - Clients SHOULD choose the tls-unique channel binding type.
>
>       Conversely, clients MAY choose a different channel binding type
>       though: user input, configuration, or a future, as-yet undefined
>       channel binding type negotiation protocol.
>
>     - clients MUST convey to the server, through GS2, which channel
>       binding type it chose.
>
>  - The GS2 header needs a to gain a field by which the client can tell
>    the server what channel binding type it chose (see above).
>
>    This header should either always be present, or it should be present
>    only when the client chooses a channel binding type other than the
>    default.  If it's easier for the WG to accept this new GS2 header
>    field by making it not present in the default case, then so be it.

Yup, that's it.  Except...

  - Clients SHOULD choose the highest-layer/innermost end-to-end TLS
    channel as the channel to bind to;

That is, s/MUST/SHOULD/, to avoid inadvertently prohibiting clients from 
binding to a channel type other than TLS.



BTW, note that we say both client and server MUST implement tls-unique; 
this assures that a secure, interoperable configuration is possible, but 
does not preclude other configurations.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5TNmj022718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:29:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5TNDe022716; Thu, 28 May 2009 22:29:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5THfY022701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 22:29:22 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4T5TF1l016737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 01:29:16 -0400 (EDT)
Date: Fri, 29 May 2009 01:29:15 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, May 28, 2009 06:35:16 PM -0500 Nicolas Williams 
<[e-mail]> wrote:

>
> On Thu, May 28, 2009 at 10:49:03PM +0100, Alexey Melnikov wrote:
>> 1). SCRAM should just use a single allowed TLS channel binding and don't
>> have any negotiation of other TLS channel bindings (*) (**)
>> a). the default is tls-unique
>> b). the default is tls-server-end-point
>> 2). SCRAM should just use tls-server-end-point, fallback to tls-unique,
>> no negotiation of other TLS channel bindings (*)
>> 3). SCRAM should always use channel binding negotiation (*)
>> 4). SCRAM should have a default TLS channel binding with optional
>> negotiation of TLS channel bindings (*)
>> a). the default is tls-unique
>> b). the default is
>> 5). I have another opinion [this is for the case when there is some
>> valid choice which you think should be considered by the WG]
>
> (1a) future-proofed would be my preferred approach.  I.e., (1a) with the
> '**' details filled out.

Mine as well.  Particularly, I think we're trying to achieve the following:

- Maximum interoperability without compromising security
- Not too painful to implement, for clients or servers
- Not define negotiaton now, but...
- Leave the door open to define negotiation later or...
- Let SASL application protocols define negotation or...
- Let users/administrators select channels and CB types

To that end, I think the things we have to do now are define a way for 
GS2/SCRAM to carry information about what CB type is in use, and specify a 
default behavior in the absence of guidance from the user, application 
protocol specification, or an as-yet-undefined negotiation mechanism.

I can imagine a number of ways to define negotiation in the future, 
including both some that negotiate mechanism and CB type separately and 
some that link them.  Nico and I have worked through one possible 
negotiation strategy in each of those categories and convinced ourselves 
that each approach can be defined in the future without impacting 
GS2/SCRAM, provided we add the header field Nico describes below (we also 
designed an extension to TCP, but you don't care about that).

If we're going to have a single default, that should be tls-unique.


I'm also OK with (2), future-proofed in the same way as (1a), but Nico 
makes an argument that tls-server-end-point may be dangerous given the 
possibility of GSS-API mechanisms which depend on unique channel bindings. 
I'll accept that argument for now, but I think that such dependencies 
should be discouraged at the GSS-API layer, since the GSS-API imposes no 
requirement that callers use unique channel bindings or in fact any at all. 
But that's probably a discussion for kitten.

I'd be OK with (4a), but like Nico, I don't feel it's worthwhile to specify 
a negotiation mechanism now.  In practice, it's going to be some time 
before there are SASL application protocols which care about channel types 
other than TLS, and if we're deciding that TLS endpoint bindings are unsafe 
and/or not worthwhile, then we're unlikely to need a binding type for TLS 
other than tls-unique any time soon.  For similar reasons, (3) seems not 
worth doing.


Like Nico, I believe that (1b) is unacceptable since tls-server-end-point 
may not always work.



> I believe we can do this by adding a field to the GS2 header that would
> be present *only* when the channel binding type used is not the default
> one.  Since this would not materially change SCRAM/GS2, I believe this
> would be the ideal solution.

I'm fine with this approach, or with adding a field which is always present 
when channel bindings are in use.

I believe Nico is writing up a concrete proposal which builds on what he's 
already said and on the goals I mention above.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5TN5M022719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:29:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5TNnt022717; Thu, 28 May 2009 22:29:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5TBXb022696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 22:29:22 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4T5T9Eh016733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 01:29:09 -0400 (EDT)
Date: Fri, 29 May 2009 01:29:08 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: SASL WG <[e-mail]>, [e-mail]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, May 28, 2009 07:08:42 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> My current view is that channel binding type (tls-unique v.
> tls-server-end-point v. other types (whether other TLS types or non-TLS
> types) for SCRAM be accomplished through SASL mechanism negotiation.
> Specifically, I prefer the I-D to define a set of mechanism variants,
> possibly open ended to allow for future channel binding types, that
> allow, in addition to hash function, the channel binding type to be
> advertise by the server (in supporting application protocols) and
> selected by the client.  Specifically, I recommend names such as:
> 	SCRAM-SHA-1  (no channel binding)
> 	SCRAM-SHA-1-TLS-UNIQUE
> 	SCRAM-SHA-1-TLS-SERVER-END-POINT

Ugh.  This creates exactly the kind of geometric registration problem that 
Nico, I, and others find completely unacceptable.  I can understand your 
desire to link negotiation of mechanisms and channel types, but this is not 
the way to do it.  The SASL architecture is modular in nature; given a 
modular implementation a user can take an arbitrary SASL application 
protocol (possibly a private one you've never heard of) and an arbitrary 
mechanism (also possibly a private one you've never heard of) and use them 
together.  Channel bindings should have the same property; it should be 
possible to construct an implementation where users can take any such 
combination, add an arbitrary channel binding type (including a private one 
you've never heard of), and use them together.  And they shouldn't first 
have to register a SASL mechanism name in an IESG-controlled mechanism 
family (or any mechanism name) to do so.

Since I want users, administrators, or writers of SASL application protocol 
specifications to be able to specify use of an arbitrary channel binding 
type with SCRAM, I do not support use of a mechanism name which encodes a 
particular channel binding type.  I do support a means of allowing the 
client to inform the server, within and secured by the mechanism, of which 
channel binding type is in use.  I believe this provides sufficient 
flexibility not only to allow users, admins, and application protocols to 
do what they need, but also to allow later introduction of a negotiation 
mechanism with whatever properties we deem necessary.



> I do not support in SCRAM exchange negotiation as this tends to lead to
> interoperability problems (client asks to SCRAM, server offers a channel
> binding types the client is not willing to use, must abort the exchange,
> possibly having to reconnect, to try some other mechanisms).

Yes, multi-level negotiation is to be avoided.  A client must not be forced 
to choose SCRAM before it knows what channel binding types it will be able 
to use.  For that reason I also do not support in-mechanism negotiation. 
However, I do support inclusion in the mechanism of a means of informing 
the server as to which channel binding type the client has selected, which 
opens the door for arbitrary means of selecting a channel binding type.


-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5NLZV022475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 22:23:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T5NLjG022474; Thu, 28 May 2009 22:23:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T5NAm1022456 for <[e-mail]>; Thu, 28 May 2009 22:23:21 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4T5NARI000556 for <[e-mail]>; Fri, 29 May 2009 05:23:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4T5NA31021231 for <[e-mail]>; Thu, 28 May 2009 23:23:10 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4T5DHPZ015083; Fri, 29 May 2009 00:13:17 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4T5DHZ0015082; Fri, 29 May 2009 00:13:17 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Fri, 29 May 2009 00:13:17 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, May 29, 2009 at 12:06:51AM +0200, Simon Josefsson wrote:
> 1a
> 4a
> 3
> 4b (I'm assuming it refers to tls-server-end-point)
> 1b
> 2
> 5 use YAP

Mostly the same for me, as you can see from my other post, but I need to
add some details.

After much discussion with Jeff H. and, separately, Sam H., I think the
following proposal is likely to be simple enough to garner consensus and
yet flexible enough to let us adapt to future conditions.  The proposal:

 - GS2 (and, therefore, SCRAM) will provide a DEFAULT channel binding
   type agreement process for all SASL application protocols that do not
   provide their own channel binding type agreement.

   This default would be:

    - Servers MUST implement tls-unique;
    - Clients MUST implement tls-unique;
    - Clients MUST choose the highest-layer/innermost end-to-end TLS
      channel as the channel to bind to;
    - Clients SHOULD choose the tls-unique channel binding type.

      Conversely, clients MAY choose a different channel binding type
      though: user input, configuration, or a future, as-yet undefined
      channel binding type negotiation protocol.

    - clients MUST convey to the server, through GS2, which channel
      binding type it chose.

 - The GS2 header needs a to gain a field by which the client can tell
   the server what channel binding type it chose (see above).

   This header should either always be present, or it should be present
   only when the client chooses a channel binding type other than the
   default.  If it's easier for the WG to accept this new GS2 header
   field by making it not present in the default case, then so be it.

Note that there's no reference to tls-server-end-point in the above
proposal.  And notice that the server knows what channel binding type
the client chose.

Notice too that we are left in a position where we can actually add
channel binding type negotiation later.  Jeff has one sketch of such an
extension, and I have another.  Both rely on the fact that we have
mechanism negotiation to begin with.  Jeff's is an pseudo-mechanism for
negotiation (think of SPNEGO), and adds a round-trip.  Mine adds no
round trips, and does not have the N*M mechanism name registration
problem -- it adds new affixes like SCRAM/GS2's -PLUS suffix to indicate
the need for channel binding type negotiation, and uses the mechanism
negotiation to negotiate both: mechanism and channel binding type.
Details of these sketches should be discussed only to establish that we
will be able to add channel binding type negotiation later if we ever
need it, and, crucially, to show that the GS2 header field mentioned
above makes that possible.

The sum total changes to SCRAM/GS2 would be:

 - New text to describe the default channel binding type agreement
   process.

 - New text and ABNF to describe the new GS2 header field.

Comments?

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T3Q1Or015724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 20:26:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T3Q1q4015723; Thu, 28 May 2009 20:26:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T3PoxZ015708 for <[e-mail]>; Thu, 28 May 2009 20:26:00 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4T3PnDl019596 for <[e-mail]>; Fri, 29 May 2009 03:25:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4T3Pnuc051559 for <[e-mail]>; Thu, 28 May 2009 21:25:49 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4T38Rh2015045; Thu, 28 May 2009 22:08:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4T38Rlm015044; Thu, 28 May 2009 22:08:27 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 28 May 2009 22:08:26 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 28, 2009 at 07:49:45PM -0700, Kurt Zeilenga wrote:
> >We don't need alternatives.
> 
> But aren't alternatives just something we have to live with given the  
> RFC 5056 IANA Considerations?

Just because they are possible doesn't mean that we need them.

Before we consider any alternative to three registered TLS channel
binding types I'd like to know why we couldn't use those.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T3O20F015585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 20:24:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T3O2wg015584; Thu, 28 May 2009 20:24:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T3O1WP015576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 20:24:02 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4T3NubI031057; Fri, 29 May 2009 03:23:59 GMT (envelope-from [e-mail])
Cc: Alexey Melnikov <[e-mail]>, SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 20:23:55 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 28, 2009, at 7:08 PM, Kurt Zeilenga wrote:

> That is, while I favor 3 but only if a negotiation is via names of  
> the variants of the SCRAM mechanism.  So I guess I rather call this  
> 5 as I rather my comments be take as supporting the other forms of  
> negotiation.

yikes.  I meant: I rather my comments NOT be taken as supporting other  
forms of negotiation.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T2nxhV013054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 19:49:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T2nx06013053; Thu, 28 May 2009 19:49:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T2nwY8013047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 19:49:58 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4T2nkTk029815; Fri, 29 May 2009 02:49:50 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Date: Thu, 28 May 2009 19:49:45 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 28, 2009, at 1:38 PM, Nicolas Williams wrote:

>
> On Thu, May 28, 2009 at 10:39:00PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>>
>>> Simon has submitted an I-D for the purpose of publishing these as  
>>> RFCs:
>>> draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).
>>
>> The goal with that document was to offer another channel binding
>> construct, based on the TLS PRF.  My document does not describe
>> Microsoft's channel binding types, which are based on the TLS  
>> Finished
>> message.
>
> We don't need alternatives.

But aren't alternatives just something we have to live with given the  
RFC 5056 IANA Considerations?

I think we need to be careful of specifications that assume that there  
will be one and only one unique channel binding type or one and only  
one server, client, or dual end-point channel binding type for a  
particular kind of channel.  We already have two unique bindings for  
TLS registered (though one claims to be specific to TELNET, nothing  
seems to precludes it use outside of TELNET), and then Simon's.  And  
you have noted the one could define TLS server end-point channel  
binding types that only identified the server's name.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T28lDY010309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 19:08:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T28l2t010308; Thu, 28 May 2009 19:08:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T28kAA010301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 19:08:47 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4T28gXI028691; Fri, 29 May 2009 02:08:44 GMT (envelope-from [e-mail])
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 19:08:42 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My current view is that channel binding type (tls-unique v. tls-server- 
end-point v. other types (whether other TLS types or non-TLS types)  
for SCRAM be accomplished through SASL mechanism negotiation.   
Specifically, I prefer the I-D to define a set of mechanism variants,  
possibly open ended to allow for future channel binding types, that  
allow, in addition to hash function, the channel binding type to be  
advertise by the server (in supporting application protocols) and  
selected by the client.  Specifically, I recommend names such as:
	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE
	SCRAM-SHA-1-TLS-SERVER-END-POINT

I do not support advertisement of pseudo mechanism names as this  
presumes the security applicability of all present and future channel  
binding types when used in all present and future SASL mechanisms with  
all present and future application problems is the same.  I argue that  
the security characteristics of each channel binding types,  
mechanisms, and protocol differ significantly enough that it  
reasonable that application protocol server implementor or deployer  
might reasonable want to place restrictions on which channel binding  
types are available on a per mechanism basis.

I do not support in SCRAM exchange negotiation as this tends to lead  
to interoperability problems (client asks to SCRAM, server offers a  
channel binding types the client is not willing to use, must abort the  
exchange, possibly having to reconnect, to try some other mechanisms).

That is, while I favor 3 but only if a negotiation is via names of the  
variants of the SCRAM mechanism.  So I guess I rather call this 5 as I  
rather my comments be take as supporting the other forms of negotiation.

The only other option I think I could support is defining only:
	SCRAM-SHA-1  (no channel binding)
	SCRAM-SHA-1-TLS-UNIQUE

Under this option (basically 1a), I would not use the PLUS name for  
SCRAM-SHA-1-TLS-UNIQUE (or SCRAM-SHA-1-TLS-SERVER-END-POINT or other  
name restricted to a specific channel binding type) to encourage  
"meaningful" names of additional variants that could be subsequently  
introduced.  That is, I think the PLUS name in more suitable for the  
two options above that I do not support.

-- Kurt, as a WG participant


On May 28, 2009, at 2:49 PM, Alexey Melnikov wrote:

>
> I've discussed channel bindings with Nico in jabber and we agreed  
> that we need to get WG consensus on how TLS channel bindings should  
> be used with SCRAM.
> Please provide an orded list of alternatives you find acceptable  
> from the choices listed below. (Please restrict discussions of  
> variants of these choices at the moment. I will do another poll on  
> such choices later, depending on the outcome of this poll. Also,  
> please read notes for the choices before answering). Please answer  
> the poll by the end of June 7th.
>
> 1). SCRAM should just use a single allowed TLS channel binding and  
> don't have any negotiation of other TLS channel bindings (*) (**)
> a). the default is tls-unique
> b). the default is tls-server-end-point
> 2). SCRAM should just use tls-server-end-point, fallback to tls- 
> unique, no negotiation of other TLS channel bindings (*)
> 3). SCRAM should always use channel binding negotiation (*)
> 4). SCRAM should have a default TLS channel binding with optional  
> negotiation of TLS channel bindings (*)
> a). the default is tls-unique
> b). the default is
> 5). I have another opinion [this is for the case when there is some  
> valid choice which you think should be considered by the WG]
>
> Notes:
> (*) - whether such negotiation happens inside or outside of SCRAM
> (**) - channel binding negotiation can be added later on
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T1PH5K007372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 18:25:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4T1PHwF007371; Thu, 28 May 2009 18:25:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4T1P6b4007353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 18:25:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4T1P3Jx027549; Fri, 29 May 2009 01:25:04 GMT (envelope-from [e-mail])
Cc: SASL WG <[e-mail]>
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 18:25:03 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I hereby cancel the WGLC on this document as it is reasonably clear  
that a lack of consensus exists as to the publication of the I-D as it  
currently reads.  I also intend to defer the WGLC on the GS2 document.

I encourage the WG to respond to this poll.  The chairs will determine  
WG consensus of responses, including comments, including discussions  
not restricted to the variants listed.  The chairs will also consider  
off-list comments.  (Participants are of course free to reach  
independent conclusions of the responses they are aware of, however  
the chairs have not and will not delegated their RFC 2418  
responsibilities in this area.)

-- Kurt, as co-chair

On May 28, 2009, at 2:49 PM, Alexey Melnikov wrote:

>
> I've discussed channel bindings with Nico in jabber and we agreed  
> that we need to get WG consensus on how TLS channel bindings should  
> be used with SCRAM.
> Please provide an orded list of alternatives you find acceptable  
> from the choices listed below. (Please restrict discussions of  
> variants of these choices at the moment. I will do another poll on  
> such choices later, depending on the outcome of this poll. Also,  
> please read notes for the choices before answering). Please answer  
> the poll by the end of June 7th.
>
> 1). SCRAM should just use a single allowed TLS channel binding and  
> don't have any negotiation of other TLS channel bindings (*) (**)
> a). the default is tls-unique
> b). the default is tls-server-end-point
> 2). SCRAM should just use tls-server-end-point, fallback to tls- 
> unique, no negotiation of other TLS channel bindings (*)
> 3). SCRAM should always use channel binding negotiation (*)
> 4). SCRAM should have a default TLS channel binding with optional  
> negotiation of TLS channel bindings (*)
> a). the default is tls-unique
> b). the default is
> 5). I have another opinion [this is for the case when there is some  
> valid choice which you think should be considered by the WG]
>
> Notes:
> (*) - whether such negotiation happens inside or outside of SCRAM
> (**) - channel binding negotiation can be added later on
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SNjIfu001791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 16:45:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SNjIvK001790; Thu, 28 May 2009 16:45:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SNj8si001780 for <[e-mail]>; Thu, 28 May 2009 16:45:18 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4SNj7Y3004049 for <[e-mail]>; Thu, 28 May 2009 23:45:08 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4SNj75v058606 for <[e-mail]>; Thu, 28 May 2009 17:45:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4SNZGa7014830; Thu, 28 May 2009 18:35:16 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4SNZGUK014829; Thu, 28 May 2009 18:35:16 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 28 May 2009 18:35:16 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 28, 2009 at 10:49:03PM +0100, Alexey Melnikov wrote:
> 1). SCRAM should just use a single allowed TLS channel binding and don't 
> have any negotiation of other TLS channel bindings (*) (**)
> a). the default is tls-unique
> b). the default is tls-server-end-point
> 2). SCRAM should just use tls-server-end-point, fallback to tls-unique, 
> no negotiation of other TLS channel bindings (*)
> 3). SCRAM should always use channel binding negotiation (*)
> 4). SCRAM should have a default TLS channel binding with optional 
> negotiation of TLS channel bindings (*)
> a). the default is tls-unique
> b). the default is
> 5). I have another opinion [this is for the case when there is some 
> valid choice which you think should be considered by the WG]

(1a) future-proofed would be my preferred approach.  I.e., (1a) with the
'**' details filled out.

I believe we can do this by adding a field to the GS2 header that would
be present *only* when the channel binding type used is not the default
one.  Since this would not materially change SCRAM/GS2, I believe this
would be the ideal solution.

So, really, I want (5), which in my case is:

 - by default use tls-unique (in the case of TLS channels, of course)
   (this is (1a) so far)
 - if the client wishes to use any other channel binding type then it
   must indicate which type that is via a GS2 header field that would
   otherwise not be present
 - if we ever need to add channel binding type negotation we can do it
   later because of the previous item.

My (5) is almost indistinguishable from (1a).  It adds a single
conditional to server implementations of SCRAM/GS2 and nothing at all to
clients.

(1b) is not acceptable.  tls-unique is available for all TLS channels;
the same can't be said for tls-server-end-point, which makes it not
suitable for use as the only channel binding type.

(2) would be OK, BUT, keep in mind that this has to be true for GS2 as 
well, and that there may be mechanisms like YAP for which
tls-server-end-point is a weaker channel binding type than tls-unique
(see below!).

(3) seems too complicated.

(4a) is almost like my (1a)/my (5), but with "later" being "now".  (4a)
is not worthwhile at this time.

I don't know what (4b) mean.  Did you mean to say "tls-server-end-point"
or "<fill in the blank>"?  Either way, (1a)/my (5) is preferable.


As for whether tls-server-end-point is weaker than tls-unique for YAP...
That's a very interesting question!  Sam and I spent quite a bit of time
today discussing it.

And the answer is not as obvious as we'd thought.  Clearly YAP with
tls-server-end-point (or any non-unique channel binding type) is subject
to replays, but if the only entities that could do the replaying are the
client and the server, then there's no real harm.  The assumption buried
there is that there are no trusted proxies -- perhaps not a good
assumption!  Also, suppose there was an end-point channel binding type
that uses the server end-point's name rather than the end-point's
cert/public key, then you get an additional weakness: a dependency on
trust anchors being actually trust-worthy.  Another weakness for YAP
with non-unique channel binding types may be that an attacker can
compute a dictionary of YAP messages, off-line, one for every possible
password, and if SASL authentication is retriable then the attacker gets
as many tries as the server allows.  Whereas with unique channel
bindings the attacker must do the computation in real-time.

So unique channel binding types are a better fit for YAP and YAP-like
mechanisms, but it's not clear that end-point channel binding types are
fatal to YAP.  In fact, if there are no proxies and the client uses a
TLS cipher suite with confidentiality protection, then it should be fine
for the client to use YAP with tls-server-end-point, provided that the
server has an N-strikes-you're-locked-and-must-change-your-password
policy.  But clearly unique channel binding types are stronger in the
face of authentication mechanisms like YAP that need a nonce from an
external source and use the channel binding as one.

Now consider that SCRAM is a GS2 mechanism, and that someone could have
a GSS-API mechanism that is like YAP (i.e., it depends on unique channel
bindings for non-replayability).  This argues for a preference for
tls-unique over tls-server-end-point.

The above analysis is the reason that I support (1a)/my (5).  I believe
Sam is also on board with this.

Thanks,

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SM6vmG094991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 15:06:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SM6vwd094990; Thu, 28 May 2009 15:06:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SM6s11094981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 15:06:56 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4SM6pig031401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2009 00:06:53 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: SASL WG <[e-mail]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090528:[e-mail]::YTPWaerPixBAa6eL:qV8
X-Hashcash: 1:22:090528:[e-mail]::dG3G0Eb1jv153VCq:Ee9y
Date: Fri, 29 May 2009 00:06:51 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Thu, 28 May 2009 22:49:03 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> I've discussed channel bindings with Nico in jabber and we agreed that
> we need to get WG consensus on how TLS channel bindings should be used
> with SCRAM.
> Please provide an orded list of alternatives you find acceptable from
> the choices listed below. (Please restrict discussions of variants of
> these choices at the moment. I will do another poll on such choices
> later, depending on the outcome of this poll. Also, please read notes
> for the choices before answering). Please answer the poll by the end
> of June 7th.
>
> 1). SCRAM should just use a single allowed TLS channel binding and
> don't have any negotiation of other TLS channel bindings (*) (**)
> a). the default is tls-unique
> b). the default is tls-server-end-point
> 2). SCRAM should just use tls-server-end-point, fallback to
> tls-unique, no negotiation of other TLS channel bindings (*)
> 3). SCRAM should always use channel binding negotiation (*)
> 4). SCRAM should have a default TLS channel binding with optional
> negotiation of TLS channel bindings (*)
> a). the default is tls-unique
> b). the default is
> 5). I have another opinion [this is for the case when there is some
> valid choice which you think should be considered by the WG]

My preferred order is as follows:

1a
4a
3
4b (I'm assuming it refers to tls-server-end-point)
1b
2
5 use YAP

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SLuEi5094228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 14:56:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SLuEEx094227; Thu, 28 May 2009 14:56:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SLu4uD094216 for <[e-mail]>; Thu, 28 May 2009 14:56:14 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4SLu30U008731 for <[e-mail]>; Thu, 28 May 2009 21:56:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4SLu3r2017085 for <[e-mail]>; Thu, 28 May 2009 15:56:03 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4SLk9eC014785; Thu, 28 May 2009 16:46:09 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4SLk9ba014784; Thu, 28 May 2009 16:46:09 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 28 May 2009 16:46:09 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 27, 2009 at 11:40:16AM -0700, Kurt Zeilenga wrote:
> This message initiates a SASL WG Last Call on the Internet-Draft:
> 
> >	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
> >	Author(s)       : A. Menon-Sen, et al.
> >	Filename        : draft-ietf-sasl-scram-01.txt
> >	Pages           : 33
> >	Date            : 2009-05-26

My only comments are editorial, otherwise I'm happy with this
Internet-Draft:

 - Clarify this sentence:

  "This means that SCRAM is actually both, a GSS-API and SASL mechanism."

   as follows:

  "This means that this document defines both, a GSS-API mechanism and a
   SASL mechanism."

   Rationale: one must remove the GS2 header from the initial context
   token and then add the RFC2743 initial context token header in order
   to get SCRAM as a GSS-API mechanism, therefore the original text
   above might be confusing to some readers.  See section 8.

 - Section 4, there's a typo: (20-length("SCRAM-")-lenght("-PLUS")
   (the second 'length' is misspelled).

 - Section 5, "SCRAM is a text protocol where...".  Really?  I thought
   SCRAM was a mechanism, not a protocol...  How about:

   "SCRAM is a SASL mechanism whose authentication messages are
   text-based messages containing one or more attribute-value pairs
   separated by commas."

   (That these messages are exchanged by a client and server seems
   superfluous once one describes SCRAM as a SASL mechanism.)

 - Section 6:

"
   o  If the client negotiates mechanisms then client MUST select SCRAM-
      <hash-function>-PLUS if offered by the server.  Otherwise, if the
      client does not negotiate mechanisms then it MUST select only
      SCRAM-<hash-function> (not suffixed with "-PLUS").
"

   s/then client/then the client/

   s/MUST select SCRAM-<hash-function>-PLUS if offered by the server/
     MUST select SCRAM-<hash-function>-PLUS if offered by the server and
     the client wants to select SCRAM with the given hash function/

 - Section 6:

   o  If the client supports channel binding but the server does not
      then the client MUST ...

   s/the server does not/the server does not (i.e., did not offer
     SCRAM-<hash-function>-PLUS) then the client MUST .../


Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SLnosj093826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 14:49:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SLnoOl093825; Thu, 28 May 2009 14:49:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SLndjN093814 for <[e-mail]>; Thu, 28 May 2009 14:49:49 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.3.10] (92.40.3.10.sub.mbb.three.co.uk [92.40.3.10])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 28 May 2009 22:49:37 +0100
Message-ID: <[e-mail]>
Date: Thu, 28 May 2009 22:49:03 +0100
From: Alexey Melnikov <[e-mail]>
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: SASL WG <[e-mail]>
Subject: Poll: use of TLS channel bindings in SCRAM
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've discussed channel bindings with Nico in jabber and we agreed that 
we need to get WG consensus on how TLS channel bindings should be used 
with SCRAM.
Please provide an orded list of alternatives you find acceptable from 
the choices listed below. (Please restrict discussions of variants of 
these choices at the moment. I will do another poll on such choices 
later, depending on the outcome of this poll. Also, please read notes 
for the choices before answering). Please answer the poll by the end of 
June 7th.

1). SCRAM should just use a single allowed TLS channel binding and don't 
have any negotiation of other TLS channel bindings (*) (**)
 a). the default is tls-unique
 b). the default is tls-server-end-point
2). SCRAM should just use tls-server-end-point, fallback to tls-unique, 
no negotiation of other TLS channel bindings (*)
3). SCRAM should always use channel binding negotiation (*)
4). SCRAM should have a default TLS channel binding with optional 
negotiation of TLS channel bindings (*)
 a). the default is tls-unique
 b). the default is
5). I have another opinion [this is for the case when there is some 
valid choice which you think should be considered by the WG]

Notes:
(*) - whether such negotiation happens inside or outside of SCRAM
(**) - channel binding negotiation can be added later on



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKtgED089763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:55:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SKtgMX089762; Thu, 28 May 2009 13:55:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKtfoL089756 for <[e-mail]>; Thu, 28 May 2009 13:55:42 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4SKtffq023115 for <[e-mail]>; Thu, 28 May 2009 20:55:41 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4SKtfeJ040992 for <[e-mail]>; Thu, 28 May 2009 14:55:41 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4SKcK6s014752; Thu, 28 May 2009 15:38:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4SKcKZ7014751; Thu, 28 May 2009 15:38:20 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 28 May 2009 15:38:20 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 28, 2009 at 10:39:00PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > Simon has submitted an I-D for the purpose of publishing these as RFCs:
> > draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).
> 
> The goal with that document was to offer another channel binding
> construct, based on the TLS PRF.  My document does not describe
> Microsoft's channel binding types, which are based on the TLS Finished
> message.

We don't need alternatives.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKdLQi088707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:39:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SKdLXM088706; Thu, 28 May 2009 13:39:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SKd81v088680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 13:39:20 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4SKd0lC029398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 May 2009 22:39:02 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Jeffrey Hutzelman <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090528:[e-mail]::OH0plpczzMEPjqXo:12l1
X-Hashcash: 1:22:090528:[e-mail]::lsVA2fdNDusyr6eA:0DeH
X-Hashcash: 1:22:090528:[e-mail]::ZAeOWlhC+4cbdF/h:FN4T
X-Hashcash: 1:22:090528:[e-mail]::67bTrQbKMFAu8N7P:ECb2
Date: Thu, 28 May 2009 22:39:00 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Thu, 28 May 2009 14:08:58 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> Simon has submitted an I-D for the purpose of publishing these as RFCs:
> draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).

The goal with that document was to offer another channel binding
construct, based on the TLS PRF.  My document does not describe
Microsoft's channel binding types, which are based on the TLS Finished
message.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SJQb4t083352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 12:26:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SJQbMw083351; Thu, 28 May 2009 12:26:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SJQQ2R083334 for <[e-mail]>; Thu, 28 May 2009 12:26:36 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4SJQQLf007790 for <[e-mail]>; Thu, 28 May 2009 19:26:26 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4SJQPRs017878 for <[e-mail]>; Thu, 28 May 2009 13:26:25 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4SJ8xnj014682; Thu, 28 May 2009 14:08:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4SJ8wpW014681; Thu, 28 May 2009 14:08:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Thu, 28 May 2009 14:08:58 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, May 28, 2009 at 01:31:45PM -0400, Jeffrey Hutzelman wrote:
> Oh, ugh; those really should have been done as RFC's so we could have 
> proper references.  In any case, let's not worry about it too much just 
> yet, since this will likely be changing anyway.

Several I-Ds that I've edited recently have such references.  I asked on
the xml2rfc list just what would be the best way to make normative
references to IANA registry entries.  This is the stanza I use:

            <reference anchor='tls-server-end-point'>
                <front>
                    <title>Registration of TLS server end-point channel
                        bindings</title>
                    <author initials='L.' surname='Zhu' fullname='Larry Zhu'>
                        <organization abbrev='MSFT'>Microsoft</organization>
                    </author>
                    <date month='July' year='2008'/>
                </front>
                <format type='TXT'
                    target='http://www.iana.org/assignments/channel-binding-types/tls-server-end-point'/>
            </reference>
            <reference anchor='tls-unique'>
                <front>
                    <title>Registration of TLS unique channel binding
                        (generic)</title>
                    <author initials='L.' surname='Zhu' fullname='Larry Zhu'>
                        <organization abbrev='MSFT'>Microsoft</organization>
                    </author>
                    <date month='July' year='2008'/>
                </front>
                <format type='TXT'
                    target='http://www.iana.org/assignments/channel-binding-types/tls-unique'/>
            </reference>

But I agree, the moment I had to go ask I felt sorry we'd not sought to
publish these as RFCs instead of just expert-reviewed IANA
reigstrations.

Simon has submitted an I-D for the purpose of publishing these as RFCs:
draft-josefsson-sasl-tls-cb-01 (which I've not yet reviewed).

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SHW0HN073977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 10:32:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SHW0h9073976; Thu, 28 May 2009 10:32:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SHVmhI073966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 28 May 2009 10:31:59 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4SHVjAc016913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 13:31:45 -0400 (EDT)
Date: Thu, 28 May 2009 13:31:45 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt 
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, May 28, 2009 08:41:32 AM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

>
> The I-D needs normative references to the 'tls-server-end-point' and
> 'tls-unique' channel binding type technical specifications.
>
> OLD:
>     If an external TLS channel is to be bound into the authentication,
>     and if the channel supports channel bindings of type
>     'tls-server-end-point', then those MUST be used, else if the
>     channel supports channel bindings of type 'tls-unique' type,
>     then those MUST be used.
>
> NEW:
>     If an external TLS channel is to be bound into the authentication,
>     and if the channel supports channel bindings of type
>     'tls-server-end-point' [CBT-TLS-EP], then those MUST be used, else if
> the
>     channel supports channel bindings of type 'tls-unique' [CBT-TLS-U],
>     then those MUST be used.
>
> and add to both sets of normative references:
>
>     [CBT-TLS-EP] Larry Zhu, "Registration of TLS server end-point channel
> bindings",
>
> http://www.iana.org/assignments/channel-binding-types/tls-server-end-poin
> t,
>       June 26, 2008.
>
>     [CBT-TLS-U] Larry Zhu, "Registration of TLS unique channel bindings
> (generic)",
>       http://www.iana.org/assignments/channel-binding-types/tls-unique,
>       June 26, 2008.

Oh, ugh; those really should have been done as RFC's so we could have 
proper references.  In any case, let's not worry about it too much just 
yet, since this will likely be changing anyway.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SFfknR065291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 08:41:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SFfktQ065290; Thu, 28 May 2009 08:41:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SFfZqP065259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 08:41:45 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4SFfWjC086227 for <[e-mail]>; Thu, 28 May 2009 15:41:33 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt 
Date: Thu, 28 May 2009 08:41:32 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The I-D needs normative references to the 'tls-server-end-point' and  
'tls-unique' channel binding type technical specifications.

OLD:
    If an external TLS channel is to be bound into the authentication,
    and if the channel supports channel bindings of type
    'tls-server-end-point', then those MUST be used, else if the
    channel supports channel bindings of type 'tls-unique' type,
    then those MUST be used.

NEW:
    If an external TLS channel is to be bound into the authentication,
    and if the channel supports channel bindings of type
    'tls-server-end-point' [CBT-TLS-EP], then those MUST be used, else  
if the
    channel supports channel bindings of type 'tls-unique' [CBT-TLS-U],
    then those MUST be used.

and add to both sets of normative references:

    [CBT-TLS-EP] Larry Zhu, "Registration of TLS server end-point  
channel bindings",
      http://www.iana.org/assignments/channel-binding-types/tls-server-end-point 
,
      June 26, 2008.

    [CBT-TLS-U] Larry Zhu, "Registration of TLS unique channel  
bindings (generic)",
      http://www.iana.org/assignments/channel-binding-types/tls-unique,
      June 26, 2008.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SAncHQ041289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 03:49:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4SAncNk041288; Thu, 28 May 2009 03:49:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4SAnQXu041261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 28 May 2009 03:49:37 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4SAnL4E054829; Thu, 28 May 2009 10:49:22 GMT (envelope-from [e-mail])
Cc: Jeffrey Hutzelman <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Date: Thu, 28 May 2009 03:49:20 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 27, 2009, at 3:13 PM, Nicolas Williams wrote:

> I strongly disagree with Kurt's characterization of the addition of
> channel binding support via SCRAM/GS2 as not rising to the level of a
> "new feature" for SASL that is disallowed by the WG's charter.

It's my view that charter statement that "new features" are beyond the  
scope of the WG was not intended to limit design of new mechanisms  
that the WG was specifically chartered to develop.   New mechanisms  
are themselves our new features to SASL.  And new mechanisms, by there  
very nature, are quite likely to have input requirements and  
characteristics that are different from previously introduced  
mechanisms.

I also note that channel binding were incorporated into the design  
prior to the last review and approval of our WG charter.

I believe the intent of the "new features" statement was intended to  
restrict the scope of the WG's "work to progress the SASL Technical  
Specification toward Draft Standard" item (e.g. rfc4422bis work, as  
well as any updates to RFC 4422 the WG might want to work on).

> I also
> don't consider the charter to be a material roadblock to SCRAM/GS2
> making progress: we can always update the charter if we really have  
> to.

I certainly don't see the charter as being a material roadblock to  
SCRAM/GS2 making progress.  I do consider it a minor pot hole in the  
road in the WG doing work on a mechanism-independent channel binding  
type negotiation.  I think it minor as, if consensus supports doing  
this work, the charter can be updated.

I also reiterate that none of the above statements, or my recent prior  
statements, should be viewed as closing off this discussion on whether  
mechanism-independent channel binding type negotiation is needed or  
not, or discussion of possible solutions.

It is my intent to close on the question of whether a mechanism- 
independent channel binding type negotiation is needed or not through  
the SCRAM and GS2 WGLCs.  Those who believe that a mechanism- 
independent channeling binding type negotiation method is necessary  
can and should argue that SCRAM and GS2 I-Ds need to be changed to  
normatively reference a specification detailing such, or at least for  
specific changes to the I-D for a mechanism-specific negotiation  
method that they believe can be later be use as a basis for a  
mechanism-independent channeling binding type method.

The intent of my comments, and the WGLCs, is to try to focus  
discussions on what changes, if any, should be made to the SCRAM and  
GS2 I-Ds.

-- Kurt, as co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RMVZ7V090895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 15:31:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RMVZqm090894; Wed, 27 May 2009 15:31:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RMVO9O090883 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 27 May 2009 15:31:34 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4RMVNZe000634 for <[e-mail]>; Wed, 27 May 2009 22:31:23 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RMVNbV062490 for <[e-mail]>; Wed, 27 May 2009 16:31:23 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RMDxEb014225; Wed, 27 May 2009 17:13:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RMDwHD014224; Wed, 27 May 2009 17:13:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 17:13:58 -0500
From: Nicolas Williams <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 27, 2009 at 05:40:19PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, May 27, 2009 10:31:41 PM +0100 Alexey Melnikov 
> <[e-mail]> wrote:
> >I don't believe it is.
> >Firstly, this issue is largely orthogonal to SCRAM/GS2 design. Very
> >little would change if we can reach consensus on channel binding
> >negotiation.
> 
> I'm not sure that's true.  At least one of the approaches I could imagine 
> would involve reopening some issues that have been a bit sticky in the 
> past.  It is my strong preference to avoid going there, but it might happen 
> anyway.

For example: we might want to add a field to the GS2 header for the
client to indicate to the server which channel binding type it chose.

> >Secondly, we failed to reach consensus on this issue so far. Asking to
> >just table SCRAM/GS2 till we reach a consensus is not reasonable, because
> >there is no guaranty that that would happen at all.
> 
> Tabling it indefinitely would be unreasonable, and if we had actually 
> failed to reach consensus, then it would be appropriate to move on with 
> SCRAM/GS2.  However, what we actually have is an active discussion on a 
> single issue (or, perhaps, a pair of closely related issues) which at least 
> to me appears to be converging.  The fact that it has not done so yet does 
> not mean we have failed to reach consensus; it means the consensus is not 
> yet fully developed.

I have made a number of proposals, demonstrating my willingness to seek
a compromise that addresses Kurt's and others' needs.

I'm certain that we'll reach a consensus, either on a compromise, or, if
indeed we reach rough consensus on always using unique channel binding
types, then on Kurt's proposal to do that.

I strongly disagree with Kurt's characterization of the addition of
channel binding support via SCRAM/GS2 as not rising to the level of a
"new feature" for SASL that is disallowed by the WG's charter.  I also
don't consider the charter to be a material roadblock to SCRAM/GS2
making progress: we can always update the charter if we really have to.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RLeOCn087603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 14:40:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RLeOBi087602; Wed, 27 May 2009 14:40:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RLeNNf087596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 27 May 2009 14:40:24 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4RLeJFW004589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 17:40:20 -0400 (EDT)
Date: Wed, 27 May 2009 17:40:19 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation  (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Wednesday, May 27, 2009 10:31:41 PM +0100 Alexey Melnikov 
<[e-mail]> wrote:


> I don't believe it is.
> Firstly, this issue is largely orthogonal to SCRAM/GS2 design. Very
> little would change if we can reach consensus on channel binding
> negotiation.

I'm not sure that's true.  At least one of the approaches I could imagine 
would involve reopening some issues that have been a bit sticky in the 
past.  It is my strong preference to avoid going there, but it might happen 
anyway.


> Secondly, we failed to reach consensus on this issue so far. Asking to
> just table SCRAM/GS2 till we reach a consensus is not reasonable, because
> there is no guaranty that that would happen at all.

Tabling it indefinitely would be unreasonable, and if we had actually 
failed to reach consensus, then it would be appropriate to move on with 
SCRAM/GS2.  However, what we actually have is an active discussion on a 
single issue (or, perhaps, a pair of closely related issues) which at least 
to me appears to be converging.  The fact that it has not done so yet does 
not mean we have failed to reach consensus; it means the consensus is not 
yet fully developed.

> I've talked to Nico at length about this

So have I.

> and I think we have a proposal,
> or at least a set of alternatives that people should decide on. I will
> send it separately.

After which I will follow up your list of alternatives with a concrete 
proposal on which I hope we can build a consensus.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RLWLE7087121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 14:32:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RLWLSi087120; Wed, 27 May 2009 14:32:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RLWA5B087097 for <[e-mail]>; Wed, 27 May 2009 14:32:20 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.65.17] (92.40.65.17.sub.mbb.three.co.uk [92.40.65.17])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 27 May 2009 22:32:08 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 May 2009 22:31:41 +0100
From: Alexey Melnikov <[e-mail]>
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: Jeffrey Hutzelman <[e-mail]>
CC: [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation  (Re: Updated SASL And Channel Binding document (-03))
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeffrey,
I will reply to your technical comments separately.
Here I just comment on this:

Jeffrey Hutzelman wrote:

> While I appreciate your and Alexey's desire to finish these documents, 
> we still have an open issue which is likely to affect them, and so I 
> believe that a WGLC on either document is premature.

I don't believe it is.
Firstly, this issue is largely orthogonal to SCRAM/GS2 design. Very 
little would change if we can reach consensus on channel binding 
negotiation.

Secondly, we failed to reach consensus on this issue so far. Asking to 
just table SCRAM/GS2 till we reach a consensus is not reasonable, 
because there is no guaranty that that would happen at all.

> I know you believe that true negotiation is unnecessary and that 
> hardcoding behavior into individual mechanisms is OK, but several of 
> us do not share that view, and lacking a demonstrated consensus _on 
> that issue_, I do not believe it can be considered closed.  
> Particularly, I know there are other people who have not spoken up on 
> this issue, and so I do not believe that consensus can be accurately 
> read from the discussion so far.

I've talked to Nico at length about this and I think we have a proposal, 
or at least a set of alternatives that people should decide on. I will 
send it separately.
So, there is so hope of concluding this particular issue.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RL2NG1084392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 14:02:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RL2NwJ084391; Wed, 27 May 2009 14:02:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RL2MOH084385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 May 2009 14:02:22 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4RL2Fru012305; Wed, 27 May 2009 21:02:16 GMT (envelope-from [e-mail])
Cc: Nicolas Williams <[e-mail]>, Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Date: Wed, 27 May 2009 14:02:15 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 27, 2009, at 1:05 PM, Jeffrey Hutzelman wrote:

>
> NB: I hate SASL's use of the word "protocol" to mean "something  
> built on top of SASL", for which the word "application" would be  
> much more useful. One of the reasons I hate it is that it means that  
> about 50% of the audience gets confused when I use the word  
> "protocol" in its usual sense, as I do in this document.

The problem with "application" is that it often used, as Nico used it  
in this thread, to refer to a component of an implementation as  
opposed what's happening on wire within a particular layer of the  
protocol stack.  I much rather discuss things in terms of what's  
happening on the wire, and leave the details of what's going on in  
implementations to implementors.

>
>
> --On Wednesday, May 27, 2009 12:16:09 PM -0700 Kurt Zeilenga <[e-mail] 
> > wrote:
>
>> I note that this in no way precludes the SCRAM I-D and/or GS2 I-D  
>> from
>> being revised, if consensus so supports, to provide for different
>> negotiation scheme for variants of mechanisms, including possibly
>> variants utilizing different channel binding types.
>
> I've kept quiet until now, because I'm busy and really don't have  
> time for this.  However...
>
> (A) I believe that handling negotiation of channel binding types  
> separately
>   inside each mechanism is a major flaw, because it leads to a multi- 
> level
>   negotiation problem.

Yes, I believe this was part of the reason why the current SCRAM I-D  
uses different names to negotiate variants of the mechanism.

At present there are two variants, with and without channel bindings.   
My suggestion, if the WG decides to support multiple with channel  
binding variants, is to continue to use names to negotiate variants of  
the mechanism.  We just go from 2 to 3 variants for each hash variant.

>
> (B) I believe that supporting only one channel binding type per  
> mechanism,
>   or only one per (mechanism,channel type), is a major flaw, because  
> it
>   prevents switching CB types should one prove to be poorly-defined.


Isn't channel binding type agility so similar to hash algorithm  
agility that we can use a similar methods for dealing with this?

> For
>   example, if tls-unique had been defined to use a hash of the TLS  
> master
>   secret instead of the finished messages, it would need to be  
> discarded
>   and replaced, because the master secret does not name a unique  
> channel.

>
> (C) Separately, I believe that supporting only one CB type per  
> mechanism,
>   or only one per (mechanism,channel type), is a major flaw, because  
> it
>   is clear that there are situations in which endpoint CB will not  
> work,
>   and also situations in which unique CB will not work, and thus it  
> needs
>   to be possible to choose from among multiple CB types.

My concern with SCRAM was that it requires use of endpoint CBs in  
certain cases.

> (D) It is certainly possible to handle separately the issues of how  
> servers
>   can advertise which CB types they support and of how clients should
>   choose which CB types to use, and indeed given (A) I see no reason
>   to hold up SCRAM or GS2 until these have been handled.

Is it reasonable for a server to offer some CBs types only with some  
mechanisms?  Given that each channel binding type offers different  
security characteristics, and different mechanisms offer different  
security characteristics, are we so sure that a deployer may not  
reasonable wish to disable some combinations of channel binding types  
and mechanisms?

> HOWEVER, as
>   soon as it is possible to select among multiple channel binding  
> types,
>   it is necessary for the client to be able to inform the server of  
> which
>   type of channel bindings it is using.  That _DOES_ need to be  
> mechanism
>   specific, since SASL contains no mechanism-independent protocol bits
>   and thus no mechanism-independent way to carry this information.

Negotiation of CB types via mechanism name (e.g., SCRAM-SHA-1-EP v.  
SCRAM-SCRAM-1-U), I believe, informs the server of which CB type is  
used.

> This
>   means that carrying this information will require modifications to
>   SCRAM and to GS2.
>
> As a result of (D), I do not think that either SCRAM or GS2 is ready  
> for publication, as the protocols are incomplete.
>
>
> While I appreciate your and Alexey's desire to finish these  
> documents, we still have an open issue which is likely to affect  
> them, and so I believe that a WGLC on either document is premature.   
> I know you believe that true negotiation is unnecessary and that  
> hardcoding behavior into individual mechanisms is OK, but several of  
> us do not share that view, and lacking a demonstrated consensus _on  
> that issue_, I do not believe it can be considered closed.   
> Particularly, I know there are other people who have not spoken up  
> on this issue, and so I do not believe that consensus can be  
> accurately read from the discussion so far.

I encourage those all WG participants to express their opinions of  
relevancy to the SCRAM and GS2 I-Ds to express them before the end of  
the WGLCs on these I-Ds.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RK5QiT080107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 13:05:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RK5Q9o080106; Wed, 27 May 2009 13:05:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.201.117]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RK5EQY080091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 27 May 2009 13:05:25 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n4RK5831002489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 16:05:11 -0400 (EDT)
Date: Wed, 27 May 2009 16:05:08 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Kurt Zeilenga <[e-mail]>, Nicolas Williams <[e-mail]>
cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.117
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

NB: I hate SASL's use of the word "protocol" to mean "something built on 
top of SASL", for which the word "application" would be much more useful. 
One of the reasons I hate it is that it means that about 50% of the 
audience gets confused when I use the word "protocol" in its usual sense, 
as I do in this document.

--On Wednesday, May 27, 2009 12:16:09 PM -0700 Kurt Zeilenga 
<[e-mail]> wrote:

> I note that this in no way precludes the SCRAM I-D and/or GS2 I-D from
> being revised, if consensus so supports, to provide for different
> negotiation scheme for variants of mechanisms, including possibly
> variants utilizing different channel binding types.

I've kept quiet until now, because I'm busy and really don't have time for 
this.  However...

(A) I believe that handling negotiation of channel binding types separately
    inside each mechanism is a major flaw, because it leads to a multi-level
    negotiation problem.

(B) I believe that supporting only one channel binding type per mechanism,
    or only one per (mechanism,channel type), is a major flaw, because it
    prevents switching CB types should one prove to be poorly-defined.  For
    example, if tls-unique had been defined to use a hash of the TLS master
    secret instead of the finished messages, it would need to be discarded
    and replaced, because the master secret does not name a unique channel.

(C) Separately, I believe that supporting only one CB type per mechanism,
    or only one per (mechanism,channel type), is a major flaw, because it
    is clear that there are situations in which endpoint CB will not work,
    and also situations in which unique CB will not work, and thus it needs
    to be possible to choose from among multiple CB types.

(D) It is certainly possible to handle separately the issues of how servers
    can advertise which CB types they support and of how clients should
    choose which CB types to use, and indeed given (A) I see no reason
    to hold up SCRAM or GS2 until these have been handled.  HOWEVER, as
    soon as it is possible to select among multiple channel binding types,
    it is necessary for the client to be able to inform the server of which
    type of channel bindings it is using.  That _DOES_ need to be mechanism
    specific, since SASL contains no mechanism-independent protocol bits
    and thus no mechanism-independent way to carry this information.  This
    means that carrying this information will require modifications to
    SCRAM and to GS2.

As a result of (D), I do not think that either SCRAM or GS2 is ready for 
publication, as the protocols are incomplete.


While I appreciate your and Alexey's desire to finish these documents, we 
still have an open issue which is likely to affect them, and so I believe 
that a WGLC on either document is premature.  I know you believe that true 
negotiation is unnecessary and that hardcoding behavior into individual 
mechanisms is OK, but several of us do not share that view, and lacking a 
demonstrated consensus _on that issue_, I do not believe it can be 
considered closed.  Particularly, I know there are other people who have 
not spoken up on this issue, and so I do not believe that consensus can be 
accurately read from the discussion so far.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RJGEOd076598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 12:16:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RJGEOj076597; Wed, 27 May 2009 12:16:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RJGCsH076589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 May 2009 12:16:13 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4RJG9lm008932; Wed, 27 May 2009 19:16:10 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Date: Wed, 27 May 2009 12:16:09 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 27, 2009, at 9:50 AM, Nicolas Williams wrote:

>
> On Tue, May 26, 2009 at 04:14:37PM -0500, Nicolas Williams wrote:
>> And we can even harmonize (1) and (2a):
>
> I.e., optional channel binding type negotiation, with N+M mech names
> instead of N*M, and with whatever default the WG prefers best (e.g.,
> tls-unique).
>
> WG chairs: is there any intention to start a formal call for consensus
> on this issue?  It can run concurrently with the WGLC if you want, but
> we definitely need to establish consensus on this issue.

My intention is to conduct the SCRAM WGLC (which I just initiated) and  
then, in a week or so, initiate a WGLC on the GS2 I-D.

I don't intend at this time to initiate a WG LC on greater issues,  
such as those requiring "new features" to be added to SASL  
[RFC4422].   I consider mechanism independent channel binding type  
negotiation schemes to be a new SASL feature.

To the extent there are greater issues that you or others believe need  
to be addressed in order for SCRAM or GS2 to be published, these  
issues can certainly be discussed before and during the above WG LCs.   
However, I do intend to move forward under the assumption that  
consensus generally supports publishing SCRAM and GS2 independently of  
any SASL "new features" development.  I make this assumption based  
upon our WG charter which specifically disallows the WG for taking on  
"new feature" development while chartering us to take on SCRAM and GS2  
mechanism work.  These WGLC will, amongst other things, test this  
assumption.

I note that this in no way precludes the SCRAM I-D and/or GS2 I-D from  
being revised, if consensus so supports, to provide for different  
negotiation scheme for variants of mechanisms, including possibly  
variants utilizing different channel binding types.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RIx2e0075141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 11:59:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RIx2ja075140; Wed, 27 May 2009 11:59:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RIx1Cw075133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 May 2009 11:59:01 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4RIwwnD008400; Wed, 27 May 2009 18:58:58 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Date: Wed, 27 May 2009 11:58:58 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 27, 2009, at 11:48 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
>
>> This message initiates a SASL WG Last Call on the Internet-Draft:
>>
>>>    Title           : Salted Challenge Response (SCRAM) SASL  
>>> Mechanism
>>>    Author(s)       : A. Menon-Sen, et al.
>>>    Filename        : draft-ietf-sasl-scram-01.txt
>>>    Pages           : 33
>>>    Date            : 2009-05-26
>>
>> The purpose of this WG Last Call is to ensure that the Working  
>> Group  has achieved consensus that the document is suitable for  
>> publication  on the Standards Track.
>
> Thanks!
>
>> Please review the document for both technical and editorial  
>> problems.  Technical issues should be discussed on this list.  
>> Editorial issues  may be sent to the document editor.
>> The Last Call period will close on Friday, 12 June 2008.
>> Upon completion of the last call, the WG chair(s) will take action   
>> based upon the consensus of the WG. Possible actions include:
>> 1) recommending to the IETF Applications Area Directors
>
> We like that :-).

s/Applications/Security/  (missed an edit after cut-n-pasting from a  
prior (LDAPBIS) WGLC message)

>
>
>> that the  document, after possible editorial or other minor  
>> changes, be  considered by the IESG for publication as a Standard  
>> Track RFC (which  generally involves an IETF-wide Last Call); or
>> 2) requiring that outstanding issues be adequately addressed prior  
>> to  further action (including, possibly, another WG Last Call).
>> Remember that it is our responsibility as Working Group members to   
>> ensure the quality of our documents and of the Internet Standards   
>> process.  So, please read and comment!
>> Kurt Zeilenga, SASL WG co-chair
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RInYjI074620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 11:49:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RInY42074619; Wed, 27 May 2009 11:49:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RInXT9074613 for <[e-mail]>; Wed, 27 May 2009 11:49:34 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.199] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 27 May 2009 19:49:32 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 May 2009 19:48:51 +0100
From: Alexey Melnikov <[e-mail]>
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: Kurt Zeilenga <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

> This message initiates a SASL WG Last Call on the Internet-Draft:
>
>>     Title           : Salted Challenge Response (SCRAM) SASL Mechanism
>>     Author(s)       : A. Menon-Sen, et al.
>>     Filename        : draft-ietf-sasl-scram-01.txt
>>     Pages           : 33
>>     Date            : 2009-05-26
>
> The purpose of this WG Last Call is to ensure that the Working Group  
> has achieved consensus that the document is suitable for publication  
> on the Standards Track.

Thanks!

> Please review the document for both technical and editorial problems.  
> Technical issues should be discussed on this list. Editorial issues  
> may be sent to the document editor.
> The Last Call period will close on Friday, 12 June 2008.
> Upon completion of the last call, the WG chair(s) will take action  
> based upon the consensus of the WG. Possible actions include:
> 1) recommending to the IETF Applications Area Directors

We like that :-).

> that the  document, after possible editorial or other minor changes, 
> be  considered by the IESG for publication as a Standard Track RFC 
> (which  generally involves an IETF-wide Last Call); or
> 2) requiring that outstanding issues be adequately addressed prior to  
> further action (including, possibly, another WG Last Call).
> Remember that it is our responsibility as Working Group members to  
> ensure the quality of our documents and of the Internet Standards  
> process.  So, please read and comment!
> Kurt Zeilenga, SASL WG co-chair




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RIeV6l074200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 11:40:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RIeVrc074199; Wed, 27 May 2009 11:40:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RIeK1a074174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 27 May 2009 11:40:31 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4RIeHq0004533 for <[e-mail]>; Wed, 27 May 2009 18:40:18 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: WG Last Call: draft-ietf-sasl-scram-01.txt 
Date: Wed, 27 May 2009 11:40:16 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message initiates a SASL WG Last Call on the Internet-Draft:

> 	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
> 	Author(s)       : A. Menon-Sen, et al.
> 	Filename        : draft-ietf-sasl-scram-01.txt
> 	Pages           : 33
> 	Date            : 2009-05-26


The purpose of this WG Last Call is to ensure that the Working Group  
has achieved consensus that the document is suitable for publication  
on the Standards Track.
Please review the document for both technical and editorial problems.  
Technical issues should be discussed on this list. Editorial issues  
may be sent to the document editor.
The Last Call period will close on Friday, 12 June 2008.
Upon completion of the last call, the WG chair(s) will take action  
based upon the consensus of the WG. Possible actions include:
1) recommending to the IETF Applications Area Directors that the  
document, after possible editorial or other minor changes, be  
considered by the IESG for publication as a Standard Track RFC (which  
generally involves an IETF-wide Last Call); or
2) requiring that outstanding issues be adequately addressed prior to  
further action (including, possibly, another WG Last Call).
Remember that it is our responsibility as Working Group members to  
ensure the quality of our documents and of the Internet Standards  
process.  So, please read and comment!
Kurt Zeilenga, SASL WG co-chair



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RH0Ngq065441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 10:00:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RH0NTO065440; Wed, 27 May 2009 10:00:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RH0NPN065433 for <[e-mail]>; Wed, 27 May 2009 10:00:23 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RH0M6x023590 for <[e-mail]>; Wed, 27 May 2009 17:00:23 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RH0M3R035397 for <[e-mail]>; Wed, 27 May 2009 11:00:22 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RGoWbn014124; Wed, 27 May 2009 11:50:32 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RGoWLb014123; Wed, 27 May 2009 11:50:32 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 11:50:32 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 04:14:37PM -0500, Nicolas Williams wrote:
> And we can even harmonize (1) and (2a):

I.e., optional channel binding type negotiation, with N+M mech names
instead of N*M, and with whatever default the WG prefers best (e.g.,
tls-unique).

WG chairs: is there any intention to start a formal call for consensus
on this issue?  It can run concurrently with the WGLC if you want, but
we definitely need to establish consensus on this issue.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RG5xkt060507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 09:05:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RG5xrj060506; Wed, 27 May 2009 09:05:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RG5mmF060494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Wed, 27 May 2009 09:05:59 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4RG5mv3011370 for <[e-mail]>; Wed, 27 May 2009 16:05:48 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RG5mZH057583 for <[e-mail]>; Wed, 27 May 2009 10:05:48 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RFtwH5014096; Wed, 27 May 2009 10:55:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RFtv6w014095; Wed, 27 May 2009 10:55:57 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 10:55:57 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 27, 2009 at 04:55:14PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Are you asking that we submit an I-D to put channel binding type
> >registrations on the Standards-Track?
> >
> Somebody should have done this before. But now that they are registered, 
> I don't care. As long as the definitions are stable.
> 
> >I have no problem with that, but
> >I find it odd that on the one hand you guys want to rush SCRAM/GS2
> >through without updating SASL, yet now would have SCRAM/GS2 block on a
> >new set of work.
> > 
> >
> See above.

I definitely don't mind producing an update to RFC5056 and turning the
existing registrations into RFCs, if that's the IETF consensus (or even
just this WG's).  I could use a co-author/editor.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFu0vY059322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:56:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RFu039059321; Wed, 27 May 2009 08:56:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFtnhM059301 for <[e-mail]>; Wed, 27 May 2009 08:56:00 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.199] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 27 May 2009 16:55:48 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 May 2009 16:55:14 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>Are you asking that we submit an I-D to put channel binding type
>registrations on the Standards-Track?
>
Somebody should have done this before. But now that they are registered, 
I don't care. As long as the definitions are stable.

>I have no problem with that, but
>I find it odd that on the one hand you guys want to rush SCRAM/GS2
>through without updating SASL, yet now would have SCRAM/GS2 block on a
>new set of work.
>  
>
See above.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFk1Bj058486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:46:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RFk1ZT058485; Wed, 27 May 2009 08:46:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFjooF058468 for <[e-mail]>; Wed, 27 May 2009 08:46:00 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RFjnwT011648 for <[e-mail]>; Wed, 27 May 2009 15:45:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RFjnJZ040983 for <[e-mail]>; Wed, 27 May 2009 09:45:49 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RFZxHS014078; Wed, 27 May 2009 10:35:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RFZxAB014077; Wed, 27 May 2009 10:35:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 10:35:59 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 27, 2009 at 07:08:42AM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > I don't see how it's more efficient.  Neither having the app provide the
> > bindings up front nor having it respond to a callback request for
> > bindings makes a difference in terms of protocol round-trips, for
> > example.  It might make a difference in terms of whether the channel has
> > to compute just one or several bindings, but I doubt it: a single
> > additional SHA-256 computation over a cert will be in the noise when
> > compared to all the other computations (certificate validation, RSA
> > encryption, record message cipher/mac application, ...).
> 
> I was thinking of implementing channel bindings to IPSEC layers.
> Getting that channel binding data may be expensive, as it likely will
> involve talking to other processes.

It may well involve IPC, but that is still very likely to be in the
noise compared to all the crypto you need to setup and use SAs.

> >> Updating RFC 4422 will certainly take time, so I prefer to not let
> >> SCRAM/GS2 wait on that happening.  I think also using that time to
> >> collect implementation experience with SCRAM/GS2 will be valuable.
> >
> > I don't care that much.  But I do want to give proper guidance to
> > implementors of SCRAM/GS2 given that we know about YAP _now_.  I think
> > it would be irresponsible of us to do otherwise.
> 
> Certainly.  The devil is in the details.

So why insist on rushing SCRAM/GS2 through?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFhumY058265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:43:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RFhu38058264; Wed, 27 May 2009 08:43:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFhjTN058246 for <[e-mail]>; Wed, 27 May 2009 08:43:55 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RFhikK010293 for <[e-mail]>; Wed, 27 May 2009 15:43:44 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RFhi2Y038983 for <[e-mail]>; Wed, 27 May 2009 09:43:44 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RFXspQ014070; Wed, 27 May 2009 10:33:54 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RFXsPW014069; Wed, 27 May 2009 10:33:54 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 10:33:54 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Are you asking that we submit an I-D to put channel binding type
registrations on the Standards-Track?  I have no problem with that, but
I find it odd that on the one hand you guys want to rush SCRAM/GS2
through without updating SASL, yet now would have SCRAM/GS2 block on a
new set of work.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFgOwi058108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 08:42:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RFgOSl058107; Wed, 27 May 2009 08:42:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RFgD2X058084 for <[e-mail]>; Wed, 27 May 2009 08:42:23 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4RFg7El010885 for <[e-mail]>; Wed, 27 May 2009 15:42:13 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4RFg7Hh037962 for <[e-mail]>; Wed, 27 May 2009 09:42:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4RFWFrt014064; Wed, 27 May 2009 10:32:15 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4RFWEXO014063; Wed, 27 May 2009 10:32:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Wed, 27 May 2009 10:32:14 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, May 27, 2009 at 07:04:57AM +0200, Simon Josefsson wrote:
> The RFC 5056 rules isn't the problem here, as far as I can see.  The
> particular channel binding registrations are the problem.  As far as I
> can tell the problems are:
> 
> 1) tls-server-end-point is under-specified and assumes PKIX without
> stating so, and without any reference to PKIX documents.

There's enough there to implement.

> 2) Both tls-server-end-point and tls-unique is not under IETF/IESG's
> change control.

I don't care one way or the other.  I care about stability, which the
rules for updating registrations are good enough for.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RARFxD023846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 03:27:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4RARF94023845; Wed, 27 May 2009 03:27:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4RAR3sm023830 for <[e-mail]>; Wed, 27 May 2009 03:27:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.149] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 27 May 2009 11:27:02 +0100
Message-ID: <[e-mail]>
Date: Wed, 27 May 2009 11:26:29 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>, Nicolas Williams <[e-mail]>
CC: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Nicolas Williams <[e-mail]> writes:
>  
>
>>>I'm slightly worried that channel binding definitions can be changed
>>>after initial definition though, it kind of defeats the purpose of
>>>having a normative reference to them.
>>>      
>>>
>>Perhaps we should revise RFC5056 to change the rules for channel binding
>>type registration and updates (though I don't think we need to).  That,
>>however, is not what this thread is about, and it's not necessary to
>>progress SCRAM/GS2.
>>    
>>
>I don't think having standards track protocols like SCRAM/GS2 reference
>a channel binding type that isn't under the IESG's change control is a
>good idea.
>  
>
Agreed.

>The RFC 5056 rules isn't the problem here, as far as I can see.  The
>particular channel binding registrations are the problem.  As far as I
>can tell the problems are:
>
>1) tls-server-end-point is under-specified and assumes PKIX without
>stating so, and without any reference to PKIX documents.
>  
>
Agreed.
I think clarifying/extending it before we start deploying 
tls-server-end-point would be a good thing.

>2) Both tls-server-end-point and tls-unique is not under IETF/IESG's
>change control.
>  
>
Indeed this is a problem. We certainly don't want for Microsoft (or any 
other company) to be in control of these.
I think this issue needs to be sorted out, but this is not a topic for 
this mailing list. I will talk to Security ADs about that.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4R58lp4099163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 22:08:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4R58lQi099162; Tue, 26 May 2009 22:08:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4R58i0F099155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 22:08:46 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4R58gKh001863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2009 07:08:43 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090527:[e-mail]::tr7/zrB9YNWJwYO5:0tCi
X-Hashcash: 1:22:090527:[e-mail]::BOVT32zfaFDxsfnb:3Mrc
X-Hashcash: 1:22:090527:[e-mail]::qKVrE340QBVMUrlp:RwgJ
Date: Wed, 27 May 2009 07:08:42 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 15:36:26 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, May 26, 2009 at 09:40:28PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > So we can leave implementors to make a mistake that will cause trouble
>> > later on when YAP progresses?  We know what guidance to give: have the
>> > app provide all available channel bindings and let the framework or the
>> > mechanism pick one type.
>> 
>> That isn't the only way to implement it: the mechanism could ask the app
>> for the channel binding types it needs.  That seems more efficient, and
>
> That's equivalent, in my world view, to what I wrote.

Ok, that's good, and wasn't clear to me before.

>> I suspect (not having started implementation yet) that it will fit
>> better with how my implementation is designed.  I'm not convinced we
>> need to mandate a particular implementation approach.
>
> I don't see how it's more efficient.  Neither having the app provide the
> bindings up front nor having it respond to a callback request for
> bindings makes a difference in terms of protocol round-trips, for
> example.  It might make a difference in terms of whether the channel has
> to compute just one or several bindings, but I doubt it: a single
> additional SHA-256 computation over a cert will be in the noise when
> compared to all the other computations (certificate validation, RSA
> encryption, record message cipher/mac application, ...).

I was thinking of implementing channel bindings to IPSEC layers.
Getting that channel binding data may be expensive, as it likely will
involve talking to other processes.

>> > Not giving guidance when we know what guidance to give seems like
>> > asking for trouble.  I understand that updating RFC4422 will take some
>> > time, so perhaps we ought to have some text in SCRAM/GS2 about this,
>> > noting that a more complete SASL treatment of channel binding is a
>> > work in progress.
>> 
>> Updating RFC 4422 will certainly take time, so I prefer to not let
>> SCRAM/GS2 wait on that happening.  I think also using that time to
>> collect implementation experience with SCRAM/GS2 will be valuable.
>
> I don't care that much.  But I do want to give proper guidance to
> implementors of SCRAM/GS2 given that we know about YAP _now_.  I think
> it would be irresponsible of us to do otherwise.

Certainly.  The devil is in the details.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4R55Di0099035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 22:05:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4R55DBR099034; Tue, 26 May 2009 22:05:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4R551Mh099023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 22:05:12 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4R54uW8001811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2009 07:04:59 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090527:[e-mail]::3egNiKoWTGMIAG5d:4Svk
X-Hashcash: 1:22:090527:[e-mail]::r09MtZj344xMZdEU:9pNk
X-Hashcash: 1:22:090527:[e-mail]::+++2bAdoajVqe6F7:J3UL
Date: Wed, 27 May 2009 07:04:57 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 15:31:01 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

>> I'm slightly worried that channel binding definitions can be changed
>> after initial definition though, it kind of defeats the purpose of
>> having a normative reference to them.
>
> Perhaps we should revise RFC5056 to change the rules for channel binding
> type registration and updates (though I don't think we need to).  That,
> however, is not what this thread is about, and it's not necessary to
> progress SCRAM/GS2.

I don't think having standards track protocols like SCRAM/GS2 reference
a channel binding type that isn't under the IESG's change control is a
good idea.

The RFC 5056 rules isn't the problem here, as far as I can see.  The
particular channel binding registrations are the problem.  As far as I
can tell the problems are:

1) tls-server-end-point is under-specified and assumes PKIX without
stating so, and without any reference to PKIX documents.

2) Both tls-server-end-point and tls-unique is not under IETF/IESG's
change control.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QMK4GA075616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 15:20:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QMK4nc075615; Tue, 26 May 2009 15:20:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QMJrWM075585 for <[e-mail]>; Tue, 26 May 2009 15:20:03 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QMJqSD004374 for <[e-mail]>; Tue, 26 May 2009 22:19:52 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QMJqrX016968 for <[e-mail]>; Tue, 26 May 2009 16:19:52 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QM9x8f013504; Tue, 26 May 2009 17:09:59 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QM9xXP013503; Tue, 26 May 2009 17:09:59 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 17:09:59 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 10:59:40PM +0100, Alexey Melnikov wrote:
> In the effort of getting SCRAM published sooner, I am not going to argue 
> this point for much longer.

Well, I think we need to resolve the issue, one way or another, before
SCRAM can progress.  See also my follow-up with subject line "Request
for consensus call on channel binding type negotiation".

> Nicolas Williams wrote:
> >On Tue, May 26, 2009 at 09:44:13PM +0200, Simon Josefsson wrote:
> >>My preference is also the unique channel binding.
> >>   
> >>
> For the record - so is mine.

It used to be mine as well.  Microsoft engineers and Chris Newman
changed my mind on that (see below).

> >It won't work when using TLS concentrators.  Therefore a preference for
> >tls-unique bindings is a recipe for non-interoperability.
> >
> I am not convinced that is going to be the case. When answering this 
> question people are assuming that TLS concentrator case is going to be 
> more or less widespread that the case of TLS-used-without-X.509.

Seriously?  I've not used many non-web services that use TLS outside of
corporate environments, and in those the norm is to use a server cert.
Moreover, when the deployer doesn't know how to find and follow proper
procedures to obtain a suitable server certificate, the deployer almost
always uses a self-signed cert rather than configure the service to not
use x.509 at all.  Of course, in the case of self-signed certs there's
not likely to be any concentrators, but in the other cases I've
certainly seen concentrators.  Sun's internal IMAP service, for example,
uses TLS concentrators, and it uses server certs.

> >Therefore I reject it.
> >
> You might end up being in the rough part of the consensus.

Perhaps so.

> If you have some numbers that can persuade people that your TLS 
> concentrator case is more widespread than TLS-used-without-X.509, then 
> you might be able to change my mind. But so far I am not convinced.

I use services where TLS concentrators are used.

Also, Chris Newman supports a messaging product which is designed to
separate TLS (and, separately, SASL) from other parts of the
implementation.  Treating such implementations as equivalent to using
concentrators is the simplest way to add support for channel binding,
and IIRC Chris has stated that that's his preferred approach.

Microsoft engineers too felt that support for environments where TLS
concentrators are used was crucial.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QM0nli074329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 15:00:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QM0no7074328; Tue, 26 May 2009 15:00:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QM0l68074321 for <[e-mail]>; Tue, 26 May 2009 15:00:48 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.117] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 26 May 2009 23:00:46 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 May 2009 22:59:40 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, Kurt Zeilenga <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nico,
In the effort of getting SCRAM published sooner, I am not going to argue 
this point for much longer.

Nicolas Williams wrote:

>On Tue, May 26, 2009 at 09:44:13PM +0200, Simon Josefsson wrote:
>  
>
>>Kurt Zeilenga <[e-mail]> writes:
>>    
>>
>>>On May 25, 2009, at 11:14 AM, Nicolas Williams wrote:
>>>      
>>>
>>>>I'm more than happy to leave SCRAM and GS2 as they are, which
>>>>effectively means that we punt on channel binding type negotiation,
>>>>leaving us with a preference for end-point channel binding types over
>>>>unique ones.
>>>>        
>>>>
>>>Generally and with respect to SCRAM, I rather change the specification
>>>to always require the use of unique channel bindings.  I do understand
>>>however that some prefer use of end-point channel binding types in
>>>certain cases.
>>>      
>>>
>>My preference is also the unique channel binding.
>>    
>>
For the record - so is mine.

>It won't work when using TLS concentrators.  Therefore a preference for
>tls-unique bindings is a recipe for non-interoperability.
>
I am not convinced that is going to be the case. When answering this 
question people are assuming that TLS concentrator case is going to be 
more or less widespread that the case of TLS-used-without-X.509.

>Therefore I reject it.
>  
>
You might end up being in the rough part of the consensus.

If you have some numbers that can persuade people that your TLS 
concentrator case is more widespread than TLS-used-without-X.509, then 
you might be able to change my mind. But so far I am not convinced.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QLOd1s072006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 14:24:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QLOdvx072005; Tue, 26 May 2009 14:24:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QLOR29071987 for <[e-mail]>; Tue, 26 May 2009 14:24:38 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QLOR5a021283 for <[e-mail]>; Tue, 26 May 2009 21:24:27 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QLORIi046070 for <[e-mail]>; Tue, 26 May 2009 15:24:27 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QLEbRH011961; Tue, 26 May 2009 16:14:37 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QLEbUA011960; Tue, 26 May 2009 16:14:37 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 16:14:37 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 03:38:00PM -0500, Nicolas Williams wrote:
> On Tue, May 26, 2009 at 09:44:13PM +0200, Simon Josefsson wrote:
> > Kurt Zeilenga <[e-mail]> writes:
> > > Generally and with respect to SCRAM, I rather change the specification
> > > to always require the use of unique channel bindings.  I do understand
> > > however that some prefer use of end-point channel binding types in
> > > certain cases.
> > 
> > My preference is also the unique channel binding.
> 
> It won't work when using TLS concentrators.  Therefore a preference for
> tls-unique bindings is a recipe for non-interoperability.  Therefore I
> reject it.

Perhaps we need a consensus call on how to address the issue of channel
binding type negotiation.  We have _two_ proposals currently:

1) Let the application furnish all available channel bindings for the
   channel to be bound, and let the framework or mechanism pick one
   based on mechanism-specific rules.  (Note that the app could furnish
   the CBs via callbacks from the framework/mech -- that's not a
   material detail here.)

   That's my proposal.  SCRAM/GS2 would have a preference for end-point
   bindings.  YAP would have a requirement to use unique bindings.


2) Negotiate channel binding types via overloading the mechanism name
   negotiation further.

   That's Kurt's proposal.

   There could be two sub-proposals here:

   a) use an affix to mechanism names (e.g., offer "SCRAM1-EP, SCRAM1-U,
      YAP, ...")

      vs.

   b) use cb type names standalone in the server mech list to indicate
      what channel binding types the server supports (e.g., offer
      "SCRAM1-PLUS, YAP, ..., TLS-EP, TLS-UNIQUE").

I think we need a consensus call on this issue.  I strongly recommend
that the chairs call for one.

My objection to Kurt's proposal ((2a)) is that the namespace of channel
binding types is open, therefore we'd end up with N * (M+1) SASL
mechanism names, where N is the number of actual mechanisms and M is the
number of channel binding types.  And each new cb type would require
registering new SASL mechanism names for all mechanisms that support
channel binding.  Whereas with (2a) we would need only N + 1 + M SASL
mechanism names.  (In both cases the '1' comes from the need for a name
denoting no CB support.)

Therefore, if we really must negotiate channel binding types then I much
prefer (2b) over (2a).

And we can even harmonize (1) and (2a):

 - If the server offers SASL mechanism names that denote channel binding
   support, but the server does not offer specific channel binding
   types, then the client must do (1).

 - If the server offers SASL mechanism names that denote channel binding
   support and it offers specific channel binding types, then the client
   must do (2a): choose a mechanism and channel binding type from the
   server's list, and constrained by each mechanism's requirement/
   non-requirement for unique channel binding types.

   An algorithm for mechanism/CB type selection in the (2a) case would
   be:

    server_mechs = server_mech_list->filter(is_real_mechanism)
    server_cb_types = server_mech_list->filter(is_channel_binding_type)

    for mech in client_mechs {
	for cbtype in client_cbtypes {
	    if (!mech->supports_cbtype(cbtype))
		continue
	    if (!server_mechs->is_present(mech) ||
		!server_cb_types->is_present(cbtype) ||
		!app_cb_types->is_present(cbtype))
		continue
	    negotiated_mech = mech
	    negotiated_cbtype = cbtype
	    break
	}
    }

   The above algorithm uses a client-side preference order.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QL0o5A070388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 14:00:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QL0oZv070387; Tue, 26 May 2009 14:00:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QL0dvn070375 for <[e-mail]>; Tue, 26 May 2009 14:00:50 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.117] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 26 May 2009 22:00:38 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 May 2009 21:59:32 +0100
From: Alexey Melnikov <[e-mail]>
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: [e-mail]
CC: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-sasl-scram-01.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>
>	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
>	Author(s)       : A. Menon-Sen, et al.
>	Filename        : draft-ietf-sasl-scram-01.txt
>	Pages           : 33
>	Date            : 2009-05-26
>  
>
This version clearly states that hashes are fake. I believe channel 
binding data to be correct now.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKlokU069487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 13:47:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QKlo2u069486; Tue, 26 May 2009 13:47:50 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKloWx069480 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 May 2009 13:47:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QKloeI009269 for <[e-mail]>; Tue, 26 May 2009 20:47:50 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QKlnNM020553 for <[e-mail]>; Tue, 26 May 2009 14:47:49 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QKc06o011565; Tue, 26 May 2009 15:38:00 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QKc0gC011564; Tue, 26 May 2009 15:38:00 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 15:38:00 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Kurt Zeilenga <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 09:44:13PM +0200, Simon Josefsson wrote:
> Kurt Zeilenga <[e-mail]> writes:
> 
> > On May 25, 2009, at 11:14 AM, Nicolas Williams wrote:
> >> I'm more than happy to leave SCRAM and GS2 as they are, which
> >> effectively means that we punt on channel binding type negotiation,
> >> leaving us with a preference for end-point channel binding types over
> >> unique ones.
> >
> >
> > Generally and with respect to SCRAM, I rather change the specification
> > to always require the use of unique channel bindings.  I do understand
> > however that some prefer use of end-point channel binding types in
> > certain cases.
> 
> My preference is also the unique channel binding.

It won't work when using TLS concentrators.  Therefore a preference for
tls-unique bindings is a recipe for non-interoperability.  Therefore I
reject it.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKkRss069404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 13:46:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QKkRpw069403; Tue, 26 May 2009 13:46:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKkGDw069385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 May 2009 13:46:26 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QKkGE0008840 for <[e-mail]>; Tue, 26 May 2009 20:46:16 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QKkFDA019565 for <[e-mail]>; Tue, 26 May 2009 14:46:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QKaQmF011558; Tue, 26 May 2009 15:36:26 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QKaQAd011557; Tue, 26 May 2009 15:36:26 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 15:36:26 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 09:40:28PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > So we can leave implementors to make a mistake that will cause trouble
> > later on when YAP progresses?  We know what guidance to give: have the
> > app provide all available channel bindings and let the framework or the
> > mechanism pick one type.
> 
> That isn't the only way to implement it: the mechanism could ask the app
> for the channel binding types it needs.  That seems more efficient, and

That's equivalent, in my world view, to what I wrote.

> I suspect (not having started implementation yet) that it will fit
> better with how my implementation is designed.  I'm not convinced we
> need to mandate a particular implementation approach.

I don't see how it's more efficient.  Neither having the app provide the
bindings up front nor having it respond to a callback request for
bindings makes a difference in terms of protocol round-trips, for
example.  It might make a difference in terms of whether the channel has
to compute just one or several bindings, but I doubt it: a single
additional SHA-256 computation over a cert will be in the noise when
compared to all the other computations (certificate validation, RSA
encryption, record message cipher/mac application, ...).

> > Not giving guidance when we know what guidance to give seems like
> > asking for trouble.  I understand that updating RFC4422 will take some
> > time, so perhaps we ought to have some text in SCRAM/GS2 about this,
> > noting that a more complete SASL treatment of channel binding is a
> > work in progress.
> 
> Updating RFC 4422 will certainly take time, so I prefer to not let
> SCRAM/GS2 wait on that happening.  I think also using that time to
> collect implementation experience with SCRAM/GS2 will be valuable.

I don't care that much.  But I do want to give proper guidance to
implementors of SCRAM/GS2 given that we know about YAP _now_.  I think
it would be irresponsible of us to do otherwise.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKf2ah069059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 13:41:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QKf2rn069058; Tue, 26 May 2009 13:41:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QKeqLZ069039 for <[e-mail]>; Tue, 26 May 2009 13:41:02 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QKepF0028482 for <[e-mail]>; Tue, 26 May 2009 20:40:51 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QKepka015720 for <[e-mail]>; Tue, 26 May 2009 14:40:51 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QKV2wK011549; Tue, 26 May 2009 15:31:02 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QKV1q5011548; Tue, 26 May 2009 15:31:01 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 15:31:01 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 09:30:30PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
> >> Nicolas Williams <[e-mail]> writes:
> >> > I still don't see the need to say anything at all about x.509.  How
> >> > about:
> >> >
> >> >    If an external TLS channel is to be bound into the GS2
> >> >    authentication, and if the channel supports channel bindings of type
> >> >    'tls-server-end-point', then those MUST be used, else if the channel
> >> >    supports channel bindings of type 'tls-unique' type, then those MUST
> >> >    be used.
> >> 
> >> That works for me, but it seems to me to have the same meaning in
> >> practice because tls-server-end-point is only well defined for X.509.
> >
> > Indirection helps: we can update tls-server-end-point to support
> > OpenPGP, but if we do then we'd leave SCRAM/GS2 broken if they were to
> > bake in knowledge of tls-server-end-point's specification.
> 
> That would be good.
> 
> I'm slightly worried that channel binding definitions can be changed
> after initial definition though, it kind of defeats the purpose of
> having a normative reference to them.

Perhaps we should revise RFC5056 to change the rules for channel binding
type registration and updates (though I don't think we need to).  That,
however, is not what this thread is about, and it's not necessary to
progress SCRAM/GS2.

I'd be happy to discuss updates to RFC5056 on a different list.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QK1i7A066113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 13:01:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QK1ilU066112; Tue, 26 May 2009 13:01:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QK1h1M066106 for <[e-mail]>; Tue, 26 May 2009 13:01:44 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 5D83A3A70E9; Tue, 26 May 2009 13:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-scram-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 26 May 2009 13:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-01.txt
	Pages           : 33
	Date            : 2009-05-26

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.

This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements.  When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-scram-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJiJZZ064914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:44:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QJiJko064913; Tue, 26 May 2009 12:44:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJiGbs064904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 12:44:18 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QJiDwU021251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 21:44:15 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::6CQOmk8B334jWjr4:1V9B
X-Hashcash: 1:22:090526:[e-mail]::edERb40NTQ+ZggPD:5oQN
X-Hashcash: 1:22:090526:[e-mail]::+TXjBI4+Ekoe2LUh:6LOT
X-Hashcash: 1:22:090526:[e-mail]::GnxDwXDER81StKr3:Ano2
Date: Tue, 26 May 2009 21:44:13 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 26 May 2009 09:48:08 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On May 25, 2009, at 11:14 AM, Nicolas Williams wrote:
>> I'm more than happy to leave SCRAM and GS2 as they are, which
>> effectively means that we punt on channel binding type negotiation,
>> leaving us with a preference for end-point channel binding types over
>> unique ones.
>
>
> Generally and with respect to SCRAM, I rather change the specification
> to always require the use of unique channel bindings.  I do understand
> however that some prefer use of end-point channel binding types in
> certain cases.

My preference is also the unique channel binding.

> One solution for SCRAM is to offer:
> 	SCRAM-SHA-1
> 	SCRAM-SHA-1-ENDPOINT
> 	SCRAM-SHA-1-UNIQUE

FWIW, I prefer that to the current approach.  This variant allows
implementers to chose which channel binding type to support.  The
*-UNIQUE variant needs to be the mandatory to implement because it is
the only with general applicability.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJeZc0064455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:40:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QJeZtN064454; Tue, 26 May 2009 12:40:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJeW3r064447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 12:40:34 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QJeShu021130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 21:40:30 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::Lz/SN//WwpfTAy3X:9lk
X-Hashcash: 1:22:090526:[e-mail]::t2agu9W5qT2SQsgi:2RLf
X-Hashcash: 1:22:090526:[e-mail]::pYTeeiHZ402peb69:5/3/
Date: Tue, 26 May 2009 21:40:28 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 11:33:01 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, May 26, 2009 at 06:19:47PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > The channel binding type negotiation must happen somewhere, and it so
>> > happens that SCRAM/GS2 will not specify what component of SASL (the app,
>> > the framework or the mechanism) will do it, but it will specify a rule
>> > for selecting channel binding type.  An implementor could make the app
>> > apply that rule, or the framework, or the mechanism -- and still comply
>> > with SCRAM/GS2.  Making the app choose will make it harder to later
>> > implement Kurt's YAP mechanism in that framework.
>> >
>> > Therefore guidance is needed.  At the very least the guidance should be
>> > that framework implementors should not leave the choice to applications.
>> > But if the WG consensus is that we don't need to update RFC4422, that's
>> > fine with me -- the sooner we finish SCRAM/GS2, the better.
>> 
>> Agreed.  And I think it is too early to mandate a particular
>> implementation approach.
>
> So we can leave implementors to make a mistake that will cause trouble
> later on when YAP progresses?  We know what guidance to give: have the
> app provide all available channel bindings and let the framework or the
> mechanism pick one type.

That isn't the only way to implement it: the mechanism could ask the app
for the channel binding types it needs.  That seems more efficient, and
I suspect (not having started implementation yet) that it will fit
better with how my implementation is designed.  I'm not convinced we
need to mandate a particular implementation approach.

> Not giving guidance when we know what guidance to give seems like
> asking for trouble.  I understand that updating RFC4422 will take some
> time, so perhaps we ought to have some text in SCRAM/GS2 about this,
> noting that a more complete SASL treatment of channel binding is a
> work in progress.

Updating RFC 4422 will certainly take time, so I prefer to not let
SCRAM/GS2 wait on that happening.  I think also using that time to
collect implementation experience with SCRAM/GS2 will be valuable.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJXhX0064091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:33:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QJXh2d064090; Tue, 26 May 2009 12:33:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJXgfV064083 for <[e-mail]>; Tue, 26 May 2009 12:33:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.117] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 26 May 2009 20:33:40 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 May 2009 20:32:41 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Nicolas Williams <[e-mail]> writes:
>
>  
>
>>On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>>    
>>
>>>Nicolas Williams <[e-mail]> writes:
>>>      
>>>
>>>>I still don't see the need to say anything at all about x.509.  How
>>>>about:
>>>>
>>>>   If an external TLS channel is to be bound into the GS2
>>>>   authentication, and if the channel supports channel bindings of type
>>>>   'tls-server-end-point', then those MUST be used, else if the channel
>>>>   supports channel bindings of type 'tls-unique' type, then those MUST
>>>>   be used.
>>>>        
>>>>
>>>That works for me, but it seems to me to have the same meaning in
>>>practice because tls-server-end-point is only well defined for X.509.
>>>      
>>>
>>Indirection helps: we can update tls-server-end-point to support
>>OpenPGP, but if we do then we'd leave SCRAM/GS2 broken if they were to
>>bake in knowledge of tls-server-end-point's specification.
>>    
>>
>That would be good.
>
>I'm slightly worried that channel binding definitions can be changed
>after initial definition though, it kind of defeats the purpose of
>having a normative reference to them.
>  
>
Simon, I share your concern.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJUxsw063909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:30:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QJUxa7063908; Tue, 26 May 2009 12:30:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJUkcT063897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 12:30:58 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QJUUXF020838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 21:30:32 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::cqlvHTptLmt1XlPv:3KPm
X-Hashcash: 1:22:090526:[e-mail]::LU/5OSIPVpQVk5IW:A2Jw
X-Hashcash: 1:22:090526:[e-mail]::F1Qsud+oaqjhXWBh:DYnR
Date: Tue, 26 May 2009 21:30:30 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 11:28:41 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > I still don't see the need to say anything at all about x.509.  How
>> > about:
>> >
>> >    If an external TLS channel is to be bound into the GS2
>> >    authentication, and if the channel supports channel bindings of type
>> >    'tls-server-end-point', then those MUST be used, else if the channel
>> >    supports channel bindings of type 'tls-unique' type, then those MUST
>> >    be used.
>> 
>> That works for me, but it seems to me to have the same meaning in
>> practice because tls-server-end-point is only well defined for X.509.
>
> Indirection helps: we can update tls-server-end-point to support
> OpenPGP, but if we do then we'd leave SCRAM/GS2 broken if they were to
> bake in knowledge of tls-server-end-point's specification.

That would be good.

I'm slightly worried that channel binding definitions can be changed
after initial definition though, it kind of defeats the purpose of
having a normative reference to them.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJKI4Q063262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 12:20:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QJKIGl063261; Tue, 26 May 2009 12:20:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QJKCcE063247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 May 2009 12:20:17 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4QJK9FS098677; Tue, 26 May 2009 19:20:10 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Tue, 26 May 2009 12:20:09 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 26, 2009, at 9:55 AM, Nicolas Williams wrote:

>
> On Tue, May 26, 2009 at 09:48:08AM -0700, Kurt Zeilenga wrote:
>> Generally and with respect to SCRAM, I rather change the  
>> specification
>> to always require the use of unique channel bindings.  I do  
>> understand
>> however that some prefer use of end-point channel binding types in
>> certain cases.
>
> Indeed, we'll not agree to always require the use of unique channel
> bindings.

My problem with the the current approach is that requires use of  
endpoint channel bindings in certain cases where some deployers may  
prefer to use unique channel bindings.

>> One solution for SCRAM is to offer:
>> 	SCRAM-SHA-1
>> 	SCRAM-SHA-1-ENDPOINT
>> 	SCRAM-SHA-1-UNIQUE
>
> That complicates everything.

I rather simplify everything by not supporting endpoint channel  
binding types.  But if we're going to support end point channel  
bindings, I think their use should be server choice.

>> However, as WG Chair, I'm willing to discuss and conclude on this
>> issue (for SCRAM) as part of SCRAM WGLC.
>
> I don't see what difference it makes whether we discuss this in the
> context of a WGLC or not.  Either way we need a resolution.
>
> So let's discuss it now.

By all means.  It wasn't my intent to defer discussions.  It is my  
intent to defer determination of consensus of this issue, for SCRAM,  
until the conclusion of the soon to be issued SCRAM WGLC.

> To solve this without adding yet another negotiation via SASL  
> mechanism
> name we could just declare that the negotiation will be done by
> SCRAM/GS2, and that the application must furnish channel bindings all
> available channel binding types.  That would not precluse YAP, and it
> would not complicate SCRAM/GS2.

I rather avoid multiple levels of negotiation.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QHRkEb054983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 10:27:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QHRkJL054982; Tue, 26 May 2009 10:27:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QHRjsA054974 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 May 2009 10:27:45 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QHRi2M008672 for <[e-mail]>; Tue, 26 May 2009 17:27:45 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QHRi1p047381 for <[e-mail]>; Tue, 26 May 2009 11:27:44 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QHHtij011494; Tue, 26 May 2009 12:17:55 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QHHtTX011493; Tue, 26 May 2009 12:17:55 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 12:17:55 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 09:26:33AM -0700, Kurt Zeilenga wrote:
> On May 23, 2009, at 7:35 AM, Alexey Melnikov wrote:
> >I believe it addresses all outstanding issues the WG could agree on,  
> >so I would like to request WGLC for the document.
> 
> I've asked Alexey to revise the I-D slightly before it's WGLC'ed.
> 
> The current I-D says that providing proper examples is an open  
> issue.   As Alexey does not have the cycles at present to actually  
> proper examples (e.g, w/ correct hash values), he's going to close  
> this issue by adding notes to the text that the hash values are garbage.
> 
> While I personally rather correct the hash values (a comment I'll  
> raise at WGLC), I am willing as co-chair to issue a WG LC so long as  
> it quite clear that the hash values are garbage.
> 
> I hope someone can make moot this issue by computing correct hash  
> values.

Using a packet capture tool (wireshark) I extracted the first
certificate in an HTTPS connection to https://mail.google.com, I
inspected the signature algorithm (sha1WithRSAEncryption, that is,
1.2.840.113549.1.1.5), selected a hash function according to the
tls-server-end-point specification (SHA-256), and computed the hash of
that certificate as it appeared on the wire[*]:

cb5845b573a767ec92ad033ab2b16997fefbbaabedc6b83b9c163505eb44aff8

The certificate in question has serial #6EDF0D9499FD4533DD1297FC42A93BE1
and was issued by 'Thawte SGC CA'.  The issuer's signature of that cert
is:

      0000 - 00 62 f1 f3 05 0e bc 10-5e 49 7c 7a ed f8 7e 24   .b......^I|z..~$
      0010 - d2 f4 a9 86 bb 3b 83 7b-d1 9b 91 eb ca d9 8b 06   .....;.{........
      0020 - 59 92 f6 bd 2b 49 b7 d6-d3 cb 2e 42 7a 99 d6 06   Y...+I.....Bz...
      0030 - c7 b1 d4 63 52 52 7f ac-39 e6 a8 b6 72 6d e5 bf   ...cRR..9...rm..
      0040 - 70 21 2a 52 cb a0 76 34-a5 e3 32 01 1b d1 86 8e   p!*R..v4..2.....
      0050 - 78 eb 5e 3c 93 cf 03 07-22 76 78 6f 20 74 94 fe   x.^<...."vxo t..
      0060 - aa 0e d9 d5 3b 21 10 a7-65 71 f9 02 09 cd ae 88   ....;!..eq......
      0070 - 43 85 c8 82 58 70 30 ee-15 f3 3d 76 1e 2e 45 a6   C...Xp0...=v..E.
      0080 - bc                                                .

[*] Running openssl asn1parse -inform DER -in path_to_cert -dump fully
    decodes the captured certificate -- no errors nor warnings resulted.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QH53Cf052485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 10:05:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QH53et052481; Tue, 26 May 2009 10:05:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QH52IV052474 for <[e-mail]>; Tue, 26 May 2009 10:05:03 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QH52Wf000852 for <[e-mail]>; Tue, 26 May 2009 17:05:02 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QH524T027275 for <[e-mail]>; Tue, 26 May 2009 11:05:02 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QGtDMJ011466; Tue, 26 May 2009 11:55:13 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QGtDOo011465; Tue, 26 May 2009 11:55:13 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 11:55:13 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 09:48:08AM -0700, Kurt Zeilenga wrote:
> Generally and with respect to SCRAM, I rather change the specification  
> to always require the use of unique channel bindings.  I do understand  
> however that some prefer use of end-point channel binding types in  
> certain cases.

Indeed, we'll not agree to always require the use of unique channel
bindings.

> One solution for SCRAM is to offer:
> 	SCRAM-SHA-1
> 	SCRAM-SHA-1-ENDPOINT
> 	SCRAM-SHA-1-UNIQUE

That complicates everything.

> However, as WG Chair, I'm willing to discuss and conclude on this  
> issue (for SCRAM) as part of SCRAM WGLC.

I don't see what difference it makes whether we discuss this in the
context of a WGLC or not.  Either way we need a resolution.

So let's discuss it now.

To solve this without adding yet another negotiation via SASL mechanism
name we could just declare that the negotiation will be done by
SCRAM/GS2, and that the application must furnish channel bindings all
available channel binding types.  That would not precluse YAP, and it
would not complicate SCRAM/GS2.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGmDce050779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:48:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGmDtd050778; Tue, 26 May 2009 09:48:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGmCP0050772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 May 2009 09:48:13 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4QGm82s092764; Tue, 26 May 2009 16:48:10 GMT (envelope-from [e-mail])
Cc: Simon Josefsson <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Nicolas Williams <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Tue, 26 May 2009 09:48:08 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 25, 2009, at 11:14 AM, Nicolas Williams wrote:
> I'm more than happy to leave SCRAM and GS2 as they are, which
> effectively means that we punt on channel binding type negotiation,
> leaving us with a preference for end-point channel binding types over
> unique ones.


Generally and with respect to SCRAM, I rather change the specification  
to always require the use of unique channel bindings.  I do understand  
however that some prefer use of end-point channel binding types in  
certain cases.

One solution for SCRAM is to offer:
	SCRAM-SHA-1
	SCRAM-SHA-1-ENDPOINT
	SCRAM-SHA-1-UNIQUE

or, if one wanted to name one of the latter two with -PLUS, s/-UNIQUE/- 
PLUS/.

However, as WG Chair, I'm willing to discuss and conclude on this  
issue (for SCRAM) as part of SCRAM WGLC.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGlfjj050615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:47:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGlfsN050614; Tue, 26 May 2009 09:47:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGlToe050585 for <[e-mail]>; Tue, 26 May 2009 09:47:40 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.117] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 26 May 2009 17:47:27 +0100
Message-ID: <[e-mail]>
Date: Tue, 26 May 2009 17:46:37 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>  
>
>>Nicolas Williams <[e-mail]> writes:
>>    
>>
>>>I still don't see the need to say anything at all about x.509.  How
>>>about:
>>>
>>>   If an external TLS channel is to be bound into the GS2
>>>   authentication, and if the channel supports channel bindings of type
>>>   'tls-server-end-point', then those MUST be used, else if the channel
>>>   supports channel bindings of type 'tls-unique' type, then those MUST
>>>   be used.
>>>      
>>>
>>That works for me, but it seems to me to have the same meaning in
>>practice because tls-server-end-point is only well defined for X.509.
>>    
>>
>Indirection helps: we can update tls-server-end-point to support
>OpenPGP, but if we do then we'd leave SCRAM/GS2 broken if they were to
>bake in knowledge of tls-server-end-point's specification.
>  
>
>>For consistency, SCRAM would need to be updated as well, though.
>>    
>>
>Yes.
>  
>
I will post the updated version today.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGgpMt050195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:42:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGgpg9050194; Tue, 26 May 2009 09:42:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGgpOB050182 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 May 2009 09:42:51 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QGgoJd021568 for <[e-mail]>; Tue, 26 May 2009 16:42:50 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QGgoRV026930 for <[e-mail]>; Tue, 26 May 2009 10:42:50 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QGX1Ni011400; Tue, 26 May 2009 11:33:01 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QGX1ph011399; Tue, 26 May 2009 11:33:01 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 11:33:01 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 06:19:47PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > The channel binding type negotiation must happen somewhere, and it so
> > happens that SCRAM/GS2 will not specify what component of SASL (the app,
> > the framework or the mechanism) will do it, but it will specify a rule
> > for selecting channel binding type.  An implementor could make the app
> > apply that rule, or the framework, or the mechanism -- and still comply
> > with SCRAM/GS2.  Making the app choose will make it harder to later
> > implement Kurt's YAP mechanism in that framework.
> >
> > Therefore guidance is needed.  At the very least the guidance should be
> > that framework implementors should not leave the choice to applications.
> > But if the WG consensus is that we don't need to update RFC4422, that's
> > fine with me -- the sooner we finish SCRAM/GS2, the better.
> 
> Agreed.  And I think it is too early to mandate a particular
> implementation approach.

So we can leave implementors to make a mistake that will cause trouble
later on when YAP progresses?  We know what guidance to give: have the
app provide all available channel bindings and let the framework or the
mechanism pick one type.  Not giving guidance when we know what guidance
to give seems like asking for trouble.  I understand that updating
RFC4422 will take some time, so perhaps we ought to have some text in
SCRAM/GS2 about this, noting that a more complete SASL treatment of
channel binding is a work in progress.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGceIn049858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:38:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGcea1049857; Tue, 26 May 2009 09:38:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGcU5D049831 for <[e-mail]>; Tue, 26 May 2009 09:38:40 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QGcU3E000747 for <[e-mail]>; Tue, 26 May 2009 16:38:30 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QGcU6i023237 for <[e-mail]>; Tue, 26 May 2009 10:38:30 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QGSfgm011392; Tue, 26 May 2009 11:28:41 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QGSfsd011391; Tue, 26 May 2009 11:28:41 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 11:28:41 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > I still don't see the need to say anything at all about x.509.  How
> > about:
> >
> >    If an external TLS channel is to be bound into the GS2
> >    authentication, and if the channel supports channel bindings of type
> >    'tls-server-end-point', then those MUST be used, else if the channel
> >    supports channel bindings of type 'tls-unique' type, then those MUST
> >    be used.
> 
> That works for me, but it seems to me to have the same meaning in
> practice because tls-server-end-point is only well defined for X.509.

Indirection helps: we can update tls-server-end-point to support
OpenPGP, but if we do then we'd leave SCRAM/GS2 broken if they were to
bake in knowledge of tls-server-end-point's specification.

> For consistency, SCRAM would need to be updated as well, though.

Yes.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGbeT2049744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:37:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGbe4m049743; Tue, 26 May 2009 09:37:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGbb4H049731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 09:37:39 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QGbXnO016744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 18:37:36 +0200
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::XCndPyIOq+ymvzC3:1xrJ
X-Hashcash: 1:22:090526:[e-mail]::WI6dGJH7uYhyigjR:7ux2
X-Hashcash: 1:22:090526:[e-mail]::pJxpEVhdjzfFTtRh:7nwP
Date: Tue, 26 May 2009 18:37:33 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Tue, 26 May 2009 09:26:33 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> On May 23, 2009, at 7:35 AM, Alexey Melnikov wrote:
>
>> I believe it addresses all outstanding issues the WG could agree on,
>> so I would like to request WGLC for the document.
>
> I've asked Alexey to revise the I-D slightly before it's WGLC'ed.
>
> The current I-D says that providing proper examples is an open issue.
> As Alexey does not have the cycles at present to actually  proper
> examples (e.g, w/ correct hash values), he's going to close  this
> issue by adding notes to the text that the hash values are garbage.
>
> While I personally rather correct the hash values (a comment I'll
> raise at WGLC), I am willing as co-chair to issue a WG LC so long as
> it quite clear that the hash values are garbage.
>
> I hope someone can make moot this issue by computing correct hash
> values.

I volunteer to propose examples.  I have been waiting for the WGLC to
start before looking into implementation.

Is anyone interested in interop testing?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGQrvb048775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:26:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGQr4o048774; Tue, 26 May 2009 09:26:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGQgWm048758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 26 May 2009 09:26:53 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4QGQXLL088975; Tue, 26 May 2009 16:26:34 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Date: Tue, 26 May 2009 09:26:33 -0700
References: <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On May 23, 2009, at 7:35 AM, Alexey Melnikov wrote:

> I believe it addresses all outstanding issues the WG could agree on,  
> so I would like to request WGLC for the document.

I've asked Alexey to revise the I-D slightly before it's WGLC'ed.

The current I-D says that providing proper examples is an open  
issue.   As Alexey does not have the cycles at present to actually  
proper examples (e.g, w/ correct hash values), he's going to close  
this issue by adding notes to the text that the hash values are garbage.

While I personally rather correct the hash values (a comment I'll  
raise at WGLC), I am willing as co-chair to issue a WG LC so long as  
it quite clear that the hash values are garbage.

I hope someone can make moot this issue by computing correct hash  
values.

-- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGJqd3048206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:19:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGJq8c048205; Tue, 26 May 2009 09:19:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGJn35048194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 09:19:51 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QGJkMc016106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 18:19:48 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::HWKq8uUXQQ9SOGl+:4ufH
X-Hashcash: 1:22:090526:[e-mail]::ee0QAFX3RTIC8h1C:9PbU
X-Hashcash: 1:22:090526:[e-mail]::K+tPIhMMU6aVaATZ:UP/I
Date: Tue, 26 May 2009 18:19:47 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 10:52:50 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, May 26, 2009 at 04:23:34PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> 
>> > On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
>> >> Alexey Melnikov <[e-mail]> writes:
>> >> > I would rather not make SCRAM depend on yet another draft we need to
>> >> > get consensus on. We might never finish this way.
>> >> 
>> >> I agree.  The text I believed was missing from SCRAM/GS2 is in that
>> >> document, but as the thread pointed out, there actually is sufficient
>> >> text in SCRAM already.  The GS2 document can use similar text too.
>> >
>> > I'm very confused.  I thought you (Simon), along with Kurt, insisted
>> > that we had to address channel binding type negotiation, and SCRAM and
>> > GS2 quite clearly don't address that.
>> 
>> I believe SCRAM do -- it is just that the negotiation happens in the
>> document rather than in the protocol.  That is fine, and appears more
>> robust.  The language in SCRAM to achieve this is:
>
> I don't really want to argue with this, but, "... the negotiation
> happens in the document rather than in the protocol" is not really
> meaningful to me.

I'm referring to section 5.1 of GS2 -13.  That language resolves how
channel bindings are chosen.  The alternative is for the client and
server to negotiate the choice.

> The channel binding type negotiation must happen somewhere, and it so
> happens that SCRAM/GS2 will not specify what component of SASL (the app,
> the framework or the mechanism) will do it, but it will specify a rule
> for selecting channel binding type.  An implementor could make the app
> apply that rule, or the framework, or the mechanism -- and still comply
> with SCRAM/GS2.  Making the app choose will make it harder to later
> implement Kurt's YAP mechanism in that framework.
>
> Therefore guidance is needed.  At the very least the guidance should be
> that framework implementors should not leave the choice to applications.
> But if the WG consensus is that we don't need to update RFC4422, that's
> fine with me -- the sooner we finish SCRAM/GS2, the better.

Agreed.  And I think it is too early to mandate a particular
implementation approach.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGGGNV047933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:16:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QGGGQq047932; Tue, 26 May 2009 09:16:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QGGDFJ047859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 09:16:15 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QGG93W016053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 18:16:12 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::9G9TLgTTr8ioXRk/:8LUu
X-Hashcash: 1:22:090526:[e-mail]::hZdHhsqvBj3eiPaB:KUDy
X-Hashcash: 1:22:090526:[e-mail]::qK6BHlDG+vtWnH31:ITfg
Date: Tue, 26 May 2009 18:16:09 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Tue, 26 May 2009 10:44:46 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Tue, May 26, 2009 at 04:17:57PM +0200, Simon Josefsson wrote:
>> Nicolas Williams <[e-mail]> writes:
>> > OTOH, we could update tls-server-end-point to support OpenPGP.  So we
>> > should really say that "if tls-server-end-point bindings are available,
>> > ..." so as to avoid having to say anything at all about server certs.
>> 
>> Until that happens, GS2 now reads:
>> 
>> 5.1.  Channel Binding to TLS Channels
>> 
>>    If an external TLS channel is to be bound into the GS2
>>    authentication, and if the channel was established using a X.509
>>    [RFC5280] server certificate to authenticate the server, then the GS2
>>    client and server MUST use the 'tls-server-end-point' channel binding
>>    type.  See the IANA Channel Binding Types registry.
>> 
>>    If an external TLS channel is to be bound into the GS2
>>    authentication, and if the channel was established without the use of
>>    any X.509 server certificate to authenticate the server, then the GS2
>>    client and server MUST use the 'tls-unique' channel binding type.
>> 
>> Comments?
>
> I still don't see the need to say anything at all about x.509.  How
> about:
>
>    If an external TLS channel is to be bound into the GS2
>    authentication, and if the channel supports channel bindings of type
>    'tls-server-end-point', then those MUST be used, else if the channel
>    supports channel bindings of type 'tls-unique' type, then those MUST
>    be used.

That works for me, but it seems to me to have the same meaning in
practice because tls-server-end-point is only well defined for X.509.

For consistency, SCRAM would need to be updated as well, though.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QG2pSY045671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 09:02:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QG2pcm045670; Tue, 26 May 2009 09:02:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QG2eZZ045649 for <[e-mail]>; Tue, 26 May 2009 09:02:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QG2dcp009393 for <[e-mail]>; Tue, 26 May 2009 16:02:39 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QG2d0W056456 for <[e-mail]>; Tue, 26 May 2009 10:02:39 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QFqoAV011308; Tue, 26 May 2009 10:52:50 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QFqoI7011307; Tue, 26 May 2009 10:52:50 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 10:52:50 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 04:23:34PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> > On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
> >> Alexey Melnikov <[e-mail]> writes:
> >> > I would rather not make SCRAM depend on yet another draft we need to
> >> > get consensus on. We might never finish this way.
> >> 
> >> I agree.  The text I believed was missing from SCRAM/GS2 is in that
> >> document, but as the thread pointed out, there actually is sufficient
> >> text in SCRAM already.  The GS2 document can use similar text too.
> >
> > I'm very confused.  I thought you (Simon), along with Kurt, insisted
> > that we had to address channel binding type negotiation, and SCRAM and
> > GS2 quite clearly don't address that.
> 
> I believe SCRAM do -- it is just that the negotiation happens in the
> document rather than in the protocol.  That is fine, and appears more
> robust.  The language in SCRAM to achieve this is:

I don't really want to argue with this, but, "... the negotiation
happens in the document rather than in the protocol" is not really
meaningful to me.

The channel binding type negotiation must happen somewhere, and it so
happens that SCRAM/GS2 will not specify what component of SASL (the app,
the framework or the mechanism) will do it, but it will specify a rule
for selecting channel binding type.  An implementor could make the app
apply that rule, or the framework, or the mechanism -- and still comply
with SCRAM/GS2.  Making the app choose will make it harder to later
implement Kurt's YAP mechanism in that framework.

Therefore guidance is needed.  At the very least the guidance should be
that framework implementors should not leave the choice to applications.
But if the WG consensus is that we don't need to update RFC4422, that's
fine with me -- the sooner we finish SCRAM/GS2, the better.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QFuExX045129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 08:56:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QFuEmP045128; Tue, 26 May 2009 08:56:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QFu3St045114 for <[e-mail]>; Tue, 26 May 2009 08:56:13 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4QFu3VO002283 for <[e-mail]>; Tue, 26 May 2009 15:56:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QFu2Jm049916 for <[e-mail]>; Tue, 26 May 2009 09:56:03 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QFkE30011299; Tue, 26 May 2009 10:46:14 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QFkEgn011298; Tue, 26 May 2009 10:46:14 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 10:46:14 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, May 23, 2009 at 10:40:21AM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Nicolas Williams <[e-mail]> writes:
> >>On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
> >>>Could someone familiar with Cyrus SASL tell us whether a SASL mechanism
> >>>.so plugin can get the list of advertised SASL mechanisms both in client
> >>>mode and server mode?
> >>>
> >>Oh, I see, what you mean is that there's no way for the app to tell GNU
> >>SASL the list of mechanism names advertised by the server.
> >>
> >No, I am talking about the implementation of the SASL mechanism inside a
> >SASL library.  I suspect GNU SASL and Cyrus SASL, and other libraries,
> >behave similar here.
> > 
> >
> sasl_client_start() has a parameter for the list of SASL mechanisms 
> advertised by the server.
> (It is also frequently used to force selection of a single mechanism.)
> 
> However at the moment there is no way to retrieve the list of 
> server-advertised SASL mechanisms in plugins.

Channel binding will require new APIs.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QFsnoV045004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 08:54:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QFsnvu045003; Tue, 26 May 2009 08:54:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QFsd0C044986 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 26 May 2009 08:54:49 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n4QFsccT005266 for <[e-mail]>; Tue, 26 May 2009 15:54:38 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4QFscUT048980 for <[e-mail]>; Tue, 26 May 2009 09:54:38 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4QFil3K011293; Tue, 26 May 2009 10:44:47 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4QFikA2011292; Tue, 26 May 2009 10:44:46 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 26 May 2009 10:44:46 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, May 26, 2009 at 04:17:57PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> > OTOH, we could update tls-server-end-point to support OpenPGP.  So we
> > should really say that "if tls-server-end-point bindings are available,
> > ..." so as to avoid having to say anything at all about server certs.
> 
> Until that happens, GS2 now reads:
> 
> 5.1.  Channel Binding to TLS Channels
> 
>    If an external TLS channel is to be bound into the GS2
>    authentication, and if the channel was established using a X.509
>    [RFC5280] server certificate to authenticate the server, then the GS2
>    client and server MUST use the 'tls-server-end-point' channel binding
>    type.  See the IANA Channel Binding Types registry.
> 
>    If an external TLS channel is to be bound into the GS2
>    authentication, and if the channel was established without the use of
>    any X.509 server certificate to authenticate the server, then the GS2
>    client and server MUST use the 'tls-unique' channel binding type.
> 
> Comments?

I still don't see the need to say anything at all about x.509.  How
about:

   If an external TLS channel is to be bound into the GS2
   authentication, and if the channel supports channel bindings of type
   'tls-server-end-point', then those MUST be used, else if the channel
   supports channel bindings of type 'tls-unique' type, then those MUST
   be used.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEf9Oh038065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:41:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QEf9rQ038064; Tue, 26 May 2009 07:41:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEf4TZ038053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 07:41:08 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QEew8T013526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <[e-mail]>; Tue, 26 May 2009 16:41:02 +0200
From: Simon Josefsson <[e-mail]>
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-13.txt
References: <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::bZWLdST6c/6RTE2O:3h83
X-Hashcash: 1:22:090526:[e-mail]::KJnHuiOofdd37K1U:9dDw
X-Hashcash: 1:22:090526:[e-mail]::bsB69fctbm8JndoJ:H0Ot
Date: Tue, 26 May 2009 16:40:58 +0200
In-Reply-To: <[e-mail]> ([e-mail]'s message of "Tue, 26 May 2009 07:30:01 -0700 (PDT)")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-13.txt

I believe this version is ready for WGLC.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEXxeg037449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:33:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QEXxTD037448; Tue, 26 May 2009 07:33:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEXu89037440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 07:33:58 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QEXrEf013342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 16:33:55 +0200
X-Hashcash: 1:22:090526:[e-mail]::np6Bdl9iiZNwQ5p0:GD+n
From: Simon Josefsson <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::rQxK2DZ1bj+5JK6t:24R4
X-Hashcash: 1:22:090526:[e-mail]::pzy/nhmmfZv6uCT5:6dhD
Date: Tue, 26 May 2009 16:33:53 +0200
In-Reply-To: <[e-mail]> (Kurt Zeilenga's message of "Wed, 29 Apr 2009 12:29:52 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga <[e-mail]> writes:

> Simon wrote:
>
>> There is no interface
>> for querying for the advertised mechanisms, since no SASL mechanism
>> before has needed this.
>
> Right.  The SASL [RFC4422] design is that introduction of any
> mechanism may place new requirements on those trying to abstract away
> the differences between mechanisms to application level protocol
> implementations.
>
> While SCRAM and GS2 (and YAP) introduce such new requirements, I still
> buy into that RFC 4422 needs to be changed to support these new
> requirements.  And I certainly don't buy into the idea that what we
> say today about "CB in SASL" will be generally "good enough" for all
> future mechanisms.
>
> I am still of the mind that discussion of these new requirements need
> only be discussed in the mechanism specifications that introduce
> them.  It will be hard enough to reach consensus with respect to a
> single mechanism (or family of mechanisms) than to attempt to reach
> consensus for all future mechanisms.

I agree.  Let's use the same text in SCRAM and GS2 on channel bindings,
and see how that approach works out in practice.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEVjQH037248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:31:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QEVjpk037247; Tue, 26 May 2009 07:31:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEVjIR037241 for <[e-mail]>; Tue, 26 May 2009 07:31:45 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0297B28C2B6; Tue, 26 May 2009 07:30:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-gs2-13.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 26 May 2009 07:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-13.txt
	Pages           : 23
	Date            : 2009-05-26

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding.  Only GSS-API mechanisms that support channel
binding are supported.

See <http://josefsson.org/sasl-gs2-*/> for more information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-gs2-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-gs2-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QENiZQ036646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:23:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QENixX036645; Tue, 26 May 2009 07:23:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QENfkm036637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 07:23:42 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QENYqK013107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 16:23:36 +0200
X-Hashcash: 1:22:090526:[e-mail]::TKchSUsr6ZCejCrc:5mj4
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::KPJiPVYbHgerZ5H0:1aeD
X-Hashcash: 1:22:090526:[e-mail]::weFg2vB8XmexZq43:2bsn
Date: Tue, 26 May 2009 16:23:34 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 25 May 2009 13:14:42 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
>> Alexey Melnikov <[e-mail]> writes:
>> > I would rather not make SCRAM depend on yet another draft we need to
>> > get consensus on. We might never finish this way.
>> 
>> I agree.  The text I believed was missing from SCRAM/GS2 is in that
>> document, but as the thread pointed out, there actually is sufficient
>> text in SCRAM already.  The GS2 document can use similar text too.
>
> I'm very confused.  I thought you (Simon), along with Kurt, insisted
> that we had to address channel binding type negotiation, and SCRAM and
> GS2 quite clearly don't address that.

I believe SCRAM do -- it is just that the negotiation happens in the
document rather than in the protocol.  That is fine, and appears more
robust.  The language in SCRAM to achieve this is:

http://tools.ietf.org/html/draft-ietf-sasl-scram-00#section-6.1

I suggested that we use similar language in GS2.

> I'm more than happy to leave SCRAM and GS2 as they are, which
> effectively means that we punt on channel binding type negotiation,
> leaving us with a preference for end-point channel binding types over
> unique ones.

GS2 needs to use the same text first though.  It doesn't now.  I'll
submit an updated document shortly.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEI2to036242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:18:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QEI2L6036241; Tue, 26 May 2009 07:18:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QEI01A036232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 07:18:01 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QEHv13012889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 16:17:59 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::6t1EG1dHzoMuGvRq:2pmk
X-Hashcash: 1:22:090526:[e-mail]::fKsiOunJ29cJHzvt:M18m
X-Hashcash: 1:22:090526:[e-mail]::TsMShZQ+3RJ6T7Af:TVCa
Date: Tue, 26 May 2009 16:17:57 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 25 May 2009 13:16:51 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Sat, May 23, 2009 at 01:41:18PM +0100, Alexey Melnikov wrote:
>> Simon Josefsson wrote:
>> >However, I think SCRAM section 6.1 is under-specified -- if OpenPGP
>> >server certificates are used, the tls-server-end-point channel binding
>> >doesn't work.  My suggestion is to change "server certificate" into
>> >"X.509 [PKIX] server certificate".
>> > 
>> >
>> Agree.
>
> OTOH, we could update tls-server-end-point to support OpenPGP.  So we
> should really say that "if tls-server-end-point bindings are available,
> ..." so as to avoid having to say anything at all about server certs.

Until that happens, GS2 now reads:

5.1.  Channel Binding to TLS Channels

   If an external TLS channel is to be bound into the GS2
   authentication, and if the channel was established using a X.509
   [RFC5280] server certificate to authenticate the server, then the GS2
   client and server MUST use the 'tls-server-end-point' channel binding
   type.  See the IANA Channel Binding Types registry.

   If an external TLS channel is to be bound into the GS2
   authentication, and if the channel was established without the use of
   any X.509 server certificate to authenticate the server, then the GS2
   client and server MUST use the 'tls-unique' channel binding type.

Comments?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QECWAs035763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 07:12:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4QECWWL035762; Tue, 26 May 2009 07:12:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4QECJpQ035694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 26 May 2009 07:12:31 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4QECEmK012716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2009 16:12:16 +0200
From: Simon Josefsson <[e-mail]>
To: Nicolas Williams <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090526:[e-mail]::sD/D9oVr7fw0kh0S:9iKS
X-Hashcash: 1:22:090526:[e-mail]::nizdLssgjRnaPO5w:93Eg
X-Hashcash: 1:22:090526:[e-mail]::RL49AWfllrmqlQCK:0ggTJ
Date: Tue, 26 May 2009 16:12:14 +0200
In-Reply-To: <[e-mail]> (Nicolas Williams's message of "Mon, 25 May 2009 13:51:06 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams <[e-mail]> writes:

> On Mon, May 25, 2009 at 02:14:16PM +0200, Simon Josefsson wrote:
>> > I believe it addresses all outstanding issues the WG could agree on,
>> > so I would like to request WGLC for the document.
>> 
>> Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
>> for them to be compatible, I think it would be useful to do WGLC of both
>> SCRAM and GS2 at the same time.
>
> I agree.
>
>> As far as I recall there are only minor issues with GS2 left, including:
>> 
>> * Is additional language on locale issues required?
>
> We definitely resolved that.  The localization issue in the
> GSS_Inquire_SASLname_for_mech() API is purely local, therefore there's
> no need to say anything about language tag negotiation.

OK.

>> * Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>>   length string to indicate asserted absence of a registered IANA name?
>>   See section 3.
>
> No, it should generate an OID hash-based name, per-GS2.

Ah.  I agree.  I believe this isn't clear in -12, though.  I'll submit
an update that fixes this, and references the new SCRAM document too.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PLICaC051144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 14:18:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PLICT0051143; Mon, 25 May 2009 14:18:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PLI0i8051123 for <[e-mail]>; Mon, 25 May 2009 14:18:11 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 25 May 2009 22:17:59 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 May 2009 22:16:53 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Mon, May 25, 2009 at 02:14:16PM +0200, Simon Josefsson wrote:
>  
>
>>* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>>  length string to indicate asserted absence of a registered IANA name?
>>  See section 3.    
>>
>No, it should generate an OID hash-based name, per-GS2.
>  
>
This is fine with me.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PJ2ZCg034319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 12:02:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PJ2Z1G034318; Mon, 25 May 2009 12:02:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PJ2Ojp034296 for <[e-mail]>; Mon, 25 May 2009 12:02:35 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PJ2OAp021607 for <[e-mail]>; Mon, 25 May 2009 19:02:24 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PJ2OAP046460 for <[e-mail]>; Mon, 25 May 2009 13:02:24 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4PIqZk0010573; Mon, 25 May 2009 13:52:35 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4PIqZvM010572; Mon, 25 May 2009 13:52:35 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 25 May 2009 13:52:35 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, May 25, 2009 at 02:05:47PM +0200, Simon Josefsson wrote:
> > I think in short term we will have bugs due to introduction of channel
> > bindings, so I think having this information in authentication
> > exchange would help with debugging problems.
> 
> I agree with that, but supporting a field in the protocol just for
> debugging purposes seems to offer a low benefit to cost ratio.  It isn't
> that difficult to debug channel binding problems using other methods.

I agree.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PJ17pa034145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 12:01:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PJ16Dv034141; Mon, 25 May 2009 12:01:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PJ0u0l034097 for <[e-mail]>; Mon, 25 May 2009 12:01:06 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PJ0uTp019480 for <[e-mail]>; Mon, 25 May 2009 19:00:56 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PJ0tkC045570 for <[e-mail]>; Mon, 25 May 2009 13:00:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4PIp7Oh010567; Mon, 25 May 2009 13:51:07 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4PIp63R010566; Mon, 25 May 2009 13:51:06 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 25 May 2009 13:51:06 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, May 25, 2009 at 02:14:16PM +0200, Simon Josefsson wrote:
> > I believe it addresses all outstanding issues the WG could agree on,
> > so I would like to request WGLC for the document.
> 
> Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
> for them to be compatible, I think it would be useful to do WGLC of both
> SCRAM and GS2 at the same time.

I agree.

> As far as I recall there are only minor issues with GS2 left, including:
> 
> * Is additional language on locale issues required?

We definitely resolved that.  The localization issue in the
GSS_Inquire_SASLname_for_mech() API is purely local, therefore there's
no need to say anything about language tag negotiation.

> * Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>   length string to indicate asserted absence of a registered IANA name?
>   See section 3.

No, it should generate an OID hash-based name, per-GS2.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIcHBY031421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 11:38:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PIcHHg031420; Mon, 25 May 2009 11:38:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIcGVo031414 for <[e-mail]>; Mon, 25 May 2009 11:38:17 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PIcG55009062 for <[e-mail]>; Mon, 25 May 2009 18:38:16 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PIcGPF036458 for <[e-mail]>; Mon, 25 May 2009 12:38:16 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4PISRIN010557; Mon, 25 May 2009 13:28:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4PISPtI010556; Mon, 25 May 2009 13:28:25 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 25 May 2009 13:28:25 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: GS2 is ready for WG LC too
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, May 25, 2009 at 03:15:19PM +0200, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> > I think some text in at least section on C-binding is needed.
> > Note, that Chris Newman has specified explicit language tag parameter
> > in SASL API. IMHO, you don't have to do the same, but you need to know
> > why you want to differ.
> 
> Nico?

The GSS-API does not (yet) expose to apps any such language tag
negotiations that the mechanism might do, and if it ever does it will be
optional, that is, only if the mechanism itself supports it.

Therefore we certainly don't need language tag negotiation in the GS2
headers.

Mechanisms only need to negotiation language tags if there's going to be
human-readable error messages in GSS-API error tokens.  In practice
there's a finite number of errors that can occur in this context (as
opposed to more complex contexts, such as client<->KDC/kadmin
exchanges), so there's no need for localization in GSS-API mechanisms.

However, there is a local localization issue.  If an API can return a
human readable description of a mechanism, say, then that needs to be
localized.  That's an entirely local issue -- no language tag
negotiation is needed!  (I thought we'd settled this already.)

> What do you mean by SASL API?  I think SASL and the GSS-API are
> different creatures, one is a wire protocol and the other is a
> programming API.

I think of them as much the same sort of thing:

 - a protocol _pattern_ (SASL specifies NO bits on the wire, and the
   GSS-API specifies just a very few bits on the initial context token)

 - an abstract API (SASL certainly has one, though it's very subtly
   specified)

 - programming language bindings of that abstract API (only the GSS-API
   has standard bindings)

> I added these functions to the document, but I don't care strongly about
> the feature, so I hope Nico's answer will resolve it.  We could remove
> those fields, as they are not needed for GS2.  Or even remove the
> functions from the document too: it is possible to implement GS2 against
> a GSS-API stack that doesn't have these APIs.

Which functions?  GSS_Inquire_SASLname_for_mech()?  Please keep the
localized mechanism description output argument (see above); I strongly
object to its removal.

> >>* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
> >>  length string to indicate asserted absence of a registered IANA name?
> >>  See section 3.

It should compute and return the GS2 OID hash name.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIQp17030128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 11:26:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PIQpF7030127; Mon, 25 May 2009 11:26:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIQeV2030104 for <[e-mail]>; Mon, 25 May 2009 11:26:50 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PIQcsa015026 for <[e-mail]>; Mon, 25 May 2009 18:26:38 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PIQeh4031903 for <[e-mail]>; Mon, 25 May 2009 12:26:40 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4PIGpaf010549; Mon, 25 May 2009 13:16:51 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4PIGp8F010548; Mon, 25 May 2009 13:16:51 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 25 May 2009 13:16:51 -0500
From: Nicolas Williams <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, May 23, 2009 at 01:41:18PM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >However, I think SCRAM section 6.1 is under-specified -- if OpenPGP
> >server certificates are used, the tls-server-end-point channel binding
> >doesn't work.  My suggestion is to change "server certificate" into
> >"X.509 [PKIX] server certificate".
> > 
> >
> Agree.

OTOH, we could update tls-server-end-point to support OpenPGP.  So we
should really say that "if tls-server-end-point bindings are available,
..." so as to avoid having to say anything at all about server certs.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIOh9M029870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 11:24:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PIOhTU029869; Mon, 25 May 2009 11:24:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PIOWVo029838 for <[e-mail]>; Mon, 25 May 2009 11:24:42 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4PIOWM9003199 for <[e-mail]>; Mon, 25 May 2009 18:24:32 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4PIOWJW031247 for <[e-mail]>; Mon, 25 May 2009 12:24:32 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n4PIEhqk010543; Mon, 25 May 2009 13:14:43 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n4PIEgnl010542; Mon, 25 May 2009 13:14:42 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Mon, 25 May 2009 13:14:42 -0500
From: Nicolas Williams <[e-mail]>
To: Simon Josefsson <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
> Alexey Melnikov <[e-mail]> writes:
> > I would rather not make SCRAM depend on yet another draft we need to
> > get consensus on. We might never finish this way.
> 
> I agree.  The text I believed was missing from SCRAM/GS2 is in that
> document, but as the thread pointed out, there actually is sufficient
> text in SCRAM already.  The GS2 document can use similar text too.

I'm very confused.  I thought you (Simon), along with Kurt, insisted
that we had to address channel binding type negotiation, and SCRAM and
GS2 quite clearly don't address that.

I'm more than happy to leave SCRAM and GS2 as they are, which
effectively means that we punt on channel binding type negotiation,
leaving us with a preference for end-point channel binding types over
unique ones.

Nico
-- 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PHJ4KS022810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 10:19:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PHJ4dk022809; Mon, 25 May 2009 10:19:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PHIqLS022781 for <[e-mail]>; Mon, 25 May 2009 10:19:03 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 25 May 2009 18:18:50 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 May 2009 18:17:59 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: GS2 is ready for WG LC too
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>
>  
>
>>>Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
>>>for them to be compatible, I think it would be useful to do WGLC of both
>>>SCRAM and GS2 at the same time.
>>>      
>>>
>>Agreed. Or at least send them to IETF LC/IESG at the same time.
>>    
>>
>Yup.
>  
>
>>>As far as I recall there are only minor issues with GS2 left, including:
>>>
>>>* Is additional language on locale issues required?
>>>      
>>>
>>I think some text in at least section on C-binding is needed.
>>Note, that Chris Newman has specified explicit language tag parameter
>>in SASL API. IMHO, you don't have to do the same, but you need to know
>>why you want to differ.
>>    
>>
>Nico?
>
>What do you mean by SASL API?
>
The API used by Cyrus SASL. Chris designed the original version.

One example of the function using language tags is:

/* translate an error number into a string
 * input:
 *  saslerr  -- the error number
 *  langlist -- comma separated list of RFC 1766 languages (may be NULL)
 * results:
 *  outlang  -- the language actually used (may be NULL if don't care)
 * returns:
 *  the error message in UTF-8 (only the US-ASCII subset if langlist is 
NULL)
 */
LIBSASL_API const char *sasl_errstring(int saslerr,
                       const char *langlist,
                       const char **outlang);

>I think SASL and the GSS-API are
>different creatures, one is a wire protocol and the other is a
>programming API.
>
>I added these functions to the document, but I don't care strongly about
>the feature, so I hope Nico's answer will resolve it.  We could remove
>those fields, as they are not needed for GS2.  Or even remove the
>functions from the document too: it is possible to implement GS2 against
>a GSS-API stack that doesn't have these APIs.
>
>Robust GS2 implementations will probably have to deal with GSS-API
>stacks that doesn't have the functions anyway.
>  
>
>>>* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>>> length string to indicate asserted absence of a registered IANA name?
>>> See section 3.
>>>      
>>>
>>I don't think this is useful. We should reduce the number of branches
>>needed to handle a call to this function.
>>    
>>
>How would you then differentiate the situation where the call fails for
>some random reason,
>
I have hard time imagining such case, but ...

>or where it fails because there is no registered
>IANA name for a particular GSS-API mechanism?
>
... can you just use a different error code?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PDFPot091168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 06:15:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PDFPgx091167; Mon, 25 May 2009 06:15:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PDFMcR091157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 25 May 2009 06:15:24 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4PDFIFO008589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 May 2009 15:15:20 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: GS2 is ready for WG LC too
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090525:[e-mail]::hAqZuXDZ2jFU8Tvr:9t0y
X-Hashcash: 1:22:090525:[e-mail]::Gr9f2ytfpXvXHGMx:5bQO
Date: Mon, 25 May 2009 15:15:19 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Mon, 25 May 2009 13:39:44 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

>>Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
>>for them to be compatible, I think it would be useful to do WGLC of both
>>SCRAM and GS2 at the same time.
>>  
>>
> Agreed. Or at least send them to IETF LC/IESG at the same time.

Yup.

>>As far as I recall there are only minor issues with GS2 left, including:
>>
>>* Is additional language on locale issues required?
>>  
>>
> I think some text in at least section on C-binding is needed.
> Note, that Chris Newman has specified explicit language tag parameter
> in SASL API. IMHO, you don't have to do the same, but you need to know
> why you want to differ.

Nico?

What do you mean by SASL API?  I think SASL and the GSS-API are
different creatures, one is a wire protocol and the other is a
programming API.

I added these functions to the document, but I don't care strongly about
the feature, so I hope Nico's answer will resolve it.  We could remove
those fields, as they are not needed for GS2.  Or even remove the
functions from the document too: it is possible to implement GS2 against
a GSS-API stack that doesn't have these APIs.

Robust GS2 implementations will probably have to deal with GSS-API
stacks that doesn't have the functions anyway.

>>* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>>  length string to indicate asserted absence of a registered IANA name?
>>  See section 3.
>>  
>>
> I don't think this is useful. We should reduce the number of branches
> needed to handle a call to this function.

How would you then differentiate the situation where the call fails for
some random reason, or where it fails because there is no registered
IANA name for a particular GSS-API mechanism?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PCeU4M086647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 05:40:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PCeUW6086646; Mon, 25 May 2009 05:40:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PCeJrq086625 for <[e-mail]>; Mon, 25 May 2009 05:40:30 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.133] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 25 May 2009 13:40:17 +0100
Message-ID: <[e-mail]>
Date: Mon, 25 May 2009 13:39:44 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: GS2 is ready for WG LC too  (was Re: I-D Action:draft-ietf-sasl-scram-00.txt)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Alexey Melnikov <[e-mail]> writes:
>  
>
>>[e-mail] wrote:
>>    
>>
>>I believe it addresses all outstanding issues the WG could agree on,
>>so I would like to request WGLC for the document.
>>    
>>
>Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
>for them to be compatible, I think it would be useful to do WGLC of both
>SCRAM and GS2 at the same time.
>  
>
Agreed. Or at least send them to IETF LC/IESG at the same time.

>As far as I recall there are only minor issues with GS2 left, including:
>
>* Is additional language on locale issues required?
>  
>
I think some text in at least section on C-binding is needed.
Note, that Chris Newman has specified explicit language tag parameter in 
SASL API. IMHO, you don't have to do the same, but you need to know why 
you want to differ.

>* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
>  length string to indicate asserted absence of a registered IANA name?
>  See section 3.
>  
>
I don't think this is useful. We should reduce the number of branches 
needed to handle a call to this function.

>Anyway, a WGLC on GS2 will provoke a more complete summary of open
>issues, which seems like a good idea at this point.  Chairs?
>  
>
Indeed.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PCENZv082223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 05:14:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PCENZ3082222; Mon, 25 May 2009 05:14:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PCEJMX082210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 25 May 2009 05:14:22 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4PCEGiM007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 May 2009 14:14:18 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
References: <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090525:[e-mail]::xVxytghZ8RqvpUK6:6QQP
X-Hashcash: 1:22:090525:[e-mail]::QWUjo4H4RW1ihuse:a546
Date: Mon, 25 May 2009 14:14:16 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sat, 23 May 2009 15:35:08 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> [e-mail] wrote:
>
>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>>
>>
>>	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
>>	Author(s)       : A. Menon-Sen, et al.
>>	Filename        : draft-ietf-sasl-scram-00.txt
>>	Pages           : 33
>>	Date            : 2009-05-23
>>  
>>
> This version is essentially the same as draft-newman-auth-scram-13.txt.

Great!

> I believe it addresses all outstanding issues the WG could agree on,
> so I would like to request WGLC for the document.

Since the SCRAM protocol wire syntax needs to match the GS2 wire syntax
for them to be compatible, I think it would be useful to do WGLC of both
SCRAM and GS2 at the same time.

As far as I recall there are only minor issues with GS2 left, including:

* Is additional language on locale issues required?

* Is it a good idea for GSS_Inquire_SASLname_for_mech to return a zero
  length string to indicate asserted absence of a registered IANA name?
  See section 3.

Anyway, a WGLC on GS2 will provoke a more complete summary of open
issues, which seems like a good idea at this point.  Chairs?

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PC5rxg081041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 05:05:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PC5rFb081040; Mon, 25 May 2009 05:05:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PC5pDb081034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 25 May 2009 05:05:52 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4PC5lpQ006537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 May 2009 14:05:49 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090525:[e-mail]::jwI+SA29XjQveuwu:2EMU
X-Hashcash: 1:22:090525:[e-mail]::6NwlhRXlnkoIPQ/7:7Y+A
Date: Mon, 25 May 2009 14:05:47 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sat, 23 May 2009 13:12:28 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Simon Josefsson wrote:
>
>>Kurt Zeilenga <[e-mail]> writes:
>>  
>>
>>>On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:
>>>    
>>>
>>>>On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>>>>      
>>>>
>>>>>I generally do not favor changing RFC 4422 as discussed in this I-D.
>>>>>
>>>>>My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>>>>in
>>>>>similar ways (by design), we should not impose any restriction that
>>>>>other mechanisms which support channel bindings do so in a like way.
>>>>>
>>>>>For instance, many of the suggested restrictions make little sense
>>>>>for
>>>>>YAP.  Nor would they necessarily make sense for a "channel-bound"
>>>>>EXTERNAL mechanism (which, BTW, I have in the works).
>>>>>        
>>>>>
>>>>Can you elaborate?  Also, EXTERNAL is just not an issue.
>>>>      
>>>>
>>>Basically, there is a desire for a client to state from which lower-
>>>level it wishes to pull up an identity from.  So, my idea is to use
>>>unique channel bindings to specify which lower-level.  This use of
>>>channel binding is not intended to add any security protection, just
>>>as a convenient means to uniquely identify a channel.
>>>    
>>>
>>That is already described in:
>>
>>http://tools.ietf.org/html/draft-josefsson-sasl-external-channel-00
>>
>>There were comments that said transferring the actual channel binding
>>data is pointless, so I'll remove that part and resubmit as -01.
>>  
>>
> I think in short term we will have bugs due to introduction of channel
> bindings, so I think having this information in authentication
> exchange would help with debugging problems.

I agree with that, but supporting a field in the protocol just for
debugging purposes seems to offer a low benefit to cost ratio.  It isn't
that difficult to debug channel binding problems using other methods.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PBkMtT077958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 May 2009 04:46:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4PBkMDk077956; Mon, 25 May 2009 04:46:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4PBk8iG077903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Mon, 25 May 2009 04:46:20 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4PBk4Za006042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 25 May 2009 13:46:06 +0200
From: Simon Josefsson <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090525:[e-mail]::nPdnZgcjcIZrgiZH:0iNm
X-Hashcash: 1:22:090525:[e-mail]::RFvfaxVlkHSp42iJ:1tVQ
X-Hashcash: 1:22:090525:[e-mail]::0WXd2UweziXeqHb5:oB10
Date: Mon, 25 May 2009 13:46:04 +0200
In-Reply-To: <[e-mail]> (Alexey Melnikov's message of "Sat, 23 May 2009 10:18:28 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX,RDNS_DYNAMIC,SPF_FAIL autolearn=no version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on yxa-v.extundo.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]> writes:

> Nicolas Williams wrote:
>
>>On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>>  
>>
>>>Nicolas Williams <[e-mail]> writes:
>>>    
>>>
>>>>http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>>>>      
>>>>
>>>Thanks.  Something along these lines is needed before we can implement
>>>SCRAM and GS2.
>>>    
>>>
>>Well, no, but we do need this before SCRAM and GS2 can progress, IMO.
>>  
>>
> I would rather not make SCRAM depend on yet another draft we need to
> get consensus on. We might never finish this way.

I agree.  The text I believed was missing from SCRAM/GS2 is in that
document, but as the thread pointed out, there actually is sufficient
text in SCRAM already.  The GS2 document can use similar text too.

/Simon



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OAG9ba062116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 May 2009 03:16:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4OAG9l1062115; Sun, 24 May 2009 03:16:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4OAFw0x062102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 24 May 2009 03:16:09 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n4OAFsjL044912; Sun, 24 May 2009 10:15:55 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: Alexey Melnikov <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: SASL WG meeting in Stockholm
Date: Sun, 24 May 2009 03:15:54 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.935.3)
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on boole.openldap.org
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've now submitted our usual request.  -- Kurt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NEZxI0098592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 07:35:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NEZxNZ098591; Sat, 23 May 2009 07:35:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NEZvFW098584 for <[e-mail]>; Sat, 23 May 2009 07:35:58 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 15:35:56 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 15:35:08 +0100
From: Alexey Melnikov <[e-mail]>
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: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.
>
>
>	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
>	Author(s)       : A. Menon-Sen, et al.
>	Filename        : draft-ietf-sasl-scram-00.txt
>	Pages           : 33
>	Date            : 2009-05-23
>  
>
This version is essentially the same as draft-newman-auth-scram-13.txt.

I believe it addresses all outstanding issues the WG could agree on, so 
I would like to request WGLC for the document.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NEGqWa096259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 07:16:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NEGqsG096258; Sat, 23 May 2009 07:16:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NEGfBs096232 for <[e-mail]>; Sat, 23 May 2009 07:16:52 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 73C823A6E85; Sat, 23 May 2009 07:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sasl-scram-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sat, 23 May 2009 07:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Simple Authentication and Security Layer Working Group of the IETF.


	Title           : Salted Challenge Response (SCRAM) SASL Mechanism
	Author(s)       : A. Menon-Sen, et al.
	Filename        : draft-ietf-sasl-scram-00.txt
	Pages           : 33
	Date            : 2009-05-23

The secure authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS.  Unfortunately, the
challenge response mechanisms presently on the standards track all
fail to meet requirements necessary for widespread deployment, and
have had success only in limited use.

This specification describes a family of Simple Authentication and
Security Layer (SASL, RFC 4422) authentication mechanisms called the
Salted Challenge Response Authentication Mechanism (SCRAM), which
addresses the security concerns and meets the deployability
requirements.  When used in combination with TLS or an equivalent
security layer, a mechanism from this family could improve the
status-quo for application protocol authentication and provide a
suitable choice for a mandatory-to-implement mechanism for future
application protocol standards.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-scram-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sasl-scram-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ND2bVA090328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 06:02:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4ND2b4Y090327; Sat, 23 May 2009 06:02:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4ND2aPD090320 for <[e-mail]>; Sat, 23 May 2009 06:02:36 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 14:02:34 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 14:01:49 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Jeffrey Hutzelman <[e-mail]>, SASL WG <[e-mail]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Wed, Apr 01, 2009 at 11:52:02PM -0400, Jeffrey Hutzelman wrote:
>  
>
>>For starters, I think we should not algorithmically modify mechanism names; 
>>instead, any GSS-API mechanism (including SCRAM) that wishes to define 
>>friendly SASL mechanism names should define two such names, for the "PLUS" 
>>and "non-PLUS" cases.  This makes it easier to express the requirement that 
>>these names be registered in the SASL mechanism name registry and not 
>>conflict with the names of any existing (or future) SASL mechanisms.   
>>
>
>OTOH, having a common affix for "server supports channel binding" makes
>it easier to implement a common mechanism selection function in a
>client-side SASL framework.
>
>Yes, it wouldn't be hard for such a framework to ask each mechanism
>plugin what names it has and which indicate "server supports channel
>binding"...
>  
>
>>Secondly, I'd propose including the "plus" bit before the algorithm:
>>    
>>
I wouldn't mind that, but at this point I would rather leave SCRAM/GS2 
documents as is.

>>GS2B-oidoidoidoidoid (basic)
>>GS2P-oidoidoidoidoid (plus)
>>
>>SCRAM_B-HMAC-SHA-1   (basic)
>>SCRAM_P-HMAC-SHA-1   (plus)
>>SCRAM_P-HMAC-SHA-256 (plus)
>>
>Chris believes that mechanism names will leak into configuration UIs,
>and that therefore it's important that the -PLUS affix be meaningful to
>humans.  I think we can leave the affix as an implementation detail
>(e.g., the user configured "SCRAM" but the client and server will
>understand that SCRAM-PLUS is also allowed unless the user specifically
>disallowed channel binding).
>
I agree.

>>Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
>>removing or abbreviating the "HMAC" component, which is mostly redundant.
>>    
>>
>
>Chris proposed that we just call it "SCRAM1" -- we don't need the
>algorithm names in the mechanism name.  I agree with that.  That way the
>-PLUS suffix becomes a non-issue for SCRAM (it's already a non-issue for
>GS2 -- see the latest GS2 I-D).
>
I think having hash function name in the SCRAM mechanism name would be 
move obvious to operators/implementors.
So I deleted "HMAC-" instead.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCgKlS088877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 05:42:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NCgKIa088876; Sat, 23 May 2009 05:42:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCgJvm088869 for <[e-mail]>; Sat, 23 May 2009 05:42:20 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 13:42:16 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 13:41:18 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Kurt Zeilenga <[e-mail]> writes:
>
>>On Apr 22, 2009, at 2:53 AM, Simon Josefsson wrote:
>>    
>>
>>>Nicolas Williams <[e-mail]> writes:
>>>      
>>>
>>>>http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>>>>        
>>>>
>>>Thanks.  Something along these lines is needed before we can implement
>>>SCRAM and GS2.      
>>>
>>Why?
>>
>>In particular, do you think it not possible (or not feasible) to
>>implement SCRAM and/or GS2 without change to RFC 4422 and, if so, why?
>>
>>My take on SCRAM, at least, is that it's quite implementable without
>>change to RFC 4422.    
>>
>Yes, I had missed section 6.1 of SCRAM -12.  So SCRAM would be possible
>to implement without the above document.
>
>GS2 isn't, since there is no similar description of how channel binding
>types are selected.  So GS2 needs the same text.  The same text also
>seems useful in GS2 to make it more likely that native-SCRAM and
>SCRAM-over-GS2 will interoperate.  Otherwise a SCRAM-over-GS2
>implementation may select a different channel binding type.
>
>However, I think SCRAM section 6.1 is under-specified -- if OpenPGP
>server certificates are used, the tls-server-end-point channel binding
>doesn't work.  My suggestion is to change "server certificate" into
>"X.509 [PKIX] server certificate".
>  
>
Agree.
BTW, I think your text about tls-unique is not quite correct - it should 
be used in all other cases.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCRT8W087997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 05:27:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NCRTRD087996; Sat, 23 May 2009 05:27:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCRIhr087986 for <[e-mail]>; Sat, 23 May 2009 05:27:29 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 08B832E369; Sat, 23 May 2009 14:26:37 +0200 (CEST)
Received: from [e-mail] (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1243081596-44373-44372/6/29 (5 recipients); Sat, 23 May 2009 14:26:36 +0200
Message-Id: <I/[e-mail]>
Date: Sat, 23 May 2009 14:27:57 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Cc: Nicolas Williams <[e-mail]>, [e-mail], Simon Josefsson <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> I would rather not make SCRAM depend on yet another draft we need to 
> get consensus on. We might never finish this way.

+1

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCDMdJ087355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 05:13:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4NCDMOb087354; Sat, 23 May 2009 05:13:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4NCDBew087334 for <[e-mail]>; Sat, 23 May 2009 05:13:22 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 13:13:08 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 13:12:28 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: [e-mail]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Kurt Zeilenga <[e-mail]> writes:
>  
>
>>On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:
>>    
>>
>>>On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>>>      
>>>
>>>>I generally do not favor changing RFC 4422 as discussed in this I-D.
>>>>
>>>>My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>>>in
>>>>similar ways (by design), we should not impose any restriction that
>>>>other mechanisms which support channel bindings do so in a like way.
>>>>
>>>>For instance, many of the suggested restrictions make little sense
>>>>for
>>>>YAP.  Nor would they necessarily make sense for a "channel-bound"
>>>>EXTERNAL mechanism (which, BTW, I have in the works).
>>>>        
>>>>
>>>Can you elaborate?  Also, EXTERNAL is just not an issue.
>>>      
>>>
>>Basically, there is a desire for a client to state from which lower-
>>level it wishes to pull up an identity from.  So, my idea is to use
>>unique channel bindings to specify which lower-level.  This use of
>>channel binding is not intended to add any security protection, just
>>as a convenient means to uniquely identify a channel.
>>    
>>
>That is already described in:
>
>http://tools.ietf.org/html/draft-josefsson-sasl-external-channel-00
>
>There were comments that said transferring the actual channel binding
>data is pointless, so I'll remove that part and resubmit as -01.
>  
>
I think in short term we will have bugs due to introduction of channel 
bindings, so I think having this information in authentication exchange 
would help with debugging problems.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9ep7A077997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 02:40:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4N9epbx077996; Sat, 23 May 2009 02:40:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9eo26077988 for <[e-mail]>; Sat, 23 May 2009 02:40:51 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 10:40:49 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 10:40:21 +0100
From: Alexey Melnikov <[e-mail]>
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: Simon Josefsson <[e-mail]>
CC: Nicolas Williams <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Simon Josefsson wrote:

>Nicolas Williams <[e-mail]> writes:
>  
>
>>On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
>>    
>>
>>>Nicolas Williams <[e-mail]> writes:
>>>      
>>>
 [...]

>>>I don't care strongly which approach is used, so I could live with
>>>CB-foo.
>>>
>>>I can assert that SCRAM-TLSENDPOINT etc is easier to implement than the
>>>CB-foo approach in GNU SASL, because there is no established interface
>>>for SASL mechanisms to discover the list of supported mechanisms.
>>>      
>>>
>>That's strange.  Because listing the server's SASL mechanisms is how
>>apps negotiate SASL mechs.  So how do GNU SASL apps deal?
>>    
>>
>I was talking about the _mechanisms_ in GNU SASL.  There is no interface
>for querying for the advertised mechanisms, since no SASL mechanism
>before has needed this.
>  
>
>>>Could someone familiar with Cyrus SASL tell us whether a SASL mechanism
>>>.so plugin can get the list of advertised SASL mechanisms both in client
>>>mode and server mode?
>>>      
>>>
>>Oh, I see, what you mean is that there's no way for the app to tell GNU
>>SASL the list of mechanism names advertised by the server.
>>    
>>
>No, I am talking about the implementation of the SASL mechanism inside a
>SASL library.  I suspect GNU SASL and Cyrus SASL, and other libraries,
>behave similar here.
>  
>
sasl_client_start() has a parameter for the list of SASL mechanisms 
advertised by the server.
(It is also frequently used to force selection of a single mechanism.)

However at the moment there is no way to retrieve the list of 
server-advertised SASL mechanisms in plugins.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9VqJ3077471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 02:31:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4N9VqFq077470; Sat, 23 May 2009 02:31:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9VpNK077460 for <[e-mail]>; Sat, 23 May 2009 02:31:52 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 10:31:50 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 10:31:19 +0100
From: Alexey Melnikov <[e-mail]>
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: Kurt Zeilenga <[e-mail]>
CC: [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kurt Zeilenga wrote:

>>> Changes from -02:
>>>
>>> - added channel binding type negotiation through pseudo-mechanism  
>>> names
>>>    - CB-tls-srv-endpoint
>>>    - CB-tls-unique
>>>    - If the server doesn't list any then the client assumes all  
>>> channel
>>>      binding types available on the client side are also available on
>>>      the server side.  But the server SHOULD list them.
>>
>> I'm concerned that (today) the implementation of a SASL mechanism does
>> not have easy access to the list of supported SASL mechanism exposed  by
>> the server.
>
> Given that mechanism negotiation is "protocol specific", this should  
> not be surprising to anyone.  In fact, protocols need not even 
> provide  a mechanism negotiation facility.

It is only a SHOULD in section 4, bullet 2. But the intent was to not 
declare older (pre-SASL framework) protocols non-compliant. But as far 
as I know, all protocols that lacked this facility have it now.
As a side note, I feel quite strongly that this facility should be 
present in all new protocols.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9JBq4076217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 02:19:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4N9JBi6076216; Sat, 23 May 2009 02:19:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N9JAd3076210 for <[e-mail]>; Sat, 23 May 2009 02:19:10 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <She=[e-mail]>; Sat, 23 May 2009 10:19:08 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 10:18:28 +0100
From: Alexey Melnikov <[e-mail]>
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: Nicolas Williams <[e-mail]>
CC: Simon Josefsson <[e-mail]>, [e-mail]
Subject: Re: Updated SASL And Channel Binding document (-03)
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nicolas Williams wrote:

>On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>  
>
>>Nicolas Williams <[e-mail]> writes:
>>    
>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>>>      
>>>
>>Thanks.  Something along these lines is needed before we can implement
>>SCRAM and GS2.
>>    
>>
>Well, no, but we do need this before SCRAM and GS2 can progress, IMO.
>  
>
I would rather not make SCRAM depend on yet another draft we need to get 
consensus on. We might never finish this way.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N8OHpl073018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 May 2009 01:24:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4N8OHEo073017; Sat, 23 May 2009 01:24:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4N8O5Al073008 for <[e-mail]>; Sat, 23 May 2009 01:24:16 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.56.208] (92.40.56.208.sub.mbb.three.co.uk [92.40.56.208])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 23 May 2009 09:24:04 +0100
Message-ID: <[e-mail]>
Date: Sat, 23 May 2009 09:23:40 +0100
From: Alexey Melnikov <[e-mail]>
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: [e-mail]
Subject: SASL WG meeting in Stockholm
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I haven't seen the meeting request yet (IESG gets all kind of cool 
reports now). The deadline is on Monday, May 25th.
Are we celebrating being done with SCRAM and GS2, or do we want to meet?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45Jx5qE070995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 12:59:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n45Jx5ud070994; Tue, 5 May 2009 12:59:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n45JwsbC070975 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 5 May 2009 12:59:04 -0700 (MST) (envelope-from [e-mail])
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n45JwrNr006584 for <[e-mail]>; Tue, 5 May 2009 19:58:53 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n45Jwrp2029667 for <[e-mail]>; Tue, 5 May 2009 13:58:53 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n45JnDaW025666; Tue, 5 May 2009 14:49:13 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n45JnD3j025665; Tue, 5 May 2009 14:49:13 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to [e-mail] using -f
Date: Tue, 5 May 2009 14:49:13 -0500
From: Nicolas Williams <[e-mail]>
To: Kurt Zeilenga <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on YAP
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.7i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-sasl/mail-archive/>
List-ID: <ietf-sasl.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Apr 29, 2009 at 10:54:38AM -0700, Kurt Zeilenga wrote:
> On Apr 29, 2009, at 9:30 AM, Nicolas Williams wrote:
> >On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
> >> YAP relies on client to authenticate the server within this lower-
> >>level security layer to avoid information disclosure to rogue  
> >>servers.
> >
> >I don't think that's a good idea.  Here's why: if you're really
> >authenticating the server at the lower layer then why are you using
> >channel binding in YAP?
> 
> The channel binding also ensures the client lower-level and YAP end  
> points are the same.
> 
> One problem in many uses of TLS in application protocols is that the  
> server has no clue wether the client's user well authenticated the  
> server, hence the server has to be leery of man-in-the-middle  
> attacks.  By using channel bindings, the server need not be concerned  
> about whether the client's user well authenticated the server as it  
> can rely on the channel binding to avoid man-in-the-middle attacks.

What you seem to be asking for is something like what SSHv2 does: first
key exchange and server authentication, then user authentication with
channel binding and with privacy protection.  SSHv2 pubkey userauth
consists of a message bearing a signature of the SSHv2 session ID, which
in turn binds the entire key exchange.  And you want this in just half a
round-trip because between TCP, TLS and the application's framing of
SASL and mechanism negotiation you're already up to an obnoxiously large
number of round-trips (1.5 for TCP, 2 for TLS, 1 for mechanism
negotiation, N for SASL mech, and up to 1 for the SASL app's outcome of
authentication message).

You might be interested in draft-williams-tls-app-sasl-opt-03.txt then.
That I-D would reduce the number of round-trips to: 1.5 for TCP, 2 for
TLS, N-1 for the SASL mech, and in the generic-sasl protocol specified
therein, 0 for the outcome of authentication message.  A total reduction
of 3 round-trips.

I'm not sure that I care for YAP as an Experimental mechanism when I
believe we ought to be looking at reducing the number of round-trips and
we can get a significantly larger round-trip reduction than the .5
round-trips that YAP saves over a variant that authenticates the server.

And if we can greatly simplify channel binding type negotiation in the
process, then let's.

Nico
--