Subject: Poll: use of TLS channel bindings in SCRAM

From: Alexey Melnikov <[email-masked]>
Date: Thu, 28 May 2009 22:49:03 +0100

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 00:06:51 +0200

Alexey Melnikov <[email-masked]> writes:

> 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 (*) (**)
> 2). SCRAM should just use tls-server-end-point, fallback to
> tls-unique, no negotiation of other TLS channel bindings (*)

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 28 May 2009 18:35:16 -0500

> 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
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 28 May 2009 18:25:03 -0700

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.
>
> 2). SCRAM should just use tls-server-end-point, fallback to tls- 
> unique, no negotiation of other TLS channel bindings (*)

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 28 May 2009 19:08:42 -0700

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 28 May 2009 20:23:55 -0700

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.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 00:13:17 -0500

> 4b (I'm assuming it refers to tls-server-end-point)

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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 01:29:08 -0400

--On Thursday, May 28, 2009 07:08:42 PM -0700 Kurt Zeilenga 
<[email-masked]> 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.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 01:29:15 -0400

> (1a) future-proofed would be my preferred approach.  I.e., (1a) with the

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.

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 01:36:07 -0400

>    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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 00:39:05 -0500

> 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 00:36:58 -0500

> binding to a channel type other than TLS.

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 09:21:27 +0200

> proposal.  And notice that the server knows what channel binding type

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?

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

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

(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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 May 2009 10:36:27 +0100

Kurt Zeilenga wrote:

> 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  

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.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 10:42:09 -0500

> 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.

> 	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

That's an exceedingly obnoxious aspect of this problem.

> Jeff's schemes, if I understand them all correctly.

I don't agree.

> SASL mechanism negotiation are handled in some implementations, which is

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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 12:19:31 -0400

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

> 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

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

> 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?

> mechanism preference, c) mechanism dependence/ non-dependence on unique

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 20:29:42 +0200

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 14:54:31 -0400

> 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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 13:02:53 -0700

> 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).

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 15:22:32 -0500

> 2) Add text to say that with 'y' a list of cb type names supported by

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,

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

> tls-unique, clients SHOULD choose tls-unique, ...)

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

> 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.

> of how the protocol will look like.

Awesome.  Thanks!

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

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 16:49:57 -0400

--On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga 
<[email-masked]> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 15:47:48 -0500

> 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.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 22:59:17 +0200

> b) provide for downgrade detection should we ever add channel binding

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

> authentication necessarily must fail :)

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

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

Yes.

> protocols_, and explicitly allow SASL app protocols to specify a

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?

> 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

Done.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 16:00:46 -0500

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

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

> 		their own channel binding type agreement is provided

Perfect.

> with better text.  Suggestions?

No, I think the above is fine.

> 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
--

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 23:13:47 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> 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.

> 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...
>
> 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.
>
> 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...
>
> 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.
>

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.

> 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.

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 17:17:06 -0400

> 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.

> 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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 17:28:55 -0400

> 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.

> 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

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.

> above.

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

>> meechanisms and channel binding types they need.

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 14:47:39 -0700

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

>
> --On Friday, May 29, 2009 01:02:53 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
> 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.

>> numbers

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.

>> values
> 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.

> 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).

>> multiple

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.

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2009 23:56:18 +0200

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 18:02:39 -0400

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

>> <[email-masked]
> 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.

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 15:08:13 -0700

> applicability of any particular channel binding type is the same for  

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.

> 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.

> If you don't agree with this approach to reaching consensus, please  

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 29 May 2009 18:22:49 -0400

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

> On Fri, May 29, 2009 at 06:02:39PM -0400, Jeffrey Hutzelman wrote:
> 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.
>
> 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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 17:05:40 -0500

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 15:23:34 -0700

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 17:20:51 -0500

> and deployers to choose which binding types they support on a per  

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.
> 

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
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 16:57:04 -0500

> of channel binding types.

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

> 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  

That's the point of our proposal.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 17:18:49 -0700

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

> being terribly clear.

I am trying my best to offer clarification.

> His primary goal is clearly to allow for YAP and

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 19:14:23 -0500

On Fri, May 29, 2009 at 05:00:31PM -0700, Kurt Zeilenga wrote:
> From my initial review of your proposal:
> 
> 1) Jeffrey's message  
> <[email-masked]>) 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
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 29 May 2009 19:22:58 -0500

> might revise the I-D), I hope they would bring this to my attention  

OK, good, we're done with that.

> 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
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 17:00:31 -0700

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

> You must review the proposal and tell us whether it meets your  
> requirement

1) Jeffrey's message  

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 18:56:04 -0700

On May 29, 2009, at 5:22 PM, Nicolas Williams wrote:
> 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

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 19:28:42 -0700

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

> 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

+1.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 29 May 2009 19:44:05 -0700

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 30 May 2009 00:01:57 -0500

> 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.

> channel binding type negotiation later.

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

> the SCRAM and GS2 specification.

Nonsense.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 30 May 2009 00:29:36 -0500

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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 30 May 2009 01:46:25 -0400

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 30 May 2009 11:17:01 +0100

> 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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 06:53:30 -0700

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

>
> --On Friday, May 29, 2009 07:44:05 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>
>>
> 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.
>

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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 08:06:41 -0700

> 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.

> 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  

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 30 May 2009 11:15:29 -0400

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

> 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
> 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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 08:39:39 -0700

On May 30, 2009, at 3:17 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.
>>
> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 09:26:22 -0700

> 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.

> 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).

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 30 May 2009 11:49:41 -0400

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

> 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.
>
>>
> 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.
>
> 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?

> 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.

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 10:09:43 -0700

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 30 May 2009 13:06:26 -0500

[Responding slightly out of order.]

> my negotiation approach has no need for SCRAM-*-PLUS.

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

> think it will be a major deciding factor on what stand I take in the  

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.

> negotiation solutions.  I do plan on making a stand before the poll  

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
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 30 May 2009 13:12:44 -0500

> the poll, as this might discourage participants who have yet to speak  

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
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 11:31:38 -0700

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.

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 11:51:22 -0700

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 30 May 2009 11:58:49 -0700

> 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

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 11:58:49 -0700
Sender: [email-masked]

> 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

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 11:51:22 -0700
Sender: [email-masked]

-- Kurt

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 11:31:38 -0700
Sender: [email-masked]

-- Kurt

Date: Sat, 30 May 2009 13:12:44 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Sender: [email-masked]

Nico
-- 

Date: Sat, 30 May 2009 13:06:26 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Sender: [email-masked]

Nico
-- 

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 10:09:43 -0700
Sender: [email-masked]

-- Kurt

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 09:26:22 -0700
Sender: [email-masked]

-- Kurt

Date: Sat, 30 May 2009 11:49:41 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: SCRAM/GS2 deadline/consquences (Was: Poll: use of TLS channel bindings in SCRAM)
Date: Sat, 30 May 2009 08:39:39 -0700
Sender: [email-masked]

-- Kurt

Date: Sat, 30 May 2009 11:15:29 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 08:06:41 -0700
Sender: [email-masked]

-- Kurt

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Sat, 30 May 2009 06:53:30 -0700
Sender: [email-masked]

-- Kurt, as chair.

Date: Sat, 30 May 2009 11:17:01 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Date: Sat, 30 May 2009 00:29:36 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Where do we stand? (Re: Poll: use of TLS channel bindings in SCRAM)
Sender: [email-masked]

Nico
-- 

Date: Sat, 30 May 2009 01:46:25 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Sat, 30 May 2009 00:01:57 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nonsense.

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 19:44:05 -0700
Sender: [email-masked]

-- Kurt, as co-chair

Cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 19:28:42 -0700
Sender: [email-masked]

+1.

-- Kurt

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 18:56:04 -0700
Sender: [email-masked]

You asserted:

-- Kurt

Date: Fri, 29 May 2009 19:22:58 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nico
-- 

Date: Fri, 29 May 2009 19:14:23 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nico
-- 

Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 17:18:49 -0700
Sender: [email-masked]

-- Kurt

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 17:00:31 -0700
Sender: [email-masked]

1) Jeffrey's message  

-- Kurt

Date: Fri, 29 May 2009 17:20:51 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nico
-- 

Cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 15:23:34 -0700
Sender: [email-masked]

-- Kurt

Date: Fri, 29 May 2009 17:05:40 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Date: Fri, 29 May 2009 18:22:49 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Kurt Zeilenga <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Fri, 29 May 2009 16:57:04 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 15:08:13 -0700
Sender: [email-masked]

> say

-- Kurt

Date: Fri, 29 May 2009 18:02:39 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 23:56:18 +0200
Sender: [email-masked]

/Simon

Cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 14:47:39 -0700
Sender: [email-masked]

-- Kurt

Date: Fri, 29 May 2009 17:28:55 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Fri, 29 May 2009 17:17:06 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 23:13:47 +0200
Sender: [email-masked]

Hear, hear.

/Simon

Date: Fri, 29 May 2009 16:00:46 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Perfect.

That's fine too.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 22:59:17 +0200
Sender: [email-masked]

Yes.

I'm not sure.

Thoughts?

Done.

/Simon

Date: Fri, 29 May 2009 15:47:48 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Date: Fri, 29 May 2009 16:49:57 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nico: 2N+M   = 12+5   = 17

-- Jeff

Date: Fri, 29 May 2009 15:22:32 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

and

Awesome.  Thanks!

Nico
-- 

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Fri, 29 May 2009 13:02:53 -0700
Sender: [email-masked]

-- Kurt

Date: Fri, 29 May 2009 14:54:31 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 20:29:42 +0200
Sender: [email-masked]

Thoughts?

/Simon

Date: Fri, 29 May 2009 12:19:31 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Nor will I.

-- Jeff

Date: Fri, 29 May 2009 10:42:09 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

I don't agree.

Nico
-- 

Date: Fri, 29 May 2009 10:36:27 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Very well.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 09:21:27 +0200
Sender: [email-masked]

/Simon

Date: Fri, 29 May 2009 00:36:58 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Date: Fri, 29 May 2009 00:39:05 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Thanks,

Nico
-- 

Date: Fri, 29 May 2009 01:38:43 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

--On Wednesday, May 27, 2009 02:02:15 PM -0700 Kurt Zeilenga 
<[email-masked]> 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.

Date: Fri, 29 May 2009 01:36:07 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Fri, 29 May 2009 01:29:15 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Fri, 29 May 2009 01:29:08 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>, [email-masked]
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

-- Jeff

Date: Fri, 29 May 2009 00:13:17 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

   This default would be:

Comments?

Nico
-- 

Date: Thu, 28 May 2009 22:08:26 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

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
-- 

Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 20:23:55 -0700
Sender: [email-masked]

Cc: Simon Josefsson <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Date: Thu, 28 May 2009 19:49:45 -0700
Sender: [email-masked]

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

>
> On Thu, May 28, 2009 at 10:39:00PM +0200, Simon Josefsson wrote:
>>> 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

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 19:08:42 -0700
Sender: [email-masked]

> (**) - channel binding negotiation can be added later on

Cc: SASL WG <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Date: Thu, 28 May 2009 18:25:03 -0700
Sender: [email-masked]

-- Kurt, as co-chair

> (**) - channel binding negotiation can be added later on

Date: Thu, 28 May 2009 18:35:16 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Thanks,

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Poll: use of TLS channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 29 May 2009 00:06:51 +0200
Sender: [email-masked]

1a
4a
3

/Simon

Date: Thu, 28 May 2009 16:46:09 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

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
-- 

Date: Thu, 28 May 2009 22:49:03 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Poll: use of TLS channel bindings in SCRAM
Sender: [email-masked]

Notes:

Date: Thu, 28 May 2009 15:38:20 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

On Thu, May 28, 2009 at 10:39:00PM +0200, Simon Josefsson wrote:
> > 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.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 28 May 2009 22:39:00 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> 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

Date: Thu, 28 May 2009 14:08:58 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

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
-- 

Date: Thu, 28 May 2009 13:31:45 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt 
Sender: [email-masked]

--On Thursday, May 28, 2009 08:41:32 AM -0700 Kurt Zeilenga 
<[email-masked]> 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

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt 
Date: Thu, 28 May 2009 08:41:32 -0700
Sender: [email-masked]

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.

Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
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
Sender: [email-masked]

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

Date: Wed, 27 May 2009 17:13:58 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

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 
> <[email-masked]> 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
-- 

Date: Wed, 27 May 2009 17:40:19 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation  (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

--On Wednesday, May 27, 2009 10:31:41 PM +0100 Alexey Melnikov 
<[email-masked]> 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

Date: Wed, 27 May 2009 22:31:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
CC: [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation  (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

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.

Cc: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
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
Sender: [email-masked]

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 <[email-masked] 
> > 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

Date: Wed, 27 May 2009 16:05:08 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

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 
<[email-masked]> 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

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
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
Sender: [email-masked]

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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Date: Wed, 27 May 2009 11:58:58 -0700
Sender: [email-masked]

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
>
>

Date: Wed, 27 May 2009 19:48:51 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

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

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: WG Last Call: draft-ietf-sasl-scram-01.txt 
Date: Wed, 27 May 2009 11:40:16 -0700
Sender: [email-masked]

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

Date: Wed, 27 May 2009 11:50:32 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

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
-- 

Date: Wed, 27 May 2009 10:55:57 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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.

Date: Wed, 27 May 2009 16:55:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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.

Date: Wed, 27 May 2009 10:35:59 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Wed, May 27, 2009 at 07:08:42AM +0200, Simon Josefsson wrote:
> > 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?

Date: Wed, 27 May 2009 10:33:54 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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
-- 

Date: Wed, 27 May 2009 10:32:14 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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.

Date: Wed, 27 May 2009 11:26:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
CC: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Simon Josefsson wrote:

>>>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.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 27 May 2009 07:08:42 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, May 26, 2009 at 09:40:28PM +0200, Simon Josefsson wrote:
>> > 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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 27 May 2009 07:04:57 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> 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

Date: Tue, 26 May 2009 17:09:59 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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
-- 

Date: Tue, 26 May 2009 22:59:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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:
>  
>
>>>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.

Date: Tue, 26 May 2009 16:14:37 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Request for consensus call on channel binding type negotiation (Re: Updated SASL And Channel Binding document (-03))
Sender: [email-masked]

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:
> > > 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
-- 

Date: Tue, 26 May 2009 21:59:32 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: "Kurt D. Zeilenga" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-scram-01.txt
Sender: [email-masked]

[email-masked] 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.

Date: Tue, 26 May 2009 15:38:00 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 09:44:13PM +0200, Simon Josefsson wrote:
> > 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
-- 

Date: Tue, 26 May 2009 15:36:26 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 09:40:28PM +0200, Simon Josefsson wrote:
> > 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
-- 

Date: Tue, 26 May 2009 15:31:01 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 09:30:30PM +0200, Simon Josefsson wrote:
> > On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
> >> > 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
-- 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-scram-01.txt 
Date: Tue, 26 May 2009 13:00:01 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 21:44:13 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> 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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 21:40:28 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, May 26, 2009 at 06:19:47PM +0200, Simon Josefsson wrote:
>> > 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

Date: Tue, 26 May 2009 20:32:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Simon Josefsson wrote:

>>On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>>    
>>
>>>>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.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 21:30:30 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>> > 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

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Tue, 26 May 2009 12:20:09 -0700
Sender: [email-masked]

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

Date: Tue, 26 May 2009 12:17:55 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Sender: [email-masked]

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
-- 

Date: Tue, 26 May 2009 11:55:13 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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
-- 

Cc: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Tue, 26 May 2009 09:48:08 -0700
Sender: [email-masked]

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

Date: Tue, 26 May 2009 17:46:37 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
>  
>
>>>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.

Date: Tue, 26 May 2009 11:33:01 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 06:19:47PM +0200, Simon Josefsson wrote:
> > 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.

Date: Tue, 26 May 2009 11:28:41 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 06:16:09PM +0200, Simon Josefsson wrote:
> > 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
-- 

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 18:37:33 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> 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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Date: Tue, 26 May 2009 09:26:33 -0700
Sender: [email-masked]

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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 18:19:47 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, May 26, 2009 at 04:23:34PM +0200, Simon Josefsson wrote:
>> > On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
>> >> > 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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 18:16:09 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, May 26, 2009 at 04:17:57PM +0200, Simon Josefsson wrote:
>> > 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

Date: Tue, 26 May 2009 10:52:50 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 04:23:34PM +0200, Simon Josefsson wrote:
> > On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
> >> > 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
-- 

Date: Tue, 26 May 2009 10:46:14 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Sat, May 23, 2009 at 10:40:21AM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >>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.

Date: Tue, 26 May 2009 10:44:46 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Tue, May 26, 2009 at 04:17:57PM +0200, Simon Josefsson wrote:
> > 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
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-13.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 16:40:58 +0200
Sender: [email-masked]

[email-masked] writes:

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

I believe this version is ready for WGLC.

/Simon

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 16:33:53 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> 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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-13.txt 
Date: Tue, 26 May 2009 07:30:01 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 16:23:34 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
>> > 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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 16:17:57 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> 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

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 May 2009 16:12:14 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> 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

Date: Mon, 25 May 2009 22:16:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Sender: [email-masked]

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.

Date: Mon, 25 May 2009 13:52:35 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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.

Date: Mon, 25 May 2009 13:51:06 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Sender: [email-masked]

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
-- 

Date: Mon, 25 May 2009 13:28:25 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: GS2 is ready for WG LC too
Sender: [email-masked]

On Mon, May 25, 2009 at 03:15:19PM +0200, Simon Josefsson wrote:
> > 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
-- 

Date: Mon, 25 May 2009 13:16:51 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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.

Date: Mon, 25 May 2009 13:14:42 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

On Mon, May 25, 2009 at 01:46:04PM +0200, Simon Josefsson wrote:
> > 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
-- 

Date: Mon, 25 May 2009 18:17:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: GS2 is ready for WG LC too
Sender: [email-masked]

Simon Josefsson wrote:

>>>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?

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: GS2 is ready for WG LC too
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 25 May 2009 15:15:19 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> 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

Date: Mon, 25 May 2009 13:39:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: GS2 is ready for WG LC too  (was Re: I-D Action:draft-ietf-sasl-scram-00.txt)
Sender: [email-masked]

Simon Josefsson wrote:

>>[email-masked] 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.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 25 May 2009 14:14:16 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> [email-masked] 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

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 25 May 2009 14:05:47 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>>>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

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 25 May 2009 13:46:04 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Nicolas Williams wrote:
>
>>On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>>  
>>
>>>>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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: SASL WG meeting in Stockholm
Date: Sun, 24 May 2009 03:15:54 -0700
Sender: [email-masked]

I've now submitted our usual request.  -- Kurt

Date: Sat, 23 May 2009 15:35:08 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-scram-00.txt
Sender: [email-masked]

[email-masked] 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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-scram-00.txt 
Date: Sat, 23 May 2009 07:15:01 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

Date: Sat, 23 May 2009 14:01:49 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

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.

Date: Sat, 23 May 2009 13:41:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Simon Josefsson wrote:

>Kurt Zeilenga <[email-masked]> writes:
>
>>On Apr 22, 2009, at 2:53 AM, Simon Josefsson wrote:
>>    
>>
>>>>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.

Date: Sat, 23 May 2009 14:27:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Cc: Nicolas Williams <[email-masked]>, [email-masked], Simon Josefsson <[email-masked]>
Sender: [email-masked]

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

Date: Sat, 23 May 2009 13:12:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

Simon Josefsson wrote:

>>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.

Date: Sat, 23 May 2009 10:40:21 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Simon Josefsson wrote:

>>On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
>>    
>>
 [...]

>>>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.

Date: Sat, 23 May 2009 10:31:19 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

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.

Date: Sat, 23 May 2009 10:18:28 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Nicolas Williams wrote:

>On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>  
>
>>>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.

Date: Sat, 23 May 2009 09:23:40 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: SASL WG meeting in Stockholm
Sender: [email-masked]

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?

Date: Tue, 5 May 2009 14:49:13 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on YAP
Sender: [email-masked]

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
--