Discussion:
[strongSwan] Checking X509 Extended Key Usage
Sven Anders
2018-06-19 16:22:12 UTC
Permalink
Hello!

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 <***@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
Andreas Steffen
2018-06-19 16:47:39 UTC
Permalink
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.

Best regards

Andreas
Post by Sven Anders
Hello!
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 ***@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]==
Sven Anders
2018-06-20 07:49:49 UTC
Permalink
Hi Andreas,
Post by 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 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...
Post by Andreas Steffen
Post by Sven Anders
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 <***@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
Andreas Steffen
2018-06-20 08:43:49 UTC
Permalink
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>

Best regards

Andreas
Post by Sven Anders
Hi Andreas,
Post by 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 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...
Post by Andreas Steffen
Post by Sven Anders
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 ***@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]==
Sven Anders
2018-06-20 11:41:23 UTC
Permalink
Post by Andreas Steffen
Hi Sven,
you can use certificate policies which are based on OIDs.
remote {
auth = pubkey
cert_policy = <OID list>
...
}
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 '***@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?
Post by Andreas Steffen
Post by Sven Anders
Hi Andreas,
Post by 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 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...
Post by Andreas Steffen
Post by Sven Anders
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 <***@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
Andreas Steffen
2018-06-22 09:39:14 UTC
Permalink
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
Post by Sven Anders
Post by Andreas Steffen
Hi Sven,
you can use certificate policies which are based on OIDs.
remote {
auth = pubkey
cert_policy = <OID list>
...
}
rightcertpolicy=<OID list>
Thanks for pointing me to the right direction. I missed this in the
manual page.
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.
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
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[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?
Post by Andreas Steffen
Post by Sven Anders
Hi Andreas,
Post by 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 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...
Post by Andreas Steffen
Post by Sven Anders
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 ***@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]==
Sven Anders
2018-07-04 13:39:53 UTC
Permalink
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
Post by Andreas Steffen
Hi Sven,
the certificate policy must be contained in all certificates
https://www.strongswan.org/testing/testresults5dr/swanctl/rw-ed25519-certpol/
Regards
Andreas
Post by Sven Anders
Post by Andreas Steffen
Hi Sven,
you can use certificate policies which are based on OIDs.
remote {
auth = pubkey
cert_policy = <OID list>
...
}
rightcertpolicy=<OID list>
Thanks for pointing me to the right direction. I missed this in the
manual page.
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.
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
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[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?
Post by Andreas Steffen
Post by Sven Anders
Hi Andreas,
Post by 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 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...
Post by Andreas Steffen
Post by Sven Anders
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 <***@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
Tobias Brunner
2018-07-05 13:13:47 UTC
Permalink
Hi Sven,
Post by Sven Anders
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
"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?
No, I think it simply means that instead of listing all the valid
policies the certificate MAY define anyPolicy instead. According to
section 6 the absence of a policy extension clears the allowed policies
for certificates under that certificate (6.1.3 (e) and also 6.1.2 (a)),
this doesn't reject the certificate, it just means the policies will be
ignored.
Post by Sven Anders
Or SHOULD I set the special policy, iff I want
no limitation?
Yes, I think so.
Post by Sven Anders
How does strongswan evaluate this? Does it need the policy in the root
certificate too and is this correct?
Yes, the constraints plugin checks that the policy in an end-entity
certificate is either contained explicitly in the CA certificates (or
mapped to a different OID via policy map), or that they specify the
anyPolicy OID. The complete trust chain is checked.
Post by Sven Anders
What, if I do NOT own the CA but have a Sub-CA signed by an official CA?
Can I use certification policies then?
Depends on the policy extension in that official CA certificate.
Post by Sven Anders
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...
Then the root CA probably has no policy extension and the policy will be
ignored and, therefore, can't be matched to the rightcertpolicy option.

Regards,
Tobias

Continue reading on narkive:
Loading...