[anonsec] details of IKE/IPsec channel binding
mcr at sandelman.ca
Wed Mar 21 09:46:03 PDT 2007
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
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:
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.
This has API impacts, if we have to provide for checking a channel
blog, not just communicating it to the applications for memcpy() check.
More information about the ANONSEC