[strongSwan] PLUTO_XAUTH_ID trustworthy (by cert)?

[Trevor Cordes]

Is PLUTO_XAUTH_ID (as passed to a user-defined updown script) 100%
trustworthy in an ikev2 / eap-tls / user certs connection scenario?
What I mean by that, is can it be selected, set, or spoofed by the
client?

What I'm hoping is PLUTO_XAUTH_ID (or some other updown variable)
contains the CN or the rfc822Name of the user cert (verified against
the root CA) used to connect.  In fact, if the option PLUTO_THEIR_ID
existed and had the cert info, that would be perfect (PLUTO_PEER_ID
doesn't help here as it just contains the peer's DHCP IP on the LAN).

If the answer to the above is "yes" then read no further!  My problem
is solved (just let me know!).

To be concrete, I want PLUTO_XAUTH_ID to be trevor at foo.com and be
guaranteed to come / be derived from the same data that produces the
parts of the debug log below:

Feb 27 01:12:35 pog charon: 15[ASN] L2 - issuer:
Feb 27 01:12:35 pog charon: 15[ASN]   'C=NL, O=Foo, CN=Foo VPN Root CA'
Feb 27 01:12:35 pog charon: 15[ASN] L2 - subject:
Feb 27 01:12:35 pog charon: 15[ASN]   'C=NL, O=Foo, CN=trevor at foo.com'
Feb 27 01:12:35 pog charon: 15[ASN] L8 - rfc822Name:
Feb 27 01:12:35 pog charon: 15[ASN]   'trevor at foo.com'

What I'm worried about, is that PLUTO_XAUTH_ID is trivially
user-definable and not verified through the cert chain; for instance
being pulled out of the debug log line below:

Feb 27 01:12:35 pog charon: 10[IKE] received EAP identity 'trevor at foo.com'

As that line appears before the cert lines I list above, I'm worried
that it's not verified against the certs. The reason I have this hunch
is that the docs description eap_identity makes it sound trivial to set
and unconfirmed by certs.


If PLUTO_XAUTH_ID is not cert guaranteed, can I request a feature where
some cert guaranteed identifier is provided (like trevor at foo.com as
defined in the cert CN from my example above)?

TLDR can stop here.


The reason I need this is that I want the updown script to setup my
iptables differently for the connection's PLUTO_PEER_SOURCEIP depending
on what user cert was used to connect.  So trevor at foo.com can get
access to a various port set, and carol at foo.com gets access to a
different set.

The reason I need to do *that* is I'm dealing solely with Windows 7
clients and I want to have a way to provide a different access set to
different windows users *on the same windows computer*.  I wasted so
much time trying to get this to work to find out in the end it seems to
be impossible.  To save others the hassle in the future, I'll mention
what I tried.

I tried different machine certs hoping that Windows 7 VPN client will
intelligently select between them based on the FQDN (I setup one per
desired configuration set) specified as the host to connect to.  It
doesn't.  Strongswan will pick one, Windows will pick one, if you get
lucky they agree, if not it'll never work, usually with Windows barfing.

I tried different cacerts hoping that Windows 7 VPN client will
intelligently select between them when set to "smart card or other
certifate" option and narrowing the cacert choice to just the one I
want to match as left/rightca in the conn.  That doesn't work, Windows
and strongswan will still iterate over all installed certs on the
Windows box and then pick the wrong one (sometimes getting lucky).

So I then tried user certs to select on EAP identity in the user cert.
Set that up then finally found a couple of emails/sites that said
strongswan can't switch conns based on identitiy.

So I'm nearly positive, though I pray someone can enlighten me
otherwise, that it is impossible to make Windows 7 VPN somehow tell
strongswan what configuration set it wants (i.e. switch to the desired
conn) when you need to allow multiple ones on a single computer.

Note, I can't differentiate based on incoming IP, my box has just 1
external IP from the ISP.  I can't differentiate based on internal
interface, as I want all the configuration sets to be available on all
interfaces.  Moving to Win 10 (which from what I read may not even
solve this problem either) is not an option at this time.

My last hope is to lump everything together into one conn and use an
updown to configure iptables policy.

Thanks for reading and thanks for helping and thanks for such a great
and useful tool!