[147082] in cryptography@c2.net mail archive
Re: [Cryptography] [cryptography] very little is missing for
daemon@ATHENA.MIT.EDU (Paul Wouters)
Fri Sep 13 11:45:28 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 12 Sep 2013 20:28:56 -0400 (EDT)
From: Paul Wouters <paul@cypherpunks.ca>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20130912190406.GB3175@gmail.com>
Cc: Eugen Leitl <eugen@leitl.org>,
Cryptography List <cryptography@metzdowd.com>, cryptography@randombit.net
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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