[strongSwan] Checking X509 Extended Key Usage

Sven Anders anders at anduras.de
Wed Jul 4 15:39:53 CEST 2018


Hello Andreas,

I'm getting closer by using certificate policies instead of the EKUs.

In your example scenario the CA has the policy set too.
I'm a bit unsure if this is necessary, because a RFC 5280 in section
4.2.1.4 (Certificate Policies) states:

"When a CA does not wish to limit the set of policies for certification
 paths that include this certificate, it MAY assert the special policy
 anyPolicy, with a value of { 2 5 29 32 0 }."

Does this "MAY" mean, that a root certificate without any policy does
not limit the policy? Or SHOULD I set the special policy, iff I want
no limitation?
It's not really clear here (for me).

How does strongswan evaluate this? Does it need the policy in the root
certificate too and is this correct?
What, if I do NOT own the CA but have a Sub-CA signed by an official CA?
Can I use certification policies then?

Currently I have an user certificate with a specific policy and a
Sub-CA with a "anyPolicy" set. But I cannot connect, if I enable the
"rightcertpolicy" option...

Regards
 Sven

Am 22.06.2018 um 11:39 schrieb 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
>>
> 


Mit freundlichen Grüßen
 Sven Anders

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

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht: Passau HRB 6032
Mitglieder des Vorstands: Dipl.-Inf. Sven Anders, Dipl.-Inf. Marcus Junker
Vorsitzender des Aufsichtsrats: RA Mark Peters
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anders.vcf
Type: text/x-vcard
Size: 339 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180704/365efc88/attachment.vcf>


More information about the Users mailing list