[anonsec] details of IKE/IPsec channel binding

[Nicolas Williams]

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