Subject: [IPsec] RFC 4945 IPsec profiles and foot^W text bullets

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jan 2019 13:11:10 -0500 (EST)

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

ExecSum: Should a certificate with serverAuth marked Critical be
rejected by IKE or not?

Relevant sections of the RFC:

5.1.3.  X.509 Certificate Extensions

    Conforming IKE implementations MUST recognize extensions that must or
    may be marked critical according to this specification.  These
    extensions are: KeyUsage, SubjectAltName, and BasicConstraints.

[...]

    With respect to
    compliance with the PKIX certificate profile, IKE implementations
    processing certificates MAY ignore the value of the criticality bit
    for extensions that are supported by that implementation, but MUST
    support the criticality bit for extensions that are not supported by
    that implementation.  That is, a relying party SHOULD processes all
    the extensions it is aware of whether the bit is true or false -- the
    bit says what happens when a relying party cannot process an
    extension.

[...]

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.

[...]

5.1.3.12.  ExtendedKeyUsage

    The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in
    certificates for use with IKE.

[...]

    If a certificate is intended
    to be used with both IKE and other applications, and one of the other
    applications requires use of an EKU value, then such certificates
    MUST contain either the keyPurposeID id-kp-ipsecIKE or
    anyExtendedKeyUsage [5], as well as the keyPurposeID values
    associated with the other applications.  Similarly, if a CA issues
    multiple otherwise-similar certificates for multiple applications
    including IKE, and it is intended that the IKE certificate NOT be
    used with another application, the IKE certificate MAY contain an EKU
    extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its
    use with the other application.  Recall, however, that EKU extensions
    in certificates meant for use in IKE are NOT RECOMMENDED.

    Conforming IKE implementations are not required to support EKU.  If a
    critical EKU extension appears in a certificate and EKU is not
    supported by the implementation, then RFC 3280 requires that the
    certificate be rejected.  Implementations that do support EKU MUST
    support the following logic for certificate validation:

    o  If no EKU extension, continue.

    o  If EKU present AND contains either id-kp-ipsecIKE or
       anyExtendedKeyUsage, continue.

    o  Otherwise, reject cert.

I guess confusion arises from the term "supporting the EKU". If a crypto
library supports the EKU for TLS, but not for IKE, is this "supported"
or not?

Furthermore, it seems if you want to use a certificate for TLS and IKE,
it seems technically you need to set keyPurposeID id-kp-ipsecIKE or
anyExtendedKeyUsage but in practise I've never seen these (I hadn't even
heard of it until I read this RFC yesterday)

So what happened that bit me. Libreswan uses the NSS library, and it did
not have an IPsec profile for certificate validation. So it assumed a
TLS profile for validation. This meant IKE certificates were forced to
have serverAuth or clientAuth. And we tried verification as server, and
on failure tried as client. But if none of these were present, NSS would
always fail validation. So we wanted a real IPsec profile, and the NSS
people implemented RFC 4945 for us.

Then we found a deployment that had set the critical bit for the
serverAuth and NSS followed the above, rejected validation, causing
regression.

What's confusing to me is:

    Conforming IKE implementations are not required to support EKU.

So what should a crypto library do?

- Ignore all EKU's in IPsec profile mode?
- Ignore the critical flag in all EKU's in IPsec profile mode?
- Consider serverAuth as "supported" or "unsupported" for the IPsec profile?
- If "supported", should it ignore the critical flag in IPsec profile mode?
- Should it consider the above differently depending on id-kp-ipsecIKE
   or anyExtendedKeyUsage being present?

As for the last question, that is theoretical. This usage is simply not
used in the wild and requiring it is not going to help anyone at this
point.

Chairs: I think this is a topic worth discussing, because it might make
sense to update 4945 to reflect the reality of dual use certificates
that only have the serverAuth EKU.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Jan 2019 16:36:21 -0500

> ExecSum: Should a certificate with serverAuth marked Critical be

It depends upon how it arrives.

My position is that any certificate pinned into a config file should always
be valid, it's just a container for a public key.

If it arrives via a protocol, and must be validated, then all sorts of checks
are reasonable, but in general, I dislike checks that reject certificates
because they contain *more* than is expected.

I don't think it helps anyone, not even the lawyers, and contributes to
widespread (weak) PSK usage.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Thu, 31 Jan 2019 23:05:22 -0500 (EST)

> because they contain *more* than is expected.

The trouble seems to be that IKE implementations did accept more (like
serverAuth) and some did accept weird things like critical bit with
EKU's unrelated to IKE/IPsec.

> widespread (weak) PSK usage.

I think that was more openssl being the only crappy tool that there was
fault :P

It's entertaining to see WireGuard go through the same. Certificates are
too complex and annoying, lets only support raw keys. We tried that 25
years ago :)

So the issue we have now is that we have an RFC with requirements and
the real world not following these requirements at all.

For example, do you accept a subjectAltName of type dNSName with an IP
address in text form.

If you are strict on the CA flag, then self-signed certs have to be
rejected.

And the other issue is that if you want to use a certificate for IKE and
TLS (eg an SSL VPN), then you have two PKIX profiles that might actually
have contractory constrains or requirements. Additionally, whether you
like it or not such a combined certificate will be forced to comply to
CAB/forum. As an expale, loading your LetsEncrypt certificate into IKE
to use it for SSL-VPN and IPsec VPNs.

I think actual deployment, and what is specified in RFCs, at least in
RFC 4945, has diverted quite a bit. I think 4945 needs to be updated.
But that update would almost have to be "TLS compliant", so it basically
comes down to "ignore all the 4945 stuff".

Paul