Bug 1212132 - Support for IKE/IPsec typical PKIX usage so libreswan can use nss without rejecting certs based on EKU
Summary: Support for IKE/IPsec typical PKIX usage so libreswan can use nss without rej...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nss
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Bob Relyea
QA Contact: Jaroslav Aster
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks: 1639404 1650450 1651314 1725116
TreeView+ depends on / blocked
 
Reported: 2015-04-15 15:38 UTC by Paul Wouters
Modified: 2019-08-06 13:08 UTC (History)
15 users (show)

Fixed In Version: nss-util-3.36.0-2.el7,nss-3.36.0-8.el7,nss-3.43.0-2.el7
Doc Type: Bug Fix
Doc Text:
.NSS now processes X.509 certificates for use with IPsec correctly Previously, the NSS library did not properly process X.509 certificates for use with IPsec. As a consequence, if X.509 certificates had non-empty Extended Key Usage (EKU) attributes that did not contain `serverAuth` and `clientAuth` attributes, the `Libreswan` IPsec implementation incorrectly rejected validation of the certificates. With this update, the IPsec profiles in NSS have been fixed, and Libreswan can now accept the described certificates.
Clone Of:
: 1650450 1651314 (view as bug list)
Environment:
Last Closed: 2019-08-06 13:08:26 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1252891 0 P2 RESOLVED Implement certUsageIPSec as defined in RFC 4945 2021-02-15 15:07:48 UTC
Mozilla Foundation 1537927 0 P1 RESOLVED IPsec usage is too restrictive for existing deployments 2021-02-15 15:07:48 UTC
Red Hat Bugzilla 1639404 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Knowledge Base (Solution) 3683121 0 None None None 2018-11-09 13:41:31 UTC
Red Hat Product Errata RHSA-2019:2237 0 None None None 2019-08-06 13:08:53 UTC

Internal Links: 1639404

Description Paul Wouters 2015-04-15 15:38:37 UTC
Description of problem:

libreswan up to 3.12 (and all versions of openswan) use very old custom X.509 code for certificate verification.

libreswan 3.13 will use NSS for this.

IKE/IPsec has different EKU requirements/usage, and while testing we found that almost every IKE/IPsec enrollment would have their certificates rejected based on EKU use. So we need a way to relax these constrains.

This can either be a new profile type, or it could be by implementing cert_pi_keyusage and cert_pi_extendedKeyusage options for CERT_PKIXVerifyCert()

This NSS feature will be required before we can release libreswan-3.13

Comment 4 Elio Maldonado Batiz 2016-01-21 19:18:55 UTC
Paul, in Description you said 
"This NSS feature will be required before we can release libreswan-3.13" 
Just checked and we currently have
on fedora:   libreswan-3.16-1.fc23.x86_64 and 
on rhel-7.2: libreswan-3.15-5.el7_1.x86_64
Do we still this this bug?

Comment 5 Tuomo Soini 2016-01-21 20:37:17 UTC
We have worked around this problem but problem still exists and work-around is not totally fool proof. Our work-around was to verify certificate as TLS client cert first and if this fails, as TLS server cert so normally certificates work.

But because IPsec vpn certificates are not required to have EKU at all it's very likely we will hit problems with our work-around sooner or later.

The version using NSS code for certificate verification is 3.14 and later.

Comment 6 Kai Engert (:kaie) (inactive account) 2016-01-22 18:13:03 UTC
It seems like you're asking for something rather simple, which is, to add some more known constants for key usages, is that correct?

Could you please be more precise in which ones exactly you need, etc?

We need to implement this upstream. If you give us more details, we can try to add it upstream. If you need it urgently, we can try to backport it to RHEL when done.

But we need some more exact details first, what exactly is missing. Are you able to provide the details?

Comment 7 Paul Wouters 2016-01-22 18:35:37 UTC
Most VPN certificates don't specify any EKU's. We'd be happy if we can tell NSS to skip checking any EKU's. But let's get Matt Rogers input on this as well,

Comment 8 Tuomo Soini 2016-01-22 18:43:29 UTC
Requirements for certificates for ike use are explained in

https://tools.ietf.org/html/rfc4809#section-3

Generally, "Digital Signature" KU is required, EKU must not be checked at all. But I find it easier to point to document instead of writing all that info here.

Comment 9 Matt Rogers 2016-02-01 16:28:41 UTC
It would suffice to have a SECCertificateUsage type to pass to CERT_PKIXVerifyCert() and other verify functions, eg. 'certificateUsageIPsec' that follows this logic for the KU validation:

https://tools.ietf.org/html/rfc4945#section-5.1.3.2

5.1.3.2.  KeyUsage

   IKE uses an end-entity certificate in the authentication process.
   The end-entity certificate may be used for multiple applications.  As
   such, the CA can impose some constraints on the manner that a public
   key ought to be used.  The KeyUsage (KU) and ExtendedKeyUsage (EKU)
   extensions apply in this situation.

   Since we are talking about using the public key to validate a
   signature, if the KeyUsage extension is present, then at least one of
   the digitalSignature or the nonRepudiation bits in the KeyUsage
   extension MUST be set (both can be set as well).  It is also fine if
   other KeyUsage bits are set.

   A summary of the logic flow for peer cert validation follows:

   o  If no KU extension, continue.

   o  If KU present and doesn't mention digitalSignature or
      nonRepudiation (both, in addition to other KUs, is also fine),
      reject cert.

   o  If none of the above, continue.

Along with this, the EKU should be ignored.

Comment 10 Patrick Monnerat 2016-02-02 17:40:00 UTC
This is also a big problem on Fedora 23 (libreswan-3.16-1.fc23.x86_64, nss-3.21.0-1.1.fc23.x86_64).
I have been trying to use certificates for roadrunner users in libreswan for more than 3 days now, without success.
The debug output shows me the certificates are always rejected (both by client and server profiles), whatever combination of KU/EKU flags I've tried.
Even certificates without KU/EKU are rejected.
It's a pity I cannot replace the (buggy and outdated) racoon daemon by libreswan because of this problem.
Many thanks in advance for a serious fix.

Comment 11 Tuomo Soini 2016-02-02 19:01:41 UTC
This bug is not a libreswan support request. https://lists.libreswan.org/ is correct contact.

Comment 12 Tuomo Soini 2016-02-29 18:30:50 UTC
(In reply to Kai Engert (:kaie) from comment #6)
> It seems like you're asking for something rather simple, which is, to add
> some more known constants for key usages, is that correct?
> 
> Could you please be more precise in which ones exactly you need, etc?
> 
> We need to implement this upstream. If you give us more details, we can try
> to add it upstream. If you need it urgently, we can try to backport it to
> RHEL when done.
> 
> But we need some more exact details first, what exactly is missing. Are you
> able to provide the details?

What would be the time to get such an interface which doesn't chack EKU at all and only verify required key usages (digitalSignature and/or nonRepudiation).

We'd really need this asap. Note, we use CERT_PKIXVerifyCert() now, If we need to switch to another interface, please give us information which interface we should use.

Comment 13 Kai Engert (:kaie) (inactive account) 2016-03-02 13:36:48 UTC
It would be nice/helpful if you could attach (at least one) sample certificate.

If your scenario involves a chain of certs, please attach a full chain (any format), or multiple example chains.

Comment 14 Kai Engert (:kaie) (inactive account) 2016-03-02 16:37:15 UTC
Thanks to Paul and Tuomo for today's IRC discussion, which clarified my questions.

I've reported the request to the upstream project at
  https://bugzilla.mozilla.org/show_bug.cgi?id=1252891

Comment 24 Bob Relyea 2018-11-14 18:33:00 UTC
nss-util-3.36.0-2.el7

Comment 25 Bob Relyea 2018-11-14 18:34:04 UTC
nss-util-3.36.0-2.el7,nss-3.36.0-8.el7

Comment 39 Bob Relyea 2019-03-25 23:06:14 UTC
This patch shouldn't be in modified or ON_QA yet. It wasn't part of the rebase daiki did.

Comment 40 Bob Relyea 2019-03-26 15:41:35 UTC
Fixed in nss-3.43.0-2.el7

Comment 46 errata-xmlrpc 2019-08-06 13:08:26 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2237


Note You need to log in before you can comment on or make changes to this bug.