[anonsec] details of IKE/IPsec channel binding

[Nicolas Williams]

On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote:
> 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.

Exactly.

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

Exactly.

> The question is, do we still need to have something as a channel binding that
> 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
--