[Swan-dev] ikev2-10-2behind-nat and 80d68d57a57
Andrew Cagney
andrew.cagney at gmail.com
Thu Sep 19 20:49:44 UTC 2019
The commit fixes the problem:
When using X.509 certificates, this option can be used to accept
certificates
that violate the rules of RFC 4945 Section 3.1 by not having their IKE ID
listed as a subjectAltName (SAN) on their certificate. The default (yes)
is to not accept these certificates as it enables an attack where
a compromised
host can use its valid certificate and some other hosts' peer ID to pretend
to be that other host.
seems to be a little too aggressive. For instance in
ikev2-10-2behind-nat on east I see:
- north establishes #1,#2 creating instance "pool-eastnet-ikev2"[1]
with cert E=user-north at testing.libreswan.org
- road starts establishing #3,#4 and grabs connection instance
"pool-eastnet-ikev2"[1]
- during authentication "pool-eastnet-ikev2"[1] is found unsuitable -
E=user-road at testing.libreswan.org !=
E=user-north at testing.libreswan.org I'm guessing
the old code would then stumble on, eventually going back to the
original connection and re-refining it (the patch stops this):
"pool-eastnet-ikev2"[1] 192.1.2.254 #3: switched from
"pool-eastnet-ikev2"[1] 192.1.2.254 to "pool-eastnet-ikev2"
| rw_instantiate() instantiated "pool-eastnet-ikev2"[2] 192.1.2.254
for 192.1.2.254
"pool-eastnet-ikev2"[2] 192.1.2.254 #3: Authenticated using RSA
(#include rant about how connection prefixes changing randomly and
meaninglessly)
Presumably tweaking the connection would fix this?
But here's my question. Why was road assigned the instance
"pool-eastnet-ikev2"[1] to start with? Would it be better to:
- in the responder, on first contact, assign a non-template connection
to the state
- during auth, when everything is known, switch to or refine the
connection instance as needed
it won't help when first contact has a choice of connections; but it
might help when the problem is finding the correct connection instance
- the initial decision hasn't dug a hole
thoughts,
Andrew
More information about the Swan-dev
mailing list