https://bugs.openldap.org/show_bug.cgi?id=9318
Issue ID: 9318 Summary: RFC 6125 compliance (SANs-ID vs CN-ID) Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: dar@xoe.solutions Target Milestone: ---
As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client.
It goes on
Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID). If the client chooses to compare a reference identifier of type CN-ID against that string, it MUST follow the comparison rules for the DNS domain name portion of an identifier of type DNS-ID, SRV-ID, or URI-ID, as described under Section 6.4.1, Section 6.4.2, and Section 6.4.3.
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
(https://tools.ietf.org/html/rfc6125#section-6.4.4)
This is an Internet Standards Track document.
Ldap still using CN-ID by default, in the presence of URI/DNS/SRV SANs is prohibited and not standards compliant. It _may_ only fall back to CN if non of those values is provided.
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #1 from Ryan Tandy ryan@openldap.org --- The very same RFC says, in section 1.4 (Applicability):
This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols published prior to this document, such as those excerpted under Appendix B.
For LDAP, RFC 2830 (excerpted in the appendix as mentioned) is the relevant specification, which 6125 explicitly says it does NOT supersede.
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Not only is this bug invalid, but RFC6125 is fundamentally broken. See also https://bugzilla.redhat.com/show_bug.cgi?id=1740070#c26
*** This issue has been marked as a duplicate of issue 9266 ***
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #3 from dar@xoe.solutions --- Interesting, although in appendix B, the most specific paragraph discourages explicitly it's use, although it allows the current implementation.
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [LDAP-SCHEMA] value in the last Relative Distinguished Name (RDN) of the subject field of the server's certificate (where "last" refers to the DER-encoded order, not the order of presentation in a string representation of DER- encoded data). This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right- to-left convention.
It starts out by recommending for LDAP
The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced. Once a match is produced, the server's identity has been verified, and the server identity check is complete. Different subjectAltName types are matched in different ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of various subjectAltName types.
Am I correctly analyzing that compliance with this requirement to fence off man in the middle attacks is actually delegated to the ssl implementation, whereas it's openldap that chooses to extracts the authc_id from the peer's CN exclusively for SASL authentication?
Am I correctly inducing therefor, that OpenLDAP would happly acquire any CN string and present it as SASL's authc_id, more so since RFC 6125 states:
The following topics are out of scope for this specification: o Client or end-user identities.
If my speculations are correct, I'd like to invalidate this report.
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #4 from dar@xoe.solutions --- Maybe it would be good to put a debug message accordingly, though:
Debug0( LDAP_DEBUG_ANY, "TLS: unable to validate host based on subject alternative names falling back to subject name...\n" );
The current error message (wrongly) suggests that the only option is common name based host validation
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #5 from Quanah Gibson-Mount quanah@openldap.org --- Here's the project's view of RFC 6125:
https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/th...
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |UNCONFIRMED Resolution|DUPLICATE |---
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED Version|2.5 |2.4.51 Target Milestone|--- |2.4.52
--- Comment #6 from Quanah Gibson-Mount quanah@openldap.org --- In openldap head:
Commits: • 608a8223 by Howard Chu at 2020-08-21T18:05:08+00:00 ITS#9318 add TLS_REQSAN option
Add an option to specify how subjectAlternativeNames should be handled when validating the names in a server certificate.
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #7 from Quanah Gibson-Mount quanah@openldap.org --- additional in master for slapd: Commits: • 650b1404 by Howard Chu at 2020-08-21T20:06:56+01:00 ITS#9054, #9318 add new TLS options to slapd bindconf
https://bugs.openldap.org/show_bug.cgi?id=9318
dar@xoe.solutions changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED
--- Comment #8 from dar@xoe.solutions --- minor crsscheck, not sure it's a thing: https://gitlab.com/openldap/openldap/-/commit/650b1404c2db8aec7faeb6e30c8b64...
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |TEST
--- Comment #9 from Quanah Gibson-Mount quanah@openldap.org --- Do not change states of bugs. This was marked test on purpose.
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #10 from Quanah Gibson-Mount quanah@openldap.org --- Also, the OpenLDAP git repo, as documented on the website is:
gitlab.com is a mirror.
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #11 from dar@xoe.solutions ---
Do not change states of bugs. This was marked test on purpose.
Sorry, I wasn't even aware having done that. I'm absolutely not used to this bug system. :D
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9325
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #12 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to dar from comment #11)
Do not change states of bugs. This was marked test on purpose.
Sorry, I wasn't even aware having done that. I'm absolutely not used to this bug system. :D
No worries, I've fixed the template so only the developers can change the state of a bug now. ;) So really you helped me find something I'd meant to be in place already!
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED
--- Comment #13 from Quanah Gibson-Mount quanah@openldap.org --- RE24:
• 730ba65e by Howard Chu at 2020-08-21T22:43:47+00:00 ITS#9318 add TLS_REQSAN option
Add an option to specify how subjectAlternativeNames should be handled when validating the names in a server certificate.
• a9f42b12 by Howard Chu at 2020-08-21T23:02:11+00:00 ITS#9054, #9318 add new TLS options to slapd bindconf
For use with back-ldap/back-meta/syncrepl/etc
https://bugs.openldap.org/show_bug.cgi?id=9318
--- Comment #14 from Quanah Gibson-Mount quanah@openldap.org --- trunk: Commits: • d5ed7c50 by Howard Chu at 2020-08-28T11:09:25+01:00 ITS#9054, #9318 document new TLS options in slapd
RE24:
Commits: • cfc231a5 by Howard Chu at 2020-08-28T15:27:59+00:00 ITS#9054, #9318 document new TLS options in slapd
https://bugs.openldap.org/show_bug.cgi?id=9318
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org