Subject: I-D Action:draft-ietf-sasl-channel-bindings-00.txt

From: [email-masked]
Date: Thu, 9 Apr 2009 16:15:01 -0700 (PDT)

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           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-00.txt
	Pages           : 8
	Date            : 2009-04-09

This document specifies the semantics of channel binding for the
Simple Authentication and Security Layers (SASL) framework,
mechanisms and applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-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.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 13 Apr 2009 14:03:47 -0700

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

-- Kurt

On Apr 9, 2009, at 4:15 PM, [email-masked] wrote:

> <mime-attachment>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 16:19:24 -0500

> EXTERNAL mechanism (which, BTW, I have in the works).

Can you elaborate?  Also, EXTERNAL is just not an issue.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 13 Apr 2009 15:55:53 -0700

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

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 01:15:41 +0200

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

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 18:07:21 -0500

> as a convenient means to uniquely identify a channel.

You're conflating unrelated things.  That you want to use the
authenticated client ID from a lower layer has nothing to do with
channel binding.  EXTERNAL does NOT do channel binding in the RFC5056
sense or any other sense for that matter.

YAP is interesting though: it depends on using a unique channel binding
rather than an end-point channel binding because it uses the unique
channel binding as a nonce.

So I see your point w.r.t. YAP.

I think what we can do then is this: the application MUST provide all
the types of channel binding available and the mechanism MUST pick one
to use according to the default rules we shall list (prefer
tls-server-end-point over tls-unique) or one specified for the mechanism
(YAP always insists on tls-unique).

That's more complex than I'd prefer.  I don't mind the alternatives
though: either forget YAP or use of YAP will require YAP-specific logic
in the application.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 18:47:45 -0500

> sense or any other sense for that matter.

I should preempt your response: the channel binding cannot help the
mechanism (in this case EXTERNAL) find the authenticated ID of the
corresponding channel.  Consider an implementation where TLS is being
done in a different process than the one where SASL is being done: how
does knowledge of the channel binding help the SASL mech find the
channel?

For EXTERNAL the app will just have to retrieve the authenticated ID
itself.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 02:19:35 +0200

> For EXTERNAL the app will just have to retrieve the authenticated ID

The name of the channel will help, though.  Then the app will know to
use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
etc.

I'm not certain the channel binding documents is useful here though, it
will require implementers to understand all channel bindings available
for, e.g., TLS.  It may be simpler to do EXTERNAL-* directly.

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 13 Apr 2009 17:47:13 -0700

On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:

>> You're conflating unrelated things.

I agree I was conflating issues.

The use of the channel binding information would be merely to allow  
the client to identify to the server which channel to pull the  
authentication identity from.

I won't raise EXTERNAL in this thread again (if you don't :-).

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 13 Apr 2009 19:38:26 -0700

> (YAP always insists on tls-unique).

My concern holds:
   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.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 22:02:31 -0500

> authentication identity from.

No, absolutely not.  The channel binding type is not being negotiated.
The only things we're negotiating are: which mechanism, and whether to
do channel binding.  Thus the channel binding type has to be agreed upon
from context and a priori.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 22:01:19 -0500

> The name of the channel will help, though.  Then the app will know to
                                   ^
Help who?  Not the mechanism.

> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS

The server doesn't get to find out what channel binding type was used by
looking at the token.  The server has to know a priori.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 13 Apr 2009 22:05:30 -0500

> other mechanisms which support channel bindings do so in a like way.

I don't quite agree.  We're not saying "you can't use the channel
binding as an input to key derivation" or "you can't send the channel
binding as is."  What we are saying is: the channel binding type is not
negotiated, therefore it has to be known from context.

Ignoring YAP the relevant context is: the use or non-use of a TLS server
cert.  To allow for YAP we need to make the relevant context be
mechanism-specific (for YAP: always tls-unique, for all others so far:
the use or non-use of a TLS server cert).

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 13 Apr 2009 21:48:00 -0700

> negotiated, therefore it has to be known from context.

No, what you are saying (as I read your I-D) is that future mechanism  
providing channel bindings MUST do so in a way that similar to a  
particular set of mechanisms (whether that set is just GS2-* or GS2-*  
+ YAP is not relevant to my concern).  I don't see stating such  
restrictions as being appropriate.  While I agree that it is desirable  
for future mechanisms not to be unnecessarily different than existing  
mechanisms, I think rather avoid mandating commonality here and  
elsewhere.  In RFC 4422, we generally only RECOMMENDED commonality for  
certain kinds of information.  This allows for future mechanisms to  
address issues we haven't yet even thought.

-- Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Apr 2009 07:54:04 +0100

>No, absolutely not.  The channel binding type is not being negotiated.
Why not?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Apr 2009 09:52:23 +0200

> Help who?  Not the mechanism.

Help server applications to know which security channel layer to look
for user credentials.  This is under specified in EXTERNAL, and I
suspect it is one reason EXTERNAL isn't widely supported by, e.g., MUAs
that support client TLS authentication.

> looking at the token.  The server has to know a priori.

Why?

If the client tells the server to look for credentials in, e.g., the TLS
channel, the server can do so.  If that doesn't work, the expected
outcome is failure.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 10:39:34 -0400

--On Monday, April 13, 2009 09:48:00 PM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> particular set of mechanisms (whether that set is just GS2-* or GS2-* +
> YAP is not relevant to my concern).  I don't see stating such

Channel bindings are not a parameter for the mechanism to "use" however it 
wants.

The purpose of channel bindings is to cryptographically bind a lower-layer 
channel to the authentication process, in order to eliminate the 
possibility of a MitM attack.  Channel bindings are passed to a mechanism 
specifically for this purpose, and the mechanism is expected to indicate 
whether or not the channel bindings provided at both ends are the same. 
This is _important_; when an application passes channel bindings to SASL, 
it is saying "I intend to use this lower-layer channel and to depend on it 
to protect the integrity and/or confidentiality of my communication; is 
that safe?".

For a mechanism to "use" channel binding data in another way, such as was 
suggested for EXTERNAL, would violate the assumptions of the application in 
a way that breaks the abstraction, requiring applications to have 
mechanism-specific knowledge such as "If I'm using SCRAM-PLUS, I should 
pass in channel bindings corresponding to the channel I want SCRAM to 
authenticate (which probably doesn't have its own client credentials), but 
if I'm using EXTERNAL-CHANNEL, I need to pass in channel bindings 
corresponding to the channel I have already authenticated and whose client 
authentication I want the mechanism to use".  The first usage is consistent 
with the purpose of channel bindings; the second is inappropriately 
overloading them to mean something else.

With regard to the needs of YAP, I think it would be fine for a mechanism 
to have the property that it depends on the channel used to be a unique 
channel, rather than an endpoint channel.  This would be a property of the 
mechanism, never something that is negotiated; if you don't _have_ a unique 
channel to bind to, then YAP should not be advertised.

Now, to date your objections have been quite vague.  Can you please point 
to one or more specific MUSTs or SHOULDs that you disagree with, and 
explain why?  Otherwise we are going to keep going around in circles 
forever.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:32:03 -0500

> >No, absolutely not.  The channel binding type is not being negotiated.

Oh, it could be.  But that's not part of SCRAM nor GS2 at this time.  So
far we did not need it to be negotiable, and I don't think YAP is enough
to make it so we have to make it negotiable (EXTERNAL is not even
relevant to this).

If we want to make the channel binding type negotiable _now_ is the time
to do it, and as with the use of channel binding itself, it will have to
be done as part of the mechanism negotiation.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 11:30:01 -0500

> that support client TLS authentication.

You don't need to name the channel binding or type.  You need only name
the _layer_ where the channel is that EXTERNAL is referring to.

> > looking at the token.  The server has to know a priori.

I was referring to GS2 mechanisms there (the GSS-API does not expose
this information).

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 10:39:14 -0700

On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman wrote:

>
> --On Monday, April 13, 2009 09:48:00 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>
>>
> Channel bindings are not a parameter for the mechanism to "use"  
> however it wants.

The point is more that we shouldn't assume there is one and only one  
channel binding framework.  RFC 5056 and the particulars of this I-D  
are in their early stage in its adoption, we should be careful not to  
assume either is the end-all solution to channel bindings.  For  
instance, it's quite unclear that the dual naming approach is the end- 
all negotiation solution (we haven't tried it in the real world yet).

Channel binding to me is, I think, still a limited extension to SASL.   
No well established mechanism uses channel binding, and we only have a  
couple presently in the works.

I simply think it's too early to treat channel bindings as if it were  
a mature feature of SASL.

>
>
>
> The purpose of channel bindings is to cryptographically bind a lower- 
> layer channel to the authentication process, in order to eliminate  
> the possibility of a MitM attack.  Channel bindings are passed to a  
> mechanism specifically for this purpose, and the mechanism is  
> expected to indicate whether or not the channel bindings provided at  
> both ends are the same. This is _important_; when an application  
> passes channel bindings to SASL, it is saying "I intend to use this  
> lower-layer channel and to depend on it to protect the integrity and/ 
> or confidentiality of my communication; is that safe?".
>
> For a mechanism to "use" channel binding data in another way, such  
> as was suggested for EXTERNAL, would violate the assumptions of the  
> application in a way that breaks the abstraction, requiring  
> applications to have mechanism-specific knowledge such as "If I'm  
> using SCRAM-PLUS, I should pass in channel bindings corresponding to  
> the channel I want SCRAM to authenticate (which probably doesn't  
> have its own client credentials), but if I'm using EXTERNAL-CHANNEL,  
> I need to pass in channel bindings corresponding to the channel I  
> have already authenticated and whose client authentication I want  
> the mechanism to use".  The first usage is consistent with the  
> purpose of channel bindings; the second is inappropriately  
> With regard to the needs of YAP, I think it would be fine for a  
> mechanism to have the property that it depends on the channel used  
> to be a unique channel, rather than an endpoint channel.  This would  
> be a property of the mechanism, never something that is negotiated;  
> if you don't _have_ a unique channel to bind to, then YAP should not  
> be advertised.
>
>
>
> Now, to date your objections have been quite vague.

At present, I am trying to focus on the primary issue I have and hence  
I haven't attempted to slam each secondary issue I have.  That would  
be a lot of work, as I have problems with nearly every line of the I- 
D.  Hence, at present, I intend to focus on the basic premise of the I- 
D which I disagree with.

 From section 1:
>    The introduction of the Salted Challenge Response (SCRAM) SASL  
> mechanism [I-D.newman-auth-scram] and GS2 family of SASL mechanisms  
> [I-D.ietf-sasl-gs2] requires the introduction into SASL of an  
> abstract interface to channel binding [RFC5056].

I simply disagree that the introduction of mechanisms which support  
channel bindings requires any change to RFC 4422.  While certainly  
introduction of mechanisms with new features requiring new kinds of  
information to be provided to it will require changes in  
implementation to obtain and provide this information, this is already  
discussed in RFC 4422.

>    While this layer does generally hide the particulars of protocols  
> from mechanisms and the particulars of mechanisms from protocols,
>    this layer does not generally hide the particulars of mechanisms  
> from protocol implementations. For example, different mechanisms
>    require different information to operate, some of them use  
> password-based authentication, some of then require realm  
> information, others make use of Kerberos tickets, certificates, etc.

While one could add "some might support channel bindings" to this  
list, but given it's only a 'for example', that's not necessary.

And as far as the statements premise referring to a need to establish  
what the INTERNAL interface between components of an implementation,  
such as component primarily implementing an application protocol, a  
component primarily implement a SASL framework, a component  
implementing a particular SASL mechanism, a component implementing a  
lower-lever security service such as TLS, I argue that these are  
implementation details.   RFC 4422 has no business specify what is to  
passed between such components and when... it shouldn't even make  
assumptions that such components exist as separate modules of code  
with distinct abstract interfaces between them.  Very unlike this  
document, RFC 4422 purposely avoided getting into the details of  
interfaces between components of an implementation.

Now, what I would suggest is to start with a slight different premise:  
It is desirable for mechanisms supporting channeling binding do so in  
similar manner.  And then to make some RECOMMENDations along this  
line.  Such as adding to Section 5 of RFC 4422,

   SASL mechanisms SHOULD reuse existing channel bindings forms, as  
well as associated syntaxes and semantics, such as detailed in  
[RFC5056].

and then work outward from there (adding some discussion of channel  
binding security considerations, etc.).

I also think that if the WG did want add text in the SASL technical  
specification concerning channel bindings (whatever that text might  
be), that it would be far better to do so as part of revising RFC 4422  
itself instead of an update RFC.   The problem is that while the  
update RFC might read fine (to some) on its own, it doesn't  
necessarily read with in concert with what RFC 4422 says.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 12:54:46 -0500

> couple presently in the works.

But that's precisely why we now must define what channel binding means
in the context of SASL.  By "means" I mean: what impact it has on
abstract APIs, and, since we've decided to make the use of channel
binding negotiable, what impact it has on application protocols.

> a mature feature of SASL.

I don't understand that statement.  We have consensus, I think, for
SCRAM not providing security layers and for relying on channel binding
for protection against MITMs.  That means we MUST specify what channel
binding means in the context of SASL.  Whether what we specify is
"mature" or not does not enter the picture -- the IETF does not insist
on deployment before standardization, and I'm surprised to see you
arguing, effectively, that it does.

> D.  Hence, at present, I intend to focus on the basic premise of the I- 

You're not giving us much to work with.  State your objection(s).
(Though I believe I've figured it out from your reference to YAP, as I
wrote earlier.)

> implementation to obtain and provide this information, this is already  

Did you read the sub-thread we had where Jeff H. commented that the
logic for selecting a channel binding type to use needed to be not
mechanism-specific?  That's what gave rise to this I-D.  It might help
for you to comment on Jeff's points.

> what the INTERNAL interface between components of an implementation,  

I wrote "abstract."  It's definitely NOT an internal interface.  We've a
number of applications available for Linux/Solaris/*BSD/Windows that use
SASL via a system library.  Those interfaces are most definitely
public, not internal.

> implementation details.

The interfaces between those components must be public interfaces unless
the application is monolythic (i.e., all the components are from the
same implementor, tightly integrated, and not separately
replaceable/updateable).

>                           RFC 4422 has no business specify what is to  

Nonsense.  Why even have RFC4422 if there's no room for public SASL
interfaces?

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 12:06:38 -0700

On Apr 14, 2009, at 10:54 AM, Nicolas Williams wrote:

> abstract APIs,

RFC 4422 purposed avoided detailing APIs.  It merely says that  
generally possible to abstract interfaces between application  
protocols and a framework and between a framework and a mechanisms.   
It leaves the particulars of what boundaries to draw between  
components of an implementation to the implementation, as well as the  
particulars of what is passed over those boundaries, and when, etc.

> and, since we've decided to make the use of channel

> binding negotiable, what impact it has on application protocols.

No, we've (basically) decided that use of channel binding in SCRAM and  
GS should be negotiable.   We haven't made any decision that all  
futures that support channel bindings must do so in a manner which is  
negotiable.

> for protection against MITMs.

Yes, but consensus on SCRAM doesn't imply consensus for all future  
mechanisms.

> That means we MUST specify what channel
> binding means in the context of SASL.

In the context of SCRAM certainly.  In general, no.

> Whether what we specify is

We're in the process of revising RFC 4422 for draft standard status,  
so maturity is a factor in what we put into RFC 4422.

But my point was less about IETF process, and more about possibly bad  
assumptions that the solutions we have to day are the end-all  
solutions.  I want to avoid unnecessarily restricting the future  
design of new mechanisms.

> (Though I believe I've figured it out from your reference to YAP, as I

I gave YAP as only an example of how your assumptions in your I-D  
didn't account for what mechanisms folks might want to reasonable  
design and use.

My point is that your assumption that we today can come up with a  
channel binding solution to end all solutions is a bad assumption.    
We should assume it's a good enough solution for today.  While  
recommending future mechanisms not differ unnecessarily might be  
reasonable, saying they MUST do channel binding as detailed in I-D is,  
IMO, a bad thing.

> mechanism-specific?

Yes, and I agree it need not be mechanism specific.  However, I  
disagree that it need be the same in all mechanisms.

> That's what gave rise to this I-D.  It might help

> SASL via a system library.  Those interfaces are most definitely

The point here is that any interface between components of an  
implementation are implementation details, not protocol details.  RFC  
4422 specifies protocol, not implementation details.

Your I-D gets into details which RFC 4422 left to implementors.  For  
instance, it mandates what and when and how channel binding data is  
passed between two components of implementation.

> same implementor, tightly integrated, and not separately

Whether or not such interfaces are public or private is orthogonal to  
whether the interfaces are implementation details or protocol  
details.  I argue they are not protocol details, they are  
implementation details.

> Nonsense.  Why even have RFC4422 if there's no room for public SASL

RFC 4422 provides a conceptional model and a requirement mechanism and  
protocol specifications.  Without ever getting into public SASL  
interfaces, SASL has been widely and successfully deployed.

You appear to argue that channel binding will not being widely and  
successfully deployed unless we get into these implementation  
details.  I think our operational experience with RFC 2222 and RFC  
4422 counters your argument.

-- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 15:37:58 -0400

--On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

>
> RFC 4422 purposed avoided detailing APIs.

We're talking about abstractions, not API's.

> It merely says that generally
> possible to abstract interfaces between application protocols and a
> framework and between a framework and a mechanisms.  It leaves the
> particulars of what boundaries to draw between components of an
> implementation to the implementation, as well as the particulars of what
> is passed over those boundaries, and when, etc.

Not really.  It _claims_ to do that, but then it goes on to describe what 
is expected of protocols and mechanisms.  It _does_ create an abstraction; 
if it didn't, it would be useless.

For example, we know that mechanisms produce tokens which the protocol is 
expected to transport back and forth, but whose format and semantics are 
known only to the mechanism.  And, we know that the client and server sides 
of a mechanism always take turns producing tokens, so that the protocol can 
transport them via a challenge/response or request/reply sort of exchange.

We know that mechanisms result in either success or failure, but that it is 
up to the protocol to decide how to convey this from server to client.  In 
the case of success, mechanisms also produce an authenticated name, whose 
syntax and semantics are mechanism-specific(*).

We also know that protocols may provide an authorization name, whose syntax 
and semantics are known only to the protocol, but which the mechanism is 
responsible for transporting from client to server, possibly (preferably?) 
in a secure manner.

We know that mechanisms may provide a facility for encryption and/or 
integrity protection of application data exchange after the authentication 
process completes.  We know that when such a layer is in use, it works by 
the protocol passing definite-length chunks of protocol data ("buffers") to 
the mechanism, which transforms them into buffers of protected data in a 
mechanism format.  The protocol is then responsible for transporting the 
protected buffers and handing them to the mechanism on the far end, which 
transforms them back into plain protocol data.

All of this, and more, we know because RFC4422 specifies these things about 
the interaction between protocols and mechanisms, without regard to which 
protocol and which mechanism.  That is an abstract interface.  "Interface" 
does not always mean "C function call API".

What draft-ietf-sasl-channel-bindings does is extend the abstract interface 
defined by RFC4422 to encompass handling of channel bindings.  It does so 
by saying that mechanisms may support channel binding and protocols may 
provide CB data to the mechanism.  When the mechanism supports CB and the 
protocol client and server both provide CB data, then authentication 
succeeds only when the CB data provided on both ends matches.  Like the 
other items listed above, this behavior is and should be independent of 
which protocol and which mechanism is used.

> No, we've (basically) decided that use of channel binding in SCRAM and GS
> should be negotiable.   We haven't made any decision that all futures
> that support channel bindings must do so in a manner which is negotiable.

> In the context of SCRAM certainly.  In general, no.

No, if we do it at all, we must do it at the SASL layer.  Attempting to do 
it only at the SCRAM layer violates the abstraction, by requiring every 
protocol to have mechanism-specific knowledge.  That would defeat the point 
of having SASL in the first place.

> Yes, and I agree it need not be mechanism specific.  However, I disagree
> that it need be the same in all mechanisms.

Then you missed my point.  The point is _not_ that it does not need to be 
mechanism-specific.  The point is that it _does_ need to _not_ be 
mechanism-specific.  This is how we avoid writing a hundred new RFC's 
whenever someone designs a new mechanism.  It's also how sane application 
protocol implementors avoid having to change their implementations for 
every new mechanism.

If you want to implement every combination of protocol x mechanism 
separately, feel free.  But don't deny me the abstraction that allows me to 
instead implement each protocol once and each mechanism once, and further 
to let someone else do most of that work while I reap the benefits simply 
by changing configuration.

Abstraction is _important_.
Modularity is _important_.

These things provide scalability, and thus feasibility.
These things make the difference between analysis that is too complicated 
to be possible, and analysis that is simple enough to do.

Having channel bindings work the same way for every protocol and for every 
mechanism allows me to analyze how each protocol handles channel bindings 
and how each mechanism handles channel bindings, instead of having to 
separately analyze each combination.  This significantly improves my job in 
promoting the security of my site and of the Internet.

> 4422 specifies protocol, not implementation details.

RFC 4422 specifies almost no protocol.
It specifies an abstraction.

> passed between two components of implementation.

No, it mandates what and when and how channel binding data is passed 
between abstract components in a (implied) block diagram, which may or may 
not bear any resemblance to an actual implementation.  In the same way that 
RFC4422 mandates what and when and how mechanism tokens or security layer 
buffers are passed between the same abstract components.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Apr 2009 14:34:26 -0500

> RFC 4422 purposed avoided detailing APIs.  It merely says that  

Nonetheless it contains enough text to derive abstract APIs from.
Certainly there exist concrete SASL APIs.  Avoid the matter all you
want, but the fact is that no one really builds monolythic apps with
embedded TLS and SASL implementations.

> futures that support channel bindings must do so in a manner which is  

That's true, but the channel binding type is not negotiated, so that
does impact the abstract APIs (whether you believe in them or not).

Let's short-circuit this discussion as we're going around in circles.
You are asserting that YAP by design can only use unique channel binding
types and, indeed, MUST use channel binding with unique channel binding
types.  And you want this to fit in the SASL channel binding concept,
whether that concept exists as a specification or not.

Fine.  Propose some text, possibly using the alternative approach that I
mentioned: require that applications provide *all* available channel
bindings for all available types for the channel being bound to.  Then
the mechanism can select which one to use.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 13:52:52 -0700

On Apr 14, 2009, at 12:37 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 12:06:38 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>

I argue that the I-D does detail interfaces (beyond what RFC 4422  
says).  It specifically discusses what and when channel binding  
information and mechanism information is to be passed between  
components of an implementation.

     In order to use SASL [RFC4422] with channel binding the client  
and server applications MUST provide a channel binding type and  
channel binding data to the selected SASL mechanism before the first  
mechanism's authentication message is produced (client side) or  
consumed (server side).
This is unnecessarily prescriptive.
> Not really.  It _claims_ to do that, but then it goes on to describe  
> what is expected of protocols and mechanisms.  It _does_ create an  
> abstraction; if it didn't, it would be useless.

Yes, but it's descriptive in nature, not prescriptive.  I find the  
language in the I-D far too prescriptive.

>
>
> For example, we know that mechanisms produce tokens which the  
> protocol is expected to transport back and forth, but whose format  
> and semantics are known only to the mechanism.  And, we know that  
> the client and server sides of a mechanism always take turns  
> producing tokens, so that the protocol can transport them via a  
> challenge/response or request/reply sort of exchange.
>
> We know that mechanisms result in either success or failure, but  
> that it is up to the protocol to decide how to convey this from  
> server to client.  In the case of success, mechanisms also produce  
> an authenticated name, whose syntax and semantics are mechanism- 
> specific(*).
>
> We also know that protocols may provide an authorization name, whose  
> syntax and semantics are known only to the protocol, but which the  
> mechanism is responsible for transporting from client to server,  
> possibly (preferably?) in a secure manner.
>
> integrity protection of application data exchange after the  
> authentication process completes.  We know that when such a layer is  
> in use, it works by the protocol passing definite-length chunks of  
> protocol data ("buffers") to the mechanism, which transforms them  
> into buffers of protected data in a mechanism format.  The protocol  
> is then responsible for transporting the protected buffers and  
> handing them to the mechanism on the far end, which transforms them  
> back into plain protocol data.
>
>
> All of this, and more, we know because RFC4422 specifies these  
> things about the interaction between protocols and mechanisms,  
> without regard to which protocol and which mechanism.  That is an  
> abstract interface.  "Interface" does not always mean "C function  
> call API".

Of course.   I've tried to avoid use of the term API.

> What draft-ietf-sasl-channel-bindings does is extend the abstract  
> interface defined by RFC4422 to encompass handling of channel  
> bindings.

I argue that
	1) no change to RFC 4422 is required to "handle channel bindings"
	(the I-D implies changes are required)

	2) while adding some recommendations and considerations might be  
appropriate at this time,
         I generally think it premature to mandate particulars of  
channel binding in the SASL specification.

> It does so by saying that mechanisms may support channel binding and  
> protocols may provide CB data to the mechanism.

The I-D and its proponents appear to be arguing that changes to RFC  
4422 are required for SCRAM, YAP and other mechanisms to be  
successfully implemented and deployed, and uses this 'requirement' to  
justify nearly a dozen mandates.

I argue that the premise that changes to RFC 4422 are required is  
incorrect.  No change to RFC 4422 is required for such mechanisms to  
be successfully implemented and deployed.

So before we argue about individual mandates, I'd like the premise of  
the I-D to be restated.

> When the mechanism supports CB and the protocol client and server  
> both provide CB data, then authentication succeeds only when the CB  
> data provided on both ends matches.  Like the other items listed  
> above, this behavior is and should be independent of which protocol  
> and which mechanism is used.

I might agree to such so long as we don't mandate the CB data be RFC  
5056 CB data.  Now maybe I read too much in the draft, but given that  
my suggested SHOULD was not well received by Nico, I assume I read the  
I-D correctly.

> No, if we do it at all, we must do it at the SASL layer.  Attempting  
> to do it only at the SCRAM layer violates the abstraction, by  
> requiring every protocol to have mechanism-specific knowledge.

RFC 4422 doesn't hide particulars of mechanism implementations from  
particulars of framework implementations from particulars of  
application protocol mechanisms.

The RFC 4422 abstraction only allows for protocols and mechanisms to  
be specified independently.

New mechanisms have always tended to introduce new data requirements  
which impact interfaces between components of an implementation.  Such  
an introduction does not break the SASL conceptional model, the impact  
is simply an artifact of the conceptional model.

RFC 4422 says:
    It is possible to design and implement this framework in ways that  
do
    abstract away particulars of similar mechanisms.  Such a framework
    implementation, as well as mechanisms implementations, could be
    designed not only to be shared by multiple implementations of a
    particular protocol but to be shared by implementations of multiple
    protocols.

So, from an RFC 4422 perspective, the differences in channel bindings  
between say it is possible to abstract away particulars of SCRAM and  
YAP channel binding, but that some future mechanism may not fit into  
that abstract.

> That would defeat the point of having SASL in the first place.

I guess we disagree on the point of SASL is.

>> disagree
> Then you missed my point.  The point is _not_ that it does not need  
> to be mechanism-specific.  The point is that it _does_ need to _not_  
> be mechanism-specific.  This is how we avoid writing a hundred new  
> RFC's whenever someone designs a new mechanism.  It's also how sane  
> application protocol implementors avoid having to change their  
> implementations for every new mechanism.

I argue it is premature to view our channel binding solution to be the  
end-all solution to channel binding.

> separately, feel free.  But don't deny me the abstraction that  
> allows me to instead implement each protocol once and each mechanism  
> once,

Oh please.  Nothing I suggest hinders your ability to abstract away  
the particulars of mechanisms and protocols.  Folks have been doing  
this for ages.

> and further to let someone else do most of that work while I reap  
> the benefits simply by changing configuration.
>

I assume some implementors will continue to let you do such that.   
Nothing in RFC 4422 ever said implementors of SASL were required to  
abstract away the particulars of mechanisms.  They simply choose to do  
so (and for good reason).

What RFC 4422 did was leave the particulars of such abstractions to  
implementors.  Whether and how a particular implementor chooses to  
abstract away any particular mechanism difference has been, and should  
continue to be, an implementation choice.

> These things make the difference between analysis that is too  
> complicated to be possible, and analysis that is simple enough to do.
>
> Having channel bindings work the same way for every protocol and for  
> every mechanism allows me to analyze how each protocol handles  
> channel bindings and how each mechanism handles channel bindings,  
> instead of having to separately analyze each combination.  This  
> significantly improves my job in promoting the security of my site  
> and of the Internet.
>
>

A very limited abstraction.

> between abstract components in a (implied) block diagram, which may  
> or may not bear any resemblance to an actual implementation.  In the  
> same way that RFC4422 mandates what and when and how mechanism  
> tokens or security layer buffers are passed between the same  
> abstract components.

I guess we'll just have to agree to disagree.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 14:20:05 -0700

> Let's short-circuit this discussion as we're going around in circles.

Okay.

> whether that concept exists as a specification or not.

I note that I only used YAP in this thread to illustrate that what we  
thing today (or, I guess yesterday) was adequate for all future  
mechanisms is not necessarily adequate.

The fact that you can adjust your proposal to account for YAP says  
nothing about your current or modified proposal being about to deal  
well with what some future mechanism designer might wish to do in  
their mechanism.

> the mechanism can select which one to use.

I already proposed an alternative approach but you seemed to have  
ignored it.

I'll repeat it here:

-- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Apr 2009 17:27:58 -0400

--On Tuesday, April 14, 2009 01:52:52 PM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

>> <[email-masked]
> I argue that the I-D does detail interfaces (beyond what RFC 4422 says).
> It specifically discusses what and when channel binding information and
> mechanism information is to be passed between components of an
> implementation.
>
>      In order to use SASL [RFC4422] with channel binding the client and
> server applications MUST provide a channel binding type and channel
> binding data to the selected SASL mechanism before the first mechanism's
> authentication message is produced (client side) or consumed (server
> side).

No, it's not, though you may be reading too much into it.  A SASL protocol 
must be prepared to make channel binding information available to the 
mechanism by the first time the mechanism produces or consumes a message, 
because some mechanisms will be unable to process channel bindings unless 
the data is available at that time.  We're not telling you how your 
implementation API has to work; we're telling you not to design a protocol 
that expects not to provide channel binding data to the mechanism until 
after some mechanism tokens have been exchanged, because such a protocol 
will not work.

> language in the I-D far too prescriptive.

No, it's prescriptive.  It doesn't describe how the existing mechanisms and 
protocols happen to be; it describes things that must be true of all 
mechanisms and protocols and they way they interact.  Unless you're using 
the words "descriptive" and "prescriptive" in a with which I'm not familiar.

>          I generally think it premature to mandate particulars of channel
> binding in the SASL specification.
>
> The I-D and its proponents appear to be arguing that changes to RFC 4422
> are required for SCRAM, YAP and other mechanisms to be successfully
> implemented and deployed, and uses this 'requirement' to justify nearly a
> dozen mandates.
>
> incorrect.  No change to RFC 4422 is required for such mechanisms to be
> successfully implemented and deployed.

A change to the abstraction is required in order to allow specifying, 
implementing, and deploying support for channel bindings in SCRAM, YAP, 
GS2, and other mechanisms without breaking the abstraction and requiring 
that protocols understand the details of specific mechanisms, now and 
forevermore.

Again, I find that abstraction _essential_.
It is _intolerable_ to me that protocols should have to have 
mechanism-specific knowledge about each mechanism.  I find such a 
requirement contrary to the fundamental nature of SASL.

There is no getting around this.

Of course, one could change the abstraction without bothering to document 
it.  That's essentially what you've done if SCRAM, YAP, and GS2 all handle 
channel bindings in a similar way and protocols and protocol 
implementations start depending on it, but we _don't_ update RFC4422.  Then 
what happens is a couple of years from now, someone writes a protocol or 
mechanism that violates the unwritten assumptions, and we have a mess on 
our hands.

Since the purpose of the IETF is, in large part, to document protocols bits 
_and semantics_, I feel we should do our job and document the changes we 
are making to the SASL abstraction.  Otherwise, why are we here?

> So before we argue about individual mandates, I'd like the premise of the
> I-D to be restated.

The premise of the I-D is, "in order to say 'SCRAM does XXX with the 
channel bindings data provided by the protocol', we must first say that the 
protocol can provide channel bindings data to mechanisms."

Do you disagree with that assertion?

Do you believe it is OK to simply _assume_ that SASL protocols can provide 
channel bindings data to mechanisms, without saying what CB data is or what 
it's for or what it means?

Do you believe it is OK to simply _assume_ that SASL protocols will always 
be designed such that CB data is available to mechanisms in time to use it, 
without actually making this a requirement of SASL protocol designs?

Do you believe it is OK for SASL protocols to simply _assume_ that if they 
provide channel binding data to the mechanism and the authentication 
succeeds, then it is safe to rely on the security properties of the lower 
layer channel and that there is no MitM?  Or do we need to require 
mechanisms that provide support for channel bindings to actually guarantee 
this?

> I might agree to such so long as we don't mandate the CB data be RFC 5056
> CB data.  Now maybe I read too much in the draft, but given that my
> suggested SHOULD was not well received by Nico, I assume I read the I-D
> correctly.

I believe it is appropriate to specify that when we're talking about 
"channel bindings", we mean the concept described by RFC5056.  I believe it 
is critically important to specify that we're not talking about what EAP 
means when it talks about "channel bindings".

I don't believe it's necessarily important to require that channel binding 
tokens have a particular format, or that they use the binding types listed 
in the registry which RFC5056 creates.  I also don't believe that the 
present I-D requires that, or that RFC5056 requires that.

> particulars of framework implementations from particulars of application
> protocol mechanisms.
>
> The RFC 4422 abstraction only allows for protocols and mechanisms to be
> specified independently.

Correct.  But note that I didn't say "... requiring every protocol 
implementation to have mechanism-implementation-specific knowledge".  I 
meant what I said -- if we only specify what channel bindings mean for 
SCRAM, and for YAP, and for GS2, then each protocol specification must 
specify how to handle channel bindings for SCRAM, and for YAP, and for GS2, 
and each protocol specification must be updated every time a new mechanism 
comes along that supports channel binding.  That is intolerable.

And frankly, the abstraction _does_ allow for protocols and mechanisms to 
be implemented independently, as evidenced by the existence of multiple 
SASL framework libraries which do exactly this.  I do _not_ want to see 
this capability go away because someone decided it would be OK to ignore 
the abstraction and start requiring every protocol to have specific 
knowledge of every mechanism.

> I guess we disagree on the point of SASL is.

Maybe.  My interpretation goes back to the pre-SASL days when the Cyrus 
IMAP server included an abstraction for supporting multiple authentication 
methods, specifically so that the rest of the software and the IMAP 
protocol would not need to know the particulars of any given mechanism.

> end-all solution to channel binding.

You keep saying this.  But see, we are specifying how to do channel binding 
in SASL.  I've explained in several ways why it is necessary to do this at 
the SASL level, and not for each separate (protocol,mechanism) tuple, and 
the argument boils down to this: we do not have the infinite time it would 
take to do the latter.

It is entirely possible we will need to change the abstraction again later, 
in response to new information.  But despite the fact that we are only now 
getting around to nailing down the details for SASL, channel bindings are 
not a new concept; the IETF has been working on this for several years, and 
RFC5056 is a standards-track document which represents the consensus of the 
IETF on how to handle channel bindings.

> Oh please.  Nothing I suggest hinders your ability to abstract away the
> particulars of mechanisms and protocols.  Folks have been doing this for
> ages.

You suggest allowing the abstraction to be different for every mechanism. 
That precludes abstracting away the differences between mechanisms.

> I guess we'll just have to agree to disagree.

No, I don't think we can do that.  We need to reach a rough consensus in 
order to move forward.  I do not believe it is appropriate to move forward 
with documents such as SCRAM, GS2, and YAP, without updating RFC4422 to 
reflect the changes they make to the SASL abstraction.  You appear to 
believe it is not appropriate to update RFC4422 to reflect the changes we 
are making to the abstraction.  These positions are in direct conflict, 
which we need to resolve.

-- Jeff

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 14 Apr 2009 16:24:35 -0700

On Apr 14, 2009, at 2:27 PM, Jeffrey Hutzelman wrote:

>
> --On Tuesday, April 14, 2009 01:52:52 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>
>> says).
>> and
> No, it's not, though you may be reading too much into it.  A SASL  
> protocol must be prepared to make channel binding information  
> available to the mechanism by the first time the mechanism produces  
> or consumes a message, because some mechanisms will be unable to  
> process channel bindings unless the data is available at that time.   
> We're not telling you how your implementation API has to work; we're  
> telling you not to design a protocol that expects not to provide  
> channel binding data to the mechanism until after some mechanism  
> tokens have been exchanged, because such a protocol will not work.

Then you should word this as a requirement upon application protocol  
specifications instead of requirement upon implementors.

> No, it's prescriptive.  It doesn't describe how the existing  
> mechanisms and protocols happen to be; it describes things that must  
> be true of all mechanisms and protocols and they way they interact.   
> Unless you're using the words "descriptive" and "prescriptive" in a  
> with which I'm not familiar.
>
>
>> 4422
> A change to the abstraction is required in order to allow  
> specifying, implementing, and deploying support for channel bindings  
> in SCRAM, YAP, GS2, and other mechanisms without breaking the  
> abstraction and requiring that protocols understand the details of  
> specific mechanisms, now and forevermore.

I think the change you refer to is an implementation detail.

RFC 4422 said that while it possible to abstract away differences  
between a set of mechanisms, such abstractions will have to adapt in  
order to handle new mechanisms with yet more differences.

This is the nature of SASL as specified.

> Again, I find that abstraction _essential_.

I find it desirable.

> mechanism-specific knowledge about each mechanism.

Protocol specifications or protocol implementations?  Or both.

RFC 4422 is clear that it offers the former but not the latter.

> I find such a requirement contrary to the fundamental nature of SASL.
>

There is no getting around the issue that in order to implement a  
different mechanism that one might have to change aspects of the  
framework and protocol implementation.  This has always been true, and  
is part of the fundamental nature of SASL approach to authentication  
frameworks.

>
>
> Of course, one could change the abstraction without bothering to  
> document it.  That's essentially what you've done if SCRAM, YAP, and  
> GS2 all handle channel bindings in a similar way and protocols and  
> protocol implementations start depending on it, but we _don't_  
> update RFC4422.

Consider introduction of realms [RFC 2831].   The only thing we  
changed from RFC 2222 to RFC 4422 was to note that some mechanisms  
have a realm concept (the word "realm" did appear in RFC 2222, but  
only within the specification of the KERBEROS_V4 mechanism).  Despite  
the introduction having numerous impacts of this upon the abstractions  
implementors had designed/are designing to hide the differences  
between mechanisms, we didn't specify anything about realms.

> Then what happens is a couple of years from now, someone writes a  
> protocol or mechanism that violates the unwritten assumptions, and  
> we have a mess on our hands.

Well, I might suggest a word of caution be added to RFC 4422 text:

It is possible to design and implement this framework in ways that do  
abstract away particulars of similar mechanisms. Such a framework  
implementation, as well as mechanisms implementations, could be  
designed not only to be shared by multiple implementations of a  
particular protocol but to be shared by implementations of multiple  
protocols.
that notes that expanding an existing implementation to handle  
mechanisms and/or protocols dissimilar from those previously support  
might require substantial reworking of the implementation.

However, I think RFC 4422 is already quite clear that it does not  
generally hide the particulars of mechanisms from protocol  
implementations nor the differences of protocols from mechanism  
implementations.

>
>
> Since the purpose of the IETF is, in large part, to document  
> protocols bits _and semantics_, I feel we should do our job and  
> document the changes we are making to the SASL abstraction.   
> Otherwise, why are we here?

While we're introducing mechanisms which are notably dissimilar to  
existing mechanisms, and that introduction will impact abstractions  
implementors have designed and implemented, I don't believe the  
introduction of these mechanisms changes the SASL conceptional model  
or otherwise necessities a change in RFC 4422.

I note that what I object to is the premise that adding the text is  
required.  I argue that adding text about channel binding is merely  
desirable.  The difference in premise one starts with significant  
impacts the text.  In particular, where this I-D contains nearly a  
dozen mandates, the text that I would likely offer would likely  
contain zero mandates and a number of weak recommendations (similar to  
the weak recommendations we have on various other mechanism data  
requirements).

> channel bindings data provided by the protocol', we must first say  
> that the protocol can provide channel bindings data to mechanisms."
>

First, I assume by "protocol" your refer to a component of an  
implementation that implements a particular application level  
protocol, such as XMPP.

I would agree that a component of an implementation that implements  
that SCRAM mechanism needs to provided with the inputs the SCRAM  
mechanism requires.

> Do you believe it is OK to simply _assume_ that SASL protocols can  
> provide channel bindings data to mechanisms, without saying what CB  
> data is or what it's for or what it means?

I think SCRAM specification needs to be clear as to what the SCRAM  
mechanism input requirements are.

I see no specification barrier to implementation of SCRAM.

I note again SCRAM has been implemented.  I have not heard any SCRAM  
implementor stating the specifications of SCRAM nor RFC 4422 where  
incomplete or otherwise insufficient to allow for independent  
interoperability implementation of the mechanism.

> Do you believe it is OK to simply _assume_ that SASL protocols will  
> always be designed such that CB data is available to mechanisms in  
> time to use it, without actually making this a requirement of SASL  
> protocol designs?

Today implementations will try mechanisms for which they do not have  
all the required data inputs for.  I suspect this problem will  
continue.  I don't think this issue is unique to any particular data  
input requirement.

> Do you believe it is OK for SASL protocols to simply _assume_ that  
> if they provide channel binding data to the mechanism and the  
> authentication succeeds, then it is safe to rely on the security  
> properties of the lower layer channel and that there is no MitM?

I think implementors need to well understand the implementation- 
specific interfaces they use and be very careful of what assumptions  
they make.

> Or do we need to require mechanisms that provide support for channel  
> bindings to actually guarantee this?

I think mechanism specifications should be clear as to what security  
properties are provided under various circumstances.

> "channel bindings", we mean the concept described by RFC5056.  I  
> believe it is critically important to specify that we're not talking  
> about what EAP means when it talks about "channel bindings".
>
> I don't believe it's necessarily important to require that channel  
> binding tokens have a particular format, or that they use the  
> binding types listed in the registry which RFC5056 creates.  I also  
> don't believe that the present I-D requires that, or that RFC5056  
> requires that.
>
>
>
> implementation to have mechanism-implementation-specific  
> knowledge".  I meant what I said -- if we only specify what channel  
> bindings mean for SCRAM, and for YAP, and for GS2, then each  
> protocol specification must specify how to handle channel bindings  
> for SCRAM, and for YAP, and for GS2, and each protocol specification  
> must be updated every time a new mechanism comes along that supports  
> channel binding.  That is intolerable.
>
> And frankly, the abstraction _does_ allow for protocols and  
> mechanisms to be implemented independently, as evidenced by the  
> existence of multiple SASL framework libraries which do exactly  
> this.  I do _not_ want to see this capability go away because  
> someone decided it would be OK to ignore the abstraction and start  
> requiring every protocol to have specific knowledge of every  
> mechanism.
>
>
> Maybe.  My interpretation goes back to the pre-SASL days when the  
> Cyrus IMAP server included an abstraction for supporting multiple  
> authentication methods, specifically so that the rest of the  
> software and the IMAP protocol would not need to know the  
> particulars of any given mechanism.
>
> You keep saying this.  But see, we are specifying how to do channel  
> binding in SASL.  I've explained in several ways why it is necessary  
> to do this at the SASL level, and not for each separate  
> (protocol,mechanism) tuple, and the argument boils down to this: we  
> do not have the infinite time it would take to do the latter.
>
> It is entirely possible we will need to change the abstraction again  
> later, in response to new information.  But despite the fact that we  
> are only now getting around to nailing down the details for SASL,  
> channel bindings are not a new concept; the IETF has been working on  
> this for several years, and RFC5056 is a standards-track document  
> which represents the consensus of the IETF on how to handle channel  
> bindings.
>
>> the
> You suggest allowing the abstraction to be different for every  
> mechanism. That precludes abstracting away the differences between  
> mechanisms.

In one extreme, yes, every mechanism differs in every regard.  But in  
the other extreme, ever mechanism is the same in very regard.

I think mechanisms ought to be similar where appropriate and different  
where appropriate, where what's appropriate is largely left to the  
designer of the mechanism.

If a designer doesn't design well, oh well.

> No, I don't think we can do that.  We need to reach a rough  
> consensus in order to move forward.  I do not believe it is  
> appropriate to move forward with documents such as SCRAM, GS2, and  
> YAP, without updating RFC4422 to reflect the changes they make to  
> the SASL abstraction.

What text in RFC 4422 need to change in order for a developer to  
implement YAP as currently specified?

> You appear to believe it is not appropriate to update RFC4422 to  
> reflect the changes we are making to the abstraction.

I believe that the introduction of mechanisms which differ  
significantly from existing mechanisms does not necessitate a change  
to RFC 4422.

It is the nature of SASL that such introductions will likely have an  
impact upon implementation-specific abstractions to hide the details  
of mechanisms from protocol implementations.

> These positions are in direct conflict, which we need to resolve.
>
> -- Jeff
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 15 Apr 2009 12:22:18 -0500

I've updated the I-D:

http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt

I've removed the words "abstract API".  I believe the I-D is entirely
prescriptive of how applications interact with SASL mechanisms.  The I-D
is NOT prescriptive of any SASL mechanism details, but it does impose a
pair of requirements on SASL mechanisms in a way that does not dictate
mechanism design.  The new version is entirely in keeping with RFC4422,
IMO.

The new text should allow for mechanisms like YAP that require the use
of unique channel binding types, as it now requires that the app provide
the channel bindings for all available channel binding types.

Incidentally, I believe YAP can be seen as a variant of SCRAM that
optimizes away one round trip, using the channel binding as the client
and server nonce, and caching the salt and iteration count on the client
side.  Whereas SCRAM looks like:

      C: p,a=cnewman,n=Chris Newman,r=ClientNonce
      S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
      C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

YAP as a variant of SCRAM would look like:

      C: p,a=cnewman,n=Chris Newman,r=<channel-binding-type:data>,
         s=PxR/wv+epq,i=128,p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

or, if the client's idea of the user's salt and itteration count is
wrong:

      C: p,a=cnewman,n=Chris Newman,r=<channel-binding-type:data>,
         s=PxR/wv+epq,i=128,p=WxPv/siO5l+qxN4
      S: s=PxR/wv+epq,i=128
      C: p=WxPv/siO5l+qxN4
      S: v=WxPv/siO5l+qxN4

(No, I did not compute actual HMACs and base64 encodings of them.)

If you respond to the YAP-as-variant-of-SCRAM part of this message then
please change the Subject header line.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 16 Apr 2009 11:04:28 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-sasl-channel-bindings-02.txt

Is the following part realistic?

   In order to use SASL [RFC4422] with channel binding [RFC5056] the
   client and server applications MUST provide the SASL mechanism with
   channel bindings data and channel binding type names for all
   available channel binding types for the channel to be bound.  These
   channel bindings data MUST be provided to the mechanism before the
   first authentication message is produced or consumed by the
   mechanism.

This seems to require that application supports all channel binding
types.

To fix this, how about replacing "available" with "available and
supported"?  That suggests applications need to decide which channel
bindings they want to support.

I still think something is missing to assure interoperability.

What if a client support and use a channel binding for IPSEC but the
server support and use a channel binding for TLS?  Both sides will
announce and attempt to use a channel binding.  The channel binding will
not match, and they can't talk to each other.  Both will think there is
a MITM attack going on.  What prevents this from happening?

/Simon

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 06:31:58 -0700

> of mechanisms from protocol implementations.

For instance, RFC 4422 is mum on the need for a framework  
implementations to manage information about identities established a  
lower level in order to support EXTERNAL.   And with the introduction  
of EXTERNAL-*, the framework implementations will likely need to  
change.  Instead of managing a single external identity (as most  
seemed to have done), they will need to manage one per each of the  
EXTERNAL-* variants.  Today, it seems that the community thinks this  
will be enough.  But our crystal ball in not 100% clear.  Maybe in 5  
years, someone will want to introduce a mechanism that requires  
framework implementations to provide something different.

As RFC 4422 doesn't itself attempt to abstract away the differences  
between mechanisms, it can and should remain mum here.

Likewise, RFC 4422 ought not try to abstract away the differences in  
mechanisms that support channel bindings.  For instance, presently the  
suggestion is mandate two names per mechanisms.  But what if tomorrow  
we find this isn't good enough.  We'd have to update RFC 4422 to allow  
introduction of something which was just because we were short-sighted  
today.

I do think it appropriate to encourage future mechanisms to be similar  
to existing mechanisms where sensible.  What I object to is us  
mandating future mechanisms be the same in area based upon what we  
think is sensible today.

RFC 4422, I think, tries very hard to leave the future open.  This  
proposal, I think, tries very hard to close our future.

-- Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 16 Apr 2009 09:45:14 -0400

--On Thursday, April 16, 2009 06:31:58 AM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> suggestion is mandate two names per mechanisms.  But what if tomorrow we
> find this isn't good enough.  We'd have to update RFC 4422 to allow

You keep bringing this up, but it's a red herring.  Nico's document doesn't 
mandate that approach; it recommends it, and mandates that mechanisms with 
optional channel binding support protect the negotiation.  I think those 
restrictions are entirely appropriate; there is an interoperability reason 
for having the CB negotiation happen at the same time as the mechanism 
negotiation, and there is a clear security reason for requiring the 
negotiation to be protected to avoid a downgrade.

-- jeff

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 07:17:08 -0700

On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman wrote:

>
> --On Thursday, April 16, 2009 06:31:58 AM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
> You keep bringing this up, but it's a red herring.  Nico's document  
> doesn't mandate that approach; it recommends it,

The document says:
    The convention is that the specification for any SASL mechanism  
that supports optional channel binding MUST specify two mechanism names
The document does only recommend a naming scheme.
The document precludes, for instance, a mechanism design in which  
different name for each type of channel binding the server is willing  
to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").
> and mandates that mechanisms with optional channel binding support  
> protect the negotiation.

His document says
    Use of channel binding must be negotiable.

I certain think we'll have mechanisms where use of channel binding is  
non-negotiable.  YAP for instance is such a mechanism.

> I think those restrictions are entirely appropriate; there is an  
> interoperability reason for having the CB negotiation happen at the  
> same time as the mechanism negotiation,

There is a general interoperability consideration here.   
Implementations should not start a mechanism exchange which they  
cannot possibly complete.  This is not unique to mechanisms that  
support CB.

> and there is a clear security reason for requiring the negotiation  
> to be protected to avoid a downgrade.

I don't see the downgrade attack issues with CB to be significantly  
different from downgrade attack of various other (security) features  
that might be selectable via mechanism name.  So I think that any  
consideration here could and should be generalized.

-- Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Apr 2009 15:23:54 +0100

Kurt Zeilenga wrote:
 [...]

> between mechanisms, it can and should remain mum here.

I actually disagree. When I think about SASL I am thinking about such 
abstraction.
For example a protocol service name is a part of this abstraction, even 
though mechanism are not required to use it. Authorization identity is 
another part.

> mechanisms that support channel bindings.  For instance, presently 
> the  suggestion is mandate two names per mechanisms.

I disagree with your first statement in this paragraph, but I am 
agreeing with the second.

> But what if tomorrow  we find this isn't good enough.  We'd have to 
> update RFC 4422 to allow  introduction of something which was just 
> because we were short-sighted  today.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 09:24:49 -0500

>    first authentication message is produced or consumed by the

Yes, it is.

> This seems to require that application supports all channel binding

No.  The application need only inquire the channel to find out the
channel bindings for it, then it must pass them to the SASL mechanism.

Nothing complicated about that.  Oh, it may require a loop, something
like:

	foreach binding_type = channel_binding_types(channel)
		sasl_set_channel_binding(binding_type,
			channel_binding(channel, binding_type))

But that does not seem too complicated to me.

> bindings they want to support.

No, "available" here means "the channel has bindings for that type."
"Supported by the channel" is implied.  "Supported by the application"
is unnecessary -- the application need not actually understand any of
the channel binding types itself.

> I still think something is missing to assure interoperability.

The mechanisms need to specify how a single type is to be selected.  YAP
will always require unique channel binding types.  SCRAM will prefer
end-point channel binding types over unique ones so as to better
traverse concetrators.

> a MITM attack going on.  What prevents this from happening?

(First of all, this is farfetched today.  Second, it means both must be
using IPsec and TLS as channels (well, both must be using IPsec, though
only one side might implement IPsec channels).)

I'd argue that we should always bind to an end-to-end channel at the
highest possible layer below the app.  That rule solves the interop
problem by stating a global preference shared a priori by both sides.
It also allows us to have channel binding from TLS to IPsec if both
sides support it.  Thus we'd have channel binding from SASL->TLS->IPsec
and only IPsec would be providing session protection.

When we worked on RFC5056 you brought up this issue and we punted, but
now I'm convinced that the right solution is to state the "always bind
to an end-to-end channel at the highest possible layer below the app"
rule.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 16 Apr 2009 10:35:54 -0400

--On Thursday, April 16, 2009 07:17:08 AM -0700 Kurt Zeilenga 
<[email-masked]> wrote:

> The document says:
>     The convention is that the specification for any SASL mechanism that
> supports optional channel binding MUST specify two mechanism names
> different name for each type of channel binding the server is willing to
> accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

Yeah, that's too narrow.  The intent here was to make it clear that 
negotiation of whether CB is used has to happen during mechanism 
negotiation, not after a mechanism has been selected.  The two-mech-name 
approach really should only be a recommendation.

Note that while I could see a use for a model where you negotiate unique vs 
endpoint vs no channel bindings, I'd rather not pull into SASL negotation 
the question of which channel to bind to.  This is different from the 
EXTERNAL-* mechanisms, where we're negotiating which channel (or channel 
type, anyway) to pull authentication information from.  That's appropriate, 
because deciding on the source of authentication information is the purpose 
of the SASL mechanism negotiation.

> non-negotiable.  YAP for instance is such a mechanism.

Again, this is just poor language.  The goal is that when the mechanism 
supports optional channel binding, it must be possible to negotiate whether 
CB is used, rather than the endpoints having to know a priori.  Where the 
mechanism requires CB, or does not support it at all, there is nothing to 
negotiate.

We should fix the language so it's clear that the requirement for 
negotiability applies only when there is actually a choice to be made.

> There is a general interoperability consideration here.  Implementations
> should not start a mechanism exchange which they cannot possibly
> complete.  This is not unique to mechanisms that support CB.

Sure, but you only "cannot possibly complete" if you don't support 
_anything_.  If you support anything at all, then there is the possibility 
that the peer also supports that, and you can't know until you start 
negotiation.

The interoperability concern is requiring negotiation of the use of CB to 
happen at the same time as negotiation of mechanism, so that you don't end 
up selecting a mechanism for which you want channel bindings and then 
discovering you don't actually have CB data to use.

> different from downgrade attack of various other (security) features that
> might be selectable via mechanism name.  So I think that any

Well, there are two considerations here...

- Mechanisms that are capable of protecting the mechanism negotation
  should do so, to prevent mechanism downgrades.  Yes, this should apply
  to _all_ mechanisms, and is independent of CB.
- Mechanisms that support channel bindings MUST protect the negotiation
  of channel bindings, to prevent CB downgrade.

Interestingly, if you do the first, and require that CB negotiation happen 
as part of mechanism negotiation, then you get the second for free, 
including preventing an attacker from subverting a channel by forcing you 
to downgrade to a mechanism that doesn't support CB.

The reason the latter is so important is because we want a client to be 
able to has a policy that says it is willing to ignore CB when the server 
cannot support them, but not when the server _can_ support them and an 
attacker wants to subvert the channel.  This is a transition strategy; the 
idea is that if you're using TLS, you really want CB, but the server might 
not have access to an API that provides the CB data, so you might have to 
settle for no CB.  You don't want the interoperability feature to create a 
security weakness.

-- Jeff

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 07:45:49 -0700

On Apr 16, 2009, at 7:23 AM, Alexey Melnikov wrote:

>
> Kurt Zeilenga wrote:
> [...]
>
>> As RFC 4422 doesn't itself attempt to abstract away the  
>> differences  between mechanisms, it can and should remain mum here.
>
> I actually disagree. When I think about SASL I am thinking about  
> such abstraction.
> For example a protocol service name is a part of this abstraction,  
> even though mechanism are not required to use it. Authorization  
> identity is another part.

I'm guilty of not precisely wording my statement.

RFC 4422 doesn't generally hide the differences in mechanisms from  
protocol implementations nor hides the differences in protocols from  
mechanism implementations.

RFC 4422 certainly does try to hide the difference in mechanism from  
protocol specifications and vice versa.

I haven't see any comment what so ever that the suggested changes have  
any impact whatsoever on protocol specifications.

>
>
>> Likewise, RFC 4422 ought not try to abstract away the differences  
>> in  mechanisms that support channel bindings.  For instance,  
>> presently the  suggestion is mandate two names per mechanisms.
>

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 09:45:08 -0500

> to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

I actually changed that in -02 since that makes no sense for YAP.
Please look at -02.

> non-negotiable.  YAP for instance is such a mechanism.

I've fixed this for YAP in -02.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 08:58:04 -0700

On Apr 16, 2009, at 7:35 AM, Jeffrey Hutzelman wrote:

>
> --On Thursday, April 16, 2009 07:17:08 AM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>> The document says:
>> that
> negotiation, not after a mechanism has been selected.  The two-mech- 
> name approach really should only be a recommendation.

then the IANA consideration section should also be reworded.  (The  
existence of two MUSTs here lead me to conclude something quite  
different about the intent.)

While I intend to await changes to the proposal before responding to  
all of your comments, I do have a few things I think to say now.

>
>
> Note that while I could see a use for a model where you negotiate  
> unique vs endpoint vs no channel bindings, I'd rather not pull into  
> SASL negotation the question of which channel to bind to.

A client does not know what server channel binding types the server  
accepts.  For instance, a server might be generally willing to accept  
unique channel bindings but never end-point channel bindings (because  
it does trust the client (and its user) to establish them (in eyes of  
the server) appropriately.

>> Implementations
> _anything_.  If you support anything at all, then there is the  
> possibility that the peer also supports that, and you can't know  
> until you start negotiation.

In general, the exchange just fails leaving the client will little  
clue as to what went wrong.  The client's user and the server operator  
chat, reach some agreement, and the client tries again.

I suspect this will be so with CB.  In the above for instance, the  
server operator is just going to tell the client's user to "use unique  
bindings".

> The interoperability concern is requiring negotiation of the use of  
> CB to happen at the same time as negotiation of mechanism, so that  
> you don't end up selecting a mechanism for which you want channel  
> bindings and then discovering you don't actually have CB data to use.

Having some CB data may very well be not the right CB data for the  
exchange, so you end up having a prior agreements anyways.

Seems much like problems we've seen before.  I still don't see  
anything so new here to "require" change to RFC 4422.

> to _all_ mechanisms, and is independent of CB.

I would be interested in discussing this further in the context of RFC  
4422 revision (that is, as changes to 4422bis I-D).

> of channel bindings, to prevent CB downgrade.

My view is that each name refers to a mechanism.  That is, SCRAM- 
SHA256 and SCRAM-SHA256-PLUS are two different SASL mechanisms based  
upon the same technology, and that downgrade between them is very  
similar to say downgrade between DIGEST-MD5 and YAP.  What we need is  
general downgrade protection.  We already have some facilities for  
downgrade protection.  I much rather see (in RFC 4422) enhancements to  
the general downgrade protections than per-security feature downgrade  
protection schemes.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 09:03:20 -0700

> I actually changed that in -02 since that makes no sense for YAP.

The above text is from -02.  As is the IANA consideration:
   Henceforth any SASL mechanism registration MUST indicate ... two  
mechanism names and an indication of which name indicates
server support for channel binding.

> I've fixed this for YAP in -02.

This text is also from -02.

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 11:12:23 -0500

> different about the intent.)

Read your e-mail.  It has been updated already in -02.

> the server) appropriately.

I'm effectively saying that the server must each kind of channel binding
when feasible.  Therefore YAP can always be available when TLS is used
UNLESS there is a TLS concentrator which does not have a way of
communicating the unique channel bindings to the server, or UNLESS the
server's TLS implementation doesn't support getting the tls-unique
bindings.  (TLS concentrators are the reason we prefer end-point channel
bindings over unique.)

> 4422 revision (that is, as changes to 4422bis I-D).

I recently proposed something along these lines, then withdrew my
proposal.  See that reply.

> the general downgrade protections than per-security feature downgrade  

The only negotiation mechanism we have now is mechanism negotiation (heh).

Adding new negotiations that are NOT done through mechanism negotiation
is a recipe for failure because it means doing changes to all
application protocols.  If you want to prevent deployment, then insist
on this.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 11:13:36 -0500

> server support for channel binding.

Read carefully:

    "...and, if the mechanism supports optional channel binding then c)
    two mechanism names and an indication of which name indicates server
    support for channel binding."

Note the "and, if..." clause.

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 09:32:04 -0700

On Apr 16, 2009, at 8:58 AM, Kurt Zeilenga wrote:

> similar to say downgrade between DIGEST-MD5 and YAP.  What we need  
> is general downgrade protection.  We already have some facilities  
> for downgrade protection.  I much rather see (in RFC 4422)  
> enhancements to the general downgrade protections than per-security  
> feature downgrade protection schemes.

Let me come at this yet another way.

Say there were mechanisms called "SCRAM-SHA256-INT" and "SCRAM-SHA256- 
INT-CONF", where both were "SCRAM-SHA256" but established (non- 
optionally) security layers, the former with just integrity protection  
and the latter with both integrity and confidentiality protection.

When a server offers "SCRAM-SHA256" as well as one or both of the  
above, there is a downgrade attack issue in the mechanism negotiation.

This issue seems to me to be not significantly different than the  
"SCRAM-SHA256" and "SCRAM-SHA256-PLUS" downgrade issue, or the DIGEST- 
MD5 vs YAP downgrade issue for that matter.

If you think they are significant different, can you explain how?

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 16 Apr 2009 09:46:11 -0700

> Note the "and, if..." clause.

I did read it carefully.  What you miss is that my concern is not just  
about YAP, it's about undue restrictions upon future mechanisms...

-- Kurt

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Apr 2009 11:48:11 -0500

> to accept (e.g, "FOO" v. "FOO-CB-END-POINT" v. "FOO-CB-UNIQUE").

How does it do that?  Are we not free to add more rules later?

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 18 Apr 2009 11:42:45 +0200

> But that does not seem too complicated to me.

The problematic part is getting the 'channel' variable.  In most cases,
it will probably be a TLS channel initiated by the same application
doing the SASL exchange.  However, it can easily be a IPSEC layer, or a
TLS-based VPN, or the new OPSEC [1] proposal.

[1] http://tools.ietf.org/search/draft-paddon-tcposp-00

> end-point channel binding types over unique ones so as to better

But there is nothing that says which channel should be preferred.  There
can be multiple channels.  That is my concern.

> only one side might implement IPsec channels).)

The only farfetched about it is the part about channel bindings.  Plenty
of people use SASL in TLS over IPSEC or SSH.  What we are adding here is
a channel binding in the SASL step, so we need to be realistic about
what kind of channels are in use.

> highest possible layer below the app.

That works.

> That rule solves the interop problem by stating a global preference
> shared a priori by both sides.  It also allows us to have channel
> binding from TLS to IPsec if both sides support it.  Thus we'd have
> channel binding from SASL->TLS->IPsec and only IPsec would be
> providing session protection.

Sounds fine.

> to an end-to-end channel at the highest possible layer below the app"

So, where do we write down this requirement?  In the GS2/SCRAM mechanism
documents, in the core SASL specification (or an update to it), or in
implementation guidance, in an clarification to RFC 5056, or somewhere
else?

/Simon