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

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 14:50:37 -0500

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

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.

 - revamped the IANA section and added text re: pseudo-mechanism names
   for channel binding type negotiation

 - added security considerations text re: channel binding type
   negotiation and protection thereof

 - added reference to YAP

 - made the text more API neutral

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Apr 2009 15:03:12 -0500

I forgot to set the to/cc: headers correctly before sending.  Sorry.

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

I did forget one change, a note that the channel to be bound must be the
end-to-end secure channel at the highest possible layer.  This, and the
need for (but not the how of) channel binding type negotiation really
belong in an update to RFC5056.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Apr 2009 11:53:35 +0200

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

>       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.  Thus, I'm not convinced the pseudo mechanism approach will
be easy to implement.

Could we explore encoding both the channel binding negotiation and
channel binding type negotiation in the SASL mechanism name?

For SCRAM, you would then have these mechanisms:

   SCRAM
   SCRAM-TLSUNIQUE
   SCRAM-TLSENDPOINT

The two latter mechanisms imply channel binding support, using the
explicit channel binding types.

For Kerberos V5 under GS2 we'd have:

   GS2-KRB5
   GS2-KRB5-TLSUNIQUE
   GS2-KRB5-TLSENDPOINT

This approach would resolve my old concern with channel binding type
negotiation in RFC 5056 in this context.  It is taken care of at the
SASL mechanism layer.

(Btw, SASL mechanisms are upper case, thus 'CB-tls-srv-endpoint'
wouldn't work.)

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Apr 2009 10:19:27 -0500

> Thanks.  Something along these lines is needed before we can implement

Well, no, but we do need this before SCRAM and GS2 can progress, IMO.

> the server.  Thus, I'm not convinced the pseudo mechanism approach will

Making that list available to *some* component that can make the choice
is part of the scheme.  The current text allows that to be the
application, the framework and/or the mechanism:

 - The application on the client side can make the choice of channel
   binding type by:
   
   a) for each locally available mechanism inquire whether it requires
   unique channel bindings and, if the server didn't advertise support
   for those or the client doesn't have support for those, then
   eliminate that mechanism from the list,

   b) pick a mechanism from the list resulting from (a),

   c) if the chosen mechanism requires unique channel bindings, then
   choose unique channel bindings as the channel binding type, else
   choose end-point channel bindings if available.

 - The framework can make the choice in exactly the same way as the
   application, *provided* that the application gives the framework the
   server's advertised mechanism list.

 - The mechanism can make the choice *provided* that the application
   gives it the server's advertised mechanism list.

> For SCRAM, you would then have these mechanisms:

N * M -> bad.

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Sat, 25 Apr 2009 07:16:50 -0700

> Thanks.  Something along these lines is needed before we can implement

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.

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

> Thus, I'm not convinced the pseudo mechanism approach will
> be easy to implement.

Given that today some server implementations find it hard to limit the  
advertisement of EXTERNAL to instances where the server has associated  
an identity for the client at some lower-level, we can surmise that  
some implementations will find this pseudo mechanism approach hard to  
implement.

> channel binding type negotiation in the SASL mechanism name?

I just wish we'd "explore" some where other than the in the base  
specification.

-- Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2009 10:29:03 +0200

> My take on SCRAM, at least, is that it's quite implementable without

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

I have merged the text into GS2:

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

Comments?  Does this work?

> a mechanism negotiation facility.

That is a good point.  So the CB-* approach doesn't work, does it?

> some implementations will find this pseudo mechanism approach hard to

Right.

> I just wish we'd "explore" some where other than the in the base

I agree.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2009 10:38:38 +0200

> Well, no, but we do need this before SCRAM and GS2 can progress, IMO.

Text to solve the same problem can also be in SCRAM and GS2, like
section 6.1 in SCRAM and my new proposed section 5.1 in GS2.  It
wouldn't be a generic solution, but will probably work in practice for
SCRAM/GS2.

> application, the framework and/or the mechanism:

As Kurt said, RFC 4422 doesn't mandate that mechanism negotiation
happens by sending a clear-text list of all supported mechanisms.  So
from a design point of view, CB-* style negotiation doesn't seem
perfect.

>> For SCRAM, you would then have these mechanisms:

I don't see that as a serious problem here, the total number of
mechanisms for a particular server isn't going to be huge.  This
approach has the advantage that both the channel binding negotiation,
and the channel binding type negotiation, happens through the same
mechanism, and that it is obvious what is intended once the mechanism is
chosen.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Apr 2009 10:02:59 -0500

> from a design point of view, CB-* style negotiation doesn't seem

We can probably wordsmith it so that listing the server's available
mechanisms isn't a direct requirement, but unless there exist Internet
apps that use SASL and which don't support listing the server's
available mechanisms then I don't think we should bother.

> I don't see that as a serious problem here, the total number of

I do.  One problem I forgot to mention is this: channel binding types
can be added at any time, so with your scheme we'd have to add new
registrations of SCRAM, GS2, ... mechanisms for each new channel binding
type.  I'd much rather have to register only the SASL name of each
channel binding type.

But wait, it gets worse.  Not only must we go back to the SASL mech name
registry to keep the M*N registrations up to date whenever a new channel
binding type is added, we also have to update deployed SASL
applications/frameworks.

Whereas with my approach the only thing that the
application/framework/mechanism need to know about new channel binding
types is whether they are "unique" (yes, apps would still need to know
about new types of channels, but the framework and mechs wouldn't).

> mechanism, and that it is obvious what is intended once the mechanism is

But we don't need this approach to solve any particular problems.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2009 21:49:06 +0200

> But we don't need this approach to solve any particular problems.

Both models solve the problem of channel binding negotiation and channel
binding type negotiation.

I see the differences as a trade-off between 1) making things easier for
IETF/IANA (your approach with CB-foo) or, 2) for application
implementers (my SCRAM-TLSENDPOINT approach).  I believe the CB-foo has
an architectural wart in that RFC 4422 doesn't mandate mechanism
advertisement.

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.

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?

Are there other major SASL libraries which people are familiar with, and
can check?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Apr 2009 15:24:32 -0500

On Mon, Apr 27, 2009 at 09:49:06PM +0200, Simon Josefsson wrote:
> implementers (my SCRAM-TLSENDPOINT approach).

But your model does not make things easier for *deployers*.

>                                                I believe the CB-foo has

Negotiation of channel binding and channel binding type through
mechanism negotiation is NOT a wart.  If you don't negotiate then you
must agree a priori on what mechanism to use, whether to use channel
binding, and what channel binding types are preferred (and if you don't
agree then you get to try again).

Now, IF there are applications where the client makes a proposal and
then the server picks a mechanism, *then* your proposal is workable and
mine isn't.

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

> .so plugin can get the list of advertised SASL mechanisms both in client

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.  But you'll
be needing interface changes in order to deal with channel binding, so
why can't one of those interface changes be that the addition of a slot
for the client app to communicate the server's mech list to the
framework?

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2009 23:22:22 +0200

> But your model does not make things easier for *deployers*.

I don't see a significant difference for deployers between these two
models.  They will need to specify which mechanism to use for
clients/servers, and maybe install new SASL plugins in their SASL
frameworks.

In the first model, they will (for example) have to document that
SCRAM-PLUS is used, and that they need to make sure
CB-UNIQUE-TLS-ENDPOINT is advertised.

In the second model, they will have to document that SCRAM-TLSENDPOINT
should be negotiated and used.

> agree then you get to try again).

You can also use the SCRAM-TLS-ENDPOINT approach, which is what I
suggested.  This model works fine even if some protocol doesn't transfer
the list of mechanisms.  There is no requirement in RFC 4422 to transfer
such a list.  That why I think it is architecturally more sound to not
assume there is a mechanism list transfer here.  However, I also agree
that this is a theoretical concern, not a practical one.

> then the server picks a mechanism, *then* your proposal is workable and

Or if some protocol just mandates that a particular SASL mechanism is
used, without advertising the entire set of supported mechanisms.  Or
use some other negotiation mechanism that doesn't involve sending the
entire list.

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

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

> But you'll be needing interface changes in order to deal with channel
> binding, so why can't one of those interface changes be that the
> addition of a slot for the client app to communicate the server's mech
> list to the framework?

Sure, it can.  This is why I don't feel strongly about the issue.  But
adding the new interface is not needed with the SCRAM-TLSENDPOINT
approach.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Apr 2009 00:38:17 -0500

> clients/servers, and maybe install new SASL plugins in their SASL

Every time a new channel binding type is registered we'll need new SASL
mechs registered for all mechs that support channel binding.  Not only
must these registrations be done with the IANA, but also every deployed
implementation needs to be updated.  And is due to the 20 character
limit on SASL mech names.  I find that unacceptable.

The only thing about any channel binding type that the apps, framework
and/or mechanism need concern themselves with is whether the channel
binding type is "unique", and that comes from the channel (meaning the
SASL apps/framework/mech don't need to know about channel binding types
a priori to know whether they are unique).

> CB-UNIQUE-TLS-ENDPOINT is advertised.

That's hardly a problem.

> should be negotiated and used.

That shouldn't be a problem, but it is, mostly because of the 20 char
mech name length limit.

> that this is a theoretical concern, not a practical one.

I actually have no problem whatsoever saying that if you must negotiate
whether to do channel binding and which channel binding type to use then
you must also list the server's mechanisms on the client side.

Channel binding is a new feature for SASL, therefore we're free to
impose such requirements.  We're not bound by the fact that RFC4422 does
not mandate mechanism negotiation nor how mechanism negotiation must be
done.

> use some other negotiation mechanism that doesn't involve sending the

See above.  I'd say such a protocol would require revising.

> for querying for the advertised mechanisms, since no SASL mechanism

Surely the server _app_ can list the locally available mechanisms, and
surely GNU SASL does _not_ yet support channel binding, and surely you
can add a way for the _client app_ to pass the server's mech list to the
framework when you add support for channel binding.  You haven't
explained why you couldn't do that, or how you have interfaces that are
sufficient for channel binding already somehow.

> adding the new interface is not needed with the SCRAM-TLSENDPOINT

Alternatively new channel binding types require updating at least the
deployed frameworks.  That's a trade-off that I find unappealing.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 28 Apr 2009 09:24:20 -0400

> not mandate mechanism negotiation nor how mechanism negotiation must be

In fact, SASL protocols have to "negotiate" a mechanism somehow; that is, 
the peers must somehow agree on which mechanism to use.  Many protocols do 
this by having the server advertise a mechanism list and then letting the 
client select one, but it is also possible to require preconfiguration or 
for mechanism selection to have been done as part of some prior 
communication.

Similarly, SASL protocols using channel binding will have to "negotiate" 
its use and a channel binding type, in that they will have to agree on 
these things.  Including CB advertisements in the mechanism list insures 
that protocols which do mechanism negotiation in the usual way will also be 
able to negotiate channel binding types in the same way, and at the same 
time, which eliminates a multi-level negotiation problem that I think we 
all agree should be avoided.  SASL protocols which select mechanisms in 
some other way will have to figure out some way to select channel binding 
types as well.

However, note that while RFC4422 does not specify a means for a client to 
discover what mechanisms are available, it _does_ specify a means for the 
server to discover what mechanism is in use -- the client is required to 
tell it, and SASL protocols are required to have a slot for this purpose. 
Similarly, if we are to negotiate channel binding types, then it will be 
necessary for the client to tell the server what CB type is in use.

Since we cannot retroactively modify all SASL applications to include a new 
slot for this purpose, the obvious choices are to either include it as part 
of the selected mechanism name, or require mechanisms supporting channel 
bindings to include a slot for carrying this information.  Note that 
channel binding data is opaque to the mechanism, and the mechanism itself 
does _not_ need to know what CB type is in use.

> sufficient for channel binding already somehow.

It is only necessary for _mechanisms_ to list the available mechanisms if 
you have a mechanism that is going to try to protect the mechanism list 
from downgrades (something I think is desirable, but as part of a general 
4422 update, not as part of adding CB to SASL), or if your implementation 
makes it the mechanism's responsibility to select a channel binding type. 
In the latter case, you don't just need to know the peer's available 
mechanisms, you need to know the locally-available CB types _and the data 
for all of them_.

Fortunately, I believe we came to the conclusion that there is no reason 
selecting CB type has to be done by the mechanism implementation.

FWIW, I find the approach of including channel types in mechanism names to 
be problematic, because it creates exactly the sort of cross-product 
explosion that SASL, by its very existence, is intended to avoid.  We 
agreed that having to separately specify, implement, and deploy every 
possible combination was not OK back when we chartered this group (really, 
before then) and took on the work of specifying a framework that would 
allow protocols and mechanisms to be defined independently.  I believe the 
principle applies equally well to mechanisms and channel binding types, 
_especially_ in a time when we have several mechanisms under development 
and when there is an ongoing effort to define channel bindings for the most 
common channel types and to encourage widespread use of channel bindings 
throughout the IETF.

Having to separately handle each combination of mechanism and channel 
binding type, and having to update everthing every time there is a new 
mechanism or channel binding type, does not scale.  It makes things hard 
for people specifying mechanisms; it makes things hard for people 
implementing SASL protocols; it makes things hard for people deploying 
these things (and especially for people who have _already deployed_ these 
things and now need to update all of their applications because a new CB 
type has appeared(*)).  It also creates unnecessary work for people 
defining new channel binding types, which means those people will not _do_ 
that work, and new CB types simply won't be available for use with SASL.

(*) My POV as an operator and Nico's as an operating system vendor are 
similar in this respect.  We both must support a variety of users of the 
software environments we provide.  Those users may be using client software 
we provide, or not.  They may be talking to server software we provide, or 
not.  They may be talking to servers we operate, or not.  Thus, we cannot 
know a priori or dictate what mechanisms or channel types they will use. 
To us, the cross-product problem means that if we do not use a framework 
library of some sort, we have to rebuild potentially hundreds of 
applications when a new mechanism or channel type comes along.

Now, if you can come up with some way of _mechanically_ generating the 
cross-product, so that it is not necessary to manually register, specify, 
implement, and deploy every combination, we can talk.  But in the meantime, 
SCRAM-HMAC-SHA-256-TLS-ENDPOINT is a bit long.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 28 Apr 2009 09:29:30 -0500

> does _not_ need to know what CB type is in use.

I'm going with "or require mechanisms supporting channel bindings to
include a slot for carrying this information" (it's just a matter of
adding the channel binding type to the GS2 header, in the case of GS2).

> makes it the mechanism's responsibility to select a channel binding type. 

I agree.  Simon has me somewhat confused as to what his actual objection
is here.

> mechanisms, you need to know the locally-available CB types _and the data 

Indeed (my I-D requires this now).

> selecting CB type has to be done by the mechanism implementation.

Note though that it does have to be done with knowledge of each channel
binding type's sub-type (unique or not) and the mechanisms' requirements
w.r.t.  unique channel binding types.

I'm very tempted to say that all mechanisms must support non-unique
channel bindings.  That would require that YAP be at least a full
round-trip instead of exactly half a round-trip.  ("At least" because
if the app chooses a non-unique channel binding then YAP would have to
devolve into a SCRAM-like mechanism.)  Requiring that YAP be adaptable
seems desirable for other reasons (for example, you want the mutual
authentication semantics that you get from having at least one
round-trip); see my comments on YAP, a separate thread.

> applications when a new mechanism or channel type comes along.

+1

> SCRAM-HMAC-SHA-256-TLS-ENDPOINT is a bit long.

Right.  I'm skeptical that anyone will come up with an acceptable way
of...

Nico
--

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 29 Apr 2009 12:29:52 -0700

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.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 29 Apr 2009 15:24:21 -0700

On Apr 29, 2009, at 12:29 PM, Kurt Zeilenga wrote:

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

s/still buy/still don't/, of course.  :-)
>
>
> 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.
>
> -- Kurt
>

Cc: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Wed, 29 Apr 2009 15:24:21 -0700
Sender: [email-masked]

On Apr 29, 2009, at 12:29 PM, Kurt Zeilenga wrote:

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

s/still buy/still don't/, of course.  :-)
>
>
> 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.
>
> -- Kurt
>

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Wed, 29 Apr 2009 12:29:52 -0700
Sender: [email-masked]

-- Kurt

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Comments on YAP
Date: Wed, 29 Apr 2009 10:54:38 -0700
Sender: [email-masked]

On Apr 29, 2009, at 9:30 AM, Nicolas Williams wrote:

>
> On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
>> On Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:
>>
>>>
>>> I looked at draft-zeilenga-sasl-yap-03 when revising
>>> draft-ietf-sasl-channel-bindings.
>>
>> I just uploaded -04.  Aside from other minor changes, it adds the
>> following clarifying statement to the Introduction.
>>
>>  YAP relies on client to authenticate the server within this lower-
>> level security layer to avoid information disclosure to rogue  
>> servers.
>
> I don't think that's a good idea.  Here's why: if you're really
> authenticating the server at the lower layer then why are you using
> channel binding in YAP?

The channel binding also ensures the client lower-level and YAP end  
points are the same.

One problem in many uses of TLS in application protocols is that the  
server has no clue wether the client's user well authenticated the  
server, hence the server has to be leery of man-in-the-middle  
attacks.  By using channel bindings, the server need not be concerned  
about whether the client's user well authenticated the server as it  
can rely on the channel binding to avoid man-in-the-middle attacks.

> And if the lower layer is not authenticating a
> server name then you don't get mutual auth at all.

If the client doesn't adhere to the SHOULD, then it runs the risk of  
disclosing the portions of the credentials (e.g., the authcid).   My  
view is that client's user is more sensitive to associated risks of  
such disclosure than the server's operator, so it seems reasonable to  
me to make a recommendation that the client authenticate the server at  
the lower level.   For my uses this level of authentication is quite  
sufficient.

-- Kurt

Date: Wed, 29 Apr 2009 11:30:29 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on YAP
Sender: [email-masked]

On Wed, Apr 29, 2009 at 09:01:24AM -0700, Kurt Zeilenga wrote:
> On Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:
> 
> >
> >I looked at draft-zeilenga-sasl-yap-03 when revising
> >draft-ietf-sasl-channel-bindings.
> 
> I just uploaded -04.  Aside from other minor changes, it adds the  
> following clarifying statement to the Introduction.
> 
>   YAP relies on client to authenticate the server within this lower- 
> level security layer to avoid information disclosure to rogue servers.

I don't think that's a good idea.  Here's why: if you're really
authenticating the server at the lower layer then why are you using
channel binding in YAP?  And if the lower layer is not authenticating a
server name then you don't get mutual auth at all.

Keep in mind that by "mutual authentication" I mean, in this case, that
a message is sent by the server that proves the server knew the
credential that it needed to verify the client's YAP message.  I do NOT
mean that the server _name_ is authenticated.

Nico
-- 

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Comments on YAP
Date: Wed, 29 Apr 2009 09:01:24 -0700
Sender: [email-masked]

On Apr 21, 2009, at 1:37 PM, Nicolas Williams wrote:

>
> I looked at draft-zeilenga-sasl-yap-03 when revising
> draft-ietf-sasl-channel-bindings.

I just uploaded -04.  Aside from other minor changes, it adds the  
following clarifying statement to the Introduction.

   YAP relies on client to authenticate the server within this lower- 
level security layer to avoid information disclosure to rogue servers.

This clarification is relevant to your comments concerning mutual  
authentication.  While YAP doesn't directly provide for mutual  
authentication, it does (quite strongly) encourage clients  
authenticate the server at the lower level.

>
>
> Here are some comments:
>
> - YAP as a variant of SCRAM seems like a good idea:

Having such a variant of SCRAM might be a good idea... but I still  
like to pursue YAP as specified in my I-D as I think its still, on its  
own, a good idea.

I leave pursuit of such a variant of SCRAM to others.

> you can reuse the
>   SCRAM PBKDF and key management.  That means less administration, and
>   also that you could normatively refer to SCRAM for parts of YAP,  
> thus
>   making the YAP I-D smaller.

>
>
> - IMO there should be a server->client message for mutual
>   authentication (though as with SCRAM there's no server name).

YAP expects the client to authenticate the server (at the lower layer)  
prior to initiating the YAP exchange.  This ensures YAP authentication  
information, such as the autchid, is not disclosed to rogue servers.

>  The
>   following is a YAP-as-variant-of-SCRAM exchange as I imagine it:
>
>    C: p,a=nico,n=Nico,p=<ClientKey XOR
> 			    HMAC(StoredKey, "n=Nico,cb=p,a=nico,tls-unique:...")
>    S: v=HMAC(ServerKey, <client's first message>)
>    C: <empty>  (optional depending on the app protocol)
>    S: <outcome of authentication>
>
>   With this you'd save a round-trip compared to SCRAM and could  
> qualify
>   for the Standards-Track (I guess what makes YAP Experimental is the
>   lack of mutual authentication).

I don't see mutual authentication as necessarily being a requirement  
for the Standards Track, but I note YAP does provide for mutual  
authentication.

That said, I continue to think Experimental as best for now (*) for YAP.

(* I don't preclude later seeking Standard Track status, such as after  
gaining significant operational experience with it.)

>
>
> - When the client has not cached the salt and/or PBKDF iteration  
> counts
>   or the cached values are out of date the mechanism could devolve  
> into
>   SCRAM:
>
>    C: n,a=nico,n=Nico,p=<ClientKey XOR
> 			    HMAC(StoredKey, "n=Nico,cb=n,a=nico,tls-unique:...")
>    S: s=<salt>,i=<iteration-count>
>    C: n,a=nico,n=Nico,p=<ClientKey XOR ...>
>    S: v=HMAC(ServerKey, <client's second message>)
>    C: <empty>  (optional depending on the app protocol)
>    S: <outcome of authentication>
>
> - You could even have YAP be exactly like SCRAM when the given channel
>   binding type is not a unique channel binding type.
>
>
>
> Nico
> -- 
>

Date: Tue, 28 Apr 2009 09:29:30 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

+1

Nico
-- 

Date: Tue, 28 Apr 2009 09:24:20 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

-- Jeff

Date: Tue, 28 Apr 2009 00:38:17 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

That's hardly a problem.

Nico
-- 

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

/Simon

Date: Mon, 27 Apr 2009 15:24:32 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Nico
-- 

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

/Simon

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

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 27 Apr 2009 12:42:57 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> I don't see any critical problem in allowing error tokens to be sent.
>
> I don't either.  I think we should make that a MAY.

Two people in favor, none against, and discussion has stopped.  I
incorporated the proposed text.  See http://josefsson.org/sasl-gs2/ for
updated document.

I believe this addresses all of Alexey's comments made in this thread.
If I missed some comment, please let me know.

/Simon

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

/Simon

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

Right.

I agree.

/Simon

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: Updated SASL And Channel Binding document (-03)
Date: Sat, 25 Apr 2009 07:16:50 -0700
Sender: [email-masked]

Why?

-- Kurt

From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: draft-josefsson-sasl-external-channel-03
Date: Thu, 23 Apr 2009 11:46:51 -0700
Sender: [email-masked]

On Apr 22, 2009, at 3:24 AM, Simon Josefsson wrote:

> Maybe Kurt could describe his use case?

Well, basically, it comes down to limitation that RFC 4422 states  
EXTERNAL has:

    In absence of some a
    priori agreement between the client and the server, the client  
cannot
    make any assumption as to what external means the server has used to
    obtain the client's credentials, nor make an assumption as to the
    form of credentials.

So, for instance, if a client established an identity using TLS (over  
TCP/IP), the client cannot assume the server pulls from TLS.  It just  
as well be pulling an identity from IP (the client's IP address).  As  
you noted in a subsequent post, an implementation might pull up the IP  
address to associate a "localhost" identity with the client.  This  
same issue happens when the client does TLS over IPC.  The client  
cannot know if the identity pulled up is from TLS or IPC layer.

Now, in many cases, the client may not care from where the server  
pulls.  It seems more likely if the client would care about what  
identity was associated to it by the server instead of the where.  For  
this, application protocols can offer "who am i?" operations.   Note  
that "who am i?" was actually introduced to solve a bit different  
issue... the issue that client cannot make assumptions about the  
identity a client associated with the credentials (even when those  
credentials include an user identifier).

I think EXTERNAL is generally "good enough", especially when combined  
with "who am i?" operations.

The use case I was thinking of was "Client wants to server to pull up  
from a particular layer (usually the layer immediately below the  
application layer protocol (e.g., TLS))".

-- Kurt

Date: Thu, 23 Apr 2009 08:48:12 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

On Wed, Apr 22, 2009 at 06:03:15PM -0400, Jeffrey Hutzelman wrote:
> If there is an a priori agreement as to what EXTERNAL is for, then there is 
> no confusion.
> 
> Lacking such agreement, the only way you can know what EXTERNAL means is if 
> it always means the same thing.  If that were the case (for example, if it 

Or if it could only reasonably mean one thing.

> always meant "use TLS") and it were simply undocumented, then it would be 
> appropriate to amend the definition of EXTERNLA to say what it means.  But 
> in fact, it appears that it does _not_ always mean the same thing.

I can't see when the client and server could be confused _today_ by what
EXTERNAL means.

> We could say "it means use the highest-layer e2e channel", but that would 
> be a backward-incompatible change, since it doesn't always mean that now.

Only if that actually changes EXTERNAL in any presently feasible
scenarios.

> We could say "it means use TLS, except when it doesn't", which would be 
> very close to the deployed reality today.  Unfortunately, the "except when 
> it doesn't" has the effect that this statement is not semantically 
> different from what the current spec says -- you still have to know whether 
> it means TLS, and if not, what else it means instead.
> 
> So, I think amending EXTERNAL is a lost cause, and we should just punt and 
> concentrate on EXTERNAL-*.

I'm not arguing otherwise.  I'm arguing that we can also clarify
EXTERNAL.

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Apr 2009 10:08:28 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
>> >> > That's what it says, but does anyone ever do that, or does everyone take
>> >> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
>> >> > the latter.
>> >> 
>> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
>> >> recall correctly) use EXTERNAL for localhost based authentication.  Some
>> >> applications probably use EXTERNAL for client-TLS too.
>> >
>> > But my earlier point stands: it's never the case, today, that there's
>> > any confusion as to what EXTERNAL means.  A rule can be stated to
>> > clarify what EXTERNAL means in future cases where there would be
>> > confusion.
>> 
>> Today the client can never know what mechanism the server used.  The
>> server can never know what mechanism the client intended to be used.  So
>> I think we disagree that there is confusion what EXTERNAL means today.
>> Reducing that perceived confusion is the point of the draft.
>
> If it can only have meant one thing then there can be no confusion.
>
> Confusion enters the picture when there can have been multiple answers.

Right, and I believe there is sufficient potential for multiple answers
to warrant work on EXTERNAL-*.

> Also, why should the client care which ID was used as long as the client
> requested a specific authzid?  :)

In some cases the client does not specify an authzid.

/Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Apr 2009 10:04:37 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> So, I think amending EXTERNAL is a lost cause, and we should just punt
> and concentrate on EXTERNAL-*.

Agreed.  Perhaps the background hasn't been clear: I considered to
publish an update of EXTERNAL with clarified semantics, i.e., "use
client credentials from the highest layered TLS channel".  However, I
think this WG has seen enough attempts to retrofit slightly modified
semantics on CRAM-MD5 and DIGEST-MD5 already (although we succeeded with
PLAIN).  My primary use case is to get client-TLS credentials reused in
SASL, so an update to EXTERNAL would have worked for me.  If someone
wants to drive that effort, I would be happy if it succeeded.  I believe
that is unlikely to succeed, because EXTERNAL appears to be deployed
with incompatible semantics already.

/Simon

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 23 Apr 2009 09:55:44 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Apr 22, 2009, at 1:29 PM, Simon Josefsson wrote:
>
>>
>> I noticed a minor nit in RFC 4422 when writing IANA section for
>> EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
>> family)' is not relevant.  Should it be removed?
>
> Yes.

Great.

> I also noticed that doesn't say anything about registration of members
> of a family.
> To address this, I propose adding the following to the end of 7.1.2.
>
> It is expected that the owner of the family provide appropriate
> guidance to IANA regarding registration of family members.  In absence
> of any particular guidance, permission of the family owner is required
> to register a member of the family.
>
> All IESG-owned families, unless otherwise specified in an IETF
> document detailing the family of mechanism, require Expert Review
> (as discussed above).

That is useful to add.  The text works for me.

/Simon

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
Date: Wed, 22 Apr 2009 19:45:48 -0700
Sender: [email-masked]

On Apr 22, 2009, at 1:29 PM, Simon Josefsson wrote:

>
> I noticed a minor nit in RFC 4422 when writing IANA section for
> EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
> family)' is not relevant.  Should it be removed?

Yes.

I also noticed that doesn't say anything about registration of members  
of a family.
To address this, I propose adding the following to the end of 7.1.2.

It is expected that the owner of the family provide appropriate
guidance to IANA regarding registration of family members.  In absence
of any particular guidance, permission of the family owner is required
to register a member of the family.

All IESG-owned families, unless otherwise specified in an IETF
document detailing the family of mechanism, require Expert Review
(as discussed above).

Date: Wed, 22 Apr 2009 18:03:15 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

--On Wednesday, April 22, 2009 04:19:54 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>
> On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
>> >> > That's what it says, but does anyone ever do that, or does everyone
>> >> > take EXTERNAL to mean "use the user authenticated by TLS"?  I
>> >> > suspect it's the latter.
>> >>
>> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils,
>> >> if I recall correctly) use EXTERNAL for localhost based
>> >> authentication.  Some applications probably use EXTERNAL for
>> >> client-TLS too.
>> >
>> > But my earlier point stands: it's never the case, today, that there's
>> > any confusion as to what EXTERNAL means.  A rule can be stated to
>> > clarify what EXTERNAL means in future cases where there would be
>> > confusion.
>>
>> Today the client can never know what mechanism the server used.  The
>> server can never know what mechanism the client intended to be used.  So
>> I think we disagree that there is confusion what EXTERNAL means today.
>> Reducing that perceived confusion is the point of the draft.
>
> If it can only have meant one thing then there can be no confusion.
>
> Confusion enters the picture when there can have been multiple answers.
>
> Also, why should the client care which ID was used as long as the client
> requested a specific authzid?  :)

If there is an a priori agreement as to what EXTERNAL is for, then there is 
no confusion.

Lacking such agreement, the only way you can know what EXTERNAL means is if 
it always means the same thing.  If that were the case (for example, if it 
always meant "use TLS") and it were simply undocumented, then it would be 
appropriate to amend the definition of EXTERNLA to say what it means.  But 
in fact, it appears that it does _not_ always mean the same thing.

We could say "it means use the highest-layer e2e channel", but that would 
be a backward-incompatible change, since it doesn't always mean that now.

We could say "it means use TLS, except when it doesn't", which would be 
very close to the deployed reality today.  Unfortunately, the "except when 
it doesn't" has the effect that this statement is not semantically 
different from what the current spec says -- you still have to know whether 
it means TLS, and if not, what else it means instead.

So, I think amending EXTERNAL is a lost cause, and we should just punt and 
concentrate on EXTERNAL-*.

-- Jeff

Date: Wed, 22 Apr 2009 16:19:54 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

On Wed, Apr 22, 2009 at 11:07:52PM +0200, Simon Josefsson wrote:
> >> > That's what it says, but does anyone ever do that, or does everyone take
> >> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> >> > the latter.
> >> 
> >> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
> >> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
> >> recall correctly) use EXTERNAL for localhost based authentication.  Some
> >> applications probably use EXTERNAL for client-TLS too.
> >
> > But my earlier point stands: it's never the case, today, that there's
> > any confusion as to what EXTERNAL means.  A rule can be stated to
> > clarify what EXTERNAL means in future cases where there would be
> > confusion.
> 
> Today the client can never know what mechanism the server used.  The
> server can never know what mechanism the client intended to be used.  So
> I think we disagree that there is confusion what EXTERNAL means today.
> Reducing that perceived confusion is the point of the draft.

If it can only have meant one thing then there can be no confusion.

Confusion enters the picture when there can have been multiple answers.

Also, why should the client care which ID was used as long as the client
requested a specific authzid?  :)

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Apr 2009 23:07:52 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> > That's what it says, but does anyone ever do that, or does everyone take
>> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
>> > the latter.
>> 
>> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
>> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
>> recall correctly) use EXTERNAL for localhost based authentication.  Some
>> applications probably use EXTERNAL for client-TLS too.
>
> But my earlier point stands: it's never the case, today, that there's
> any confusion as to what EXTERNAL means.  A rule can be stated to
> clarify what EXTERNAL means in future cases where there would be
> confusion.

Today the client can never know what mechanism the server used.  The
server can never know what mechanism the client intended to be used.  So
I think we disagree that there is confusion what EXTERNAL means today.
Reducing that perceived confusion is the point of the draft.

>> >> >  - The string "a002" in the example given should probably be explained,
>> >> >    or even removed (it seems superfluous, besides, 
>> >> 
>> >> It can't be removed, or the example wouldn't be valid ACAP, if I
>> >> understand correctly.  The same is in RFC 4422.  I don't think we need
>> >> to explain the ACAP protocol.  But maybe I'm missing something...
>> >
>> > Ah, ACAP.  But you don't need a specific application for the example.
>> 
>> We could add other examples too, but I don't see a point in removing the
>> current examples.  They are only examples, after all.  That text is
>> copied directly from RFC 4422, so I think it is useful to preserve for
>> historic comparisons too.
>
> Was there a reference to ACAP?  If not, add an informational one :)

There is one already.

/Simon

Date: Wed, 22 Apr 2009 15:41:51 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

On Wed, Apr 22, 2009 at 10:26:41PM +0200, Simon Josefsson wrote:
> > On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
> >> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> >> >> Complete diff:
> >> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> >> >> 
> >> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
> >> >
> >> > A few comments:
> >> >
> >> >  - I doubt today there's ever any cases where there could confusion as
> >> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
> >> >    a priori agreement is theoretical -- if so then the text should
> >> >    probably reflect that, otherwise examples should be given.
> >> 
> >> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
> >> refers to needs to be arranged out of band.  The point of this document
> >> [...]
> >
> > That's what it says, but does anyone ever do that, or does everyone take
> > EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> > the latter.
> 
> Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
> EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
> recall correctly) use EXTERNAL for localhost based authentication.  Some
> applications probably use EXTERNAL for client-TLS too.

But my earlier point stands: it's never the case, today, that there's
any confusion as to what EXTERNAL means.  A rule can be stated to
clarify what EXTERNAL means in future cases where there would be
confusion.

> >> >  - The string "a002" in the example given should probably be explained,
> >> >    or even removed (it seems superfluous, besides, 
> >> 
> >> It can't be removed, or the example wouldn't be valid ACAP, if I
> >> understand correctly.  The same is in RFC 4422.  I don't think we need
> >> to explain the ACAP protocol.  But maybe I'm missing something...
> >
> > Ah, ACAP.  But you don't need a specific application for the example.
> 
> We could add other examples too, but I don't see a point in removing the
> current examples.  They are only examples, after all.  That text is
> copied directly from RFC 4422, so I think it is useful to preserve for
> historic comparisons too.

Was there a reference to ACAP?  If not, add an informational one :)

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Apr 2009 22:29:25 +0200
Sender: [email-masked]

I noticed a minor nit in RFC 4422 when writing IANA section for
EXTERNAL-*, namely that in section 7.1.1 I think ' (or prefix for the
family)' is not relevant.  Should it be removed?

/Simon

To: [email-masked]
From:  Simon Josefsson <[email-masked]>
Subject:  Re: draft-josefsson-sasl-external-channel-03
Date:  Wed, 22 Apr 2009 22:26:41 +0200
Lines: 46
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Cancel-Lock: sha1:nMJdDHPPEd7SqyEBTNXNOES7Sjk=
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
>> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
>> >> Complete diff:
>> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
>> >> 
>> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
>> >
>> > A few comments:
>> >
>> >  - I doubt today there's ever any cases where there could confusion as
>> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
>> >    a priori agreement is theoretical -- if so then the text should
>> >    probably reflect that, otherwise examples should be given.
>> 
>> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
>> refers to needs to be arranged out of band.  The point of this document
>> [...]
>
> That's what it says, but does anyone ever do that, or does everyone take
> EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
> the latter.

Some applications (e.g., OpenLDAP if I understood Kurt correctly) uses
EXTERNAL for IPC channels.  Some applications (e.g., GNU MailUtils, if I
recall correctly) use EXTERNAL for localhost based authentication.  Some
applications probably use EXTERNAL for client-TLS too.

>> >  - The string "a002" in the example given should probably be explained,
>> >    or even removed (it seems superfluous, besides, 
>> 
>> It can't be removed, or the example wouldn't be valid ACAP, if I
>> understand correctly.  The same is in RFC 4422.  I don't think we need
>> to explain the ACAP protocol.  But maybe I'm missing something...
>
> Ah, ACAP.  But you don't need a specific application for the example.

We could add other examples too, but I don't see a point in removing the
current examples.  They are only examples, after all.  That text is
copied directly from RFC 4422, so I think it is useful to preserve for
historic comparisons too.

/Simon

Date: Wed, 22 Apr 2009 11:08:56 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

On Wed, Apr 22, 2009 at 12:24:00PM +0200, Simon Josefsson wrote:
> > On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> >> Complete diff:
> >> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> >> 
> >> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
> >
> > A few comments:
> >
> >  - I doubt today there's ever any cases where there could confusion as
> >    to what channel "EXTERNAL" refers to.  The confusion and the need for
> >    a priori agreement is theoretical -- if so then the text should
> >    probably reflect that, otherwise examples should be given.
> 
> I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
> refers to needs to be arranged out of band.  The point of this document
> [...]

That's what it says, but does anyone ever do that, or does everyone take
EXTERNAL to mean "use the user authenticated by TLS"?  I suspect it's
the latter.

> >  - When "EXTERNAL" is used one would think that the highest-layer,
> >    innermost end-to-end channel is the one it ought to refer to.  It
> >    strikes me as a good idea to state that.
> 
> This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
> in each EXTERNAL-FOO mechanism rather than in the generic framework, but
> I agree that this needs to be stated.  I have added this section:
> 
>   <t>The external security channel to use is implied by the SASL
>     mechanism name.  The channel has to be uniquely identifiable at
>     both cliend and server side.  This means that mechanisms
>     registered in this family MUST detail which channel should be
>     chosen if there are layered channels of the same type.</t>

OK.

> >  - An informative reference to TLS (RFC5246) seems necessary.  (Or
> >  maybe even normative.)
> 
> I've made it normative.  (There was an informative reference.)

OK.

> >  - The string "a002" in the example given should probably be explained,
> >    or even removed (it seems superfluous, besides, 
> 
> It can't be removed, or the example wouldn't be valid ACAP, if I
> understand correctly.  The same is in RFC 4422.  I don't think we need
> to explain the ACAP protocol.  But maybe I'm missing something...

Ah, ACAP.  But you don't need a specific application for the example.

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

   

N * M -> bad.

Nico
-- 

Cc: [email-masked]
From: Iv Ray <[email-masked]>
To: Dan White <[email-masked]>
Subject: Re: slow authentication
Date: Wed, 22 Apr 2009 17:11:49 +0200
Sender: [email-masked]

On 22.04.2009, at 16:40, Dan White wrote:
> Iv,
>
> The Cyrus SASL mailing list might be more appropriate for this  
> question:
>
> http://cyrusimap.web.cmu.edu/lists.html#lists
>
> Some areas to look at - If you're using SSL/TLS during  
> authentication, verify whether you're using /dev/random or /dev/ 
> urandom (see the manpage for 'random'). Using /dev/random may slow  
> down your initial connection if you don't have enough entropy.
>
> I would look more at sasl_pwcheck_method than sasl_mech_list. If  
> sasl_pwcheck_method is not specified, it will attempt all installed  
> pwcheck_methods in order. Try specifying your preferred method  
> explicitly, if it isn't already.
>
> If using the saslauthd pwcheck_method, trouble shoot saslauthd first  
> for delays (testsaslauthd).
>
> If using an exotic auxprop store method (e.g. MySQL, LDAP), trouble  
> shoot those separately. Turn off sasl_auto_transition, if enabled,  
> for trouble shooting.
>
> Set your sasl_log_level to 7. Monitor your syslog/auth.log.
>
> - Dan

Dan,

Thanks a lot! - I am starting to follow your notes.

And sorry again for confusing the list, I'll keep that in mind.

Thank you again,
Iv

Date: Wed, 22 Apr 2009 09:40:38 -0500
From: Dan White <[email-masked]>
To: Iv Ray <[email-masked]>
CC: [email-masked]
Subject: Re: slow authentication
Sender: [email-masked]

Iv Ray wrote:
>
> Hello everyone,
>
> I am running a mail server compiled from the latest versions of 
> Postfix and Cyrus IMAP with Cyrus SASL authentication on FreeBSD 6.x.
>
> Some months ago the web mail (Squirrelmail) became extremely slow to 
> login and on previous/next page inside the mail folder - it takes 
> about 25 seconds both to login and to change page.
>
> E-mail clients like Mac Mail became slow in the beginning only.
>
> I did some research and had some conversations on the Cyrus IMAP 
> mailing list and the direction so far is that the slowness is in the 
> authentication process (e-mail clients like Mac Mail experience 
> slowness only in the beginning, because they seem to authenticate only 
> then, while Squirrelmail authenticates on every request). I was 
> advised to turn off all Cyrus SASL modules except PLAIN and I did so, 
> however the 25 seconds delay persists.
>
> Does this sound familiar to someone?
>
> Any help would be appreciated.
>
> Iv
>

Iv,

The Cyrus SASL mailing list might be more appropriate for this question:

http://cyrusimap.web.cmu.edu/lists.html#lists

Some areas to look at - If you're using SSL/TLS during authentication, 
verify whether you're using /dev/random or /dev/urandom (see the manpage 
for 'random'). Using /dev/random may slow down your initial connection 
if you don't have enough entropy.

I would look more at sasl_pwcheck_method than sasl_mech_list. If 
sasl_pwcheck_method is not specified, it will attempt all installed 
pwcheck_methods in order. Try specifying your preferred method 
explicitly, if it isn't already.

If using the saslauthd pwcheck_method, trouble shoot saslauthd first for 
delays (testsaslauthd).

If using an exotic auxprop store method (e.g. MySQL, LDAP), trouble 
shoot those separately. Turn off sasl_auto_transition, if enabled, for 
trouble shooting.

Set your sasl_log_level to 7. Monitor your syslog/auth.log.

- Dan

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Apr 2009 12:24:00 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
>> Complete diff:
>> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
>> 
>> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt
>
> A few comments:
>
>  - I doubt today there's ever any cases where there could confusion as
>    to what channel "EXTERNAL" refers to.  The confusion and the need for
>    a priori agreement is theoretical -- if so then the text should
>    probably reflect that, otherwise examples should be given.

I don't follow -- RFC 4422 implies that the selection of what EXTERNAL
refers to needs to be arranged out of band.  The point of this document
is to move the negotiation in band.  Since RFC 4422 rules the
negotiation out of scope, there is by definition always confusion which
channel is intended, and even on successful authentication there is in
practice no in-band guarantees that both sides intended the same
channel.

Maybe Kurt could describe his use case?

>  - When "EXTERNAL" is used one would think that the highest-layer,
>    innermost end-to-end channel is the one it ought to refer to.  It
>    strikes me as a good idea to state that.

This is mentioned in section 3 for EXTERNAL-TLS.  I believe this belongs
in each EXTERNAL-FOO mechanism rather than in the generic framework, but
I agree that this needs to be stated.  I have added this section:

  <t>The external security channel to use is implied by the SASL
    mechanism name.  The channel has to be uniquely identifiable at
    both cliend and server side.  This means that mechanisms
    registered in this family MUST detail which channel should be
    chosen if there are layered channels of the same type.</t>

>  - An informative reference to TLS (RFC5246) seems necessary.  (Or
>  maybe even normative.)

I've made it normative.  (There was an informative reference.)

>  - The string "a002" in the example given should probably be explained,
>    or even removed (it seems superfluous, besides, 

It can't be removed, or the example wouldn't be valid ACAP, if I
understand correctly.  The same is in RFC 4422.  I don't think we need
to explain the ACAP protocol.  But maybe I'm missing something...

>  application protocol bindings of SASL are not needed in order to have
>  an example, no?).

...because I don't understand what you mean here, explain?

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 22 Apr 2009 11:53:35 +0200
Sender: [email-masked]

   SCRAM
   SCRAM-TLSUNIQUE
   SCRAM-TLSENDPOINT

   GS2-KRB5
   GS2-KRB5-TLSUNIQUE
   GS2-KRB5-TLSENDPOINT

/Simon

From: Iv Ray <[email-masked]>
To: [email-masked]
Subject: slow authentication
Date: Wed, 22 Apr 2009 09:47:41 +0200
Sender: [email-masked]

Hello everyone,

I am running a mail server compiled from the latest versions of  
Postfix and Cyrus IMAP with Cyrus SASL authentication on FreeBSD 6.x.

Some months ago the web mail (Squirrelmail) became extremely slow to  
login and on previous/next page inside the mail folder - it takes  
about 25 seconds both to login and to change page.

E-mail clients like Mac Mail became slow in the beginning only.

I did some research and had some conversations on the Cyrus IMAP  
mailing list and the direction so far is that the slowness is in the  
authentication process (e-mail clients like Mac Mail experience  
slowness only in the beginning, because they seem to authenticate only  
then, while Squirrelmail authenticates on every request). I was  
advised to turn off all Cyrus SASL modules except PLAIN and I did so,  
however the 25 seconds delay persists.

Does this sound familiar to someone?

Any help would be appreciated.

Iv

Date: Tue, 21 Apr 2009 15:37:51 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: Kurt Zeilenga <[email-masked]>
Subject: Comments on YAP
Sender: [email-masked]

I looked at draft-zeilenga-sasl-yap-03 when revising
draft-ietf-sasl-channel-bindings.

Here are some comments:

 - YAP as a variant of SCRAM seems like a good idea: you can reuse the
   SCRAM PBKDF and key management.  That means less administration, and
   also that you could normatively refer to SCRAM for parts of YAP, thus
   making the YAP I-D smaller.

 - IMO there should be a server->client message for mutual
   authentication (though as with SCRAM there's no server name).  The
   following is a YAP-as-variant-of-SCRAM exchange as I imagine it:

    C: p,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=p,a=nico,tls-unique:...")
    S: v=HMAC(ServerKey, <client's first message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

   With this you'd save a round-trip compared to SCRAM and could qualify
   for the Standards-Track (I guess what makes YAP Experimental is the
   lack of mutual authentication).

 - When the client has not cached the salt and/or PBKDF iteration counts
   or the cached values are out of date the mechanism could devolve into
   SCRAM:

    C: n,a=nico,n=Nico,p=<ClientKey XOR
			    HMAC(StoredKey, "n=Nico,cb=n,a=nico,tls-unique:...")
    S: s=<salt>,i=<iteration-count>
    C: n,a=nico,n=Nico,p=<ClientKey XOR ...>
    S: v=HMAC(ServerKey, <client's second message>)
    C: <empty>  (optional depending on the app protocol)
    S: <outcome of authentication>

 - You could even have YAP be exactly like SCRAM when the given channel
   binding type is not a unique channel binding type.

Nico
-- 

Date: Tue, 21 Apr 2009 15:17:06 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-03
Sender: [email-masked]

On Sat, Apr 18, 2009 at 12:44:09PM +0200, Simon Josefsson wrote:
> Complete diff:
> http://josefsson.org/external-channel/draft-josefsson-sasl-external-channel-03-from-2.diff.html
> 
> > http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-03.txt

A few comments:

 - I doubt today there's ever any cases where there could confusion as
   to what channel "EXTERNAL" refers to.  The confusion and the need for
   a priori agreement is theoretical -- if so then the text should
   probably reflect that, otherwise examples should be given.

 - When "EXTERNAL" is used one would think that the highest-layer,
   innermost end-to-end channel is the one it ought to refer to.  It
   strikes me as a good idea to state that.

 - An informative reference to TLS (RFC5246) seems necessary.  (Or maybe
   even normative.)

 - The string "a002" in the example given should probably be explained,
   or even removed (it seems superfluous, besides, application protocol
   bindings of SASL are not needed in order to have an example, no?).

Nico
-- 

Date: Tue, 21 Apr 2009 15:03:12 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Re: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Nico
-- 

Date: Tue, 21 Apr 2009 14:50:37 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Updated SASL And Channel Binding document (-03)
Sender: [email-masked]

Changes from -02:

 - added reference to YAP

Nico
-- 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-03.txt 
Date: Tue, 21 Apr 2009 13:00:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-03.txt
	Pages           : 10
	Date            : 2009-04-21

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

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

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

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 19 Apr 2009 06:27:47 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Apr 18, 2009, at 2:54 AM, Simon Josefsson wrote:
>
>> What problem do we want to solve by not letting IANA hand out
>> assignments on a FCFS basis?
>
> My concern is that someone will request the registration of a name in
> the family name space for a mechanism which doesn't fit well into that
> family.

Thanks for explaining, now I understand the concern better.  Still, I
don't think the human work needed to define/review instructions for
experts, assigning and replacing the expert, and dealing with the
potential of appeals, is motivated here.  The harm caused by a mistaken
registration is low.  Well intended people will listen to reason if we
can present good arguments, and eventually, we can't stop anyone from
using any mechanism name anyway.

I think the IESG have better things to do than responding to appeals
over an expert decision for this mechanism family.  The costs of IESG
appeals are high, the cost of even clearly bogus registrations is low.

The document could try to explain this issue further, and request people
more strongly to ask for review before requesting an assignment.  But I
think the current text is sufficiently clear already.

> I suspect the 7.1.1 procedures (which are FCFS) if applied here would
> likely work out okay in practice as the IANA practice seems to be "ask
> for help" in adding items to rarely used tables.  So I don't object to
> use of FCFS here.

Thanks.

/Simon

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Sat, 18 Apr 2009 06:13:39 -0700
Sender: [email-masked]

On Apr 18, 2009, at 2:54 AM, Simon Josefsson wrote:

> What problem do we want to solve by not letting IANA hand out
> assignments on a FCFS basis?

My concern is that someone will request the registration of a name in  
the family name space for a mechanism which doesn't fit well into that  
family.  I don't think specification review is requires to address  
this concern, but I do think review of the purpose of the requested  
name for the requested purpose.  I prefer that the RFC 4422, 7.1.2  
procedures used to register a family of mechanism be used in  
registering names within that family.

I suspect the 7.1.1 procedures (which are FCFS) if applied here would  
likely work out okay in practice as the IANA practice seems to be "ask  
for help" in adding items to rarely used tables.  So I don't object to  
use of FCFS here.

-- Kurt

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-gs2-12.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 18 Apr 2009 14:13:49 +0200
Sender: [email-masked]

[email-masked] writes:

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

Diff available from:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-sasl-gs2-12.txt

I think the only open issue now is how the channel binding gets chosen,
but it is similar to the same issue with SCRAM.

/Simon

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-gs2-12.txt 
Date: Sat, 18 Apr 2009 04:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title           : Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
	Author(s)       : S. Josefsson, N. Williams
	Filename        : draft-ietf-sasl-gs2-12.txt
	Pages           : 22
	Date            : 2009-04-18

This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework.  This is done by
defining a new SASL mechanism family, called GS2.  This mechanism
family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of
channel binding.  Only GSS-API mechanisms that support channel
binding are supported.

See <http://josefsson.org/sasl-gs2-*/> for more information.

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

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

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 18 Apr 2009 12:53:40 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Apr 14, 2009 at 06:06:59PM +0100, Alexey Melnikov wrote:
>> >>>I removed the part about localization.
>> >>>
>> >No!  These are purely local localizations, not part of any protocol.
>> >There's no need to mention language tags.
>> > 
>> >
>> Well Ok. But the document still needs to say how localization is controlled.
>
> It's a _local_ matter.  Like lots of other APIs.  The localization is to
> the caller's _locale_, which is a _local_ matter.
>
> There's nothing more for the spec to say, except perhaps that the
> localization is to the caller's locale.

I've restored this part of the document.  I don't care strongly about
this feature, but it is marginally potentially useful.  Let's see if it
passes further review.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 18 Apr 2009 12:01:47 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> I don't care strongly either.  FCFS w/ specification required (but not
> expert review, not standards action) seems like the best approach.

That would work.  It requires some effort on the person registering the
name, and anyone well intended to register a EXTERNAL-* name should be
able to spend the time to write down a specification for it.

Unfortunately RFC 5226 requires for "specification required" that the
specification is possible to implement in an interoperable way.  It also
requires a designated expert to evaluate.  That can be a quite delicate
issue, and I don't see what is gained by adding this.

The explanation in RFC 5226 for FCFS seems to describe the intent with
what you describe:

      First Come First Served - Assignments are made to anyone on a
            first come, first served basis.  There is no substantive
            review of the request, other than to ensure that it is
            well-formed and doesn't duplicate an existing assignment.
            However, requests must include a minimal amount of clerical
            information, such as a point of contact (including an email
            address) and a brief description of how the value will be
            used.  Additional information specific to the type of value
            requested may also need to be provided, as defined by the
            namespace.  For numbers, the exact value is generally
            assigned by IANA; with names, specific text strings can
            usually be requested.

            Examples: SASL mechanism names [RFC4422], LDAP Protocol
            Mechanisms, and LDAP Syntax [RFC4520].

The "brief description of how the value will be used" is the level of
detail that I believe we want to require.

Given that we already use FCFS to register SASL mechanism names, and
there haven't been any problems, I don't see any reason to use anything
more onerous to register EXTERNAL-* mechanism names.

/Simon

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 18 Apr 2009 11:54:23 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> Expert review is useful when it not feasible to let IANA to
> mechanically hand out assignments.

What problem do we want to solve by not letting IANA hand out
assignments on a FCFS basis?

> That is, the Reviewer should avoid reviewing the particulars of the
> mechanism and simply focus on whether the requested name is sensible
> for the requested purpose.  IANA prefers not to make such judgements,
> hence the need for Expert Review.

I don't understand how anyone can come to the conclusion that a name is
unacceptable for a purpose without reviewing the particulars of the
mechanism?  Could you give a concrete example?

The only threats I see to a FCFS approach are along these lines:

- Someone overloads IANA with one request every day
- Someone registers EXTERNAL-<offensive word>
- Someone registers EXTERNAL-<viagraspam.com>

The cost of accepting or dealing with problems like that, in the context
of registering EXTERNAL-* SASL mechanism names, appears to be low.  The
cost of implementing and handling appeals and expert review issues can
be significant and time consuming.

Again, I don't feel strongly about this, but if there is nothing else to
discuss around the draft, that seems like a good sign. ;)

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sat, 18 Apr 2009 11:42:45 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> This seems to require that application supports all channel binding
>> types.
>
> 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.

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

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

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

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

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.

> I'd argue that we should always bind to an end-to-end channel at the
> 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.

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

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

Date: Fri, 17 Apr 2009 06:34:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Choice of channel binding types in SCRAM
Sender: [email-masked]

Simon Josefsson wrote:

>Kurt Zeilenga <[email-masked]> writes:
>  
>
>>On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
>>    
>>
>>>If you were to propose adding the channel binding types to the
>>>mechanism
>>>names (well, suitably compressed to fit in the 20 char SASL mech name
>>>limit), I could go along with that.
>>>      
>>>
>>While not a perfect solution (I don't think a perfect solution
>>exists), I willing to go along with this... as I can simply ignore the
>>end-point variant.
>>    
>>
>That would work for me as well.  I don't see any reason to implement the
>tls-server-end-point channel binding as it only works with X.509 server
>certs whereas tls-unique always works.
>
>I share Kurt's concern that
>these channel binding trade-offs may make the system brittle.
>  
>
+1

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: Choice of channel binding types in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 17 Apr 2009 00:39:36 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
>> If you were to propose adding the channel binding types to the
>> mechanism
>> names (well, suitably compressed to fit in the 20 char SASL mech name
>> limit), I could go along with that.
>
> While not a perfect solution (I don't think a perfect solution
> exists), I willing to go along with this... as I can simply ignore the
> end-point variant.

That would work for me as well.  I don't see any reason to implement the
tls-server-end-point channel binding as it only works with X.509 server
certs whereas tls-unique always works.  I share Kurt's concern that
these channel binding trade-offs may make the system brittle.

/Simon

Date: Thu, 16 Apr 2009 15:05:36 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Choice of channel binding types in SCRAM
Sender: [email-masked]

On Thu, Apr 16, 2009 at 12:55:32PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
> >If you were to propose adding the channel binding types to the  
> >mechanism
> >names (well, suitably compressed to fit in the 20 char SASL mech name
> >limit), I could go along with that.
> 
> While not a perfect solution (I don't think a perfect solution  
> exists), I willing to go along with this... as I can simply ignore the  
> end-point variant.

Another possibility is to have a pair of magic mechanism names to
negotiate the use of one or another channel binding type independently
of mechanism name, with reasonable defaults for when these are missing
from the server's mech list.

Nico
-- 

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: Choice of channel binding types in SCRAM
Date: Thu, 16 Apr 2009 12:55:32 -0700
Sender: [email-masked]

On Apr 16, 2009, at 10:06 AM, Nicolas Williams wrote:
> If you were to propose adding the channel binding types to the  
> mechanism
> names (well, suitably compressed to fit in the 20 char SASL mech name
> limit), I could go along with that.

While not a perfect solution (I don't think a perfect solution  
exists), I willing to go along with this... as I can simply ignore the  
end-point variant.

-- Kurt

Date: Thu, 16 Apr 2009 12:06:31 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: Choice of channel binding types in SCRAM
Sender: [email-masked]

On Thu, Apr 16, 2009 at 09:15:00AM -0700, Kurt Zeilenga wrote:
> The selection of channel binding in SCRAM is client choice.  A client  
> may for various reasons be unwilling or unable to produce a end-point  
> channel binding.  A client ought to always use a unique channel  
> binding type and, server willing, bind to the channel, and a server  
> which willing to accept an end-point binding ought to willing to  
> accept a unique channel binding instead.  If this is not the case, it  
> would to create a very brittle system.

The client ought to always be able to use one type in particular or else
another.  And so far we'd been working with "tls-server-end-point" as
the preference.

> In short, at present, I think I favor allowing only unique channel  
> bindings in SCRAM.

Support for concentrators is crucial to deployment.  I don't see how we
can ignore concentrators.

If you were to propose adding the channel binding types to the mechanism
names (well, suitably compressed to fit in the 20 char SASL mech name
limit), I could go along with that.  Giving up on concentrators is just
not an option without first hearing from concentrator implementors
(also, I'm pretty sure that Chris would object).

Nico
-- 

Date: Thu, 16 Apr 2009 11:48:11 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Thu, Apr 16, 2009 at 09:46:11AM -0700, Kurt Zeilenga wrote:
> 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...
> 
>   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").

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

Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:46:11 -0700
Sender: [email-masked]

On Apr 16, 2009, at 9:13 AM, Nicolas Williams wrote:

>
> On Thu, Apr 16, 2009 at 09:03:20AM -0700, Kurt Zeilenga wrote:
>> On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:
>>> I actually changed that in -02 since that makes no sense for YAP.
>>> Please look at -02.
>>
>> 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.
>
> 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.

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

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

-- Kurt

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:32:04 -0700
Sender: [email-masked]

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

>>
>>
>> - Mechanisms that support channel bindings MUST protect the  
>> negotiation
>> 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.

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

Date: Thu, 16 Apr 2009 11:13:36 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Thu, Apr 16, 2009 at 09:03:20AM -0700, Kurt Zeilenga wrote:
> On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:
> >I actually changed that in -02 since that makes no sense for YAP.
> >Please look at -02.
> 
> 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.

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.

Date: Thu, 16 Apr 2009 11:12:23 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Thu, Apr 16, 2009 at 08:58:04AM -0700, Kurt Zeilenga wrote:
> 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.)

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

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

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

> >- 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.
> 
> I would be interested in discussing this further in the context of RFC  
> 4422 revision (that is, as changes to 4422bis I-D).

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

> >- Mechanisms that support channel bindings MUST protect the  
> >negotiation
> >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.

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: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Choice of channel binding types in SCRAM
Date: Thu, 16 Apr 2009 09:15:00 -0700
Sender: [email-masked]

The selection of channel binding in SCRAM is client choice.  A client  
may for various reasons be unwilling or unable to produce a end-point  
channel binding.  A client ought to always use a unique channel  
binding type and, server willing, bind to the channel, and a server  
which willing to accept an end-point binding ought to willing to  
accept a unique channel binding instead.  If this is not the case, it  
would to create a very brittle system.

Client developers generally like keep things simple.  Adding support  
for end-point types could be viewed by the client developer as an  
unnecessary complication.  It seems likely that client developers  
would simply not code support for end-point types.

Of course, some client developers might see some value in supporting  
end-point types and implement support for them.

By definition, a end-point binding is to be securely bound to the  
channel.  There have been some interesting discussions on and off list  
concerning the implications of self-signed certificates.  It was  
suggested that establishment of the end-point binding might involve  
user interfaces and this has some significant implications.

As a server developer, while I am somewhat concern that client  
developers won't well implement end-point channel bindings, I would be  
quite concerned if the creation of end-point channel bindings ever  
involved user interactions.  Such concerns might lead servers which  
reject end-point bindings.  And that in turn would lead to more client  
developers avoiding use of end-point bindings.

While I understand that end point bindings may be more TLS  
concentrator friendly, but to avoid creating a brittle system, this  
unfriendliness of unique bindings to TLS concentrators must be  
overcome OR we need to remove them from consideration.

In short, at present, I think I favor allowing only unique channel  
bindings in SCRAM.

-- Kurt

Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 09:03:20 -0700
Sender: [email-masked]

On Apr 16, 2009, at 7:45 AM, Nicolas Williams wrote:

>
> On Thu, Apr 16, 2009 at 07:17:08AM -0700, Kurt Zeilenga wrote:
>> On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman 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").
>
> I actually changed that in -02 since that makes no sense for YAP.
> Please look at -02.

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.

>>> 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've fixed this for YAP in -02.

This text is also from -02.

-- Kurt

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 08:58:04 -0700
Sender: [email-masked]

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

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.

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

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.

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

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

>
> - Mechanisms that support channel bindings MUST protect the  
> negotiation
> 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

Date: Thu, 16 Apr 2009 09:45:08 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Thu, Apr 16, 2009 at 07:17:08AM -0700, Kurt Zeilenga wrote:
> On Apr 16, 2009, at 6:45 AM, Jeffrey Hutzelman 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").

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

> >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've fixed this for YAP in -02.

Nico
-- 

Cc: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 07:45:49 -0700
Sender: [email-masked]

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

Date: Thu, 16 Apr 2009 10:35:54 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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

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.

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

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.

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

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

Date: Thu, 16 Apr 2009 09:24:49 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
Sender: [email-masked]

On Thu, Apr 16, 2009 at 11:04:28AM +0200, Simon Josefsson wrote:
> > I've updated the I-D:
> > 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.

Yes, it is.

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

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.

> To fix this, how about replacing "available" with "available and
> supported"?  That suggests applications need to decide which channel
> 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.

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

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

Date: Thu, 16 Apr 2009 15:23:54 +0100
From: Alexey Melnikov <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
CC: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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.

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

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.

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 07:17:08 -0700
Sender: [email-masked]

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

Date: Thu, 16 Apr 2009 09:45:14 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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

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

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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>, Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Thu, 16 Apr 2009 06:31:58 -0700
Sender: [email-masked]

On Apr 14, 2009, at 4:24 PM, Kurt Zeilenga wrote:

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

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: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: [email-masked]
Subject: Re: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 16 Apr 2009 11:04:28 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> I've updated the I-D:
>
> 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]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-sasl-4422bis-01.txt 
Date: Wed, 15 Apr 2009 15:36:13 -0700
Sender: [email-masked]

This is a simple refresh.

-- Kurt

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-sasl-4422bis-01.txt 
Date: Wed, 15 Apr 2009 13:45:02 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title		: Simple Authentication and Security Layer (SASL)
	Author(s)	: A. Melnikov, K. Zeilenga
	Filename	: draft-ietf-sasl-4422bis-01.txt
	Pages		: 32
	Date		: 2009-4-14
	
The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-oriented protocols via replaceable mechanisms.  It
   provides a structured interface between protocols and mechanisms.
   The resulting framework allows new protocols to reuse existing
   mechanisms and allows old protocols to make use of new mechanisms.
   The framework also provides a protocol for securing subsequent
   protocol exchanges within a data security layer.

   This document describes how a SASL mechanism is structured, describes
   how protocols include support for SASL, and defines the protocol for
   carrying a data security layer over a connection.  In addition, this
   document defines one SASL mechanism, the EXTERNAL mechanism.

   This document obsoletes RFC 4422 [[when approved]].

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

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

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

Date: Wed, 15 Apr 2009 12:22:18 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: -02 posted (Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt)
Sender: [email-masked]

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: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-02.txt 
Date: Wed, 15 Apr 2009 10:30:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-02.txt
	Pages           : 9
	Date            : 2009-04-15

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

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

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-01.txt 
Date: Wed, 15 Apr 2009 10:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

	Title           : SASL And Channel Binding
	Author(s)       : N. Williams
	Filename        : draft-ietf-sasl-channel-bindings-01.txt
	Pages           : 9
	Date            : 2009-04-15

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

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

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Cc: Simon Josefsson <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Wed, 15 Apr 2009 09:31:32 -0700
Sender: [email-masked]

On Apr 15, 2009, at 8:28 AM, Nicolas Williams wrote:

>
> On Wed, Apr 15, 2009 at 01:19:36PM +0200, Simon Josefsson wrote:
>> Having read the replies, and agreeing fully with Jeff's notion that  
>> the
>> IETF should not have a monopoly of EXTERNAL-* mechanisms, let me  
>> suggest
>> that we use a First-Come-First-Serve model.  [...]
>>
>> I don't care strongly which approach to use.  So I would be fine with
>> any of (in preference order) FCFS, specification required, or expert
>> review.  I do feel strongly that it should not be difficult to get a
>> IANA allocation.  We have plenty of bad experience with protocols  
>> that
>> has too rigid protocol number allocation policies.
>
> I don't care strongly either.  FCFS w/ specification required (but not
> expert review, not standards action) seems like the best approach.
>
> EXTERNAL is not exactly tricky, after all, so why demand, say, expert
> review?

Expert review is useful when it not feasible to let IANA to  
mechanically hand out assignments.

Expert review need not be heavy nor result in a denial.

     Additional names may be registered under Expert Review or IESG  
Approval [RFC5226].

     Registration of mechanisms detailed in IETF documents require  
IESG Approval.  The IESG Approval route
     is also open to others, such as those whose requests were denied  
under the Expert Review route.

     The Designated Expert will review only the appropriateness of the  
requested name for the requested purpose.
     No specification is required.  Where a specification is provided,  
the particulars of the specification are
     not to be considered by the Designated Expert.  Where the  
Designated Expert finds the requested name to be inappropriate,
     the Designated Expert should recommend a more appropriate name  
within the family and, if acceptable by the requestor, this
     name will be registered without any further review.  In hopefully  
rare cases where the Designated Expert finds the request
     wholly unacceptable (for instance, when the stated purpose has  
nothing to do with the purpose of the family), the
     Designated Expert may deny the request.  Actions of the Expert  
are appealable [RFC2026].

That is, the Reviewer should avoid reviewing the particulars of the  
mechanism and simply focus on whether the requested name is sensible  
for the requested purpose.  IANA prefers not to make such judgements,  
hence the need for Expert Review.

-- Kurt

Date: Wed, 15 Apr 2009 10:28:04 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
Sender: [email-masked]

On Wed, Apr 15, 2009 at 01:19:36PM +0200, Simon Josefsson wrote:
> Having read the replies, and agreeing fully with Jeff's notion that the
> IETF should not have a monopoly of EXTERNAL-* mechanisms, let me suggest
> that we use a First-Come-First-Serve model.  [...]
> 
> I don't care strongly which approach to use.  So I would be fine with
> any of (in preference order) FCFS, specification required, or expert
> review.  I do feel strongly that it should not be difficult to get a
> IANA allocation.  We have plenty of bad experience with protocols that
> has too rigid protocol number allocation policies.

I don't care strongly either.  FCFS w/ specification required (but not
expert review, not standards action) seems like the best approach.

EXTERNAL is not exactly tricky, after all, so why demand, say, expert
review?

From: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 15 Apr 2009 13:19:36 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> Simon,
>
> Overall, this I-D mets my needs.  Thanks!

Great.

> One issue the I-D needs to discuss is how to establish additional
> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC
> or EXTERNAL-IPC.  How are names of family members ensured to be
> unique?  etc.

Having read the replies, and agreeing fully with Jeff's notion that the
IETF should not have a monopoly of EXTERNAL-* mechanisms, let me suggest
that we use a First-Come-First-Serve model.  It is important to ensure
uniqueness of mechanism names, and in my experience both expert review
and specification required models can delay or defer people to request a
mechanism name.  That is bad.  Further, I see strong benefit in the
expert reviewer or specification required model over FCFS.  Thoughts?

I don't care strongly which approach to use.  So I would be fine with
any of (in preference order) FCFS, specification required, or expert
review.  I do feel strongly that it should not be difficult to get a
IANA allocation.  We have plenty of bad experience with protocols that
has too rigid protocol number allocation policies.

/Simon

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 16:24:35 -0700
Sender: [email-masked]

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:
>
>>
>> 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:
>>>
>>>>
>>>> RFC 4422 purposed avoided detailing APIs.
>>>
>>> We're talking about abstractions, not API's.
>>
>>
>> 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.
>
> 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.

>
>
>
>> Yes, but it's descriptive in nature, not prescriptive.  I find the
>> 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.
>
>
>> 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.
>
> 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.

>
> It is _intolerable_ to me that protocols should have to have  
> 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 this.

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

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

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.

>
>
>> 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.
>
>
>
>>>> 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.
>>>
>>>
>>>>> That means we MUST specify what channel
>>>>> binding means in the context of SASL.
>>>>
>>>> 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.
>>
>> 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.
>
> 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.
>
>> I argue it is premature to view our channel binding solution to be  
>> the
>> 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.

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.

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

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
>

Date: Tue, 14 Apr 2009 17:27:58 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
cc: Nicolas Williams <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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

>
> 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:
>>
>>>
>>> RFC 4422 purposed avoided detailing APIs.
>>
>> We're talking about abstractions, not API's.
>
>
> 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.

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.

> Yes, but it's descriptive in nature, not prescriptive.  I find the
> 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.

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

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.

>>> 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.
>>
>>
>>>> That means we MUST specify what channel
>>>> binding means in the context of SASL.
>>>
>>> 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.
>
> 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.

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.

> I argue it is premature to view our channel binding solution to be the
> 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.

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

Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 14:20:05 -0700
Sender: [email-masked]

On Apr 14, 2009, at 12:34 PM, Nicolas Williams wrote:
> Let's short-circuit this discussion as we're going around in circles.

Okay.

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

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.

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

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

I'll repeat it here:

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

-- Kurt

Cc: Simon Josefsson <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Tue, 14 Apr 2009 14:08:24 -0700
Sender: [email-masked]

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

>
> --On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga <[email-masked] 
> > wrote:
>
>>
>> Simon,
>>
>> Overall, this I-D mets my needs.  Thanks!
>>
>> One issue the I-D needs to discuss is how to establish additional
>> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL- 
>> IPSEC or
>> EXTERNAL-IPC.  How are names of family members ensured to be  
>> unique?  etc.
>>
>> I suggest that EXTERNAL-* family members be registered in the SASL
>> mechanism name table under an Expert Review Required policy.  I  
>> rather
>> not use "Specification Required" as that overly burdensome, and I  
>> don't
>> see any particular reason for the IETF to have a monopoly on the  
>> design
>> of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely  
>> do so
>> outside of the IETF.)
>
> Uh, generally Specification Required is _less_ restrictive than  
> Expert Review, as it only requires that you provide a specification  
> rather than requiring approval from someone.

I note that RFC 5226 says "Specification Required also implies use of  
a Designated Expert".  Designated Expert is an alias for Expert Review.

Anyways, though a document can place all kinds of requirements upon  
what an "Expert Review" might cover, I was thinking of a review  
limited to the appropriateness of the request.  That is, no  
requirement (but no preclusion) that the Expert review anything  
outside the registration request.

I would be fine with Specification Required.  The difference doesn't  
matter much (to me).

> Meeting the requirement means providing some form of specification;  
> it does not require an RFC, let alone IETF approval.
>
>
> That said, I agree with the approach, and with the notion that the  
> IETF needn't have a monopoly on EXTERNAL-* mechanisms.
>
> -- Jeff
>

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 13:52:52 -0700
Sender: [email-masked]

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:
>
>>
>> RFC 4422 purposed avoided detailing APIs.
>
> We're talking about abstractions, not API's.

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

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

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, 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.
>
>
>>> That means we MUST specify what channel
>>> binding means in the context of SASL.
>>
>> 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.

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.

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

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

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

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.
>
> Abstraction is _important_.
> Modularity is _important_.

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 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.
>
>
>> 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.
>
> RFC 4422 specifies almost no protocol.
> It specifies an abstraction.

A very limited abstraction.

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

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

Date: Tue, 14 Apr 2009 15:08:23 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
Sender: [email-masked]

On Tue, Apr 14, 2009 at 03:54:02PM -0400, Jeffrey Hutzelman wrote:
> 
> --On Tuesday, April 14, 2009 12:48:05 PM -0700 Kurt Zeilenga 
> <[email-masked]> wrote:
> 
> >
> >Simon,
> >
> >Overall, this I-D mets my needs.  Thanks!
> >
> >One issue the I-D needs to discuss is how to establish additional
> >EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC or
> >EXTERNAL-IPC.  How are names of family members ensured to be unique?  etc.
> >
> >I suggest that EXTERNAL-* family members be registered in the SASL
> >mechanism name table under an Expert Review Required policy.  I rather
> >not use "Specification Required" as that overly burdensome, and I don't
> >see any particular reason for the IETF to have a monopoly on the design
> >of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely do so
> >outside of the IETF.)
> 
> Uh, generally Specification Required is _less_ restrictive than Expert 
> Review, as it only requires that you provide a specification rather than 
> requiring approval from someone.  Meeting the requirement means providing 
> some form of specification; it does not require an RFC, let alone IETF 
> approval.
> 
> That said, I agree with the approach, and with the notion that the IETF 
> needn't have a monopoly on EXTERNAL-* mechanisms.

Moreover, we're not likely to have many more variants of EXTERNAL than
-TLS, -IPsec and -IPC.  Sure, I could see some SASL app tunneled over
HTTP with DIGEST-MD5 or HTTP/Negotiate, so maybe EXTERNAL-HTTP.  It's
unlikely that we'd have SASL apps over RPC protocols or over other SASL
apps.  Thus we can expect three, maybe four EXTERNAL-* variants.

Nico
-- 

Date: Tue, 14 Apr 2009 15:54:02 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Simon Josefsson <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-02
Sender: [email-masked]

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

>
> Simon,
>
> Overall, this I-D mets my needs.  Thanks!
>
> One issue the I-D needs to discuss is how to establish additional
> EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC or
> EXTERNAL-IPC.  How are names of family members ensured to be unique?  etc.
>
> I suggest that EXTERNAL-* family members be registered in the SASL
> mechanism name table under an Expert Review Required policy.  I rather
> not use "Specification Required" as that overly burdensome, and I don't
> see any particular reason for the IETF to have a monopoly on the design
> of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd likely do so
> outside of the IETF.)

Uh, generally Specification Required is _less_ restrictive than Expert 
Review, as it only requires that you provide a specification rather than 
requiring approval from someone.  Meeting the requirement means providing 
some form of specification; it does not require an RFC, let alone IETF 
approval.

That said, I agree with the approach, and with the notion that the IETF 
needn't have a monopoly on EXTERNAL-* mechanisms.

-- Jeff

Date: Tue, 14 Apr 2009 14:34:26 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 12:06:38PM -0700, Kurt Zeilenga wrote:
> On Apr 14, 2009, at 10:54 AM, Nicolas Williams wrote:
> >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,
> 
> 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.

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

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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Simon Josefsson <[email-masked]>
Subject: Re: draft-josefsson-sasl-external-channel-02
Date: Tue, 14 Apr 2009 12:48:05 -0700
Sender: [email-masked]

Simon,

Overall, this I-D mets my needs.  Thanks!

One issue the I-D needs to discuss is how to establish additional  
EXTERNAL-* mechanisms.  That is, say I wanted to define EXTERNAL-IPSEC  
or EXTERNAL-IPC.  How are names of family members ensured to be  
unique?  etc.

I suggest that EXTERNAL-* family members be registered in the SASL  
mechanism name table under an Expert Review Required policy.  I rather  
not use "Specification Required" as that overly burdensome, and I  
don't see any particular reason for the IETF to have a monopoly on the  
design of such mechanisms.  (If I were to specify EXTERNAL-IPC, I'd  
likely do so outside of the IETF.)

In particular, I suggest adding another registration request for  
EXTERNAL-TLS to the the IANA considerations section and then adding  
the statement:

	Registration of additional members of this family requires Expert  
Review [BCPXXXX].

to the end of the section (replacing XXXX with the number of the BCP  
that defines Expert Review).

-- Kurt

Date: Tue, 14 Apr 2009 15:37:58 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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

>> That means we MUST specify what channel
>> binding means in the context of SASL.
>
> 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.

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

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

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

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

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

Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 12:06:38 -0700
Sender: [email-masked]

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

>
> On Tue, Apr 14, 2009 at 10:39:14AM -0700, Kurt Zeilenga wrote:
>> On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman 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.
>
> 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,

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.

>
>
>> I simply think it's too early to treat channel bindings as if it were
>> 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.

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

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.

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

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.

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

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
> for you to comment on Jeff's points.
>
>> And as far as the statements premise referring to a need to establish
>> 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.

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.

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

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.

>
>
>>                          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.
>
> Nonsense.  Why even have RFC4422 if there's no room for public SASL
> interfaces?

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

Date: Tue, 14 Apr 2009 12:54:46 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 10:39:14AM -0700, Kurt Zeilenga wrote:
> On Apr 14, 2009, at 7:39 AM, Jeffrey Hutzelman 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.

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.

> I simply think it's too early to treat channel bindings as if it were  
> 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.

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

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

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

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.

> And as far as the statements premise referring to a need to establish  
> 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.

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

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

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

Nico
-- 

Cc: Nicolas Williams <[email-masked]>, [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Tue, 14 Apr 2009 10:39:14 -0700
Sender: [email-masked]

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:
>
>>
>>
>> On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:
>>
>>>
>>> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>>>
>>>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>>>> 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).
>>>>
>>>> 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.
>>>
>>> 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.
>>
>> 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.
>
>
> 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  
> 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.

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

Date: Tue, 14 Apr 2009 12:13:43 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 06:06:59PM +0100, Alexey Melnikov wrote:
> >>>I removed the part about localization.
> >>>
> >No!  These are purely local localizations, not part of any protocol.
> >There's no need to mention language tags.
> > 
> >
> Well Ok. But the document still needs to say how localization is controlled.

It's a _local_ matter.  Like lots of other APIs.  The localization is to
the caller's _locale_, which is a _local_ matter.

There's nothing more for the spec to say, except perhaps that the
localization is to the caller's locale.

Date: Tue, 14 Apr 2009 11:56:29 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-01
Sender: [email-masked]

On Tue, Apr 14, 2009 at 09:56:59AM +0200, Simon Josefsson wrote:
> Jeffrey Hutzelman <[email-masked]> writes:
> > I think you have to encode the type of channel to be used for this in
> > the mechanism name, so that it becomes part of the input to mechanism
> > selection.  It would be poor for a client to select EXTERNAL-CHANNEL
> > thinking it's going to get to use credentials from one channel type,
> > only to discover that the server only supports some different type.
> >
> > Unfortunately this does mean you need to register a distinct name for
> > each channel type, but I think that's unavoidable anyway.  The thing
> > we're interested in here is a channel type, not a channel binding
> > type.
> 
> I agree with that.  I have re-read the discussion around
> external-channel-00 and it also leaned towards that approach.
> 
> Thus, I believe the way forward is to define a EXTERNAL-* mechanism
> family and provide one instantiation as EXTERNAL-TLS.

+1

Date: Tue, 14 Apr 2009 11:43:34 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 05:41:27PM +0200, Simon Josefsson wrote:
> Jeffrey Hutzelman <[email-masked]> writes:
> > A GSS-API mechanism spec that allows this to result in an infinite
> > loop is buggy.
> 
> Where is the requirement that makes such behaviour buggy?

We don't need any stinking RFCs to tell us that infinite loops are bugs.

I almost put in a smiley, but I'm too serious about this assertion.
Some things should be self-evident, and this is one of them.  I will not
work on an update to the GSS-API just to make this clarification if it
isn't already clear.

Date: Tue, 14 Apr 2009 18:06:59 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Simon Josefsson <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, Apr 14, 2009 at 07:41:35AM +0100, Alexey Melnikov wrote:
>  
>
>>Simon Josefsson wrote:
>>    
>>
>>>Alexey Melnikov <[email-masked]> writes:
>>>      
>>>
>>>>10.  GSS_Mechanism_SASLname call
>>>>
>>>>To allow SASL implementations to query for the SASL mechanism name of
>>>>a GSS-API mechanism, we specify a new GSS-API function for this
>>>>purpose.
>>>>
>>>>   Inputs:
>>>>
>>>>   o desired_mech OBJECT IDENTIFIER
>>>>
>>>>   Outputs:
>>>>
>>>>   o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>>>     (really, ASCII)
>>>>
>>>>   o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>>>     localized
>>>>
>>>>   o mech_description UTF-8 STRING -- possibly localized
>>>>     description of this mechanism.
>>>>
>>>>
>>>>With my Apps AD hat on: if you want to allow localization, you need a
>>>>way to control language/local. So a new parameter for language tags is
>>>>needed (see RFC 4646).
>>>>        
>>>>
>>>I removed the part about localization.
>>>      
>>>
>No!  These are purely local localizations, not part of any protocol.
>There's no need to mention language tags.
>  
>
Well Ok. But the document still needs to say how localization is controlled.

>Please restore the text about localization.
>  
>

Date: Tue, 14 Apr 2009 11:45:59 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 07:41:35AM +0100, Alexey Melnikov wrote:
> Simon Josefsson wrote:
> >Alexey Melnikov <[email-masked]> writes:
> > 
> >>10.  GSS_Mechanism_SASLname call
> >>
> >> To allow SASL implementations to query for the SASL mechanism name of
> >> a GSS-API mechanism, we specify a new GSS-API function for this
> >> purpose.
> >>
> >>    Inputs:
> >>
> >>    o desired_mech OBJECT IDENTIFIER
> >>
> >>    Outputs:
> >>
> >>    o sasl_mech_name OCTET STRING -- SASL name for this mechanism
> >>      (really, ASCII)
> >>
> >>    o mech_name UTF-8 STRING -- name of this mechanism, possibly
> >>      localized
> >>
> >>    o mech_description UTF-8 STRING -- possibly localized
> >>      description of this mechanism.
> >>
> >>
> >>With my Apps AD hat on: if you want to allow localization, you need a
> >>way to control language/local. So a new parameter for language tags is
> >>needed (see RFC 4646).
> >>   
> >>
> >I removed the part about localization.

No!  These are purely local localizations, not part of any protocol.
There's no need to mention language tags.

Please restore the text about localization.

> I am not sure the "mech_name" field is useful.

Possibly not, indeed.  ("EXTERNAL", "PLAIN" could be localized, others
probably not.)

> >The important part is the 'sasl_mech_name' field.
> > 
> >
> Yes.

Not only.  The mech_description is important too for observability.

Date: Tue, 14 Apr 2009 11:41:14 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 10:06:01AM +0200, Simon Josefsson wrote:
> > Should "p" also be preceeded by "F"?

Only if the GSS mechanism is not a "standard" mechanism -- the "F" means
just that.  The Kerberos V mechanism is and SCRAM will be standard in
the RFC2743 sense, therefore the "F" should NOT be present in the case
of SASL/GS2 w/ Kerberos V or SCRAM.

Nico
-- 

Date: Tue, 14 Apr 2009 11:38:49 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 10:06:01AM +0200, Simon Josefsson wrote:
> 
> Alexey Melnikov <[email-masked]> writes:
> 
> >>>Also, the server SHOULD refrain from sending GSS-API error tokens
> >>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
> >>>along with a major status code other than GSS_S_COMPLETE or
> >>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
> >>>
> >>> I am not sure I agree – SASL error reporting is poor.    
> >>>
> >>Are you asking for GSS-API error tokens to be sent?
> >>  
> >>
> > Yes. I don't see a reason why it shouldn't.
> 
> Nico, what do you think here?
> 
> I don't care strongly.  My experience with GSS-API is that you can't
> expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
> error tokens on failures.  However, that could be seen as a bug.

I don't care strongly, and I don't agree with your experience -- error
tokens are *very* useful.  However, I've had this discussion with Sam in
the past and he's always insisted that there should be an option to not
send error tokens, and the motivation for that is to avoid leaking
information to attackers.

> I don't see any critical problem in allowing error tokens to be sent.

I don't either.  I think we should make that a MAY.

Nico
-- 

Date: Tue, 14 Apr 2009 11:32:03 -0500
From: Nicolas Williams <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 07:54:04AM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >No, absolutely not.  The channel binding type is not being negotiated.
> >
> Why not?

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

Date: Tue, 14 Apr 2009 11:30:01 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 09:52:23AM +0200, Simon Josefsson wrote:
> > 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.

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.

> >> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
> >> etc.
> >
> > 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.
> 
> Why?

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

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

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: draft-josefsson-sasl-external-channel-02
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 18:09:14 +0200
Sender: [email-masked]

Folks,

I've updated the EXTERNAL-* draft to avoid referring to the channel
binding document for security channel names.  This made it easier to
discuss TLS specific items.

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism Family for External Authentication: EXTERNAL-*
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-02.txt
> 	Pages           : 9
> 	Date            : 2009-04-14
>
> This document describes a way to perform client authentication in the
> Simple Authentication and Security Layer (SASL) framework by
> referring to the end-user authentication provided by an external
> security layer.  We specify a SASL mechanism family EXTERNAL-* and
> one instance EXTERNAL-TLS that rely on the Transport Layer Security
> (TLS) protocol.  This mechanism differs to the existing EXTERNAL
> mechanism by alleviating the a priori assumptions that servers and
> clients needs somehow negotiate out of band which secure channel that
> is intended.  This document also discuss the implementation of
> authorization decisions.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-02.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.
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 17:41:27 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> --On Tuesday, April 14, 2009 11:20:33 AM +0200 Simon Josefsson
> <[email-masked]> wrote:
>
>> I'm not certain of that: if context establishment enters into an error
>> case, sending an error token is expected.  The response to an error
>> token could be another error token.  And so on.  I don't find any text
>> that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
>> say something about this.
>
> A GSS-API mechanism spec that allows this to result in an infinite
> loop is buggy.

Where is the requirement that makes such behaviour buggy?

If there is none in RFC 2743 I think GS2 needs to discuss this.
Further, in that case, I'm not even sure you can claim that it is buggy.

> The simplest way to handle this is for processing of an error token to
> not ever produce an output_token.  More complicated approaches are
> possible, but generally unnecessary, since an "error token" already
> indicates the context establishment is going to fail.

Consider if the receiver is unable to parse an incoming token, and
doesn't know whether it is a normal context token or an error token.
Sending a error token back doesn't seem entirely unreasonable to me.

> In fact, I think it is reasonable for a GSS-API application to assume
> that any context establishment call which produces a major status
> other than GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the
> call should not be made again.

Right, and the GS2 implementation is an GSS-API application here, so the
GS2 document should explain this.

>> Hm.  Thinking more about this, I'm not sure it is possible to send an
>> error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
>> anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
>> should fail.  There is no way to associate a SASL failure with some
>> data, is there?  We could delay the SASL failure though.
>
> Yes, you'd have to delay the SASL failure for a round trip, if the
> error token is emitted by the SASL server.

Right.

Do you have a preference between my 1) and 2) option?

/Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 17:37:25 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> --On Monday, April 13, 2009 11:39:56 PM +0100 Alexey Melnikov
> <[email-masked]> wrote:
>
>> 10.  GSS_Mechanism_SASLname call
>>
>>    To allow SASL implementations to query for the SASL mechanism name of
>>    a GSS-API mechanism, we specify a new GSS-API function for this
>>    purpose.
>>
>>       Inputs:
>>
>>       o desired_mech OBJECT IDENTIFIER
>>
>>       Outputs:
>>
>>       o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>         (really, ASCII)
>>
>>       o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>         localized
>>
>>       o mech_description UTF-8 STRING -- possibly localized
>>         description of this mechanism.
>>
>>
>> With my Apps AD hat on: if you want to allow localization, you need a way
>> to control language/local. So a new parameter for language tags is needed
>> (see RFC 4646).
>
> Actually, no, you don't, because this is an abstract API, not a
> protocol, and the correct answer is platform- and language-binding
> dependent.  In particular, the correct answer is almost certainly to
> extract the name from a message catalog corresponding to the user's
> current locale, or some platform-specific equivalent.  In any case,
> localization of the GSS-API is definitely _not_ in the scope of the
> SASL WG.

Agreed.

> I think the right thing to do here is to remove the mech_name and
> mech_description outputs, which are not SASL-specific and have nothing
> to do with the purpose of this call.  That information should be
> obtained via a separate GSS_Display_mech call, to be defined in
> KITTEN.

Yup.

> For that matter, this call really ought to be renamed something like
> GSS_Inquire_mech_sasl_name, for consistency with the way the abstract
> GSS-API is defined.

Yes.  I have renamed it to GSS_Inquire_SASLname_for_mech.  I think that
is slightly better because it puts the property to query for first,
which is consistent with the two GSS_Inquire_* support calls.  It also
makes the function name the reverse of the GSS_Inquire_mech_for_SASLname
which also seems good for consistency.

/Simon

Date: Tue, 14 Apr 2009 10:56:41 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

--On Monday, April 13, 2009 11:39:56 PM +0100 Alexey Melnikov 
<[email-masked]> wrote:

> 10.  GSS_Mechanism_SASLname call
>
>    To allow SASL implementations to query for the SASL mechanism name of
>    a GSS-API mechanism, we specify a new GSS-API function for this
>    purpose.
>
>       Inputs:
>
>       o desired_mech OBJECT IDENTIFIER
>
>       Outputs:
>
>       o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>         (really, ASCII)
>
>       o mech_name UTF-8 STRING -- name of this mechanism, possibly
>         localized
>
>       o mech_description UTF-8 STRING -- possibly localized
>         description of this mechanism.
>
>
> With my Apps AD hat on: if you want to allow localization, you need a way
> to control language/local. So a new parameter for language tags is needed
> (see RFC 4646).

Actually, no, you don't, because this is an abstract API, not a protocol, 
and the correct answer is platform- and language-binding dependent.  In 
particular, the correct answer is almost certainly to extract the name from 
a message catalog corresponding to the user's current locale, or some 
platform-specific equivalent.  In any case, localization of the GSS-API is 
definitely _not_ in the scope of the SASL WG.

I think the right thing to do here is to remove the mech_name and 
mech_description outputs, which are not SASL-specific and have nothing to 
do with the purpose of this call.  That information should be obtained via 
a separate GSS_Display_mech call, to be defined in KITTEN.

For that matter, this call really ought to be renamed something like 
GSS_Inquire_mech_sasl_name, for consistency with the way the abstract 
GSS-API is defined.

-- Jeff

Date: Tue, 14 Apr 2009 10:47:48 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: SASL WG <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

--On Tuesday, April 14, 2009 11:20:33 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

> I'm not certain of that: if context establishment enters into an error
> case, sending an error token is expected.  The response to an error
> token could be another error token.  And so on.  I don't find any text
> that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
> say something about this.

A GSS-API mechanism spec that allows this to result in an infinite loop is 
buggy.  The simplest way to handle this is for processing of an error token 
to not ever produce an output_token.  More complicated approaches are 
possible, but generally unnecessary, since an "error token" already 
indicates the context establishment is going to fail.

In fact, I think it is reasonable for a GSS-API application to assume that 
any context establishment call which produces a major status other than 
GSS_S_CONTINUE_NEEDED does not expect a reply, and thus the call should not 
be made again.

> Hm.  Thinking more about this, I'm not sure it is possible to send an
> error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
> anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
> should fail.  There is no way to associate a SASL failure with some
> data, is there?  We could delay the SASL failure though.

Yes, you'd have to delay the SASL failure for a round trip, if the error 
token is emitted by the SASL server.

-- Jeff

Date: Tue, 14 Apr 2009 10:39:34 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Kurt Zeilenga <[email-masked]>, Nicolas Williams <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

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

>
>
> On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:
>
>>
>> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>>
>>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>>> 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).
>>>
>>> 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.
>>
>> 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.
>
> 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.

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

Date: Tue, 14 Apr 2009 11:58:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
> =20
>
>>Simon Josefsson wrote:
>>   =20
>>
>>>Alexey Melnikov <[email-masked]> writes:
>>>     =20
>>>
>>>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>>>
>>>>>>I am not sure I agree =E2=80=93 SASL error reporting is poor.
>>>>>>           =20
>>>>>>
>>>>>Are you asking for GSS-API error tokens to be sent?
>>>>>         =20
>>>>>
>>>>Yes. I don't see a reason why it shouldn't.
>>>>       =20
>>>>
>>>Nico, what do you think here?
>>>
>>>I don't care strongly.  My experience with GSS-API is that you can't
>>>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>>>error tokens on failures.  However, that could be seen as a bug.
>>>
>>>I don't see any critical problem in allowing error tokens to be sent.
>>>If we allow it, we need to require that implementations needs to make
>>>sure they don't endlessly send error tokens back and forward, don't we?
>>>Otherwise I think we may end up in an infinite loop.
>>>     =20
>>>
>>IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
>>But it wouldn't hurt to say explicitly.
>>   =20
>>
>
>I'm not certain of that: if context establishment enters into an error
>case, sending an error token is expected.  The response to an error
>token could be another error token.  And so on.  I don't find any text
>that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
>say something about this.
>
>Hm.  Thinking more about this, I'm not sure it is possible to send an
>error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
>anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
>should fail.  There is no way to associate a SASL failure with some
>data, is there?
>
There isn't, but an endpoint can send some data that would cause the=20
other end to fail the authentication exchange.

>We could delay the SASL failure though.
>
>So either we replace the paragraph above with:
>
>		<t>The client and server MUST NOT send any GSS-API
>		    tokens (tokens output by GSS_Init_sec_context() or
>		    GSS_Accept_sec_context() when the major status
>		    code is other than GSS_S_COMPLETE or
>		    GSS_S_CONTINUE_NEEDED) as this indicate an error
>		    situation and the SASL negotiation MUST fail.</t>
>
>Or
>
>		<t>The client and server MAY send GSS-API error tokens
>		    (tokens output by GSS_Init_sec_context() or
>		    GSS_Accept_sec_context() when the major status
>		    code is other than GSS_S_COMPLETE or
>		    GSS_S_CONTINUE_NEEDED).  As this indicate an error
>		    condition, after sending the token, the sending
>		    side should fail the authentication.</t>
>
>Is there any other option?
> =20
>
I can't think of any.
Obviously, I prefer the latter.

>Thoughts?
>
>I suspect Nico have some insight into this.
> =20
>

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 12:00:04 +0200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

>>>>Example #4: using channel binding.
>>>>
>>>>C: Request authentication exchange
>>>>S: Empty Challenge
>>>>C: yauthzid=someuser, <initial context token with standard
>>>>
>>>>Should this start with “p”?
>>>>
>>>>header removed>
>>>> S: Send reply context token as is    
>>>>
>>>Yes.
>>>
>> Should "p" also be preceeded by "F"?
>
> Yes.

No, this was wrong -- the only time the "F" should be present is when
the client were unable to remove the standard GSS-API token header.  I
tried to clarify the document, and fixed the examples.

/Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: Re: GS2: always use header compression?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 11:57:49 +0200
Sender: [email-masked]

Never mind, I had misunderstood the purpose of the "F" flag.

I have tried to clarify the document to possibly avoid others from
having the same misunderstanding.  New document:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
Diff against last version:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html

I'll wait some days for the current discussions to settle down and then
submit an update.

/Simon

Simon Josefsson <[email-masked]> writes:

> Thinking about implementing GS2, handling the gs2-std-mech ("F") flag
> seems complicated.  Is there any reason why GS2 cannot always require
> clients to remove the header and servers to add it?
>
> I believe this would lead to more robust code paths in implementations
> (i.e., removing and adding the token is always done).  It also reduces
> protocol complexity in that there are fewer ways GS2 can be negotiated.
> This reduces the number of protocol variations that can be deployed,
> which likely leads to better interoperability.
>
> Thus I propose to remove the gs2-std-mech "F" flag and update the text
> to require clients/server to always perform this step.  SCRAM doesn't
> need any update, -12 doesn't seem to send a "F" at all and doesn't
> discuss it.
>
> /Simon

From: Simon Josefsson <[email-masked]>
To: [email-masked]
Subject: GS2: always use header compression?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 11:40:40 +0200
Sender: [email-masked]

Thinking about implementing GS2, handling the gs2-std-mech ("F") flag
seems complicated.  Is there any reason why GS2 cannot always require
clients to remove the header and servers to add it?

I believe this would lead to more robust code paths in implementations
(i.e., removing and adding the token is always done).  It also reduces
protocol complexity in that there are fewer ways GS2 can be negotiated.
This reduces the number of protocol variations that can be deployed,
which likely leads to better interoperability.

Thus I propose to remove the gs2-std-mech "F" flag and update the text
to require clients/server to always perform this step.  SCRAM doesn't
need any update, -12 doesn't seem to send a "F" at all and doesn't
discuss it.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 11:20:33 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> Simon Josefsson wrote:
>
>>Alexey Melnikov <[email-masked]> writes:
>>  
>>
>>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>>
>>>>> I am not sure I agree – SASL error reporting is poor.           
>>>>>
>>>>Are you asking for GSS-API error tokens to be sent?
>>>>      
>>>>
>>>Yes. I don't see a reason why it shouldn't.
>>>    
>>>
>>Nico, what do you think here?
>>
>>I don't care strongly.  My experience with GSS-API is that you can't
>>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>>error tokens on failures.  However, that could be seen as a bug.
>>
>>I don't see any critical problem in allowing error tokens to be sent.
>>If we allow it, we need to require that implementations needs to make
>>sure they don't endlessly send error tokens back and forward, don't we?
>>Otherwise I think we may end up in an infinite loop.
>>  
>>
> IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
> But it wouldn't hurt to say explicitly.

I'm not certain of that: if context establishment enters into an error
case, sending an error token is expected.  The response to an error
token could be another error token.  And so on.  I don't find any text
that discuss this in RFC 2743 or, e.g., RFC 1964.  I think we need to
say something about this.

Hm.  Thinking more about this, I'm not sure it is possible to send an
error token: if GSS_Init_sec_context/GSS_Accept_sec_context returns
anything but GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED the SASL layer
should fail.  There is no way to associate a SASL failure with some
data, is there?  We could delay the SASL failure though.

So either we replace the paragraph above with:

		<t>The client and server MUST NOT send any GSS-API
		    tokens (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED) as this indicate an error
		    situation and the SASL negotiation MUST fail.</t>

Or

		<t>The client and server MAY send GSS-API error tokens
		    (tokens output by GSS_Init_sec_context() or
		    GSS_Accept_sec_context() when the major status
		    code is other than GSS_S_COMPLETE or
		    GSS_S_CONTINUE_NEEDED).  As this indicate an error
		    condition, after sending the token, the sending
		    side should fail the authentication.</t>

Is there any other option?

Thoughts?

I suspect Nico have some insight into this.

/Simon

Date: Tue, 14 Apr 2009 09:52:57 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
> =20
>
>>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>>along with a major status code other than GSS_S_COMPLETE or
>>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>>
>>>>I am not sure I agree =E2=80=93 SASL error reporting is poor.   =20
>>>>       =20
>>>>
>>>Are you asking for GSS-API error tokens to be sent?
>>>     =20
>>>
>>Yes. I don't see a reason why it shouldn't.
>>   =20
>>
>Nico, what do you think here?
>
>I don't care strongly.  My experience with GSS-API is that you can't
>expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
>error tokens on failures.  However, that could be seen as a bug.
>
>I don't see any critical problem in allowing error tokens to be sent.
>If we allow it, we need to require that implementations needs to make
>sure they don't endlessly send error tokens back and forward, don't we?
>Otherwise I think we may end up in an infinite loop.
> =20
>
IMHO, this would be a bug in a GSS-API mechanism and/or implementation.
But it wouldn't hurt to say explicitly.

>>>I agree with you that SASL error reporting is poor, but I'm not sure
>>>sending GSS-API error tokens will help -- the problem is typically the
>>>APIs between the SASL library and the application.  Also, GSS-API error
>>>reporting is also generally poor (e.g., no localization).
>>>     =20
>>>
>>[...]
>>   =20
>>
>>>>Example #4: using channel binding.
>>>>
>>>>C: Request authentication exchange
>>>>S: Empty Challenge
>>>>C: yauthzid=3Dsomeuser, <initial context token with standard
>>>>
>>>>Should this start with =E2=80=9Cp=E2=80=9D?
>>>>
>>>>header removed>
>>>>S: Send reply context token as is
>>>>       =20
>>>>
>>>Yes.
>>>     =20
>>>
>>Should "p" also be preceeded by "F"?
>>   =20
>>
>Yes.  I also noticed it should use 'a=3Dsomeuser' instead of
>'authzid=3Dsomeuser'.
>
>However, it would be nice with more detailed examples and explaining
>text.
> =20
>
Oh, good point.

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 10:13:27 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>I removed the part about localization.
>>
> Actually, I am not convinced this is sufficient.
>
>>Frankly, I'm not sure the
>>'mech_name' and 'mech_description' fields are useful.
>>
> I am not sure the "mech_name" field is useful.
>
>>The important part is the 'sasl_mech_name' field.
>>  
>>
> Yes.

I agree.  I've removed mech_name and mech_description from the document
now.  The fields are not used by GS2.  They are just a nice thing to
have for GSS-API generally.  Spending time to add it and fix
localization doesn't seem like the best use of our time.

/Simon

From: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 10:06:01 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

>>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>>along with a major status code other than GSS_S_COMPLETE or
>>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>>
>>> I am not sure I agree – SASL error reporting is poor.    
>>>
>>Are you asking for GSS-API error tokens to be sent?
>>  
>>
> Yes. I don't see a reason why it shouldn't.

Nico, what do you think here?

I don't care strongly.  My experience with GSS-API is that you can't
expect GSS_Init_sec_context/GSS_Accept_sec_context to generate useful
error tokens on failures.  However, that could be seen as a bug.

I don't see any critical problem in allowing error tokens to be sent.
If we allow it, we need to require that implementations needs to make
sure they don't endlessly send error tokens back and forward, don't we?
Otherwise I think we may end up in an infinite loop.

>>I agree with you that SASL error reporting is poor, but I'm not sure
>>sending GSS-API error tokens will help -- the problem is typically the
>>APIs between the SASL library and the application.  Also, GSS-API error
>>reporting is also generally poor (e.g., no localization).
>>
> [...]
>
>>>Example #4: using channel binding.
>>>
>>>C: Request authentication exchange
>>>S: Empty Challenge
>>>C: yauthzid=someuser, <initial context token with standard
>>>
>>>Should this start with “p”?
>>>
>>>header removed>
>>> S: Send reply context token as is    
>>>
>>Yes.
>>
> Should "p" also be preceeded by "F"?

Yes.  I also noticed it should use 'a=someuser' instead of
'authzid=someuser'.

However, it would be nice with more detailed examples and explaining
text.

> [...]
>
>>>The channel binding data MAY be sent (byt the actual GSS-API
>>>
>>>Typo: by
>>>    
>>>
> I've changed "byt" to "but"?

Should be fixed.

>>>mechanism used) without confidentiality protection and knowledge of
>>>it is assumed to provide no advantage to an MITM (who can, in any
>>>case, compute the channel binding data independently). If the
>>>external channel does not provide confidentiality protection and the
>>>GSS-API mechanism does not provide confidentiality protection for the
>>>channel binding data, then passive attackers (eavesdroppers) can
>>>recover the channel binding data. See [RFC5056].
>>>
>>>[…]
>>>
>>>GS2 does not directly use any cryptographic algorithms, therefore it
>>>is automatically "algorithm agile", or, as agile as the GSS-API
>>>mechanisms that are available for use in SASL apoplications via GS2.
>>>
>>> Typo: applications    
>>>
>>Thanks.
>>
>>Updated document:
>>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>>
>>Changes compared to -11:
>>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html
>>
> Other changes look good. (I am still thinking about your SASLPrep response)

Compare RFC 4616:

   The authorization identity (authzid), authentication identity
   (authcid), password (passwd), and NUL character deliminators SHALL be
   transferred as [UTF-8] encoded strings of [Unicode] characters.  As
   the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
   character MUST NOT appear in authzid, authcid, or passwd productions.

   The form of the authzid production is specific to the application-
   level protocol's SASL profile [SASL].  The authcid and passwd
   productions are form-free.  Use of non-visible characters or
   characters that a user may be unable to enter on some keyboards is
   discouraged.

/Simon

From: Simon Josefsson <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-01
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 09:56:59 +0200
Sender: [email-masked]

Jeffrey Hutzelman <[email-masked]> writes:

> --On Tuesday, April 14, 2009 01:52:27 AM +0200 Simon Josefsson
> <[email-masked]> wrote:
>
>>
>> All,
>>
>> I've noticed some renewed interest in an EXTERNAL variant that refers to
>> an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.
>>
>> There is one open issue: whether it is worthwhile to reference RFC 5056
>> for channel names, or whether the document should go ahead and define a
>> EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
>> TLS channel.  It could also reserve EXTERNAL-* for other external
>> security channels.  I don't care strongly, but I do suspect that
>> interoperability will be better with the EXTERNAL-TLS approach (as there
>> are multiple channel names for TLS channels already, and more are
>> proposed).
>
> I think you have to encode the type of channel to be used for this in
> the mechanism name, so that it becomes part of the input to mechanism
> selection.  It would be poor for a client to select EXTERNAL-CHANNEL
> thinking it's going to get to use credentials from one channel type,
> only to discover that the server only supports some different type.
>
> Unfortunately this does mean you need to register a distinct name for
> each channel type, but I think that's unavoidable anyway.  The thing
> we're interested in here is a channel type, not a channel binding
> type.

I agree with that.  I have re-read the discussion around
external-channel-00 and it also leaned towards that approach.

Thus, I believe the way forward is to define a EXTERNAL-* mechanism
family and provide one instantiation as EXTERNAL-TLS.

/Simon

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 09:52:23 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Tue, Apr 14, 2009 at 02:19:35AM +0200, Simon Josefsson wrote:
>> > For EXTERNAL the app will just have to retrieve the authenticated ID
>> > itself.
>> 
>> The name of the channel will help, though.  Then the app will know to
>                                    ^
> 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.

>> use credentials from TLS, instead of guessing or trying IPSEC, SSH, TLS
>> etc.
>
> 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.

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

Date: Tue, 14 Apr 2009 07:54:04 +0100
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

Nicolas Williams wrote:

>On Mon, Apr 13, 2009 at 05:47:13PM -0700, Kurt Zeilenga wrote:
>  
>
>>On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:
>>    
>>
>>>On Mon, Apr 13, 2009 at 06:07:21PM -0500, 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.
>>    
>>
>No, absolutely not.  The channel binding type is not being negotiated.
>  
>
Why not?

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

Date: Tue, 14 Apr 2009 07:41:35 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
>  
>
>>10.  GSS_Mechanism_SASLname call
>>
>>  To allow SASL implementations to query for the SASL mechanism name of
>>  a GSS-API mechanism, we specify a new GSS-API function for this
>>  purpose.
>>
>>     Inputs:
>>
>>     o desired_mech OBJECT IDENTIFIER
>>
>>     Outputs:
>>
>>     o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>>       (really, ASCII)
>>
>>     o mech_name UTF-8 STRING -- name of this mechanism, possibly
>>       localized
>>
>>     o mech_description UTF-8 STRING -- possibly localized
>>       description of this mechanism.
>>
>>
>>With my Apps AD hat on: if you want to allow localization, you need a
>>way to control language/local. So a new parameter for language tags is
>>needed (see RFC 4646).
>>    
>>
>I removed the part about localization.
>
Actually, I am not convinced this is sufficient.

>Frankly, I'm not sure the
>'mech_name' and 'mech_description' fields are useful.
>
I am not sure the "mech_name" field is useful.

>The important part is the 'sasl_mech_name' field.
>  
>
Yes.

Date: Tue, 14 Apr 2009 07:35:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

Simon Josefsson wrote:

>Alexey Melnikov <[email-masked]> writes:
> =20
>
 [...]

>>In Section 4.1:
>>
>>Also, the server SHOULD refrain from sending GSS-API error tokens
>>(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
>>along with a major status code other than GSS_S_COMPLETE or
>>GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>>
>>I am not sure I agree =E2=80=93 SASL error reporting is poor.   =20
>>
>Are you asking for GSS-API error tokens to be sent?
> =20
>
Yes. I don't see a reason why it shouldn't.

>I agree with you that SASL error reporting is poor, but I'm not sure
>sending GSS-API error tokens will help -- the problem is typically the
>APIs between the SASL library and the application.  Also, GSS-API error
>reporting is also generally poor (e.g., no localization).
>
 [...]

>>Example #4: using channel binding.
>>
>>C: Request authentication exchange
>>S: Empty Challenge
>>C: yauthzid=3Dsomeuser, <initial context token with standard
>>
>>Should this start with =E2=80=9Cp=E2=80=9D?
>>
>>header removed>
>>S: Send reply context token as is   =20
>>
>Yes.
>
Should "p" also be preceeded by "F"?
 [...]

>>The channel binding data MAY be sent (byt the actual GSS-API
>>
>>Typo: by
>>   =20
>>
I've changed "byt" to "but"?

>>mechanism used) without confidentiality protection and knowledge of
>>it is assumed to provide no advantage to an MITM (who can, in any
>>case, compute the channel binding data independently). If the
>>external channel does not provide confidentiality protection and the
>>GSS-API mechanism does not provide confidentiality protection for the
>>channel binding data, then passive attackers (eavesdroppers) can
>>recover the channel binding data. See [RFC5056].
>>
>>[=E2=80=A6]
>>
>>GS2 does not directly use any cryptographic algorithms, therefore it
>>is automatically "algorithm agile", or, as agile as the GSS-API
>>mechanisms that are available for use in SASL apoplications via GS2.
>>
>>Typo: applications   =20
>>
>Thanks.
>
>Updated document:
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2.txt
>
>Changes compared to -11:
>http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html
>
Other changes look good. (I am still thinking about your SASLPrep response)

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 21:48:00 -0700
Sender: [email-masked]

On Apr 13, 2009, at 8:05 PM, Nicolas Williams wrote:

>
> On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
>>
>> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
>>> 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).
>>
>> 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.
>
> 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.

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

Date: Mon, 13 Apr 2009 23:41:05 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: draft-josefsson-sasl-external-channel-01
Sender: [email-masked]

--On Tuesday, April 14, 2009 01:52:27 AM +0200 Simon Josefsson 
<[email-masked]> wrote:

>
> All,
>
> I've noticed some renewed interest in an EXTERNAL variant that refers to
> an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.
>
> There is one open issue: whether it is worthwhile to reference RFC 5056
> for channel names, or whether the document should go ahead and define a
> EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
> TLS channel.  It could also reserve EXTERNAL-* for other external
> security channels.  I don't care strongly, but I do suspect that
> interoperability will be better with the EXTERNAL-TLS approach (as there
> are multiple channel names for TLS channels already, and more are
> proposed).

I think you have to encode the type of channel to be used for this in the 
mechanism name, so that it becomes part of the input to mechanism 
selection.  It would be poor for a client to select EXTERNAL-CHANNEL 
thinking it's going to get to use credentials from one channel type, only 
to discover that the server only supports some different type.

Unfortunately this does mean you need to register a distinct name for each 
channel type, but I think that's unavoidable anyway.  The thing we're 
interested in here is a channel type, not a channel binding type.

-- Jeff

Date: Mon, 13 Apr 2009 22:05:30 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Mon, Apr 13, 2009 at 07:38:26PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
> >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).
> 
> 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.

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

Date: Mon, 13 Apr 2009 22:02:31 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Mon, Apr 13, 2009 at 05:47:13PM -0700, Kurt Zeilenga wrote:
> 
> On Apr 13, 2009, at 4:47 PM, Nicolas Williams wrote:
> 
> >
> >On Mon, Apr 13, 2009 at 06:07:21PM -0500, 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.

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.

Date: Mon, 13 Apr 2009 22:01:19 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Tue, Apr 14, 2009 at 02:19:35AM +0200, Simon Josefsson wrote:
> > For EXTERNAL the app will just have to retrieve the authenticated ID
> > itself.
> 
> 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
> etc.

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.

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 19:38:26 -0700
Sender: [email-masked]

On Apr 13, 2009, at 4:07 PM, Nicolas Williams wrote:
> 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).

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

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 17:47:13 -0700
Sender: [email-masked]

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

>
> On Mon, Apr 13, 2009 at 06:07:21PM -0500, 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: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Kurt Zeilenga <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 02:19:35 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
>> 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.
>
> 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.

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: Simon Josefsson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: SASL WG <[email-masked]>
Subject: Re: Comments on draft-ietf-sasl-gs2-11.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 02:14:37 +0200
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> GS2 SASL mechanism names must be 20 characters (after removing “GS2-“ 
> prefix and “–PLUS” suffix). The following text in Section 3.3 is out
> of date:
>
> The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
> 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
> 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
> 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
> binary, and re-group them in groups of 5, and convert them back to
> decimal, which results in these computations:
>
> It should say instead “the first 7 octets, drop 1 bit”.

Thanks, fixed.

> In Section 4.1:
>
> Also, the server SHOULD refrain from sending GSS-API error tokens
> (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
> along with a major status code other than GSS_S_COMPLETE or
> GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
>
> I am not sure I agree – SASL error reporting is poor.

Are you asking for GSS-API error tokens to be sent?

I agree with you that SASL error reporting is poor, but I'm not sure
sending GSS-API error tokens will help -- the problem is typically the
APIs between the SASL library and the application.  Also, GSS-API error
reporting is also generally poor (e.g., no localization).

> Later in the same section:
>
> gs2-std-mech = "F"
> ;; "F" means the mechanism is NOT is a
> Extra “is”
> ;; standard GSS-API mechanism in that the
> ;; RFC2743 section 3.1 header was missing

Fixed, thanks.

> The server MUST replace any occurance of "=" (comma) in the string
>
> s/(comma)/(equal sign)
>
> with "=3D".

I used 'equals' instead, as per RFC 20.

> Should the document require application of SASLPrep to authorization
> identity? I think it should, or SCRAM is not going to match GS2.
> If SASLPrep is to be used, then SASLPrep errors should also be listed
> in Section 7.

SASLPrep of authorization identities is an application issue, not a SASL
mechanism issue.  As such, SCRAM should not perform SASLprep of
authzid's.

> In Section 5:
>
> If the server supports channel binding then it must list both forms
>
> s/must/MUST
>
> of the SASL mechanism name for each GSS-API mechanism supported via
> GS2 (i.e., GSS-API mechanisms that support channel binding).

Done.

> Example #4: using channel binding.
>
> C: Request authentication exchange
> S: Empty Challenge
> C: yauthzid=someuser, <initial context token with standard
>
> Should this start with “p”?
>
> header removed>
> S: Send reply context token as is

Yes.

> 10.  GSS_Mechanism_SASLname call
>
>   To allow SASL implementations to query for the SASL mechanism name of
>   a GSS-API mechanism, we specify a new GSS-API function for this
>   purpose.
>
>      Inputs:
>
>      o desired_mech OBJECT IDENTIFIER
>
>      Outputs:
>
>      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
>        (really, ASCII)
>
>      o mech_name UTF-8 STRING -- name of this mechanism, possibly
>        localized
>
>      o mech_description UTF-8 STRING -- possibly localized
>        description of this mechanism.
>
>
> With my Apps AD hat on: if you want to allow localization, you need a
> way to control language/local. So a new parameter for language tags is
> needed (see RFC 4646).

I removed the part about localization.  Frankly, I'm not sure the
'mech_name' and 'mech_description' fields are useful.  The important
part is the 'sasl_mech_name' field.

> In Section 14.3:
>
> GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
> with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
> be used as a GS2 mechanism. To make this easier for SASL
> implementations we assign a symbolic SASL mechanism name to the
> SPNEGO GSS-API mechanism: "SPNEGO".
>
> If SPNEGO is disallowed in GS2, why do we assign a name to it?

Presumably in case SPNEGO is going to be used in SASL:

		    [What about SASL apps that don't do mechanism
		    negotiation?  Probably none exist.  But if any did
		    then presumably it would OK to use the SPNEGO
		    mechanism, no?  -Nico]</t>

However, I'm also a bit skeptical about assigning a name for it.

> The channel binding data MAY be sent (byt the actual GSS-API
>
> Typo: by
>
> mechanism used) without confidentiality protection and knowledge of
> it is assumed to provide no advantage to an MITM (who can, in any
> case, compute the channel binding data independently). If the
> external channel does not provide confidentiality protection and the
> GSS-API mechanism does not provide confidentiality protection for the
> channel binding data, then passive attackers (eavesdroppers) can
> recover the channel binding data. See [RFC5056].
>
> […]
>
> GS2 does not directly use any cryptographic algorithms, therefore it
> is automatically "algorithm agile", or, as agile as the GSS-API
> mechanisms that are available for use in SASL apoplications via GS2.
>
> Typo: applications

Thanks.

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

Changes compared to -11:
http://josefsson.org/sasl-gs2/draft-ietf-sasl-gs2-from--11.diff.html

Please verify that your suggestions have been fixed.

/Simon

Date: Mon, 13 Apr 2009 18:47:45 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Mon, Apr 13, 2009 at 06:07:21PM -0500, Nicolas Williams wrote:
> 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.

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]>
To: [email-masked]
Subject: draft-josefsson-sasl-external-channel-01
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 01:52:27 +0200
Sender: [email-masked]

All,

I've noticed some renewed interest in an EXTERNAL variant that refers to
an outer TLS channel, so I updated my earlier EXTERNAL-CHANNEL document.

There is one open issue: whether it is worthwhile to reference RFC 5056
for channel names, or whether the document should go ahead and define a
EXTERNAL-TLS mechanism directly.  That would refer directly to an outer
TLS channel.  It could also reserve EXTERNAL-* for other external
security channels.  I don't care strongly, but I do suspect that
interoperability will be better with the EXTERNAL-TLS approach (as there
are multiple channel names for TLS channels already, and more are
proposed).

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism for External Authentication using a Named Channel: EXTERNAL-CHANNEL
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-01.txt
> 	Pages           : 9
> 	Date            : 2009-04-13
>
> This document describes a way to perform end-user authentication in
> the Simple Authentication and Security Layer (SASL) framework by re-
> using an external security layer (such as the Transport Layer
> Security (TLS) protocol) that may have already completed end-user
> authentication.  In comparison with the existing EXTERNAL mechanism,
> this mechanism alleviates the a priori assumptions made by the design
> of the EXTERNAL mechanism.  This mechanism transfers an identifier of
> the external channel to be used explicitly.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Date: Mon, 13 Apr 2009 18:07:21 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Mon, Apr 13, 2009 at 03:55:53PM -0700, Kurt Zeilenga wrote:
> >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.

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: Simon Josefsson <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: Nicolas Williams <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 14 Apr 2009 01:15:41 +0200
Sender: [email-masked]

Kurt Zeilenga <[email-masked]> writes:

> On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:
>
>>
>> On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>>> I generally do not favor changing RFC 4422 as discussed in this I-D.
>>>
>>> My view is that while GS2 mechanisms (such as SCRAM) handle channel
>>> in
>>> similar ways (by design), we should not impose any restriction that
>>> other mechanisms which support channel bindings do so in a like way.
>>>
>>> For instance, many of the suggested restrictions make little sense
>>> for
>>> YAP.  Nor would they necessarily make sense for a "channel-bound"
>>> EXTERNAL mechanism (which, BTW, I have in the works).
>>
>> Can you elaborate?  Also, EXTERNAL is just not an issue.
>
> Basically, there is a desire for a client to state from which lower-
> level it wishes to pull up an identity from.  So, my idea is to use
> unique channel bindings to specify which lower-level.  This use of
> channel binding is not intended to add any security protection, just
> as a convenient means to uniquely identify a channel.

That is already described in:

http://tools.ietf.org/html/draft-josefsson-sasl-external-channel-00

There were comments that said transferring the actual channel binding
data is pointless, so I'll remove that part and resubmit as -01.

/Simon

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Date: Mon, 13 Apr 2009 15:55:53 -0700
Sender: [email-masked]

On Apr 13, 2009, at 2:19 PM, Nicolas Williams wrote:

>
> On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
>> I generally do not favor changing RFC 4422 as discussed in this I-D.
>>
>> My view is that while GS2 mechanisms (such as SCRAM) handle channel  
>> in
>> similar ways (by design), we should not impose any restriction that
>> other mechanisms which support channel bindings do so in a like way.
>>
>> For instance, many of the suggested restrictions make little sense  
>> for
>> YAP.  Nor would they necessarily make sense for a "channel-bound"
>> EXTERNAL mechanism (which, BTW, I have in the works).
>
> Can you elaborate?  Also, EXTERNAL is just not an issue.

Basically, there is a desire for a client to state from which lower- 
level it wishes to pull up an identity from.  So, my idea is to use  
unique channel bindings to specify which lower-level.  This use of  
channel binding is not intended to add any security protection, just  
as a convenient means to uniquely identify a channel.

-- Kurt

Date: Mon, 13 Apr 2009 23:39:56 +0100
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: Comments on draft-ietf-sasl-gs2-11.txt
Sender: [email-masked]

GS2 SASL mechanism names must be 20 characters (after removing =93GS2-=93=20
prefix and =93=96PLUS=94 suffix). The following text in Section 3.3 is out o=
f=20
date:

The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
binary, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations:

It should say instead =93the first 7 octets, drop 1 bit=94.

In Section 4.1:

Also, the server SHOULD refrain from sending GSS-API error tokens
(tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
along with a major status code other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.

I am not sure I agree =96 SASL error reporting is poor.

Later in the same section:

gs2-std-mech =3D "F"
;; "F" means the mechanism is NOT is a
Extra =93is=94
;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing

The server MUST replace any occurance of "=3D" (comma) in the string

s/(comma)/(equal sign)

with "=3D3D".

Should the document require application of SASLPrep to authorization=20
identity? I think it should, or SCRAM is not going to match GS2.
If SASLPrep is to be used, then SASLPrep errors should also be listed in=20
Section 7.

In Section 5:

If the server supports channel binding then it must list both forms

s/must/MUST

of the SASL mechanism name for each GSS-API mechanism supported via
GS2 (i.e., GSS-API mechanisms that support channel binding).

Example #4: using channel binding.

C: Request authentication exchange
S: Empty Challenge
C: yauthzid=3Dsomeuser, <initial context token with standard

Should this start with =93p=94?

header removed>
S: Send reply context token as is

10.  GSS_Mechanism_SASLname call

   To allow SASL implementations to query for the SASL mechanism name of
   a GSS-API mechanism, we specify a new GSS-API function for this
   purpose.

      Inputs:

      o desired_mech OBJECT IDENTIFIER

      Outputs:

      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
        (really, ASCII)

      o mech_name UTF-8 STRING -- name of this mechanism, possibly
        localized

      o mech_description UTF-8 STRING -- possibly localized
        description of this mechanism.

With my Apps AD hat on: if you want to allow localization, you need a=20
way to control language/local. So a new parameter for language tags is=20
needed (see RFC 4646).

In Section 14.3:

GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO".

If SPNEGO is disallowed in GS2, why do we assign a name to it?

The channel binding data MAY be sent (byt the actual GSS-API

Typo: by

mechanism used) without confidentiality protection and knowledge of
it is assumed to provide no advantage to an MITM (who can, in any
case, compute the channel binding data independently). If the
external channel does not provide confidentiality protection and the
GSS-API mechanism does not provide confidentiality protection for the
channel binding data, then passive attackers (eavesdroppers) can
recover the channel binding data. See [RFC5056].

[=85]

GS2 does not directly use any cryptographic algorithms, therefore it
is automatically "algorithm agile", or, as agile as the GSS-API
mechanisms that are available for use in SASL apoplications via GS2.

Typo: applications

Date: Mon, 13 Apr 2009 16:19:24 -0500
From: Nicolas Williams <[email-masked]>
To: Kurt Zeilenga <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
Sender: [email-masked]

On Mon, Apr 13, 2009 at 02:03:47PM -0700, Kurt Zeilenga wrote:
> I generally do not favor changing RFC 4422 as discussed in this I-D.
> 
> My view is that while GS2 mechanisms (such as SCRAM) handle channel in  
> similar ways (by design), we should not impose any restriction that  
> other mechanisms which support channel bindings do so in a like way.
> 
> For instance, many of the suggested restrictions make little sense for  
> YAP.  Nor would they necessarily make sense for a "channel-bound"  
> EXTERNAL mechanism (which, BTW, I have in the works).

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

From: Kurt Zeilenga <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt 
Date: Mon, 13 Apr 2009 14:03:47 -0700
Sender: [email-masked]

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:

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

Date: Fri, 10 Apr 2009 17:06:39 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Optimizing use of SASL/GS2 over TLS
Reply-To: [email-masked]
Sender: [email-masked]

[Note: SASL and KITTEN WGs are Bcc'ed.]

I've submitted an I-D describing how to reduce the number of round trips
needed for SASL/GS2 mechanism negotiation and authentication when
running over TLS:

    draft-williams-tls-app-sasl-opt-01.txt

This can be seen as a variant of the TLS/GSS proposal from a while back
as it achieves the same result: you can use the GSS-API for
authentication _and_ TLS for session protection without having to pay a
round trip penalty.  But it does it in a slightly different and simpler
way.

I'm hoping this proposal will be less controversial than the TLS/GSS
proposal.

Comments?

Nico
-- 

Date: Fri, 10 Apr 2009 13:19:42 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Never mind (Re: Protecting the mech negotiation in GS2)
Sender: [email-masked]

Never mind -- if one is doing channel binding (and one should be) then
the mechanism negotiation is protected implicitly.  And if not, well,
since the new mechanisms don't have sec layers there's not much point in
protecting the negotiation.

Nico
-- 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sasl-channel-bindings-00.txt 
Date: Thu,  9 Apr 2009 16:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

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

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

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

Date: Thu, 9 Apr 2009 17:54:50 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Updating RFC4422 to support channel bindings
Sender: [email-masked]

I've submitted draft-ietf-sasl-channel-bindings-00.txt to update RFC4422
to support channel bindings.

I expect that the chairs will want to approve of this initial
submission.

Until then you can find the submitted I-D at:

http://www.ietf.org/proceedings/staging/draft-ietf-sasl-channel-bindings-00.txt

Nico
-- 

Date: Thu, 9 Apr 2009 11:25:09 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Subject: Protecting the mech negotiation in GS2
Sender: [email-masked]

I proposed a while back that we could protect the server's mech list in
GS2.  That saves a round-trip for applications that want to protect the
mechanism negotiation.  As such it seems worth doing, and the change for
it is very small:

a) add a flag to the GS2 initial auth message header indicating whether
   the server mech list is being protected, and

b) add the server mech list to the GS2 channel binding data header.

The impact on SASL APIs should be none beyond the impact of channel
binding and the negotiation of channel binding in the first place.

Nico
-- 

Date: Fri, 03 Apr 2009 16:00:39 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

--On Friday, April 03, 2009 02:19:56 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> Except I think that's the wrong way; the server must fail authentication
>> if  it advertised channel bindings and the client reports that it did
>> not see  such an advertisement.
>
> It's worse than that -- GS2 always uses GSS channel bindings, so that
> semantic from MIT krb5 wouldn't help anyways.

I think you misinterpreted.  Let me try again.

If the server advertised support for -PLUS, indicating that it could do CB, 
but the client reports that it saw no such advertisement, then that 
indicates an attacker modified the advertisement en route, and the server 
MUST fail authentication at the SASL layer.  This happens without ever 
calling GSS.

-- Jeff

Date: Fri, 3 Apr 2009 14:19:56 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 02:19:49PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 12:28:58 PM -0500 Nicolas Williams 
> >I wasn't proposing that.  Instead I was proposing that in the case where
> >the client did not negotiate mechanisms but used channel binding and the
> >server couldn't, then the server could ignore those channel bindings IFF
> >the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
> >mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
> >ignore the client's channel bindings, just like the MIT krb5 mech
> >implementation used to, but GS2 would protect against downgrade by
> >protecting the SASL mechname used by the client and failing
> >authentication if the client used the -PLUS name and the server had no
> >channel bindings.)
> 
> Except I think that's the wrong way; the server must fail authentication if 
> it advertised channel bindings and the client reports that it did not see 
> such an advertisement.

It's worse than that -- GS2 always uses GSS channel bindings, so that
semantic from MIT krb5 wouldn't help anyways.

> The only possible reason to do what you describe is to allow a server to 
> advertise -plus, but defer the determination as to whether it supports CB 
> until after the client sends them.  That's fine, but not if the decision is 
> made based on the type of CB the client sent, which is what you'd need for 
> negotiation but breaks the protocol.

Right, forget all about this.

Nico
-- 

Date: Fri, 03 Apr 2009 14:19:49 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

--On Friday, April 03, 2009 12:28:58 PM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Fri, Apr 03, 2009 at 01:26:50PM -0400, Jeffrey Hutzelman wrote:
>> --On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams
>> > On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
>> >> We had an agreement before San Franscisco as to how CB negotation
>> >> should work.  I carefuly analyzed that approach to be sure that it
>> >> works correctly, allows CB to be used when possible, allows
>> >> interoperability when CB cannot be used, and prevents downgrade
>> >> attacks.
>> >>
>> >> I lack the time to think about whether what you just described is
>> >> semantically equivalent to the previous agreement and whether it still
>> >> meets the requirements and remains secure.
>> >>
>> >> Can we _please_ stop changing this?
>> >
>> > In this particular case I think so, because Dave's concern can be
>> > addressed differently by saying "don't do that", where "that" ->
>> > code/configure your server to advertise -PLUS and then not be able to
>> > use the required channel binding type for the given situation.
>>
>> In fact, that is the only thing you can do.
>> You can't give the server license to ignore the client's channel
>> bindings  if they're the wrong type, because that enables a MitM attack
>> where the  attackers channels from the client and to the server are of
>> different types.
>
> I wasn't proposing that.  Instead I was proposing that in the case where
> the client did not negotiate mechanisms but used channel binding and the
> server couldn't, then the server could ignore those channel bindings IFF
> the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
> mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
> ignore the client's channel bindings, just like the MIT krb5 mech
> implementation used to, but GS2 would protect against downgrade by
> protecting the SASL mechname used by the client and failing
> authentication if the client used the -PLUS name and the server had no
> channel bindings.)

Except I think that's the wrong way; the server must fail authentication if 
it advertised channel bindings and the client reports that it did not see 
such an advertisement.

There are only three cases:

- client saw advertisement and uses CB
- client saw advertisement and does not use CB
- client did not see advertisement

In the third case, if the server advertised CB at all it must fail.
In the first case, if the client's CB is the wrong type it must fail.

If the server could not use CB, it should not have advertised -plus.

The only possible reason to do what you describe is to allow a server to 
advertise -plus, but defer the determination as to whether it supports CB 
until after the client sends them.  That's fine, but not if the decision is 
made based on the type of CB the client sent, which is what you'd need for 
negotiation but breaks the protocol.

-- Jeff

Date: Fri, 3 Apr 2009 12:28:58 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 01:26:50PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams 
> >On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
> >>We had an agreement before San Franscisco as to how CB negotation
> >>should work.  I carefuly analyzed that approach to be sure that it
> >>works correctly, allows CB to be used when possible, allows
> >>interoperability when CB cannot be used, and prevents downgrade
> >>attacks.
> >>
> >>I lack the time to think about whether what you just described is
> >>semantically equivalent to the previous agreement and whether it still
> >>meets the requirements and remains secure.
> >>
> >>Can we _please_ stop changing this?
> >
> >In this particular case I think so, because Dave's concern can be
> >addressed differently by saying "don't do that", where "that" ->
> >code/configure your server to advertise -PLUS and then not be able to
> >use the required channel binding type for the given situation.
> 
> In fact, that is the only thing you can do.
> You can't give the server license to ignore the client's channel bindings 
> if they're the wrong type, because that enables a MitM attack where the 
> attackers channels from the client and to the server are of different types.

I wasn't proposing that.  Instead I was proposing that in the case where
the client did not negotiate mechanisms but used channel binding and the
server couldn't, then the server could ignore those channel bindings IFF
the client used a non-PLUS mechanism name.  (In GSS terms the SCRAM GSS
mech's GSS_Accept_sec_context() with GSS_C_NO_CHANNEL_BINDINGS would
ignore the client's channel bindings, just like the MIT krb5 mech
implementation used to, but GS2 would protect against downgrade by
protecting the SASL mechname used by the client and failing
authentication if the client used the -PLUS name and the server had no
channel bindings.)

Date: Fri, 03 Apr 2009 13:26:50 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

--On Friday, April 03, 2009 11:58:20 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
>> We had an agreement before San Franscisco as to how CB negotation
>> should work.  I carefuly analyzed that approach to be sure that it
>> works correctly, allows CB to be used when possible, allows
>> interoperability when CB cannot be used, and prevents downgrade
>> attacks.
>>
>> I lack the time to think about whether what you just described is
>> semantically equivalent to the previous agreement and whether it still
>> meets the requirements and remains secure.
>>
>> Can we _please_ stop changing this?
>
> In this particular case I think so, because Dave's concern can be
> addressed differently by saying "don't do that", where "that" ->
> code/configure your server to advertise -PLUS and then not be able to
> use the required channel binding type for the given situation.

In fact, that is the only thing you can do.
You can't give the server license to ignore the client's channel bindings 
if they're the wrong type, because that enables a MitM attack where the 
attackers channels from the client and to the server are of different types.

-- Jeff

Date: Fri, 3 Apr 2009 11:58:20 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 12:08:34PM -0400, Jeffrey Hutzelman wrote:
> We had an agreement before San Franscisco as to how CB negotation
> should work.  I carefuly analyzed that approach to be sure that it
> works correctly, allows CB to be used when possible, allows
> interoperability when CB cannot be used, and prevents downgrade
> attacks.
> 
> I lack the time to think about whether what you just described is
> semantically equivalent to the previous agreement and whether it still
> meets the requirements and remains secure.
> 
> Can we _please_ stop changing this?

In this particular case I think so, because Dave's concern can be
addressed differently by saying "don't do that", where "that" ->
code/configure your server to advertise -PLUS and then not be able to
use the required channel binding type for the given situation.

Nico
-- 

Date: Fri, 3 Apr 2009 11:55:06 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 12:05:29PM -0400, Jeffrey Hutzelman wrote:
> --On Friday, April 03, 2009 12:21:56 PM +0200 Simon Josefsson 
> <[email-masked]> wrote:
> 
> >>The idea is that when the TLS channel used server certs then the client
> >>MUST use tls-server-end-point bindings.  Otherwise it MUST use
> >>tls-unique bindings.
> >
> >Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.
> 
> It doesn't belong in either.

I agree.  We need to update RFC4422 to specify the channel binding
semantics of SASL, the -PLUS thing, and the rules for selecting TLS
channel binding types.

(I also knew we'd have to do that eventually, but wanted to wait until
the dust settled on SCRAM/GS2 -- which has happened, pretty much -- to
bring that up.  It was important to settle these matters in the context
of SCRAM/GS2 _first_, but it is also important to document these in the
context of an update to SASL.)

Nico
-- 

Date: Fri, 3 Apr 2009 11:44:11 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Mark Novak <[email-masked]>, [email-masked], Stefan Santesson <[email-masked]>, Larry Zhu <[email-masked]>, [email-masked], Paul Leach <[email-masked]>, Kevin Damour <[email-masked]>, Jeffrey Altman <[email-masked]>, Sam Hartman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 05:31:41PM +0100, Dave Cridland wrote:
> On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> >  I
> >don't know though.  Can you comment on Pasi's comments?  Are there  
> >any
> >commonly used TLS implementations that encode the server cert
> >differently on the wire than in their APIs for getting at the server
> >cert?
> 
> I have no idea at all, I'm sorry to say. It makes sense to me that  
> X.509 certs, at least, would always be encoded in DER, since that's  
> the form in which they're signed.

Between this and my other comment I'm willing to close this as a
non-issue.

> That then reduces the problem of the existing channel binding to  
> being figuring out which hash to use, and I strongly suspect that  
> just using SHA-256 is sufficient for now. (it's unfortunate this is  
> different to the hash algorithm we seem to have settled on for SCRAM,  
> but it's far from a blocker, merely a mild inconvenience).

Right, we chose SHA-256 for tls-server-end-point because it should
future proof us for long enough that people will be able to implement a
cert->hash API as described in tls-server-end-point.  I think that's
fine.  We couldn't use SHA-1 because we're not using HMAC here, so
there's no mitigation against SHA-1 breaks.  SHA-256 implementations,
including open source ones in various licenses, exist.  So I'm going to
consider this a non-issue also.

Nico
-- 

Subject: Re: TLS endpoint channel bindings in SCRAM
Date: Fri, 03 Apr 2009 17:31:41 +0100
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, Mark Novak <[email-masked]>, Larry Zhu <[email-masked]>, Sam Hartman <[email-masked]>, Leif Johansson <[email-masked]>, Paul Leach <[email-masked]>, Jeffrey Altman <[email-masked]>, Kevin Damour <[email-masked]>, Stefan Santesson <[email-masked]>
Sender: [email-masked]

On Fri Apr  3 16:25:36 2009, Nicolas Williams wrote:
> Pasi's comment indicates that your premise for this thread is wrong.

I certainly hope so. Nothing would please me more than being wrong  
here.

>   I
> don't know though.  Can you comment on Pasi's comments?  Are there  
> any
> commonly used TLS implementations that encode the server cert
> differently on the wire than in their APIs for getting at the server
> cert?

I have no idea at all, I'm sorry to say. It makes sense to me that  
X.509 certs, at least, would always be encoded in DER, since that's  
the form in which they're signed.

That then reduces the problem of the existing channel binding to  
being figuring out which hash to use, and I strongly suspect that  
just using SHA-256 is sufficient for now. (it's unfortunate this is  
different to the hash algorithm we seem to have settled on for SCRAM,  
but it's far from a blocker, merely a mild inconvenience).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Fri, 03 Apr 2009 12:08:34 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>, Dave Cridland <[email-masked]>
cc: Simon Josefsson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

--On Friday, April 03, 2009 10:10:25 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>
> On Fri, Apr 03, 2009 at 10:01:58AM -0500, Nicolas Williams wrote:
>> IF we're going to allow the server/acceptor-may-ignore-client-channel-
>> bindings-by-providing-none semantic then we must provide some indication
>> that this happened in the server's last message.  But because we need
>> this to be communicated to the client at the GS2 layer too, and securely
>> so, we'd be complicating GS2 significantly -- I don't think we want
>> that.
>
> Actually, there's a simple way to make that possible: put the mechanism
> name in the GS2 channel binding data header.  If the name ends in -PLUS
> then the server can't ignore the channel bindings because it must have
> advertised that it supports them.  Whereas if the name does not end in
> -PLUS then the server is free to ignore the client's channel bindings.
>
> Comments?

We had an agreement before San Franscisco as to how CB negotation should 
work.  I carefuly analyzed that approach to be sure that it works 
correctly, allows CB to be used when possible, allows interoperability when 
CB cannot be used, and prevents downgrade attacks.

I lack the time to think about whether what you just described is 
semantically equivalent to the previous agreement and whether it still 
meets the requirements and remains secure.

Can we _please_ stop changing this?

-- Jeff

Date: Fri, 03 Apr 2009 12:05:29 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Simon Josefsson <[email-masked]>, Nicolas Williams <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

--On Friday, April 03, 2009 12:21:56 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

>> The idea is that when the TLS channel used server certs then the client
>> MUST use tls-server-end-point bindings.  Otherwise it MUST use
>> tls-unique bindings.
>
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

It doesn't belong in either.
SCRAM and GS2 are SASL mechanisms; they operate below the SASL abstraction. 
Their job is to convey and verify the channel bindings provided by the 
application protocol.  They don't get to specify what channel bindings are 
used.  This is very important.

Whether to use channel bindings and which bindings to use is determined by 
the protocol operating above the SASL abstraction.  We can perhaps develop 
guidelines for how such protocols should behave, but they don't belong in a 
mechanism document.

Remember, the point of the abstraction is that individual users of SASL do 
not need to know about or understand individual mechanisms.  This breaks if 
there is any mechanism that attempts to apply mechanism-specific 
requirements to the protocol operating above the abstraction.

-- Jeff

Date: Fri, 3 Apr 2009 10:25:36 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], [email-masked], Mark Novak <[email-masked]>, Larry Zhu <[email-masked]>, Sam Hartman <[email-masked]>, Leif Johansson <[email-masked]>, Paul Leach <[email-masked]>, Jeffrey Altman <[email-masked]>, Kevin Damour <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

Dave Cridland wrote:
> > - By hard-coding a hash function we'd lose hash agility.  Hash  
> >agility is one of the features of the registered tls-server-end-point
> >channel binding type.  OTOH, as you note, for SCRAM this is solved by
> >the existing SCRAM hash agility approach (add a new mech).
> >
> Yes - it's not ideal, but I'm hoping that by the time hash agility  
> becomes an issue, then we'll have support for the more generic form  
> of the channel binding.

The lack of negotiability of which channel binding type to use makes
this not a good answer (but see below).

> > - We can't really negotiate which type of channel binding to use.   
> >It's relatively easy to choose between unique and server-end-point,
> >but to choose between two types of server-end-point bindings is much
> >harder (unless it's a choice made at specification time, in this case
> >for SASL/SCRAM).
> >
> But clients must stipulate which they have used.

That doesn't mean it's negotiable.  GSS-API semantics do not allow the
acceptor to find out what channel binding type the client used.

We could put the channel binding type in the GS2 header -- that would
solve that problem.  But still, the server now has to support multiple
channel binding types and now we need a way to advertise that to the
client -- otherwise the client and server could disagree and fail to
authenticate.

> >   Neither modifying tls-server-end-point nor introducing a  
> >different variant of it seem particularly appealing.  The former may
> >well  be out of the barn's doors, which would leave us only with the
> >latter choice (or fix the TLS frameworks :)
> 
> I think tls-server-end-point is a fine binding.
> 
> My problem is that it'll be years before it's available on many  
> platforms, and I think we can provide more immediately implementable  
> security than that.

Pasi's comment indicates that your premise for this thread is wrong.  I
don't know though.  Can you comment on Pasi's comments?  Are there any
commonly used TLS implementations that encode the server cert
differently on the wire than in their APIs for getting at the server
cert?  I seriously doubt that on the _client_ side, but also, I doubt it
on the server side.  Why would anyone want to write code to re-encode
certs on the fly when that can be done once at configuration time, or
never at all if the CA just does the right thing and issues a DER
certificate.

Also, even if there were implementations that re-encode non-DER certs
into DER for that API, surely, surely one could re-encode the cert at
configuration time so that it's in DER to begin with as far as the TLS
implementation goes -- then there's no need to re-encode as re-encoding
would be the identity function.

Nico
-- 

Date: Fri, 3 Apr 2009 10:15:48 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 12:03:33PM +0100, Dave Cridland wrote:
> On Thu Apr  2 17:21:23 2009, Nicolas Williams wrote:
> >Jeff Hutzelman points out that we can't introduce multiple variants  
> >of
> >tls-server-endpoint on a per-mechanism basis.  We can do that for  
> >SASL
> >apps generally, say, but not just for SCRAM.
> >
> >
> Right, I agree. Luckily, we can mandate server-side support for  
> additional channel bindings across the board.

Yes, but I don't think we should.  Pasi points out that TLS
implementations generally put the DER encoded cert on the wire.  So I
think the premise of your request for a variant of tls-server-end-point
is in question...  Can you comment on Pasi's comment?

> > Implementations of TLS that don't provide application access to the
> >server cert as it appears on the wire in TLS should just be  
> >extended.
> 
> Will sir be needing to borrow a forklift to help with his upgrade?

If Pasi is right, then no, I won't be :)

Nico
-- 

Date: Fri, 3 Apr 2009 10:10:25 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 10:01:58AM -0500, Nicolas Williams wrote:
> IF we're going to allow the server/acceptor-may-ignore-client-channel-
> bindings-by-providing-none semantic then we must provide some indication
> that this happened in the server's last message.  But because we need
> this to be communicated to the client at the GS2 layer too, and securely
> so, we'd be complicating GS2 significantly -- I don't think we want
> that.

Actually, there's a simple way to make that possible: put the mechanism
name in the GS2 channel binding data header.  If the name ends in -PLUS
then the server can't ignore the channel bindings because it must have
advertised that it supports them.  Whereas if the name does not end in
-PLUS then the server is free to ignore the client's channel bindings.

Comments?

Nico
-- 

Date: Fri, 3 Apr 2009 10:01:58 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 12:03:46PM +0100, Dave Cridland wrote:
> Then the client provides a tls-server-end-point (or not, because it  
> can't, see previous mails) and the server just ignores it, being  
> unable to verify it, or else rejects the authentication. This would  

The GSS-API does allow the acceptor to ignore channel bindings by not
providing any.  Well, actually, the GSS-API specs are a bit fuzzy on
this point, but for years the MIT krb5 implementation of the krb5 mech
actually worked that way, so there's precedent...  But one could have
mechanisms that don't allow the acceptor to ignore the channel binding
(imagine mixing the channel binding into a key derivation step).

IF we're going to allow the server/acceptor-may-ignore-client-channel-
bindings-by-providing-none semantic then we must provide some indication
that this happened in the server's last message.  But because we need
this to be communicated to the client at the GS2 layer too, and securely
so, we'd be complicating GS2 significantly -- I don't think we want
that.

> only happen when the server is not behind a concentrator, but can  
> only do tls-unique due to TLS API limitations, though - if the server  
> is behind a concentrator and hasn't been configured with its own TLS  
> identity, then one assumes it'd not offer -PLUS.

Correct -- the server must know if it is behind a concentrator, and it
must know its server cert.  Virtualization -> more communication between
the concentrator and the server than just manual configuration.

> Equally interesting is if the server can only do  
> tls-server-end-point, due to being behind a concentrator, but the  
> client can only do tls-unique because it doesn't have a TLS stack  
> which'll provide it with the relevant data.

In that case the client either must force the use of anon-anon TLS
cipher suites or it must not use channel binding.

> One assumes the client should just use tls-unique, and the server  
> will, again, ignore it or reject it.

No.  That wouldn't work: the client and the server would both use
different channel bindings and authentication must then fail.  (This
case is distinguished from the case where the server doesn't know the
channel binding and so ignores it.)

Nico
-- 

Date: Fri, 3 Apr 2009 09:47:52 -0500
From: Nicolas Williams <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 02:33:47PM +0200, [email-masked] wrote:
> Nicolas Williams wrote:
> 
> > Questions:
> > 
> > 1) Do many/most/all TLS implementations output the DER-encoded form of
> >    the server cert?  Which ones do/don't?
> > 
> > 2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
> >    hard would it be to change this?  (e.g., re-encode the cert and
> >    restart apps?)
> 
> Although the TLS spec doesn't explicitly say this, the on-the-wire
> certificate is DER encoded. There's no field specifying what the
> encoding is, so if you attempt sending PER or XER, it simply won't
> work.

Right, I doubt anyone re-encodes certs in PER or XER :)

It's BER that one should worry about.

> Some implementations might accept some limited subset of BER (to
> work around CA bugs), but even in those cases, nobody's going to
> re-encode it to DER (most likely the CA calculated the signature over
> BER encoded version -- violating all possible standards -- and the
> API would return the octets sent on the wire).

OK, thanks.

> So I don't see any problem in using the tls-server-end-point channel
> binding...

Excellent.  Thanks!

>            (and it seems it would work for OpenPGP, too)

It could be made to, but tls-server-end-point refers to the first cert
in the 'certificate_list' field of the server's Certificate message --
there's no such field in the OpenPGP case.  It'd be a trivial updat to
tls-server-end-point to allow the use of a server's OpenPGP cert though.

Nico
-- 

Date: Fri, 3 Apr 2009 09:52:12 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 12:21:56PM +0200, Simon Josefsson wrote:
> > The idea is that when the TLS channel used server certs then the client
> > MUST use tls-server-end-point bindings.  Otherwise it MUST use
> > tls-unique bindings.
> 
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

Ah, it's in SCRAM -- I need to copy that text to GS2.

> > The reason is this: tls-server-end-point bindings can work with existing
> > TLS concentrators (and with implementations that separate TLS in an
> > stunnel-like fashion), therefore it's preferable, BUT, because
> > tls-server-end-point isn't always available but tls-unique is, we
> > REQUIRE falling back on tls-unique when tls-server-end-point is not
> > available.
> 
> How is that negotiated?  Couldn't it be that the client has access to
> tls-server-end-point but not the server, or vice versa?

That would what you call a bug or configuration error.

If a server cert was used then the server should know.  If there's a TLS
concentrator then the server needs to know that and what cert was used,
which creates a bit of a problem in the virtualization case: the server
needs to know which cert was used, but this can be solved and it's a
much smaller problem, I think, than modifying concentrators to provide
tls-unique bindings to servers.

Nico
-- 

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 3 Apr 2009 14:33:47 +0200
Subject: RE: TLS endpoint channel bindings in SCRAM
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Nicolas Williams wrote:

> Questions:
>=20
> 1) Do many/most/all TLS implementations output the DER-encoded form of
>    the server cert?  Which ones do/don't?
>=20
> 2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
>    hard would it be to change this?  (e.g., re-encode the cert and
>    restart apps?)

Although the TLS spec doesn't explicitly say this, the on-the-wire
certificate is DER encoded. There's no field specifying what the
encoding is, so if you attempt sending PER or XER, it simply won't
work.

Some implementations might accept some limited subset of BER (to
work around CA bugs), but even in those cases, nobody's going to
re-encode it to DER (most likely the CA calculated the signature over
BER encoded version -- violating all possible standards -- and the
API would return the octets sent on the wire).

So I don't see any problem in using the tls-server-end-point channel
binding... (and it seems it would work for OpenPGP, too)

Best regards,
Pasi=

Subject: Re: TLS endpoint channel bindings in SCRAM
Date: Fri, 03 Apr 2009 12:03:46 +0100
From: Dave Cridland <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: <[email-masked]>, Nicolas Williams <[email-masked]>
Sender: [email-masked]

On Fri Apr  3 11:21:56 2009, Simon Josefsson wrote:
> Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like  
> that.

It's in the latest SCRAM.

> How is that negotiated?  Couldn't it be that the client has access  
> to
> tls-server-end-point but not the server, or vice versa?

Then the client provides a tls-server-end-point (or not, because it  
can't, see previous mails) and the server just ignores it, being  
unable to verify it, or else rejects the authentication. This would  
only happen when the server is not behind a concentrator, but can  
only do tls-unique due to TLS API limitations, though - if the server  
is behind a concentrator and hasn't been configured with its own TLS  
identity, then one assumes it'd not offer -PLUS.

Equally interesting is if the server can only do  
tls-server-end-point, due to being behind a concentrator, but the  
client can only do tls-unique because it doesn't have a TLS stack  
which'll provide it with the relevant data.

One assumes the client should just use tls-unique, and the server  
will, again, ignore it or reject it.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Subject: Re: TLS endpoint channel bindings in SCRAM
Date: Fri, 03 Apr 2009 12:03:33 +0100
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Thu Apr  2 17:21:23 2009, Nicolas Williams wrote:
> Jeff Hutzelman points out that we can't introduce multiple variants  
> of
> tls-server-endpoint on a per-mechanism basis.  We can do that for  
> SASL
> apps generally, say, but not just for SCRAM.
> 
> 
Right, I agree. Luckily, we can mandate server-side support for  
additional channel bindings across the board.

> Simon points out that TLS supports non-PKIX certificates.
> 
> 
Absolutely. However, I'd also state that the prevelant use of TLS is  
with X.509 certificates, and whilst I'm not arguing that this should  
be mandated, I do think we ought to take this into account, and  
indeed take advantage of it to promote deployment of channel binding.

> I agree with these points.

As do I.

>   Therefore I have to say that it's best to
> stick with tls-server-endpoint and not define any new ones, nor to  
> seek
> any changes to tls-server-endpoint.
> 
> 
I fail to see where you get this conclusion from.

>  Implementations of TLS that don't provide application access to the
> server cert as it appears on the wire in TLS should just be  
> extended.

Will sir be needing to borrow a forklift to help with his upgrade?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 03 Apr 2009 12:21:56 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Fri, Apr 03, 2009 at 02:40:30AM +0200, Simon Josefsson wrote:
>> > On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
>> >> Simon points out that TLS supports non-PKIX certificates.
>> >
>> > Actually, that's true, but the way RFC5081 adds support for OpenPGP
>> > certs happens to not work with tls-server-end-point bindings because
>> > there's no certificate_list field in the Certificate message when
>> > OpenPGP certs are negotiated.  It would not be difficult to change
>> > tls-server-end-point to cover the use of OpenPGP certs.
>> 
>> Does that mean SCRAM will require server certs?  I think that is
>> unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
>> tls-unique be supported?
>
> No, no.
>
> The idea is that when the TLS channel used server certs then the client
> MUST use tls-server-end-point bindings.  Otherwise it MUST use
> tls-unique bindings.

Got it.  Is this in SCRAM or GS2 now?  I don't recall texts like that.

> The reason is this: tls-server-end-point bindings can work with existing
> TLS concentrators (and with implementations that separate TLS in an
> stunnel-like fashion), therefore it's preferable, BUT, because
> tls-server-end-point isn't always available but tls-unique is, we
> REQUIRE falling back on tls-unique when tls-server-end-point is not
> available.

How is that negotiated?  Couldn't it be that the client has access to
tls-server-end-point but not the server, or vice versa?

/Simon

Date: Thu, 2 Apr 2009 23:58:42 -0500
From: Nicolas Williams <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Fri, Apr 03, 2009 at 02:40:30AM +0200, Simon Josefsson wrote:
> > On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
> >> Simon points out that TLS supports non-PKIX certificates.
> >
> > Actually, that's true, but the way RFC5081 adds support for OpenPGP
> > certs happens to not work with tls-server-end-point bindings because
> > there's no certificate_list field in the Certificate message when
> > OpenPGP certs are negotiated.  It would not be difficult to change
> > tls-server-end-point to cover the use of OpenPGP certs.
> 
> Does that mean SCRAM will require server certs?  I think that is
> unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
> tls-unique be supported?

No, no.

The idea is that when the TLS channel used server certs then the client
MUST use tls-server-end-point bindings.  Otherwise it MUST use
tls-unique bindings.

The reason is this: tls-server-end-point bindings can work with existing
TLS concentrators (and with implementations that separate TLS in an
stunnel-like fashion), therefore it's preferable, BUT, because
tls-server-end-point isn't always available but tls-unique is, we
REQUIRE falling back on tls-unique when tls-server-end-point is not
available.

> > Aside: if I read RFC5081 correctly it seems that you can't negotiate the
> > use of OpenPGP certs for user certs but not for server certs, and vice
> > versa.  Odd!
> 
> That is right.  It also does not permit negotiating X.509 on one side
> and OpenPGP on the other.  There is a -bis effort in progress, but I
> don't think it addresses these concerns.

Well, it should.  I think it makes sense to use PKIX for the server cert
and OpenPGP for the user cert.  I'm not sure that I care enough to go
comment on this.

Nico
-- 

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 03 Apr 2009 02:40:30 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

> On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
>> Simon points out that TLS supports non-PKIX certificates.
>
> Actually, that's true, but the way RFC5081 adds support for OpenPGP
> certs happens to not work with tls-server-end-point bindings because
> there's no certificate_list field in the Certificate message when
> OpenPGP certs are negotiated.  It would not be difficult to change
> tls-server-end-point to cover the use of OpenPGP certs.

Does that mean SCRAM will require server certs?  I think that is
unfortunate -- why can't SCRAM over TLS-anon or TLS-PSK or TLS-SRP with
tls-unique be supported?

> Aside: if I read RFC5081 correctly it seems that you can't negotiate the
> use of OpenPGP certs for user certs but not for server certs, and vice
> versa.  Odd!

That is right.  It also does not permit negotiating X.509 on one side
and OpenPGP on the other.  There is a -bis effort in progress, but I
don't think it addresses these concerns.

/Simon

Date: Thu, 2 Apr 2009 16:40:44 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Thu, Apr 02, 2009 at 11:21:23AM -0500, Nicolas Williams wrote:
> Simon points out that TLS supports non-PKIX certificates.

Actually, that's true, but the way RFC5081 adds support for OpenPGP
certs happens to not work with tls-server-end-point bindings because
there's no certificate_list field in the Certificate message when
OpenPGP certs are negotiated.  It would not be difficult to change
tls-server-end-point to cover the use of OpenPGP certs.

Aside: if I read RFC5081 correctly it seems that you can't negotiate the
use of OpenPGP certs for user certs but not for server certs, and vice
versa.  Odd!

Date: Thu, 2 Apr 2009 11:21:23 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked]
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

Jeff Hutzelman points out that we can't introduce multiple variants of
tls-server-endpoint on a per-mechanism basis.  We can do that for SASL
apps generally, say, but not just for SCRAM.

Simon points out that TLS supports non-PKIX certificates.

I agree with these points.  Therefore I have to say that it's best to
stick with tls-server-endpoint and not define any new ones, nor to seek
any changes to tls-server-endpoint.

Implementations of TLS that don't provide application access to the
server cert as it appears on the wire in TLS should just be extended.

Nico
-- 

Date: Thu, 02 Apr 2009 12:33:06 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Nicolas Williams <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>, [email-masked]
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

--On Thursday, April 02, 2009 11:09:25 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

> Chris believes that mechanism names will leak into configuration UIs,

...

> Chris proposed that we just call it "SCRAM1" -- we don't need the
> algorithm names in the mechanism name.  I agree with that.

These positions seem to be inconsistent.  If the mechanism names are going 
to leak into the UI, then I think we owe it to users to use a name that is 
actually descriptive of the mechanism.  I'd much rather have "SCRAM-SHA-1" 
and "SCRAM-SHA-256" and "SCRAM-SHA-3" than "SCRAM1", "SCRAM2", and 
"SCRAM3"; the latter are fairly useless.

I can accept the argument that the -PLUS needs to be meaningful to humans, 
though I suspect the right answer here is that those mechanisms should be 
hidden in configuration UI's -- the UI should treat SCRAM and SCRAM-PLUS as 
if they were the same mechanism, and choose between them appropriately. 
But if we use an affix like -PLUS, we're effectively limiting GSS-API 
mechanisms (and potentially, any mechanism with autonegotiated optional CB 
support) to a 15-character base name.  The GS2 spec should make this clear.

> see the latest GS2 I-D)

I tried, but I couldn't figure out which one it is. :-(

Date: Thu, 2 Apr 2009 11:02:48 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Jeffrey Hutzelman <[email-masked]>, Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

On Thu, Apr 02, 2009 at 10:58:47AM +0100, Dave Cridland wrote:
> 
> On Thu Apr  2 04:52:02 2009, Jeffrey Hutzelman wrote:
> >Finally...  What in the world were jgm et al thinking, limiting  
> >mechanism names to 20 characters and a relatively small symbol set?  
> > Now there are only 3.12E+39 possible SASL mechanism names; what  
> >ever will we do?
> 
> There's also the pressing problem of internationalized SASL mechanism  
> names.
> 
> Oh, wait, what day is it?

A day too late :)

Date: Thu, 2 Apr 2009 11:09:25 -0500
From: Nicolas Williams <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

On Wed, Apr 01, 2009 at 11:52:02PM -0400, Jeffrey Hutzelman wrote:
> For starters, I think we should not algorithmically modify mechanism names; 
> instead, any GSS-API mechanism (including SCRAM) that wishes to define 
> friendly SASL mechanism names should define two such names, for the "PLUS" 
> and "non-PLUS" cases.  This makes it easier to express the requirement that 
> these names be registered in the SASL mechanism name registry and not 
> conflict with the names of any existing (or future) SASL mechanisms.

OTOH, having a common affix for "server supports channel binding" makes
it easier to implement a common mechanism selection function in a
client-side SASL framework.

Yes, it wouldn't be hard for such a framework to ask each mechanism
plugin what names it has and which indicate "server supports channel
binding"...

> Secondly, I'd propose including the "plus" bit before the algorithm:
> 
> GS2B-oidoidoidoidoid (basic)
> GS2P-oidoidoidoidoid (plus)
> 
> SCRAM_B-HMAC-SHA-1   (basic)
> SCRAM_P-HMAC-SHA-1   (plus)
> SCRAM_P-HMAC-SHA-256 (plus)

Chris believes that mechanism names will leak into configuration UIs,
and that therefore it's important that the -PLUS affix be meaningful to
humans.  I think we can leave the affix as an implementation detail
(e.g., the user configured "SCRAM" but the client and server will
understand that SCRAM-PLUS is also allowed unless the user specifically
disallowed channel binding).

> Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
> removing or abbreviating the "HMAC" component, which is mostly redundant.

Chris proposed that we just call it "SCRAM1" -- we don't need the
algorithm names in the mechanism name.  I agree with that.  That way the
-PLUS suffix becomes a non-issue for SCRAM (it's already a non-issue for
GS2 -- see the latest GS2 I-D).

Nico
-- 

Subject: Re: TLS endpoint channel bindings in SCRAM
Date: Thu, 02 Apr 2009 12:32:21 +0100
From: Dave Cridland <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, Mark Novak <[email-masked]>, Larry Zhu <[email-masked]>, Sam Hartman <[email-masked]>, Leif Johansson <[email-masked]>, Paul Leach <[email-masked]>, Jeffrey Altman <[email-masked]>, Kevin Damour <[email-masked]>, Stefan Santesson <[email-masked]>
Sender: [email-masked]

On Wed Apr  1 23:52:20 2009, Nicolas Williams wrote:
> 1) Do many/most/all TLS implementations output the DER-encoded form  
> of
>    the server cert?  Which ones do/don't?
> 
> 
Somewhere between many and most. I suspect all the low-level TLS  
stacks (OpenSSL etc) will do. It's the bindings and suchlike I'm more  
concerned with.

In the bindings, however, it's pretty trivial to find a function  
which either hands back the DER form, or else hands back PEM (base64  
of DER), which developers can also use.

> 2) Is the cert used on the wire generally NOT DER-encoded?  If so,  
> how
>    hard would it be to change this?  (e.g., re-encode the cert and
>    restart apps?)
> 
> 
I have absolutely no idea. If I could rely on the cert being DER on  
the wire, we could reduce this to implementation notes, aside from  
the hash issue. I have no idea how to extract that hash algorithm,  
currently, but I could probably figure that out eventually.

If it turns out that tls-server-endpoint *can* be readily implemented  
at least for the common case of X.509 certificates, then I'd be very  
much happier with this outcome.

>  - By hard-coding a hash function we'd lose hash agility.  Hash  
> agility
>    is one of the features of the registered tls-server-end-point  
> channel
>    binding type.  OTOH, as you note, for SCRAM this is solved by the
>    existing SCRAM hash agility approach (add a new mech).
> 
> 
Yes - it's not ideal, but I'm hoping that by the time hash agility  
becomes an issue, then we'll have support for the more generic form  
of the channel binding.

>  - We can't really negotiate which type of channel binding to use.   
> It's
>    relatively easy to choose between unique and server-end-point,  
> but to
>    choose between two types of server-end-point bindings is much  
> harder
>    (unless it's a choice made at specification time, in this case  
> for
>    SASL/SCRAM).
> 
> 
But clients must stipulate which they have used.

>    Neither modifying tls-server-end-point nor introducing a  
> different
>    variant of it seem particularly appealing.  The former may well  
> be
>    out of the barn's doors, which would leave us only with the  
> latter
>    choice (or fix the TLS frameworks :)

I think tls-server-end-point is a fine binding.

My problem is that it'll be years before it's available on many  
platforms, and I think we can provide more immediately implementable  
security than that.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Date: Thu, 02 Apr 2009 10:58:47 +0100
From: Dave Cridland <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
Sender: [email-masked]

On Thu Apr  2 04:52:02 2009, Jeffrey Hutzelman wrote:
> Finally...  What in the world were jgm et al thinking, limiting  
> mechanism names to 20 characters and a relatively small symbol set?  
>  Now there are only 3.12E+39 possible SASL mechanism names; what  
> ever will we do?

There's also the pressing problem of internationalized SASL mechanism  
names.

Oh, wait, what day is it?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From: Simon Josefsson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Mark Novak <[email-masked]>, [email-masked], Stefan Santesson <[email-masked]>, Larry Zhu <[email-masked]>, [email-masked], Paul Leach <[email-masked]>, Kevin Damour <[email-masked]>, Jeffrey Altman <[email-masked]>, Sam Hartman <[email-masked]>
Subject: Re: [CHANNEL-BINDING] TLS endpoint channel bindings in SCRAM
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 02 Apr 2009 10:27:18 +0200
Sender: [email-masked]

Nicolas Williams <[email-masked]> writes:

>> Finally, I'd propose that SCRAM mandates support for the  
>> 'tls-x509-end-point' channel binding for the applicable cases as a  
>> reasonable fallback when support for the more flexible and  
>> future-proof tls-server-end-point binding is not available.
>> 
>> Now I'll wait to get shot down in flames. :-)
>
> No flames.  I think we could do a channel binding type just for SCRAM
> (we did one just for TELNET, after all).  But I think I'd want "DER" in
> the name, that and the hash function name too.

I don't think that will work -- TLS isn't just X.509.  TLS supports
OpenPGP server certs.  Generally, TLS can support other forms of server
authentication too.

I don't want to see SCRAM require use of X.509 server certificates if we
can avoid it.

It seems simple to avoid that here: just request the necessary features
from TLS stacks.  If we don't do that now, we likely won't do it next
time we need a channel binding for some application protocol, and then
TLS interfaces will never have this feature.  Nico volunteered to help
with this for OpenSSL, and I can volunteer to do it for GnuTLS.  We knew
from the start that channel bindings would require changes to TLS
stacks.  The major native C libraries have already been adapted, I
believe, so what remains are any language bindings.  That seems like
Just A Simple Matter Of Programming.

The alternative is to make channel binding type negotiable, something I
recall discussing at lengths earlier.  Nothing came out of that, so RFC
5056 does not support any negotiation.  I'm not sure how well it would
work to add that feature for SCRAM?  But it could be explored.

/Simon

Date: Wed, 01 Apr 2009 23:52:02 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, SASL WG <[email-masked]>
cc: [email-masked]
Subject: Re: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

--On Friday, March 27, 2009 09:02:13 PM -0700 Alexey Melnikov 
<[email-masked]> wrote:

>
> If I can still count, it is 21 US-ASCII character long. But SASL allows
> at most 20 (as per RFC 4422).

Hrm.  Well, we can't s/-PLUS/+/, as plus is not allowed.

For starters, I think we should not algorithmically modify mechanism names; 
instead, any GSS-API mechanism (including SCRAM) that wishes to define 
friendly SASL mechanism names should define two such names, for the "PLUS" 
and "non-PLUS" cases.  This makes it easier to express the requirement that 
these names be registered in the SASL mechanism name registry and not 
conflict with the names of any existing (or future) SASL mechanisms.

Secondly, I'd propose including the "plus" bit before the algorithm:

GS2B-oidoidoidoidoid (basic)
GS2P-oidoidoidoidoid (plus)

SCRAM_B-HMAC-SHA-1   (basic)
SCRAM_P-HMAC-SHA-1   (plus)
SCRAM_P-HMAC-SHA-256 (plus)

Thirdly, if we are in a pinch, we can abbreviate, like s/SHA-1/SHA1/ or 
removing or abbreviating the "HMAC" component, which is mostly redundant.

Finally...  What in the world were jgm et al thinking, limiting mechanism 
names to 20 characters and a relatively small symbol set?  Now there are 
only 3.12E+39 possible SASL mechanism names; what ever will we do?

-- Jeff

Date: Fri, 27 Mar 2009 21:02:13 -0700
From: Alexey Melnikov <[email-masked]>
To: SASL WG <[email-masked]>
Subject: A minor problem with SCRAM-HMAC-SHA-1-PLUS mechanism name
Sender: [email-masked]

If I can still count, it is 21 US-ASCII character long. But SASL allows 
at most 20 (as per RFC 4422).

Date: Fri, 27 Mar 2009 20:58:14 -0700
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= <[email-masked]>, SASL WG <[email-masked]>
Subject: SCRAM todo: deriving client and server key
Sender: [email-masked]

Chris Newman wrote:

> --On February 23, 2009 8:59:44 -0800 Love H=C3=B6rnquist =C3=85strand=20
> <[email-masked]> wrote:
>
>> Right now the client and server key differences is:
>>
>> ClientKey =3D H(SaltedPassword)
>> ServerKey =3D HMAC(SaltedPassword, salt)
>>
>> Why are the derived by two different methods ? (why not XKey =3D
>> HMAC(SaltedKey, "X key")
>
> I just realized I hadn't mentioned publicly that I think this would be=20
> a good change.
>
> Specifically:
>
> ClientKey =3D HMAC(SaltedPassword, "Client Key")
> ServerKey =3D HMAC(SaltedPassword, "Server Key")
>
> I think this actually makes the algorithm description a bit easier to=20
> understand.  What do others think?

Ok, I've updated my copy of the draft to do that.

Date: Fri, 27 Mar 2009 20:31:05 -0700
From: Alexey Melnikov <[email-masked]>
To: Nicolas Williams <[email-masked]>
CC: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: New SCRAM and GS2 I-Ds
Sender: [email-masked]

Nicolas Williams wrote:

>On Tue, Mar 24, 2009 at 06:13:19PM +0000, Dave Cridland wrote:  
>
>>On Mon Mar 23 16:13:30 2009, Nicolas Williams wrote:    
>>
>>>New versions of draft-newman-auth-scram and draft-ietf-sasl-gs2 have
>>>been posted.
>>>      
>>>
>>A couple of nits - the ABNF has:
>>
>>    ;;cbind-type    = value
>>    ;;cbind-input   = gs2-header [ value ":" cbind-data ]
>>    channel-binding = "c=" base64
>>                      ;; base64 encoding of cbind-input
>>
>>I think the "value" should be "cbind-type", and I think cbind-type =  
>>"tls-unique" / value would be better to make it clear what kind of  
>>stuff is expected there.
>>
>
>Ah, yes, this is a typo.  I need to define cbind-data (*OCTET) and fix
>cbind-input:
>
>     ;;cbind-data    = *OCTET
>     ;;cbind-type    = value
>     ;;cbind-input   = gs2-header [ cbind-type ":" cbind-data ]
>  
>
Changed. I've also added comment about "tls-unique".

>>Also, I wouldn't comment these out.
>>
>>    client-final-message-without-proof =
>>                      [channel-binding ","] nonce [","
>>                      extensions]
>>
>>Channel binding (c=) is no longer optional, so this needs updating.
>>    
>>
>
>Good catch, thanks!
>  
>
Fixed.

>>Otherwise, i think I'm up to date with these changes, and it really  
>>didn't take long, so that's great.
>>
>
>Awesome.
>
>Back to your comments in the room, we can compress the CB flag by
>removing one of its possible values since it'd be possible to
>unambiguously know what that case would be.  I used that trick to remove
>the RFC2743 initial context token header compression flag in the case of
>standard GSS mechs (before: "T" or "F"; now: "" or "F").  But I don't
>think it's worth it.
>  
>
I agree.

Date: Wed, 1 Apr 2009 17:52:20 -0500
From: Nicolas Williams <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: [email-masked], [email-masked], Mark Novak <[email-masked]>, Larry Zhu <[email-masked]>, Sam Hartman <[email-masked]>, Leif Johansson <[email-masked]>, Paul Leach <[email-masked]>, Jeffrey Altman <[email-masked]>, Kevin Damour <[email-masked]>, Stefan Santesson <[email-masked]>
Subject: Re: TLS endpoint channel bindings in SCRAM
Sender: [email-masked]

On Tue, Mar 24, 2009 at 10:37:37PM +0000, Dave Cridland wrote:
> Having carefully examined the tls-server-end-point channel binding,  
> I've a bit of a concern.

We should probably be having this discussion on the
[email-masked] list (cc'ed).  Also cc'ed are folks who
participated in the registration of tls-server-end-point.

> One of the sticking points of the tls-unique channel binding is how  
> easy it is to get at the data - OpenSSL provides an API, however it's  
> often not exposed to language bindings such as Python, etc, and other  
> TLS implementations may not provide it at all.

File bugs against them!  If you have a list of such bindings I'll
volunteer to help file and track these bugs.

> I can't find any way of getting at the on-wire representation of the  
> server's certificate, and I can't immediately find a way of  
> discovering which hash algorithm to use, either, in the vast majority  
> of bindings.
> 
> So rather than expect all TLS implementations and bindings to change,  
> I'd like to propose an alternate binding, for use where the server's  
> certificate is an X.509v3 one.
> 
> Specifically, I'd like to use a fixed hash algorithm over the  
> DER-encoded form of the certificate - I'll call this  
> "tls-x509-end-point"

Questions:

1) Do many/most/all TLS implementations output the DER-encoded form of
   the server cert?  Which ones do/don't?

2) Is the cert used on the wire generally NOT DER-encoded?  If so, how
   hard would it be to change this?  (e.g., re-encode the cert and
   restart apps?)

Notes:

 - By hard-coding a hash function we'd lose hash agility.  Hash agility
   is one of the features of the registered tls-server-end-point channel
   binding type.  OTOH, as you note, for SCRAM this is solved by the
   existing SCRAM hash agility approach (add a new mech).

 - We can't really negotiate which type of channel binding to use.  It's
   relatively easy to choose between unique and server-end-point, but to
   choose between two types of server-end-point bindings is much harder
   (unless it's a choice made at specification time, in this case for
   SASL/SCRAM).

   Neither modifying tls-server-end-point nor introducing a different
   variant of it seem particularly appealing.  The former may well be
   out of the barn's doors, which would leave us only with the latter
   choice (or fix the TLS frameworks :)

> The DER form of the certificate is readily available through most  
> bindings, in many cases in a single call, and gives exactly  
> equivalent hash-input as the on-wire format, which is very likely  
> [but not mandated, as far as I can find] to be DER anyway.
> 
> Fixing a hash algorithm simply makes this even easier - the current  
> channel binding uses SHA-256 as a "minimum hash", I'd prefer to use  
> SHA-1, as we're certain to have it for SCRAM.

True.

> Finally, I'd propose that SCRAM mandates support for the  
> 'tls-x509-end-point' channel binding for the applicable cases as a  
> reasonable fallback when support for the more flexible and  
> future-proof tls-server-end-point binding is not available.
> 
> Now I'll wait to get shot down in flames. :-)

No flames.  I think we could do a channel binding type just for SCRAM
(we did one just for TELNET, after all).  But I think I'd want "DER" in
the name, that and the hash function name too.

Comments?

> Dave.
> -- 
> Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Nico
--