Subject: [kitten] Consensus by Apathy: working on channel bindings

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Feb 2013 15:11:40 -0500

The chairs independently came to a similar conclusion to Nico.

There's been a lot of discussion of the channel binding problem nNico
proposed. In particular:

1) the description of channel binding in RFC 2743 is inconsistent with
what a lot of implementations and later specifications describe.

2) There's no way for an acceptor to determine if channel bindings
happened, especially in cases where the acceptor wants to make channel
bindings optional.

Martin has commented that he'd like to see us work on the problem. 

Several people have commented on the two solutions Nico proposed.

No one besides Martin has responded to repeated calls asking whether
this is of interest to the working group, but people continue to engage
in discussions of the appropriate solutions.

The chairs conclude that the active discussion of the solutions is
strong evidence that we want to work on this problem.
So, unless there is a strong objection, kitten will take on the problem.

we don't see sufficient consensus to choose a particular solution at
this time, but we do agree with Nico that discussion seems to be
favoring the conclusion based on creating an empty security context and
a flag setting routine.

we'd appreciate comments on which solution the WG should adopt.  I'd
like to see us make a decision before or during IETF 86.

--Sam

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 25 Feb 2013 21:05:18 +0000

> happened, especially in cases where the acceptor wants to make channel

Nico took as a given that there's some magic reason why initiators don't also get to know this, but I certainly don't see it. I don't think Nico's proposal, though, is limited to acceptors knowing, is it?

> in discussions of the appropriate solutions.

I can only speak for myself, but most of us new to this space trying to write mechanisms are trying to get the language right and understand how to pull all of this off in a world of protocols that don't naturally provide keys (which makes CB a lot more valuable to my mind). But it's a moving target, and the details keep changing, or at least it seems so.

We just want to do the right things, and assume that the experts can figure out what the right things are.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 15:22:38 -0600

> Nico took as a given that there's some magic reason why initiators don't also get to know this, but I certainly don't see it. I don't think Nico's proposal, though, is limited to acceptors knowing,…

I didn't say anywhere that only acceptors should use the new interface.

The problem is that acceptors need a) an option to succeed w/o CB, b)
to know whether CB happened.  Initiators need this too, but their need
is lesser than the acceptors'.

> We just want to do the right things, and assume that the experts can figure out what the right things are.

I get this.  Part of me says: there aren't really enough security
experts, so you have to consider becoming one yourself.  Those of us
who are experts in any aspect of security ought to make it easier for
those who don't care to become similarly expert.  This is something
that has been on our plate for a long time: simplified GSS-API,
documentation for application developers, and better documentation for
mechanism implementors (better as in easier to approach than a set of
RFCs starting with a lengthy RFC2743).  I took a step in that
direction with the simplified API draft -- still a far cry from nice
docs, but I think we need the better APIs before the better docs, at
least this particular API improvement.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Feb 2013 16:33:58 -0500

Scott, I definitely think discussing initiator behavior is also in
scope.

There are some tricky questions A lot of existing mechanisms don't allow
the initiator to distinguish an acceptor inputting empty channel
bindings from one who agreed with the initiator's bindings.

On the initiator side there are several outcomes:

1) Channel bindings? What are those? You've got to be kidding; I can't
do that with this mechanism.

2)  I sent channel bindings out into the world. You didn't ask for
mutual authentication; I have no clue what happened to your channel
bindings.

3) I sent channel bindings out into the world. If the other side was
unhappy with channel bindings we would have failed by now. Either they
ignored them or validated them. This is the most you get with GSS
mechanisms I'm reasonably familiar with

4)  I verified that the other side di something with channel
bindings. I'm sure the acceptor didn't pass in empty channel bindings.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 15:48:09 -0600

> do that with this mechanism.

Good point.  We need to distinguish between "this mech can't do CB"
and "this mech can do CB but can't report on final outcome" and "this
mech can do CB and the acceptor didn't".  We already distinguish CB
failure, so that's not a concern.

We could distinguish the first of those ("this mech can't do CB") by
returning an error, but how would that be useful in a SPNEGO context?
Right, it wouldn't.

So maybe we need two or three new ret_flags.  At which point I'd just
opt for an inquiry function that can distinguish all of these without
burning so many (or even any) ret_flags.

> mutual authentication; I have no clue what happened to your channel

Unless you got mutual anyways.

> bindings. I'm sure the acceptor didn't pass in empty channel bindings.

You've argued before that we didn't really need to verify that CB
happened on the initiator side.  Would you summarize your argument
once more?

If we nonetheless conclude that we'd like the initiator to know
whether the acceptor did do CB (and, obviously, succeeded), do we want
to update RFC4121 to indicate this?

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 25 Feb 2013 21:54:25 +0000

> bindings from one who agreed with the initiator's bindings.

That would seem make it impossible for me to know, as an application, whether I can rely on the channel for my protection services instead of using GSS primitives. Which I thought was the whole point of CB.

> mechanisms I'm reasonably familiar with

That's the one I'm unclear on the value of, given my earlier point above.

-- Scott

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 25 Feb 2013 22:00:37 +0000

> I didn't say anywhere that only acceptors should use the new interface.

I should have said "took as given they don't need to know this to make CB usable", which is related to the question you asked Sam.

I don't see how I can write an application and know whether to use the TLS layer or the GSS layer for my security services if I don't know whether the channel was bound. That's true on both ends.

> is lesser than the acceptors'.

Not clear on why, per the above. I'm sure there may be deployment issues associated with which end has to know what based on existing behavior, but ignore that for the moment. I'm just trying to understand how to rely on CB in an application.

> experts, so you have to consider becoming one yourself.

One can only spend time developing so much expertise, though. I have to assume that I can focus on the things I need to be expert in and ask questions of experts when I'm out of that territory. I was basically answering the "apathy" question. I care, I just don't know enough to comment usefully other than to have a strong suspicion that there're some pieces missing here that have been bugging me since I first started trying to write this mech.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 17:31:53 -0600

> I don't see how I can write an application and know whether to use the TLS layer or the GSS layer for my security services if I don't know whether the channel was bound. That's true on both ends.

Ah, that.  The question is: must the TLS client validate the server's
cert and/or can it continue at all if the cert cannot be validated
(e.g., ibecause it's self-signed and not pre-shared, or because
there's no trust path fromt he server cert to a trust anchor on the
client side).  Or you might skip just the CRL/OCSP checking (e.g.,
when there's no stapled OCSP).  Or you might simply log about this
because, say, you do have a decent PKI but you'd like to stop having
to have one and so you're trying to migrate into a world where you
always do CB and *then* you'll turn off the PKI or parts of it.

> Not clear on why, per the above. I'm sure there may be deployment issues associated with which end has to know what based on existing behavior, but ignore that for the moment. I'm just trying to un…

See above.

> One can only spend time developing so much expertise, though. I have to assume that I can focus on the things I need to be expert in and ask questions of experts when I'm out of that territory. I w…

Got it.   There's no need to comment on that which you don't feel
comfortable commenting.  In this case uou might, for example, have
useful feedback on which of the two proposed APIs is best (credential
options or context options) but no useful feedback on the security
aspects of the proposal (or even the problem).  Note that you may well
be in a better position to tell us which API is more usable than
others who are in a better position to tell us about the security
aspects of this issue.

Nico
--

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 25 Feb 2013 23:40:49 +0000

On 2/25/13 6:31 PM, "Nico Williams" <[email-masked]> wrote:
>client side).

Yes, if you expect me to care about this CB stuff at all. The whole point
for me is to not have to do all that stuff.

But if it's optional to get this from GSS-API, which it is, then I have to
know whether it's something I can use or not at runtime.

>others who are in a better position to tell us about the security

I'm really not able to comment much on the API because I'm living
primarily below all this. I do think it's obviously necessary to get
application feedback, but my impression is that the real work on apps is
being done now by various projects that are finally getting all the
patches done that need to be applied to real world software to make newer
mechanisms workable. So people hacking on openssh, et al are probably the
ones that need to comment on that.

-- Scott

---

From: Jim Basney <[email-masked]>
Date: Tue, 26 Feb 2013 10:21:01 -0600

> ones that need to comment on that.

RFC 4462 gives us the following recommendation regarding channel
bindings for SSH GSS-API:

   This document recommends that channel bindings SHOULD NOT be
   specified in the calls during context establishment.  This document
   does not specify any standard data to be used as channel bindings,
   and the use of network addresses as channel bindings may break SSH in
   environments where it is most useful.

So as one of the people hacking on OpenSSH, the above paragraph leads me
to immediately lose interest in GSS-API channel bindings, unless I'm
missing something.

-Jim

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 26 Feb 2013 16:29:00 +0000

>to immediately lose interest in GSS-API channel bindings, unless I'm

Yes, probably a poor example on my part since there's no CB needed there.
What I meant was just generally that the API feedback is important from
the people working on top trying to fix existing issues with apps vs. me
writing a mechanism.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Feb 2013 10:30:14 -0600

> to immediately lose interest in GSS-API channel bindings, unless I'm

No no no :)  RFC4462 is saying that in order to implement the
application protocol that it specifies, no CB inputs should be passed
to GSS_Init/Accept_sec_context().  RFC4462 is NOT making a value
judgement on CB.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 Feb 2013 13:13:34 -0500

> to immediately lose interest in GSS-API channel bindings, unless I'm

That text primarily warns you not to fill in the address information
described in the GSS-API, which is basically useless and considered
deprecated.  These days, when we speak of channel binding, we're
primarily talking about cryptographic binding to an underlying secure
channel, which in GSS-API is accomplished through a field in the channel
bindings structure that allows for protection of opaque channel-related
data provided by the application.

However, you're basically right -- the GSS-API keyex and userauth
methods described in RFC4462 do not use GSS-API channel bindings, so
this discussion is basically moot for SSH.

-- Jeff