[cryptography] very little is missing for working BTNS in Openswan

Paul Wouters paul at cypherpunks.ca
Thu Sep 12 20:28:56 EDT 2013


On Thu, 12 Sep 2013, Nico Williams wrote:

> Note: you don't just want BTNS, you also want RFC5660 -- "IPsec
> channels".  You also want to define a channel binding for such channels
> (this is trivial).
>
> To summarize: IPsec protects discrete *packets*, not discrete packet
> *flows*.  This means that -depending on configuration- you might be
> using IPsec to talk to some peer at some address at one moment, and the
> next you might be talking to a different peer at the same address, and
> you'd never know the difference.  IPsec channels consist of ensuring
> that the peer's ID never changes during the life of a given packet flow
> (e.g., TCP connection).  BTNS pretty much requires IPsec configurations
> of that make you vulnerable in this way.  I think it should be obvious
> now that "IPsec channels" is a necessary part of any BTNS
> implementation.

This is exactly why BTNS went nowhere. People are trying to combine
anonymous IPsec with authenticated IPsec. Years dead-locked in channel
binding and channel upgrades. That's why I gave up on BTNS. See also
the last bit of my earlier post regarding Opportunistic Encryption.

We can use IDs to identify "anonymous" and sandbox these connections. If
you want authenticated IPsec, use a different loaded policy that has
nothing to do with OE IPsec. In libreswan terms:

conn anonymous
 	right=yourip
 	rightid=@serverid
 	rightrsasigkey=0xAQ[....]
 	left=%any
 	leftid=@anonymous
 	leftrsasigkey=%fromike

conn admin
 	[all your normal X.509 authentication stuff]

Merging these into one, is exactly why we got transport mode,
authenticated header,IKEv2 narrowing and a bunch of BTNS drafts no
one uses.

Stop making crypto harder!

Paul


More information about the cryptography mailing list