[anonsec] details of IKE/IPsec channel binding

[Nicolas Williams]

On Sun, Apr 01, 2007 at 05:43:05PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>     Nicolas>  - Imagine I send a SYN packet protected with some SA, say,
>     Nicolas> SPI 1001, but the SYN|ACK does not arrive in time so I
>     Nicolas> retransmit, only this time I use a new SA (SPI 1002, say)
>     Nicolas> because, say, the old one expired.
> 
>     Nicolas>    We can get into a weird situation: the SA that _I_ see
>     Nicolas> as the one used to protect the channel creation trigger is
>     Nicolas> _different_ from the one seen by my peer, so we fail to
>     Nicolas> agree on channel binding!
> 
>   Perhaps, in this case, it should fail.

Well, it will fail.  But with the other channel binding scheme it will
succeed, as it should.

We seem to be willing to accept this pathological condition.  The only
question is: why not go with the way that doesn't have this corner case?

Possible reasons to reject public-keys-of-peers-as-channel-bindings:

 - doesn't work for IKEv2 w/ EAP authentication

   But does anyone want to do channel binding to channels where the
   peers were authenticated with EAP?

   I had a hallway conversation with Sam and Jeff H. about this but I
   came away unconvinced: the peers would have to be the client and the
   SG (since IKEv2 w/ EAP is only applicable to network access through
   IPsec VPNs), so given strong authentication to/of the SG at the IPsec
   layer why should any application on the client want to use channel
   bindings?  Perhaps the EAP method used wasn't very strong -- but then
   why use it at all?

   Still, I'm certainly open to arguments on this.


 - unique channel bindings are better

   They certainly are.  In SASL WG we saw a presentation about a
   password-based challenge/response authentication mechanism (YAP) that
   uses unique channel bindings as the server challenge and client
   nonce, thus saving a full round-trip (and since it only runs inside a
   secure channel it also provides a measure of privacy protection).

So count me as half-convinced.

Nico
--