Subject: draft-williams-on-channel-binding-00.txt is in the I-D repository

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Aug 2006 10:08:54 -0500

Folks, the replacement for draft-ietf-nfsv4-channel-bindings,
draft-williams-on-channel-binding-00.txt, is now in the I-D repository.

It has also been significantly expanded.  Please review.  I'd like to
ask the security ADs for an IETF Last Call on this I-D soon.

Nico
-- 

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Aug 2006 18:47:35 +0200

> ask the security ADs for an IETF Last Call on this I-D soon.

Looks good in general.  A general design question:

What about SASL/GS2 over TLS over SSH over IPSEC?  What is the channel
bindings for that, is it only the TLS binding?  Consider if the
application regards the TLS layer as weak (export ciphers) but the SSH
layer as strong, would it be permitted to use the SSH channel binding?
This sounds to me like it may require negotiation in GS2.

Some specific comments:

Section 2.1:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM could not easily force the
      channel bindings of a given channel to match those of another.

I'd change this to:

  o  The channel bindings for a given type of secure channel MUST be
      constructed in such a way that an MITM cannot influence the
      channel bindings.

This drops "easily", and makes the requirement a bit stronger; the
MITM should not have any influence over the channel bindings.

This:

   o  Unique channel bindings MUST bind not only the key exchange for
      the secure channel, but also any negotiations and authentication
      that may have taken place to establish the channel.

Sometimes negotiations/authentications are done by other protocols, or
even out-of-band over the phone, and the intention was not to cover
those things, right?  I'm not sure how to phrase it better, though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Aug 2006 12:36:23 -0500

> Looks good in general.  A general design question:

Thanks for your comments!

> This sounds to me like it may require negotiation in GS2.

How might you end up with such a complex stack?  Are you thinking of
port-forwarding LDAP/IMAP over SSHv2?

It seems to me that the right thing would be to bind each channel to the
one below, so here the SSHv2 channel would be bound to the IPsec
channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the
TLS channel, and the only channel that would provide cryptographic
session protection would be IPsec.

This seems fairly unrealistic though -- aside from port-forwarding I've
a hard time imagining how one would end up with such a complex stack.
And with port-forwarding the channel binding to SSHv2 would require that
the TLS peers know about the SSHv2 channel and its session ID, at which
point one might dispense with TLS altogether and just use SASL/GS2 with
channel binding to SSHv2 (even the SSHv2 channel is not end2end, unless
you want end2end protection, in which case there'd be no need for
channel binding of TLS to the SSHv2 channel).

Also, we'd have to explain how to bind TLS and SSHv2 to other channels...

Consider the examples given so far:

 - NFSv4, iSCSI, other similar protocols, with channel binding to IPsec
 - Extended HTTP authentication with channel binding to TLS

and the reasons for these examples:

 - app-layer authentication fits better (NFSv4, HTTP)
 - app-layer has to be in cleartext relative to a lower layer (NFSv4,
   iSCSI [iSER])
 - better HW support for cryptographic protocols lower in the stack
   (all)

SSHv2 applications don't have the problems that NFSv4 has: they neither
multiplex multiple users on one connection, lack applicable user
authentication methods, or have the RDDP problem.  So channel binding
SSHv2 to a lower layer session makes sense only for HW crypto
acceleration -- though that alone does make a lot of sense.  

>       constructed in such a way that an MITM cannot influence the

Why?  The crucial requirement is the one I give.

> MITM should not have any influence over the channel bindings.

But the MITM does have some influence over the channel bindings, just
not necessarily control over them :)

IOW, I think you need to pick a better word than 'influence', and,
anyways, I think the stated requirement is sufficiently strong.

> those things, right?  I'm not sure how to phrase it better, though.

Well, I don't want to be specific about in-band vs. out of band
negotiation.  Consider the IPsec case, where we bind to the "identities"
(valid cert names, public keys, ...) bound into the KE[*] exchanges that
spawn the SAs that protect a given connection's traffic.  Here there's
not a single negotiation/key exchange/authentication step, but
potentially many, nor do we bind to "in-band" ESP/AH things but to
KE-specific ones.

As for "out-of-band over the phone" -- sorry, but manual protocols are
out of scope.  The intention is to cover: SSHv2, TLS, IPsec and
protocols that have similar design patterns.  However, I'd like the text
to be generic, and I think this text mostly captures the intended
requirement generically.

Perhaps we should replace "exchange" with "exchange(s)" to reflect the
potential, in the IPsec channel construction case, for having more than
one exchange.  And it should be clear that the binding can be quite
indirect, as it would be in the IPsec case.

So:

   o  Unique channel bindings MUST bind not only the key exchange(s) for
      the secure channel, but also any negotiations and authentication
      that may have taken place to establish the channel.

      The binding MAY be indirect, as in the case of end-point channel
      bindings, where the channel bindings consist of end-point "names"
      that are strongly bound, through authentication, to the key
      exchange and negotiation.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 Aug 2006 20:50:41 +0200

> port-forwarding LDAP/IMAP over SSHv2?

I'm using IMAP with SASL over TLS over port-forwarded SSH to read my
mail every day, and I imagine this (TLS over VPN) isn't too uncommon.
Adding IPSEC doesn't seem entirely far fetched, especially if
usability of IPSEC improves.

> session protection would be IPsec.

Sounds OK to me, but I'm not sure it is the only solution.

> a hard time imagining how one would end up with such a complex stack.

I'm thinking of port-forwarding.

> channel binding to SSHv2

Implementing all this seems complex.  Applications or TLS libraries
typically have no idea that it is running over SSH port-forwarding.
And SSH implementation usually have no idea that is running over
IPSEC.  And...

> Also, we'd have to explain how to bind TLS and SSHv2 to other channels...

...that seem to require some additional specification work.

> anyways, I think the stated requirement is sufficiently strong.

Thinking more about this, I'd be happy if the "easily" is dropped from
your paragraph.  If it is only "difficult" (in contrast to
"computationally infeasible") to force two channel bindings to be the
same, I don't think it is good enough.

> to be generic, and I think this text mostly captures the intended

SSH host keys are usually verified out of band, if I'm not mistaken.

I think authentication of (the source to) keying material in TLS-PSK
and TLS-OpenPGP also happens out of band.

I understand that the intention isn't to cover those kind of
negotiations/authentications, but I'm not sure the text captures this.

I don't know what the exact property we are looking for here (in-band
vs out-of-band doesn't seem to be it).

>       exchange and negotiation.

Ok.

Anyway, the only real concern I have is the
GS2-over-TLS-over-SSH-over-IPSEC situation, otherwise I think the
document is ready.  I'm not sure it should move forward until at least
the TLS channel bindings document is close to done too, though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Aug 2006 14:28:00 -0500

On Tue, Aug 15, 2006 at 08:50:41PM +0200, Simon Josefsson wrote:
> [...]

VPNs aren't "channels" as far as this spec goes.  They're not end2end
(nor hop-by-hop proxy systems, like HTTP).

> Sounds OK to me, but I'm not sure it is the only solution.

I think it's the simplest, if indeed this is what you want and if the
SSHv2 session ID can be obtained by both, the IMAP client and the IMAP
server.  As it is you called it a VPN, which, IMO, rules channel binding
out.

> typically have no idea that it is running over SSH port-forwarding.

You'd have to make them aware of what's below.  That's one of the
problems with channel binding to IPsec: the lack of a) IPsec channels,
b) IPsec APIs relevant to IPsec channels.

Yes, channel binding requires new interfaces.  You've discovered this
already in the context of TLS.  But it's a generic requirement: any
channel you might want to bind to has to export its channel bindings,
a minimum of information about what security services it provides, and
maybe even more (see security considerations text about cryptographic
profiles).

> ...that seem to require some additional specification work.

But noone is asking for that.  I'll wait for you to digest my comment
about VPNs before counting you as wanting TLS/SSHv2 channel binding.

> [...]

Sure.

> [...]

Irrelevant for either of the two types of channel bindings described in
the draft: a) because an MITM can't obtain the private key to a server's
host public key and this public key is worked into the session ID
computation, b) because SSHv2 uses ephemeral-ephemeral Diffie-Hellman
for key exchange and the result of the initial key exchange too is
worked into the session ID computation.

So whether you're using an SSHv2 host public key or an SSHv2 session ID
as a channel binding an MITM cannot make this binding agree for both,
its connection to the client and its connection to the server.

> and TLS-OpenPGP also happens out of band.

Irrelevant, for similar reasons.

> the TLS channel bindings document is close to done too, though.

Maybe, but I want additional reviews, not least Sam's.  Thanks!

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Aug 2006 14:46:15 -0500

What mailing list would be approapriate to host reviews of this draft?

NFSv4's does not seem apropriate, but then, neither do the other two
(SASL, KITTEN).  Perhaps SASL, because we've been discussing channel
binding issues in the context of SASL/GS2 there.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Aug 2006 17:45:54 -0500

> binding issues in the context of SASL/GS2 there.

Sam suggests the SAAG list (duh!).

Reply-to set.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Aug 2006 10:23:57 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Nicolas Williams <[email-masked]> writes:

    >> It has also been significantly expanded.  Please review.  I'd
    >> like to ask the security ADs for an IETF Last Call on this I-D
    >> soon.

    Simon> Looks good in general.  A general design question:

    Simon> What about SASL/GS2 over TLS over SSH over IPSEC?  What is
    Simon> the channel bindings for that, is it only the TLS binding?
    Simon> Consider if the application regards the TLS layer as weak
    Simon> (export ciphers) but the SSH layer as strong, would it be
    Simon> permitted to use the SSH channel binding?  This sounds to
    Simon> me like it may require negotiation in GS2.

That's the application's problem to decide.

I definitely do not think we want every mechanism that supports
binding to a channel to need negotiation for this.