[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