Subject: Re: Updated SASL And Channel Binding document (-03)

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 May 2009 10:18:28 +0100

Nicolas Williams wrote:

>On Wed, Apr 22, 2009 at 11:53:35AM +0200, Simon Josefsson wrote:
>  
>
>>Nicolas Williams <[email-masked]> writes:
>>    
>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-03.txt
>>>      
>>>
>>Thanks.  Something along these lines is needed before we can implement
>>SCRAM and GS2.
>>    
>>
>Well, no, but we do need this before SCRAM and GS2 can progress, IMO.
>  
>
I would rather not make SCRAM depend on yet another draft we need to get 
consensus on. We might never finish this way.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 May 2009 10:31:19 +0100

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 May 2009 10:40:21 +0100

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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sat, 23 May 2009 14:27:57 +0200

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 23 May 2009 13:41:18 +0100

Simon Josefsson wrote:

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 25 May 2009 13:46:04 +0200

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 May 2009 13:14:42 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 May 2009 13:16:51 -0500

> >"X.509 [PKIX] server certificate".

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.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 16:17:57 +0200

> ..." 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]>
Date: Tue, 26 May 2009 16:23:34 +0200

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

> leaving us with a preference for end-point channel binding types over

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]>
Date: Tue, 26 May 2009 16:33:53 +0200

Kurt Zeilenga <[email-masked]> writes:

> Simon wrote:
>> There is no interface
> 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: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 10:44:46 -0500

>    client and server MUST use the 'tls-unique' channel binding type.

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: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 10:46:14 -0500

> server-advertised SASL mechanisms in plugins.

Channel binding will require new APIs.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 10:52:50 -0500

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 18:19:47 +0200

> happens in the document rather than in the protocol" is not really

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.

> 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]>
Date: Tue, 26 May 2009 18:16:09 +0200

>    supports channel bindings of type 'tls-unique' type, then those MUST

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 11:28:41 -0500

> 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: Alexey Melnikov <[email-masked]>
Date: Tue, 26 May 2009 17:46:37 +0100

>>For consistency, SCRAM would need to be updated as well, though.
I will post the updated version today.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 May 2009 09:48:08 -0700

> leaving us with a preference for end-point channel binding types over

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 11:33:01 -0500

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

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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 11:55:13 -0500

> however that some prefer use of end-point channel binding types in  

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

> One solution for SCRAM is to offer:

That complicates everything.

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 May 2009 12:20:09 -0700

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

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.

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

> context of a WGLC or not.  Either way we need a resolution.

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.

> would not complicate SCRAM/GS2.

I rather avoid multiple levels of negotiation.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 21:30:30 +0200

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 May 2009 20:32:41 +0100

>having a normative reference to them.
Simon, I share your concern.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 21:40:28 +0200

Nicolas Williams <[email-masked]> writes:

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 15:31:01 -0500

> 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: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2009 21:44:13 +0200

> however that some prefer use of end-point channel binding types in

My preference is also the unique channel binding.

> One solution for SCRAM is to offer:

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: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 15:36:26 -0500

> for the channel binding types it needs.  That seems more efficient, and

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

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 15:38:00 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 16:14:37 -0500

> tls-unique bindings is a recipe for non-interoperability.  Therefore I

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 May 2009 22:59:40 +0100

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

>>My preference is also the unique channel binding.
For the record - so is mine.

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 26 May 2009 17:09:59 -0500

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

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

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

> You might end up being in the rough part of the consensus.

Perhaps so.

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 May 2009 07:04:57 +0200

> however, is not what this thread is about, and it's not necessary to

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 May 2009 07:08:42 +0200

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

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

> 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 would be irresponsible of us to do otherwise.

Certainly.  The devil is in the details.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 May 2009 11:26:29 +0100

>a channel binding type that isn't under the IESG's change control is a
Agreed.

>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
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: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 10:32:14 -0500

> 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

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 10:33:54 -0500

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 10:35:59 -0500

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

> Certainly.  The devil is in the details.

So why insist on rushing SCRAM/GS2 through?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 May 2009 16:55:14 +0100

Nicolas Williams wrote:

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 10:55:57 -0500

> >through without updating SASL, yet now would have SCRAM/GS2 block on a

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.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 11:50:32 -0500

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 27 May 2009 12:16:09 -0700

> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 May 2009 16:05:08 -0400

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.

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 27 May 2009 14:02:15 -0700

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've kept quiet until now, because I'm busy and really don't have  
> time for this.  However...
>

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.

>   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

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

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

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 May 2009 22:31:41 +0100

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.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 May 2009 17:40:19 -0400

> little would change if we can reach consensus on channel binding

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.

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

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

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 27 May 2009 17:13:58 -0500

> past.  It is my strong preference to avoid going there, but it might happen 

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.

> not mean we have failed to reach consensus; it means the consensus is not 

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

---

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

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

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

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

---

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

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

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