[anonsec] details of IKE/IPsec channel binding

[Michael Richardson]

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.