Subject: [anonsec] details of IKE/IPsec channel binding

From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 21 Mar 2007 17:46:03 +0100

At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be.

(Nico, did we really miss refreshing draft-ietf-btns-connection-latching-00.txt
before it expired?  okay... http://www.sandelman.ca/SSW/ietf/ipsec/btns/connection-latching-00.txt
if someone needs a copy)

oops, anyway, I want to refer to: draft-williams-on-channel-binding-01.txt, section 4.2
suggests to use the host keys.

at lunch, I said that this kept making me queezy to have the channel binding only
be what amount to be public information. I discovered that my queeziness was because
I forgot that the application doing the channel binding itself was going to communicate
the channel binding blog via an integral channel.

I had previously thought that the channel binding was going to be some *secret*,
which had to be communicated carefully or, at least had to have built-in
integrity. This is wrong, the application is responsible for that.  A GSSAPI
application would already have a secure channel in which to put the channel
binding.

The question is, do we still need to have something as a channel binding that
has a stronger binding to the Diffie-Hellman.

My thought was to generate another key from SKEYSEED, and do:
      HMAC-prf(K, concatenation-of-public-keys);
and send that as well.
This would mean that comparing channel binding blogs is not just a memcpy(),
but now involves getting the key (K), and checking the hash.

Thoughts?

This has API impacts, if we have to provide for checking a channel
blog, not just communicating it to the applications for memcpy() check.

---

From: Francis.Dupont at fdupont.fr (Francis Dupont)
Date: Wed, 21 Mar 2007 18:05:37 +0100

In your previous mail you wrote:

   Thoughts?
   
=> what about to use the INTEG (integrity algorithm) in place of
the PRF (pseudo-random function) with the same arguments?
(IMHO this is more appropriate to the intended usage.)

Regards

Francis.Dupont at fdupont.fr

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 Mar 2007 12:06:35 -0500

> At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be.

I think you meant "blob" not "blog" :)

We've discussed this before and the answer is:

 - the public key values of the two peers concatenated in this order:
   channel initiator || channel acceptor

or some similar transformation of those two values.

The connection latching I-D doesn't state this, but _could_ state this.
I'd expected to put this into a separate document.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 Mar 2007 12:13:30 -0500

> the channel binding blog via an integral channel.

Exactly.

> application would already have a secure channel in which to put the channel

Exactly.

> has a stronger binding to the Diffie-Hellman.

No.  It suffices that we have the keys used to "authenticate" the peers
in IKE (when using BTNS we're not really authenticating them, but we
still have such keys).  This applies only when using traditional
PKI-based IKE, not when using EAP.

> My thought was to generate another key from SKEYSEED, and do:

No can do.  (Originally I'd proposed something just like that.)  The
reason is, as explained to me by Bill Sommerfeld right before my first
presentation on this topic back at, IIRC, IETF59:

 - Imagine I send a SYN packet protected with some SA, say, SPI 1001,
   but the SYN|ACK does not arrive in time so I retransmit, only this
   time I use a new SA (SPI 1002, say) because, say, the old one
   expired.

   We can get into a weird situation: the SA that _I_ see as the one
   used to protect the channel creation trigger is _different_ from the
   one seen by my peer, so we fail to agree on channel binding!

This is how I came to add the notion of "end-point channel bindings" vs.
"unique channel bindings."

Nico
--

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Wed, 21 Mar 2007 20:52:09 +0200

> "unique channel bindings."

As the first SPI 1001 already creted the IKE SA and generated the
SKEYSEED, even if you crete new IPsec SA (using the same IKE SA, I
assume) the value generated from the SKEYSEED stays same (it is tied
to IKE SA not to the IPsec SAs). I assume we are only talking about
IKEv2 here, as there is no point of doing any work on the obsoleted
protocols.

If you really destroyed the IKEv2 SA also between those two packets
then you would be seeing different value, but on the other hand same
happens, if you happen to recreate new private / public key pair
between those exchanges (and as IKEv2 SA will probably be there for
several minutes in any case, the only reason to tear it down quickly
is the change of the authentication information, like private /
public key pair, so that thing happening is not that uncommon when
comparing to first case).

Anyways you always need to take care of the case where some packet can
have two different channels bound to it, for example if some fragments
of the final packet arrived through the IPsec SA authenticated using
public key X of IKEv2 SA 1, and other parts came from IPsec SA using
public key Y of IKEv2 SA 2. This can happen if you use the
fragmentation handling from the rfc4301 where you put non-first
fragments to one SA (which might be created using the host public /
private key pair X) and first fragments are put to the port specific
IPsec SA which is created using users public / private key pair Y.

So there we are not talking about two different packets having
different channel binding values, we are talking of different parts of
the one packet having different channel bindings. 
-- 
kivinen at safenet-inc.com

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 Mar 2007 14:33:34 -0500

> IKEv2 here, as there is no point of doing any work on the obsoleted

This needs to work for IKEv1.  Assuming that the IKE_SA is still around
is not a good assumption.

Besides, the used of the public key values of the two peers as the
channel binding suffices.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 Mar 2007 18:06:07 -0500

On Wed, Mar 21, 2007 at 02:41:11PM -0700, Charlie Kaufman wrote:
> As you both note, the channel bindings need not be secret. In fact,
> life is much simpler if they are not.
> 
> Basing the channel bindings on the public keys of the two endpoints is
> secure *if* the two endpoints keep their private keys private (by
> either generating them randomly on each run of the protocol and
> promptly forgetting them or storing them in a safe place). This will
> be true most of the time, so perhaps it's no great sacrifice to demand
> it be true all the time. My biggest concern is that it doesn't work
> with shared secret or EAP authentication.
> 
> As Nicolas notes, there is a possible problem with winding in any of
> the current session keys because the exchange could fail if it takes
> place in the middle of a session key rollover. That's sufficiently
> unlikely that one could choose to live with it, but it sure is ugly.
> 
> The way I wish I had specified it in the original IKEv2 spec was that
> channel bindings would be additional bytes taken from the key
> expansion using PRF+ of SKEYSEED of the original IKE SA (i.e., it
> would not change even if the IKE SA were rekeyed and all of the IPsec
> SAs were rekeyed). This would be a good solution, but might be tricky
> to implement depending on how your IPsec implementation is structured.

Again, this has to work with IKEv1.  Bill so insisted, and I agree.

We could use this approach when using IKEv2 so it also works when using
EAP, and fallback on public keys when IKEv1 is being used, and oh well
if you ever get bitten by the problem I described.

Nico
--

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu, 22 Mar 2007 12:12:21 +0200

> Again, this has to work with IKEv1.  Bill so insisted, and I agree.

Hmm... the BTNS charter only talks about "Current Internet Protocol
security protocol (IPsec) and Internet Key Exchange protocol (IKE)",
it does not mention IKEv1 anywhere.

The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old
RFC240x series is obsoleted.

Also the BTNS charter talks about RFC4301 / RFC4306 (IKEv2) concepts
like PAD, and bare RSA keys.

> if you ever get bitten by the problem I described.

I argue should we waste time at all to define anything else than the
RFC4301 and IKEv2 use. Things were different few years back when this
work was started...
-- 
kivinen at safenet-inc.com

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 22 Mar 2007 06:47:48 -0500

> RFC240x series is obsoleted.

IKEv1 is certainly not obsoleted.  And RFC4301 does support IKEv1, does
it not?

> RFC4301 and IKEv2 use. Things were different few years back when this

First I'd like to be convinced that the IKE_SA expiration in the middle
of channel setup is no big deal.  That is, I'd like to see consensus on
this.  And I'd like input from our AD about whether we need to support
IKEv1.

Nico
--

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu, 22 Mar 2007 14:26:30 +0200

Nicolas Williams writes:
> IKEv1 is certainly not obsoleted.

All obsoleted:

2401 Security Architecture for the Internet Protocol. S. Kent, R.
     Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes
     RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status:
     PROPOSED STANDARD)

2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998.
     (Format: TXT=52831 bytes) (Obsoletes RFC1826) (Obsoleted by
     RFC4302,
     RFC4305) (Status: PROPOSED STANDARD)

2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson.
     November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827)
     (Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD)

2407 The Internet IP Security Domain of Interpretation for ISAKMP. D.
     Piper. November 1998. (Format: TXT=67878 bytes) (Obsoleted by
     RFC4306) (Status: PROPOSED STANDARD)

2408 Internet Security Association and Key Management Protocol
     (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November
     1998. (Format: TXT=209175 bytes) (Obsoleted by RFC4306) (Status:
     PROPOSED STANDARD)

2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November
     1998. (Format: TXT=94949 bytes) (Obsoleted by RFC4306) (Updated by
     RFC4109) (Status: PROPOSED STANDARD)

> And RFC4301 does support IKEv1, does
> it not?

>From RFC4301:

   Note: This document mandates support for several features for which
   support is available in IKEv2 but not in IKEv1, e.g., negotiation of
   an SA representing ranges of local and remote ports or negotiation of
   multiple SAs with the same selectors.  Therefore, this document
   assumes use of IKEv2 or a key and security association management
   system with comparable features.

> this.

I need to think about this more before making my mind for this. My
initial feeling do say that we should bind it to the IKE
authentication, i.e. the to the Diffie-Hellman exchange. 

> And I'd like input from our AD about whether we need to support
> IKEv1.

Me too...

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 22 Mar 2007 09:38:39 -0400

>IKEv1 is certainly not obsoleted.  And RFC4301 does support IKEv1, does

4301 includes mandatory features that IKEv1 cannot negotiate, so in 
that sense 4301 assumes use of IKEv2.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 23 Mar 2007 04:23:27 -0500

> that sense 4301 assumes use of IKEv2.

But if we can write connection latching and channel binding specs in a
sufficiently neutral way that IKEv1/RFC2401 can be used, wouldn't that
be good?  I did try to write the connection latching I-D that way.

Nico
--