[strongSwan] Checking X509 Extended Key Usage

[Andreas Steffen]

Hi Sven,

the certificate policy must be contained in all certificates
of the X.509 trust chain. See the following example scenario:

https://www.strongswan.org/testing/testresults5dr/swanctl/rw-ed25519-certpol/

Regards

Andreas

On 20.06.2018 13:41, Sven Anders wrote:
> 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
> 

-- 
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==