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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
