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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
