[strongSwan] Checking X509 Extended Key Usage

[Sven Anders]

Am 20.06.2018 um 10:43 schrieb Andreas Steffen:
> Hi Sven,
> 
> you can use certificate policies which are based on OIDs.
> 
> With swanctl.conf:
> 
>   remote {
>     auth = pubkey
>     cert_policy = <OID list>
>     ...
>   }
> 
> or with ipsec.conf:
> 
>   rightcertpolicy=<OID list>

Thanks for pointing me to the right direction. I missed this in the
manual page.

So the manual page states:

  left|rightcertpolicy = <OIDs>

  Comma separated list of certificate policy OIDs the peer's certificate must have.
  OIDs are specified using the numerical dotted representation. Not supported for IKEv1 connections prior to 5.0.0.


If I use the following configuration:

  conn rw-config
    also = rw-base
    ike = aes256-sha2_256-prfsha256-modp1024-modp2048,aes256gcm16-prfsha384-modp3072!
    esp = aes256-sha2_256-prfsha256,aes256-sha1,aes256gcm16-modp3072!
    leftsubnet = 10.0.0.0/8      # Split tunnel config
    leftid = "vpn.mydomain.net"  # Must match remote part on the client side
    leftcert = server.crt        # The server certificate to use
    leftsendcert = always        # not "never"
    left = 10.0.1.99

    rightdns = 10.0.0.10, 10.0.0.11
    rightsourceip = %static, %dynamic
    rightcertpolicy = 1.3.6.1.5.5.7.3.2

  conn ikev2-pubkey
    also = rw-config
    keyexchange = ikev2
    auto = add

I cannot connect and I get the following output:

8235[CFG] ike config match: 1052 (10.0.1.99 89.28.111.222 IKEv2)
8235[CFG]   candidate "ikev2-pubkey", match: 20/1/1052 (me/other/ike)
8235[CFG] selected peer config 'ikev2-pubkey'
8235[CFG]   using certificate "CN=MYNAME"
8235[CFG]   certificate "CN=MYNAME" key: 4096 bit RSA
8235[CFG]   using trusted intermediate ca certificate "DC=local, DC=my-group, CN=MY-CA01"
8235[CFG]   certificate "DC=local, DC=my-group, CN=MY-SUB-CA01" key: 4096 bit RSA
8235[CFG]   using trusted ca certificate "CN=MY-ROOT-CA01"
8235[CFG]   certificate "CN=MY-ROOT-CA01" key: 4096 bit RSA
8235[CFG]   reached self-signed root ca with a path length of 1
8235[IKE] authentication of 'MYNAME at my-group.local' with RSA signature successful
8235[CFG] constraint requires cert policy 1.3.6.1.5.5.7.3.2
8235[CFG] selected peer config 'ikev2-pubkey' inacceptable: non-matching authentication done
8235[CFG] no alternative config found

If I remove the "rightcertpolicy" line, I can connect without problems.

Any ideas?

> On 20.06.2018 09:49, Sven Anders wrote:
>> Hi Andreas,
>>
>> Am 19.06.2018 um 18:47 schrieb Andreas Steffen:
>>> Hi Sven,
>>>
>>> according to section 5.1.3.12. "ExtendedKeyUsage" of RFC 4945
>>> "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX"
>>> the IPsec User EKU is deprecated:
>>>
>>>    The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
>>>    certificates for use with IKE.  Note that there were three IPsec-
>>>    related object identifiers in EKU that were assigned in 1999.  The
>>>    semantics of these values were never clearly defined.  The use of
>>>    these three EKU values in IKE/IPsec is obsolete and explicitly
>>>    deprecated by this specification.  CAs SHOULD NOT issue certificates
>>>    for use in IKE with them.  (For historical reference only, those
>>>    values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
>>>    ipsecUser.)
>>>
>>> The only EKU flags our X.509 class supports are ocspSigning, ClientAuth,
>>> and ServerAuth.
>>
>> yes I know, that "IPsec User" is deprecated (I expected this remark would
>> come), but I used it as an example here. We want to use our own OIDs.
>>
>> Because the ExtendedKeyUsage is a just a list of OIDs and there are no
>> restrictions I know of, we use this to differentiate between classes of
>> certificates we issue.
>>
>> If this isn't supported, how can we use StrongSwan to distinguish between
>> groups of certificates without using Sub-CAs?
>> We cannot be the first with this requirement...
>>
>>> On 19.06.2018 18:22, Sven Anders wrote:
>>>>
>>>> We want to limit the usage of certificates by defining certain
>>>> "Extended Key Usage" (EKU) flags to them.
>>>>
>>>> As an example, we want to set the "IPSec User" usage (1.3.6.1.5.5.7.3.7) and
>>>> only allow connection via IPSec, if it is set. We may use some other flags
>>>> out of our own space too.
>>>>
>>>> How can I check in StrongSwan, if a certain EKU exists?

Regards
 Sven Anders

-- 
 Sven Anders <anders at anduras.de>                 () UTF-8 Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS intranet security AG
 Messestrasse 3 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin