idnits 2.17.00 (12 Aug 2021) /tmp/idnits14704/draft-saintandre-tls-server-id-check-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 6, 2010) is 4305 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. 'LDAP-TLS') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 4741 (ref. 'NETCONF') (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (ref. 'NETCONF-SSH') (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5539 (ref. 'NETCONF-TLS') (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2459 (ref. 'PKIX-OLD') (Obsoleted by RFC 3280) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: BCP J. Hodges 5 Expires: February 7, 2011 PayPal 6 August 6, 2010 8 Representation and Verification of Domain-Based Application Service 9 Identity in Certificates Used with Transport Layer Security 10 draft-saintandre-tls-server-id-check-09 12 Abstract 14 Many application technologies enable a secure connection between two 15 entities using certificates in the context of Transport Layer 16 Security (TLS). This document specifies best current practices for 17 representing and verifying the identity of application services in 18 such interactions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 7, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 57 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 60 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 61 1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 11 62 1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11 63 1.7. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 11 64 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.1. Naming Application Services . . . . . . . . . . . . . . . 11 66 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 13 67 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 13 68 3. Representation of Server Identity . . . . . . . . . . . . . . 15 69 4. Verification of Server Identity . . . . . . . . . . . . . . . 16 70 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 4.2. Constructing a List of Reference Identifiers . . . . . . . 17 72 4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 18 73 4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 18 74 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 19 75 4.4.2. Checking of Internationalized Domain Names . . . . . . 19 76 4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 19 77 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 19 78 4.5. Verifying an Application Type . . . . . . . . . . . . . . 20 79 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 20 80 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 20 81 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 20 83 4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 21 84 4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 21 85 4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 21 86 4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 22 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 22 89 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 22 90 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 22 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 94 7.2. Informative References . . . . . . . . . . . . . . . . . . 24 95 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 28 96 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 28 97 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 29 98 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 30 99 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 33 100 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 34 101 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 35 102 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 36 103 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 38 104 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 39 105 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 40 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 108 1. Introduction 110 1.1. Motivation 112 The visible face of the Internet consists of services that employ a 113 client-server architecture in which an interactive or automated 114 client connects to an application services in order to retrieve or 115 upload information, communicate with other entities, or access a 116 broader network of services. When a client connects to an 117 application services using Transport Layer Security [TLS] (or, less 118 commonly, Datagram Transport Layer Security [DTLS]), it references 119 some conception of the server's identity while attempting to 120 establish a secure connection (e.g., "the web site at example.com"). 121 Likewise, during TLS negotiation the server presents its conception 122 of the server's identity in the form of a public-key certificate that 123 was issued by a certification authority (CA) in the context of the 124 Internet Public Key Infrastructure using X.509 [PKIX]. Informally, 125 we can think of these identities as the client's "reference identity" 126 and the server's "presented identity" (these rough ideas are defined 127 more precisely later in this document through the concept of 128 particular identifiers). In general, a client needs to verify that 129 the server's presented identity matches its reference identity so 130 that it can be sure that the certificate can legitimately be used to 131 authenticate the connection. 133 Many application technologies adhere to the pattern outlined here, 134 including but not limited to the following: 136 o The Internet Message Access Protocol [IMAP] and the Post Office 137 Protocol [POP3], for which see also [USINGTLS] 139 o The Hypertext Transfer Protocol [HTTP], for which see also 140 [HTTP-TLS] 142 o The Lightweight Directory Access Protocol [LDAP], for which see 143 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 145 o The Simple Mail Transfer Protocol [SMTP], for which see also 146 [SMTP-AUTH] and [SMTP-TLS] 148 o The Extensible Messaging and Presence Protocol [XMPP], for which 149 see also [XMPPBIS] 151 o The Network News Transfer Protocol [NNTP], for which see also 152 [NNTP-TLS] 154 o The NETCONF Configuration Protocol [NETCONF], for which see also 155 [NETCONF-SSH] and [NETCONF-TLS] 157 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] 159 o The Session Initiation Protocol [SIP], for which see also 160 [SIP-CERTS] 162 o The General Internet Signalling Transport [GIST] 164 Application protocols have traditionally specified their own rules 165 for representing and verifying server identities. Unfortunately, 166 this divergence of approaches has caused some confusion among 167 certification authorities, application developers, and protocol 168 designers. 170 Therefore, to codify best current practices regarding the 171 implementation and deployment of secure PKIX-based authentication, 172 this document specifies recommended procedures for representing and 173 verifying server identities in certificates intended for use in 174 applications employing TLS. 176 1.2. Applicability 178 This document does not supersede the rules for certificate validation 179 provided in [PKIX]; specifically, in order to ensure proper 180 authentication, application clients need to verify the entire 181 certification path (this document addresses only the DNS domain name 182 of the application service itself, not the entire trust chain). This 183 document also does not supersede the rules for verifying server 184 identity provided in existing application protocol specifications, 185 such as those mentioned under Appendix A. However, it is the intent 186 of the authors that the best current practices described here can be 187 referenced by future specifications. It is also expected that this 188 document will be updated or obsoleted in the future as best practices 189 for issuance and verification of PKIX certificates continue to evolve 190 through more widespread implementation and deployment of TLS- 191 protected application services over the Internet. 193 1.3. Scope 195 1.3.1. In Scope 197 This document applies only to server identities associated with 198 fully-qualified DNS domain names, only to TLS or DTLS (or the older 199 Secure Sockets Layer (SSL) technology), and only to PKIX-based 200 systems. As a result, the scenarios described in the following 201 section are out of scope for this specification (although they might 202 be addressed by future specifications). 204 1.3.2. Out of Scope 206 The following topics are out of scope for this specification: 208 o Client or end-user identities. 210 Certificates representing client or end-user identities (e.g., the 211 rfc822Name identifier) can be used for mutual authentication 212 between a client and server or between two clients, thus enabling 213 stronger client-server security or end-to-end security. However, 214 certification authorities, application developers, and service 215 operators have less experience with client certificates than with 216 server certificates, thus gives us fewer models from which to 217 generalize and a less solid basis for defining best practices. 219 o Identifiers other than fully-qualified DNS domain names. 221 Some certification authorities issue server certificates based on 222 IP addresses, but preliminary evidence indicates that such 223 certificates are a very small percentage of issued certificates 224 (e.g., less than 1%). Furthermore, IP addresses are not 225 necessarily reliable identifiers for application services because 226 of the existence of private internets [PRIVATE], host mobility, 227 multiple interfaces on a given host, Network Address Translators 228 (NATs) resulting in different addresses for a host from different 229 locations on the network, the practice of grouping many hosts 230 together behind a single IP address, etc. Most fundamentally, 231 most users find DNS domain names much easier to work with than IP 232 addresses, which is why the domain name system was designed in the 233 first place. We prefer to define best practices for the much more 234 common use case and not to complicate the rules in this 235 specification. 237 Furthermore, we focus here on the verification of application 238 service identities, not specific resources located at such 239 services, e.g., a specific web page that can be accessed at a 240 particular Uniform Resource Identifier [URI] whose authority 241 component is the DNS domain name of the application service. We 242 also do not address identifiers derived from Naming Authority 243 Pointer (NAPTR) DNS resource records [NAPTR] and related 244 technologies such as [S-NAPTR], since such identifiers cannot be 245 validated in a trusted manner in the absence of [DNSSEC]. 247 Finally, we do not discuss attributes unrelated to DNS domain 248 names, such as those defined in [X.520] and other such 249 specifications (e.g., organizational attributes, geographical 250 attributes, company logos, and the like). 252 o Security protocols other than [TLS], [DTLS], or the older Secure 253 Sockets Layer (SSL) technology. 255 Although other secure, lower-layer protocols exist and even employ 256 PKIX certificates at times, e.g. IPsec [IPSEC], their use cases 257 can differ from those of TLS-based or DTLS-based application 258 technologies. Furthermore, application technologies have less 259 experience with IPsec than with TLS, thus making it more difficult 260 to gather feedback on proposed best practices. 262 o Keys or certificates employed outside the context of PKIX-based 263 systems. 265 Some deployed application technologies use a web of trust model 266 based on or similar to OpenPGP [OPENPGP], or use self-signed 267 certificates, or are deployed on networks are not directly 268 connected to the public Internet and therefore cannot depend on 269 Certificate Revocation Lists (CRLs) or the Online Certificate 270 Status Protocol [OCSP] to check CA-issued certificates. However, 271 the syntax of OpenPGP differs essentially from that of X.509, the 272 data in self-signed certificates has not been certified by a third 273 party in any way, and checking of CA-issued certificates via CRLs 274 or OSCP is critically important to maintaining the security of 275 PKIX-based systems. Attempting to define best practices for such 276 technologies would unduly complicate the rules defined in this 277 specification. 279 Furthermore, this document also does not address various 280 certification authority policies, such as: 282 o What classes and types of certificates to issue and whether to 283 apply different policies for them (e.g., allow the wildcard 284 character in Class 2 certificates but not in Class 1 or Extended 285 Validation certificates). 287 o Whether to issue certificates based on IP addresses (or some other 288 form, such as relative domain names) in addition to fully- 289 qualified DNS domain names. 291 o Which identifiers to include (e.g., whether to include the SRVName 292 and uniformResourceIdentifier extensions). 294 o How to certify or validate fully-qualified domain names and 295 application service types. 297 o How to certify or validate other kinds of information that might 298 be included in a certificate (e.g., organization name). 300 Finally, this specification is mostly silent about user interface 301 issues, which in general are properly the responsibility of client 302 software developers and standards development organizations dedicated 303 to particular application technologies (see for example [WSC-UI]). 305 1.4. Terminology 307 Because many concepts related to "identity" are often too vague to be 308 actionable in application protocols, we define a set of more concrete 309 terms for use in this specification. 311 application service: A service on the Internet that enables 312 interactive and automated clients to connect for the purpose of 313 retrieving or uploading information, communicating with other 314 entities, or connecting to a broader network of services. 316 application service provider: An organization or individual that 317 hosts or deploys an application service. 319 attribute-type-and-value pair: A colloquial name for the ASN.1-based 320 construction comprising a Relative Distinguished Name (RDN), which 321 itself is a building-block component of Distinguished Names. See 322 Section 2 of [LDAP-DN]. 324 automated client: A software agent or device that is not directly 325 controlled by a natural person. 327 direct name: A name for an application service that is provided 328 directly to a client by a user, resulting in a source domain and 329 (optionally) a service type. 331 identifier: A particular instance of an identifier type that is 332 either presented by a server in a certificate or referenced by a 333 client for matching purposes. 335 identifier type: A formally defined category of identifier that can 336 be included in a certificate and therefore also used for matching 337 purposes; the types covered in this specification are: 339 * CN-ID = a Relative Distinguished Name (RDN) in the certificate 340 subject that contains one and only one attribute-type-and-value 341 pair of type Common Name (CN); see [PKIX] and also 342 [LDAP-SCHEMA] 344 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 346 * SRV-ID = a subjectAltName entry of type otherName whose name 347 form is SRVName; see [SRVNAME] 349 * URI-ID = a subjectAltName entry of type 350 uniformResourceIdentifier; see [PKIX] 352 indirect name: A name for an application service that is resolved by 353 a client based on a direct name provided by a user, resulting in a 354 target domain and (optionally) a service type. 356 interactive client: A software agent or device that is directly 357 controlled by a natural person. (Other specifications related to 358 security and application protocols, such as [WSC-UI], often refer 359 to this entity as a "user agent", however that term is neither 360 entirely accurate nor consistent with the terminology of common 361 application protocols such as [HTTP].) 363 PKIX certificate: An X.509v3 certificate generated and employed in 364 the context of the Internet Public Key Infrastructure using X.509 365 [PKIX]. 367 presented identifier: An identifier that is presented by a server to 368 a client within the server's PKIX certificate when the client 369 attempts to establish a secure connection with the server; the 370 certificate can include one or more presented identifiers of 371 different types. 373 reference identifier: An identifier that is used by the client for 374 matching purposes when checking the presented identifiers; the 375 client can attempt to match multiple reference identifiers of 376 different types. 378 restricted name: A name that can be used only for one type of 379 service at an application service provider. 381 service type: A formal identifier for the application protocol used 382 to provide a particular kind of service at a domain; the service 383 type typically takes the form of a Uniform Resource Identifier 384 scheme [URI] or a DNS SRV Service [DNS-SRV]. 386 source domain: The fully-qualified DNS domain name that a client 387 expects an application service to present in the certificate. 389 subjectAltName entry: A specific identifier placed in a 390 subjectAltName extension. 392 subjectAltName extension: A standard PKIX certificate extension as 393 described in [PKIX]. The subject alternative name extension 394 allows various identifiers of various types to be bound to the 395 certificate subject, in addition or in place of the subject name. 397 subject name: The name of a PKIX certificate's subject, encoded as 398 the X.501 type Name, and conveyed in a certificate's subject field 399 (see Section 4.1.2.6 of [PKIX]). Note that a subject's name(s) 400 can be represented in the subject field, the subjectAltName 401 extension, or both (see [PKIX] for details). 403 TLS client: An entity that assumes the role of a client in a 404 Transport Layer Security [TLS] negotiation; in this specfication 405 we generally assume that the TLS client is an (interactive or 406 automated) application client, however in application protocols 407 that enable server-to-server communication the TLS client could be 408 a peer application service. 410 TLS server: An entity that assumes the role of a server in a 411 Transport Layer Security [TLS] negotiation; in this specfication 412 we assume that the TLS server is an application service. 414 target domain: A domain name or host name that a client has derived 415 from the source domain in an automated fashion (e.g., by means of 416 a [DNS-SRV] lookup) or that a natural person directly controlling 417 an interactive client has explicitly configured for connecting to 418 the source domain. 420 unrestricted name: A name that can be used for any service type at 421 an application service provider. 423 Most security-related terms in this document are to be understood in 424 the sense defined in [SECTERMS]; such terms include, but are not 425 limited to, "attack", "authentication", "authorization", 426 "certification authority", "certification path", "certificate", 427 "credential", "identity", "self-signed certificate", "trust", "trust 428 anchor", "trust chain", "validate", and "verify". 430 The following capitalized keywords are to be interpreted as described 431 in [KEYWORDS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 432 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 433 "OPTIONAL". 435 1.5. Contributors 437 The following individuals made important contributions to the text of 438 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 440 1.6. Acknowledgements 442 The editors and contributors wish to thank the following individuals 443 for their feedback and suggestions: Nelson Bolyard, Kaspar Brand, Ben 444 Campbell, Scott Cantor, Wan-Teh Chang, Dave Crocker, Cyrus Daboo, 445 Charles Gardiner, Philip Guenther, Bruno Harbulot, Wes Hardaker, 446 David Harrington, Paul Hoffman, Love Hornquist Astrand, Harry Hotz, 447 Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey 448 Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve 449 Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, Martin Rex, Joe 450 Salowey, Stefan Santesson, Rob Stradling, Peter Sylvester, Paul 451 Tiemann, Dan Wing, and Dan Winship. 453 1.7. Discussion Venue 455 [[ RFC Editor: please remove this section. ]] 457 The editors are actively seeking input from certification 458 authorities, application developers, and protocol designers regarding 459 the recommendations in this document. Please send feedback to the 460 editors directly or post to the mailing list, for 461 which archives and subscription information are available at 462 . 464 2. Names 466 This section discusses naming of application services on the 467 Internet, followed by a brief tutorial about subject naming in PKIX. 469 2.1. Naming Application Services 471 This specification assumes that the name of an application service is 472 based on a DNS domain name (e.g., "example.com") -- supplemented in 473 some circumstances by a service type (e.g., "the IMAP server at 474 example.com"). 476 From the perspective of the application client or user, some names 477 are direct because they are provided directly by the user (e.g., via 478 runtime input or prior configuration) whereas other names are 479 indirect because they are resolved by the client based on input 480 provided directly by the user (e.g., a target name resolved from a 481 source name using DNS SRV records). This dimension matters for 482 certificate verification. 484 From the perspective of the application service, some names are 485 unrestricted because they can be used in any type of service (e.g., a 486 certificate might be re-used for both the HTTP service and the IMAP 487 service at example.com) whereas other names are restricted because 488 they can be used in only one type of service (e.g., a special-purpose 489 certificate that can be used only for an IMAP service). This 490 dimension matters for certificate issuance. 492 Therefore: 494 o A CN-ID is direct (provided by a user) and unrestricted (can be 495 used for any application). 497 o A DNS-ID is direct (provided by a user) and unrestricted (can be 498 used for any application). 500 o An SRV-ID can be either direct (provided by a user) or more 501 typically indirect (resolved by a client) and is restricted (can 502 be used for only a single application). 504 o A URI-ID is direct (provided by a user) and restricted (can be 505 used for only a single application). 507 We summarize this taxonomy in the following table. 509 +-----------+-----------+---------------+ 510 | | Direct | Restricted | 511 +-----------+-----------+---------------+ 512 | CN-ID | Yes | No | 513 +-----------+-----------+---------------+ 514 | DNS-ID | Yes | No | 515 +-----------+-----------+---------------+ 516 | SRV-ID | Either | Yes | 517 +-----------+-----------+---------------+ 518 | URI-ID | Yes | Yes | 519 +-----------+-----------+---------------+ 521 When implementing software, deploying services, and issuing 522 certificates for secure PKIX-based authentication, it is important to 523 keep these distinctions in mind. In particular, best practices 524 differ somewhat for application server implementations, application 525 client implementations, application service providers, and 526 certification authorities. Protocol specifications that reference 527 this document MUST specify which identifiers are mandatory-to- 528 implement by servers and clients, which identifiers are to be 529 preferred by application service providers, and which identifiers 530 ought to be supported by certificate issuers. Because these 531 requirements differ across applications, it is impossible to 532 categorically stipulate universal rules (e.g., that all software 533 implementations, service providers, and certification authorities for 534 all application protocols need to use or support DNS-IDs as a 535 baseline for the purpose of interoperability); however, it is 536 preferable that each application protocol will at least define a 537 baseline that applies to the community of software developers, 538 application service providers, and CAs actively using or supporting 539 that technology. 541 2.2. DNS Domain Names 543 For the purposes of this specification, the name of an application 544 service MUST be a DNS domain name that conforms to one of the 545 following forms: 547 1. A "traditional domain name", i.e., a fully-qualified domain name 548 or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 549 labels" as defined in [IDNA-DEFS]. Informally, such labels are 550 constrained to [US-ASCII] letters, digits, and the hyphen, with 551 the hyphen prohibited in the first character position. 552 Additional qualifications apply (please refer to the above- 553 referenced specifications for details) but they are not germane 554 to this specification. 556 2. An "internationalized domain name", i.e., a DNS domain name that 557 conforms to the overall form of a domain name (dot-separated 558 labels) but that can include Unicode code points outside the 559 traditional US-ASCII range or, more precisely, either U-labels or 560 A-labels as described in [IDNA-DEFS] and the associated 561 documents. 563 2.3. Subject Naming in PKIX Certificates 565 In theory, the Internet Public Key Infrastructure using X.509 [PKIX] 566 employs the global directory service model defined in [X.500] and 567 [X.501]. In that model, information is held in a directory 568 information base (DIB) and entries in the DIB are organized in a 569 hierarchy called the directory information tree (DIT). An object or 570 alias entry in that hierarchy consists of a set of attributes (each 571 of which has a defined type and one or more values) and is uniquely 572 identified by a Distinguished Name (DN). The DN of an entry is 573 constructed by combining the Distinguished Name of its superior 574 entries in the tree (all the way down to the root of the DIT) with 575 one or more specially-nominated attributes of the entry itself (which 576 together comprise the Relative Distinguished Name (RDN) of the entry, 577 so-called because it is relative to the Distinguished Names of the 578 superior entries in the tree). The entry closest to the root is 579 sometimes referred to as the "most significant" entry and the entry 580 farthest from the root is sometimes referred to as the "least 581 significant" entry. An RDN is a set (i.e., an unordered group) of 582 attribute-type-and-value pairs (see also [LDAP-DN]), each of which 583 asserts some attribute about the entry. 585 In practice, the certificates used in [X.509] and [PKIX] borrow key 586 concepts of X.500 and X.501 (e.g., DNs and RDNs) to identify 587 entities, but such certificates are not necessarily part of a global 588 directory information base. Specifically, the subject field of a 589 PKIX certificate is an X.501 type Name that "identifies the entity 590 associated with the public key stored in the subject public key 591 field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly 592 acceptable for the subject field to be empty, as long as the 593 certificate contains a subjectAltName extension that includes at 594 least one subjectAltName entry, because the subject alternative name 595 ("subjectAltName") extension allows various identities to be bound to 596 the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName 597 extension itself is a sequence of typed entries, where each type is a 598 distinct kind of identifier. 600 For our purposes, an application service is identified by a name or 601 names carried in the subject field and/or in one of the following 602 subjectAltName entry types: 604 o dNSName -- a (fully-qualified) DNS domain name [PKIX] 606 o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME] 608 o uniformResourceIdentifier -- a Uniform Resource Identifier [URI] 609 [PKIX] 611 We recognize that existing certificates often use a CN-ID in the 612 subject field to represent a fully-qualified DNS domain name; for 613 example, consider the following subject name, where the attribute of 614 type Common Name contains a string whose form matches that of a 615 fully-qualified DNS domain name of "www.example.com": 617 cn=www.example.com,c=GB,ou=Web Services 619 However, in general, this specification recommends and prefers use of 620 subjectAltName entries over use of the subject field where possible, 621 as more completely described in the following sections. 623 Implementation Note: Confusion sometimes arises from different 624 renderings or encodings of the hierarchical information contained 625 in a certificate. Certificates are binary objects and are encoded 626 using the Distinguished Encoding Rules (DER) specified in [X.690]. 627 However, some implementations generate displayable (a.k.a. 628 printable) renderings of certificate issuer, subject, and subject 629 alternative names, and these renderings convert the DER-encoded 630 sequences into a "string representation" before being displayed. 631 Because a Distinguished Name (DN) is an ordered sequence, order is 632 preserved in the string representation of a DN. However, because 633 a Relative Distinguished Name (RDN) is an unordered group of 634 attribute-type-and-value pairs, the string representation of an 635 RDN can differ from the canonical DER encoding. Furthermore, 636 various specifications refer to the order of RDNs using 637 terminology that is not directly related to the information 638 hierarchy, such as "most specific" vs. "least specific", "left- 639 most" vs. "right-most", "first" vs. "last", or "most significant" 640 vs. "least significant" (see for example [LDAP-DN]). To reduce 641 confusion, in this specification we avoid such terms and instead 642 use the terms provided under Section 1.4; in particular, we do not 643 use the term "(most specific) Common Name field in the Subject 644 field" from [HTTP-TLS] and instead state that a CN-ID is a 645 Relative Distinguished Name (RDN) in the certificate subject that 646 contains one and only one attribute-type-and-value pair of type 647 Common Name (thus removing the possibility that an RDN might 648 contain multiple AVAs of type CN, one of which would be considered 649 "most specific"). 651 3. Representation of Server Identity 653 When a certification authority issues a certificate based on the 654 fully-qualified DNS domain name at which the application service 655 provider will provide the relevant application, the following rules 656 apply to the representation of application service identities. 658 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName 659 entry of type dNSName) if possible as a baseline for 660 interoperability. 662 2. If the service using the certificate deploys a technology in 663 which a server is discovered by means of DNS SRV records 664 [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate 665 SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type 666 otherName whose name form is SRVName as specified in [SRVNAME]). 668 3. If the service using the certificate deploys a technology in 669 which a server is typically associated with a URI (e.g., this is 670 true of [SIP]), then the certificate SHOULD include a URI-ID 671 (i.e., a subjectAltName entry of type uniformResourceIdentifier); 672 the scheme SHALL be that of the protocol associated with the 673 service type and the authority component SHALL be the fully- 674 qualified DNS domain name of the service. 676 4. The certificate MAY include other application-specific 677 identifiers for types that were defined before specification of 678 the SRVName extension (e.g., XmppAddr for [XMPP]) or for which 679 service names or URI schemes do not exist; however, such 680 application-specific identifiers are not generally applicable and 681 therefore are out of scope for this specification. 683 5. The certificate SHOULD NOT represent the server's fully-qualified 684 DNS domain name in a CN-ID, even though many deployed clients 685 still check for this legacy identifier configuration within 686 certificate subject name. 688 6. The certificate MAY contain more than one DNS-ID, but SHOULD NOT 689 contain more than one CN-ID. 691 7. The fully-qualified DNS domain name portion of a DNS-ID or CN-ID 692 MAY contain one instance of the wildcard character '*', but only 693 as the left-most label of the domain name component of the 694 identifier (following the definition of "label" from [DNS]). 695 Specifications that reference the rules defined in this document 696 can specify that the wildcard character is not allowed in 697 certificates used by the relevant application protocol or 698 community of interest. 700 4. Verification of Server Identity 702 4.1. Overview 704 At a high level, the client verifies the application service's 705 identity by performing the following actions: 707 1. Before connecting to the server, the client constructs a list of 708 reference identifiers against which to check the presented 709 identifiers. 711 2. The server provides its identifiers in the form of a PKIX 712 certificate. 714 3. The client checks each of its reference identifiers against the 715 presented identifiers for the purpose of finding a match. 717 4. When checking a reference identifier against a presented 718 identifier, the client (a) MUST match the source domain (or, in 719 some cases, target domain) of the identifiers and (b) MAY also 720 match the service type of the identifiers. 722 Implementation Note: Naturally, in addition to checking 723 identifiers, a client might complete further checks to ensure that 724 the server is authorized to provide the requested service. 725 However, such checking is not a matter of verifying the 726 application service identity presented in a certificate, and 727 therefore methods for doing so (e.g., consulting local policy 728 information) are out of scope for this document. 730 4.2. Constructing a List of Reference Identifiers 732 Before connecting to the server, the client MUST construct a list of 733 acceptable reference identifiers. 735 The inputs here might be a URI that a user has typed into an 736 interface (e.g., an HTTP URL for a web site), configured account 737 information (e.g., the domain name of an IMAP or POP3 account for 738 retrieving email), or some other combination of information that can 739 yield a source domain and a service type. 741 The client might need to derive the source domain and service type 742 from the input(s) it has received. The derived data MUST include 743 only information that can be securely parsed out of the inputs (e.g., 744 extracting the fully-qualified DNS domain name from the authority 745 component of a URI or extracting the service type from the scheme of 746 a URI) or information for which the derivation is performed in a 747 secure manner (e.g., using [DNSSEC]). 749 In some cases the inputs might include more than one fully-qualified 750 DNS domain name, because a user might have explicitly configured the 751 client to associate a target domain with the source domain. Such 752 delegation can occur by means of user-approved DNS SRV records (e.g., 753 _xmpp-server._tcp.im.example.com might yield an address of 754 hosting.example.net) or a user-configured lookup table for host-to- 755 address or address-to-host translations (e.g., the Unix "hosts" 756 file). See under Section 5 for further discussion of service 757 delegation. 759 Using the combination of fully-qualified DNS domain name(s) and 760 service type, the client constructs a list of reference identifiers 761 in accordance with the following rules: 763 o The list MUST include a DNS-ID. A reference identifier of type 764 DNS-ID can be directly constructed from a fully-qualified DNS 765 domain name that is (a) contained in or securely derived from the 766 inputs (i.e., the source domain), or (b) explicitly associated 767 with the source domain by means of user configuration (i.e., a 768 target domain). 770 o If a server for the service type is typically discovered by means 771 of DNS SRV records, then the list SHOULD include an SRV-ID. 773 o If a server for the service type is typically associated with a 774 URI, then the list SHOULD include a URI-ID 776 o The list SHOULD NOT include a CN-ID; however, the CN-ID (if 777 included) MUST be constructed only from the source domain and 778 never from a target domain. 780 Implementation Note: The client does not need to actually 781 construct the foregoing identifiers in the formats found in a 782 certificate (e.g., as ASN.1 types), only the functional equivalent 783 of such identifiers for matching purposes. 785 Security Note: A client MUST NOT construct a reference identifier 786 corresponding to Relative Distinguished Names (RDNs) other than 787 the Common Name and MUST NOT check for such RDNs in the presented 788 identifiers. 790 4.3. Seeking a Match 792 Once the client has constructed its list of reference identifiers and 793 has received the server's presented identifiers in the form of a PKIX 794 certificate, the client checks its reference identifiers against the 795 presented identifiers for the purpose of finding a match. It does so 796 by seeking a match and aborting the search if any presented 797 identifier matches one of its reference identifiers. The search 798 fails if the client exhausts its list of reference identifiers 799 without finding a match. Detailed comparison rules for finding a 800 match are provided in the following sections. 802 Security Note: A client MUST NOT seek a match for a reference 803 identifier of CN-ID if the presented identifiers include an 804 SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName 805 entry types supported by the client. 807 4.4. Verifying a Domain Name 809 The client MUST match the source domain of a reference identifier 810 according to the following rules, depending on whether the source 811 domain is a "traditional domain name" or an "internationalized domain 812 name" as previously defined. 814 4.4.1. Checking of Traditional Domain Names 816 If the source domain of a reference identifier is a "traditional 817 domain name", then matching of the reference identifier against the 818 presented identifier is performed by comparing the set of domain name 819 components using a case-insensitive ASCII comparison, as clarified by 820 [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to 821 "www.example.com" for comparison purposes). Each label MUST match in 822 order for the names to be considered to match. 824 4.4.2. Checking of Internationalized Domain Names 826 If the source domain of a reference identifier is an 827 internationalized domain name, then an implementation MUST convert 828 every label in the domain name to an A-label before checking the 829 domain name. 831 4.4.3. Checking of Wildcard Labels 833 A client employing this specification's rules MAY match the reference 834 identifier against a presented identifier containing one instance of 835 the wildcard character '*', but only as the left-most label of the 836 domain name, e.g. *.example.com (following the definition of "label" 837 from [DNS]). 839 If such a wildcard identifier is presented, the wildcard MUST be used 840 to match only the one position-wise corresponding label (thus 841 *.example.com matches foo.example.com but not bar.foo.example.com or 842 example.com). The client MUST fail to match a presented identifier 843 in which the wildcard character is contained within a label fragment 844 (e.g., baz*.example.net is not allowed and MUST NOT be taken to match 845 baz1.example.net and baz2.example.net), or in which the wildcard 846 character does not comprise the left-most label in the presented 847 identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net 848 are allowed). 850 A specification that references the rules defined in this document 851 can specify that the wildcard character is not allowed in 852 certificates used by the relevant application protocol or community 853 of interest. 855 4.4.4. Checking of Common Names 857 As noted, a client MUST NOT seek a match for a reference identifier 858 of CN-ID if the presented identifiers include an SRV-ID, URI-ID, 859 DNS-ID, or any application-specific subjectAltName entry types 860 supported by the client. 862 Therefore, if and only if the set of identifiers does not include a 863 subjectAltName entry of type dNSName, SRVName, or 864 uniformResourceIdentifier (or any application-specific subjectAltName 865 entry types supported by the client), the client MAY as a fallback 866 check for a string whose form matches that of a fully-qualified DNS 867 domain name in the CN-ID. If the client chooses to compare a 868 reference identifier of type CN-ID against that string, it MUST 869 follow the comparison rules for the source domain of an identifier of 870 type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4. 872 4.5. Verifying an Application Type 874 A client SHOULD check not only the domain name but also the service 875 type of the service to which it connects. This is a best practice 876 because typically a client is not designed to connect to all kinds of 877 services using all possible application protocols, but instead is 878 designed to connect to one kind of service, such as a web site, an 879 email service, or an instant messaging service. 881 The service type is verified by means of either an SRV-ID or URI-ID. 883 4.5.1. SRV-ID 885 The service name portion of an SRV-ID (e.g., "xmpp") MUST be matched 886 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 887 that the "_" character is prepended to the service identifier in DNS 888 SRV records. 890 4.5.2. URI-ID 892 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 893 a case-insensitive manner, in accordance with [URI]. Note that the 894 ":" character is a separator between the scheme name and the rest of 895 the URI, and therefore does not need to be included in any 896 comparison. 898 4.6. Outcome 900 The outcome of the checking procedure is one of the following cases. 902 4.6.1. Case #1: Match Found 904 If the client has found a presented identifier that matches a 905 reference identifier, matching has succeeded. In this case, the 906 client MUST use the matched reference identifier as the validated 907 identity of the server. 909 4.6.2. Case #2: No Match Found, Cached Certificate 911 If the client finds no presented identifier that matches any of the 912 reference identifiers but a natural person has permanently accepted 913 the certificate during a previous connection attempt or via 914 configured preferences, the certificate is cached. In this case, the 915 client MUST verify that the presented certificate matches the cached 916 certificate and (if it is an interactive client) MUST notify the user 917 if the certificate has changed since the last time a secure 918 connection was successfully negotiated (where causes of change 919 include but are not limited to changes in the DNS domain name, 920 identifiers, issuer, certification path, and expiration date). 922 4.6.3. Case #3: No Match Found, Uncached Certificate 924 If the client finds no presented identifier that matches any of the 925 reference identifiers and a human user has not permanently accepted 926 the certificate for this application service during a previous 927 connection attempt, the client MUST NOT consider the certificate to 928 include a validated identity for the application service. 930 Instead, the client MUST proceed as follows. 932 4.6.3.1. Interactive User Agent 934 If the client is an interactive client that is directly controlled by 935 a natural person, then it SHOULD inform the user of the identity 936 mismatch and terminate the connection automatically with a bad 937 certificate error; this behavior is preferable because it prevents 938 the majority of users from inadvertently bypassing security 939 protections in hostile situations. 941 Security Note: Many existing interactive user agents give advanced 942 users the option of proceeding despite an identity mismatch. 943 Although this behavior can be appropriate in certain specialized 944 circumstances, in general it needs to be handled with extreme 945 caution, for example by first encouraging the user to terminate 946 the connection, forcing the user to view the entire certification 947 path, and allowing the user to accept the certificate only on a 948 temporary basis (i.e., for this connection attempt and all 949 subsequent connection attempts for the life of the application 950 session). 952 4.6.3.2. Automated Client 954 If the client is an automated application that is not directly 955 controlled by a natural person, then it SHOULD terminate the 956 connection with a bad certificate error and log the error to an 957 appropriate audit log. An automated application MAY provide a 958 configuration setting that disables this check, but MUST enable the 959 check by default. 961 5. Security Considerations 963 5.1. Service Delegation 965 When the connecting application is an interactive client, the source 966 domain name and service type MUST be provided by a human user (e.g. 967 when specifying the server portion of the user's account name on the 968 server or when explicitly configuring the client to connect to a 969 particular host or URI as in [SIP-LOC]) and MUST NOT be derived from 970 the user inputs in an automated fashion (e.g., a host name or domain 971 name discovered through DNS resolution of the source domain). This 972 rule is important because only a match between the user inputs (in 973 the form of a reference identifier) and a presented identifier 974 enables the client to be sure that the certificate can legitimately 975 be used to secure the connection. 977 However, an interactive client MAY provide a configuration setting 978 that enables a human user to explicitly specify a particular host 979 name or domain name (called a "target domain") to be checked for 980 connection purposes. 982 5.2. Wildcard Certificates 984 Allowing the wildcard character in certificates has led to homograph 985 attacks involving non-ASCII characters that look similar to 986 characters commonly included in HTTP URLs, such as "/" and "?"; for 987 discussion, see for example [Defeating-SSL]. 989 5.3. Internationalized Domain Names 991 In addition to the wildcard certificate attacks previously mentioned, 992 allowing internationalized domain names can lead to the inclusion of 993 visually similar (so-called "confusable") characters in certificates; 994 for discussion, see for example [IDNA-DEFS]. 996 6. IANA Considerations 998 This document specifies no actions for the IANA. 1000 7. References 1002 7.1. Normative References 1004 [DNS] Mockapetris, P., "Domain names - implementation and 1005 specification", STD 13, RFC 1035, November 1987. 1007 [DNS-CONCEPTS] 1008 Mockapetris, P., "Domain names - concepts and facilities", 1009 STD 13, RFC 1034, November 1987. 1011 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1012 specifying the location of services (DNS SRV)", RFC 2782, 1013 February 2000. 1015 [IDNA-DEFS] 1016 Klensin, J., "Internationalized Domain Names for 1017 Applications (IDNA): Definitions and Document Framework", 1018 RFC 5890, August 2010. 1020 [KEYWORDS] 1021 Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, March 1997. 1024 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 1025 (LDAP): String Representation of Distinguished Names", 1026 RFC 4514, June 2006. 1028 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1029 Housley, R., and W. Polk, "Internet X.509 Public Key 1030 Infrastructure Certificate and Certificate Revocation List 1031 (CRL) Profile", RFC 5280, May 2008. 1033 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1034 Subject Alternative Name for Expression of Service Name", 1035 RFC 4985, August 2007. 1037 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1038 Resource Identifier (URI): Generic Syntax", STD 66, 1039 RFC 3986, January 2005. 1041 7.2. Informative References 1043 [Defeating-SSL] 1044 Marlinspike, M., "New Tricks for Defeating SSL in 1045 Practice", February 2009, . 1049 [DNS-CASE] 1050 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 1051 Clarification", RFC 4343, January 2006. 1053 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1054 Rose, "DNS Security Introduction and Requirements", 1055 RFC 4033, March 2005. 1057 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1058 Security", RFC 4347, April 2006. 1060 [GIST] Schulzrinne, H. and M. Stiemerling, "GIST: General 1061 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1062 (work in progress), June 2009. 1064 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1065 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1066 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1068 [HTTP-TLS] 1069 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1071 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1072 4rev1", RFC 3501, March 2003. 1074 [IDNA2003] 1075 Faltstrom, P., Hoffman, P., and A. Costello, 1076 "Internationalizing Domain Names in Applications (IDNA)", 1077 RFC 3490, March 2003. 1079 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1080 September 1981. 1082 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1083 (IPv6) Specification", RFC 2460, December 1998. 1085 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1086 Internet Protocol", RFC 4301, December 2005. 1088 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1089 (LDAP): The Protocol", RFC 4511, June 2006. 1091 [LDAP-AUTH] 1092 Harrison, R., "Lightweight Directory Access Protocol 1093 (LDAP): Authentication Methods and Security Mechanisms", 1094 RFC 4513, June 2006. 1096 [LDAP-SCHEMA] 1097 Sciberras, A., "Lightweight Directory Access Protocol 1098 (LDAP): Schema for User Applications", RFC 4519, 1099 June 2006. 1101 [LDAP-TLS] 1102 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1103 Directory Access Protocol (v3): Extension for Transport 1104 Layer Security", RFC 2830, May 2000. 1106 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1107 Part Three: The Domain Name System (DNS) Database", 1108 RFC 3403, October 2002. 1110 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1111 December 2006. 1113 [NETCONF-SSH] 1114 Wasserman, M. and T. Goddard, "Using the NETCONF 1115 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1116 December 2006. 1118 [NETCONF-TLS] 1119 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1120 RFC 5539, May 2009. 1122 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1123 RFC 3977, October 2006. 1125 [NNTP-TLS] 1126 Murchison, K., Vinocur, J., and C. Newman, "Using 1127 Transport Layer Security (TLS) with Network News Transfer 1128 Protocol (NNTP)", RFC 4642, October 2006. 1130 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1131 Adams, "X.509 Internet Public Key Infrastructure Online 1132 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1134 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1135 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1137 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1138 STD 53, RFC 1939, May 1996. 1140 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1141 E. Lear, "Address Allocation for Private Internets", 1142 BCP 5, RFC 1918, February 1996. 1144 [PKIX-OLD] 1145 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1146 X.509 Public Key Infrastructure Certificate and CRL 1147 Profile", RFC 2459, January 1999. 1149 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1150 Service Location Using SRV RRs and the Dynamic Delegation 1151 Discovery Service (DDDS)", RFC 3958, January 2005. 1153 [SECTERMS] 1154 Shirey, R., "Internet Security Glossary, Version 2", 1155 RFC 4949, August 2007. 1157 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1158 A., Peterson, J., Sparks, R., Handley, M., and E. 1159 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1160 June 2002. 1162 [SIP-CERTS] 1163 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1164 Certificates in the Session Initiation Protocol (SIP)", 1165 RFC 5922, June 2010. 1167 [SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1168 Protocol (SIP): Locating SIP Servers", RFC 3263, 1169 June 2002. 1171 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1172 October 2008. 1174 [SMTP-AUTH] 1175 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1176 for Authentication", RFC 4954, July 2007. 1178 [SMTP-TLS] 1179 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1180 Transport Layer Security", RFC 3207, February 2002. 1182 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1184 [SYSLOG-TLS] 1185 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1186 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1187 March 2009. 1189 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1190 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1192 [US-ASCII] 1193 American National Standards Institute, "Coded Character 1194 Set - 7-bit American Standard Code for Information 1195 Interchange", ANSI X3.4, 1986. 1197 [USINGTLS] 1198 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1199 RFC 2595, June 1999. 1201 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1202 Interface Guidelines", World Wide Web Consortium 1203 LastCall WD-wsc-ui-20100309, March 2010, 1204 . 1206 [X.500] International Telecommunications Union, "Information 1207 Technology - Open Systems Interconnection - The Directory: 1208 Overview of concepts, models and services", ITU- 1209 T Recommendation X.500, ISO Standard 9594-1, August 2005. 1211 [X.501] International Telecommunications Union, "Information 1212 Technology - Open Systems Interconnection - The Directory: 1213 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1214 August 2005. 1216 [X.509] International Telecommunications Union, "Information 1217 Technology - Open Systems Interconnection - The Directory: 1218 Public-key and attribute certificate frameworks", ITU- 1219 T Recommendation X.509, ISO Standard 9594-8, August 2005. 1221 [X.520] International Telecommunications Union, "Information 1222 Technology - Open Systems Interconnection - The Directory: 1223 Selected attribute types", ITU-T Recommendation X.509, 1224 ISO Standard 9594-6, August 2005. 1226 [X.690] International Telecommunications Union, "Information 1227 Technology - ASN.1 encoding rules: Specification of Basic 1228 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1229 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1230 X.690, ISO Standard 8825-1, August 2008. 1232 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1233 Protocol (XMPP): Core", RFC 3920, October 2004. 1235 [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence 1236 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work 1237 in progress), April 2010. 1239 Appendix A. Prior Art 1241 (This section is non-normative.) 1243 The recommendations in this document are an abstraction from 1244 recommendations in specifications for a wide range of application 1245 protocols. For the purpose of comparison and to delineate the 1246 history of thinking about server identity verification within the 1247 IETF, this informative section gathers together prior art by 1248 including the exact text from various RFCs (the only modifications 1249 are changes to the names of several references to maintain coherence 1250 with the main body of this document, and the elision of irrelevant 1251 text as marked by the characters "[...]"). 1253 A.1. IMAP, POP3, and ACAP (1999) 1255 In 1999, [USINGTLS] specified the following text regarding server 1256 identity verification in IMAP, POP3, and ACAP: 1258 ###### 1260 2.4. Server Identity Check 1262 During the TLS negotiation, the client MUST check its understanding 1263 of the server hostname against the server's identity as presented in 1264 the server Certificate message, in order to prevent man-in-the-middle 1265 attacks. Matching is performed according to these rules: 1267 o The client MUST use the server hostname it used to open the 1268 connection as the value to compare against the server name as 1269 expressed in the server certificate. The client MUST NOT use any 1270 form of the server hostname derived from an insecure remote source 1271 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1272 o If a subjectAltName extension of type dNSName is present in the 1273 certificate, it SHOULD be used as the source of the server's 1274 identity. 1275 o Matching is case-insensitive. 1276 o A "*" wildcard character MAY be used as the left-most name 1277 component in the certificate. For example, *.example.com would 1278 match a.example.com, foo.example.com, etc. but would not match 1279 example.com. 1281 o If the certificate contains multiple names (e.g. more than one 1282 dNSName field), then a match with any one of the fields is 1283 considered acceptable. 1285 If the match fails, the client SHOULD either ask for explicit user 1286 confirmation, or terminate the connection and indicate the server's 1287 identity is suspect. 1289 ###### 1291 A.2. HTTP (2000) 1293 In 2000, [HTTP-TLS] specified the following text regarding server 1294 identity verification in HTTP: 1296 ###### 1298 3.1. Server Identity 1300 In general, HTTP/TLS requests are generated by dereferencing a URI. 1301 As a consequence, the hostname for the server is known to the client. 1302 If the hostname is available, the client MUST check it against the 1303 server's identity as presented in the server's Certificate message, 1304 in order to prevent man-in-the-middle attacks. 1306 If the client has external information as to the expected identity of 1307 the server, the hostname check MAY be omitted. (For instance, a 1308 client may be connecting to a machine whose address and hostname are 1309 dynamic but the client knows the certificate that the server will 1310 present.) In such cases, it is important to narrow the scope of 1311 acceptable certificates as much as possible in order to prevent man 1312 in the middle attacks. In special cases, it may be appropriate for 1313 the client to simply ignore the server's identity, but it must be 1314 understood that this leaves the connection open to active attack. 1316 If a subjectAltName extension of type dNSName is present, that MUST 1317 be used as the identity. Otherwise, the (most specific) Common Name 1318 field in the Subject field of the certificate MUST be used. Although 1319 the use of the Common Name is existing practice, it is deprecated and 1320 Certification Authorities are encouraged to use the dNSName instead. 1322 Matching is performed using the matching rules specified by 1323 [PKIX-OLD]. If more than one identity of a given type is present in 1324 the certificate (e.g., more than one dNSName name, a match in any one 1325 of the set is considered acceptable.) Names may contain the wildcard 1326 character * which is considered to match any single domain name 1327 component or component fragment. E.g., *.a.com matches foo.a.com but 1328 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1330 In some cases, the URI is specified as an IP address rather than a 1331 hostname. In this case, the iPAddress subjectAltName must be present 1332 in the certificate and must exactly match the IP in the URI. 1334 If the hostname does not match the identity in the certificate, user 1335 oriented clients MUST either notify the user (clients MAY give the 1336 user the opportunity to continue with the connection in any case) or 1337 terminate the connection with a bad certificate error. Automated 1338 clients MUST log the error to an appropriate audit log (if available) 1339 and SHOULD terminate the connection (with a bad certificate error). 1340 Automated clients MAY provide a configuration setting that disables 1341 this check, but MUST provide a setting which enables it. 1343 Note that in many cases the URI itself comes from an untrusted 1344 source. The above-described check provides no protection against 1345 attacks where this source is compromised. For example, if the URI 1346 was obtained by clicking on an HTML page which was itself obtained 1347 without using HTTP/TLS, a man in the middle could have replaced the 1348 URI. In order to prevent this form of attack, users should carefully 1349 examine the certificate presented by the server to determine if it 1350 meets their expectations. 1352 ###### 1354 A.3. LDAP (2000/2006) 1356 In 2000, [LDAP-TLS] specified the following text regarding server 1357 identity verification in LDAP: 1359 ###### 1361 3.6. Server Identity Check 1363 The client MUST check its understanding of the server's hostname 1364 against the server's identity as presented in the server's 1365 Certificate message, in order to prevent man-in-the-middle attacks. 1367 Matching is performed according to these rules: 1369 o The client MUST use the server hostname it used to open the LDAP 1370 connection as the value to compare against the server name as 1371 expressed in the server's certificate. The client MUST NOT use 1372 the server's canonical DNS name or any other derived form of name. 1373 o If a subjectAltName extension of type dNSName is present in the 1374 certificate, it SHOULD be used as the source of the server's 1375 identity. 1377 o Matching is case-insensitive. 1378 o The "*" wildcard character is allowed. If present, it applies 1379 only to the left-most name component. 1381 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 1382 bar.com. If more than one identity of a given type is present in the 1383 certificate (e.g. more than one dNSName name), a match in any one of 1384 the set is considered acceptable. 1386 If the hostname does not match the dNSName-based identity in the 1387 certificate per the above check, user-oriented clients SHOULD either 1388 notify the user (clients MAY give the user the opportunity to 1389 continue with the connection in any case) or terminate the connection 1390 and indicate that the server's identity is suspect. Automated 1391 clients SHOULD close the connection, returning and/or logging an 1392 error indicating that the server's identity is suspect. 1394 Beyond the server identity checks described in this section, clients 1395 SHOULD be prepared to do further checking to ensure that the server 1396 is authorized to provide the service it is observed to provide. The 1397 client MAY need to make use of local policy information. 1399 ###### 1401 In 2006, [LDAP-AUTH] specified the following text regarding server 1402 identity verification in LDAP: 1404 ###### 1406 3.1.3. Server Identity Check 1408 In order to prevent man-in-the-middle attacks, the client MUST verify 1409 the server's identity (as presented in the server's Certificate 1410 message). In this section, the client's understanding of the 1411 server's identity (typically the identity used to establish the 1412 transport connection) is called the "reference identity". 1414 The client determines the type (e.g., DNS name or IP address) of the 1415 reference identity and performs a comparison between the reference 1416 identity and each subjectAltName value of the corresponding type 1417 until a match is produced. Once a match is produced, the server's 1418 identity has been verified, and the server identity check is 1419 complete. Different subjectAltName types are matched in different 1420 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 1421 various subjectAltName types. 1423 The client may map the reference identity to a different type prior 1424 to performing a comparison. Mappings may be performed for all 1425 available subjectAltName types to which the reference identity can be 1426 mapped; however, the reference identity should only be mapped to 1427 types for which the mapping is either inherently secure (e.g., 1428 extracting the DNS name from a URI to compare with a subjectAltName 1429 of type dNSName) or for which the mapping is performed in a secure 1430 manner (e.g., using [DNSSEC], or using user- or admin-configured 1431 host-to-address/address-to-host lookup tables). 1433 The server's identity may also be verified by comparing the reference 1434 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 1435 Relative Distinguished Name (RDN) of the subject name field of the 1436 server's certificate (where "last" refers to the DER-encoded order, 1437 not the order of presentation in a string representation of DER- 1438 encoded data). This comparison is performed using the rules for 1439 comparison of DNS names in Section 3.1.3.1, below, with the exception 1440 that no wildcard matching is allowed. Although the use of the Common 1441 Name value is existing practice, it is deprecated, and Certification 1442 Authorities are encouraged to provide subjectAltName values instead. 1443 Note that the TLS implementation may represent DNs in certificates 1444 according to X.500 or other conventions. For example, some X.500 1445 implementations order the RDNs in a DN using a left-to-right (most 1446 significant to least significant) convention instead of LDAP's right- 1447 to-left convention. 1449 If the server identity check fails, user-oriented clients SHOULD 1450 either notify the user (clients may give the user the opportunity to 1451 continue with the LDAP session in this case) or close the transport 1452 connection and indicate that the server's identity is suspect. 1453 Automated clients SHOULD close the transport connection and then 1454 return or log an error indicating that the server's identity is 1455 suspect or both. 1457 Beyond the server identity check described in this section, clients 1458 should be prepared to do further checking to ensure that the server 1459 is authorized to provide the service it is requested to provide. The 1460 client may need to make use of local policy information in making 1461 this determination. 1463 3.1.3.1. Comparison of DNS Names 1465 If the reference identity is an internationalized domain name, 1466 conforming implementations MUST convert it to the ASCII Compatible 1467 Encoding (ACE) format as specified in Section 4 of RFC 3490 1468 [IDNA2003] before comparison with subjectAltName values of type 1469 dNSName. Specifically, conforming implementations MUST perform the 1470 conversion operation specified in Section 4 of RFC 3490 as follows: 1472 o in step 1, the domain name SHALL be considered a "stored string"; 1473 o in step 3, set the flag called "UseSTD3ASCIIRules"; 1474 o in step 4, process each label with the "ToASCII" operation; and 1475 o in step 5, change all label separators to U+002E (full stop). 1477 After performing the "to-ASCII" conversion, the DNS labels and names 1478 MUST be compared for equality according to the rules specified in 1479 Section 3 of RFC3490. 1481 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 1482 values of type dNSName, and then only as the left-most (least 1483 significant) DNS label in that value. This wildcard matches any 1484 left-most DNS label in the server name. That is, the subject 1485 *.example.com matches the server names a.example.com and 1486 b.example.com, but does not match example.com or a.b.example.com. 1488 3.1.3.2. Comparison of IP Addresses 1490 When the reference identity is an IP address, the identity MUST be 1491 converted to the "network byte order" octet string representation 1492 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 1493 string will contain exactly four octets. For IP Version 6, as 1494 specified in RFC 2460, the octet string will contain exactly sixteen 1495 octets. This octet string is then compared against subjectAltName 1496 values of type iPAddress. A match occurs if the reference identity 1497 octet string and value octet strings are identical. 1499 3.1.3.3. Comparison of Other subjectName Types 1501 Client implementations MAY support matching against subjectAltName 1502 values of other types as described in other documents. 1504 ###### 1506 A.4. SMTP (2002/2007) 1508 In 2002, [SMTP-TLS] specified the following text regarding server 1509 identity verification in SMTP: 1511 ###### 1513 4.1 Processing After the STARTTLS Command 1515 [...] 1517 The decision of whether or not to believe the authenticity of the 1518 other party in a TLS negotiation is a local matter. However, some 1519 general rules for the decisions are: 1521 o A SMTP client would probably only want to authenticate an SMTP 1522 server whose server certificate has a domain name that is the 1523 domain name that the client thought it was connecting to. 1525 [...] 1527 ###### 1529 In 2006, [SMTP-AUTH] specified the following text regarding server 1530 identity verification in SMTP: 1532 ###### 1534 14. Additional Requirements When Using SASL PLAIN over TLS 1536 [...] 1538 After a successful [TLS] negotiation, the client MUST check its 1539 understanding of the server hostname against the server's identity as 1540 presented in the server Certificate message, in order to prevent man- 1541 in-the-middle attacks. If the match fails, the client MUST NOT 1542 attempt to authenticate using the SASL PLAIN mechanism. Matching is 1543 performed according to the following rules: 1545 The client MUST use the server hostname it used to open the 1546 connection as the value to compare against the server name as 1547 expressed in the server certificate. The client MUST NOT use any 1548 form of the server hostname derived from an insecure remote source 1549 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1550 If a subjectAltName extension of type dNSName is present in the 1551 certificate, it SHOULD be used as the source of the server's 1552 identity. 1553 Matching is case-insensitive. 1554 A "*" wildcard character MAY be used as the leftmost name 1555 component in the certificate. For example, *.example.com would 1556 match a.example.com, foo.example.com, etc., but would not match 1557 example.com. 1558 If the certificate contains multiple names (e.g., more than one 1559 dNSName field), then a match with any one of the fields is 1560 considered acceptable. 1562 ###### 1564 A.5. XMPP (2004) 1566 In 2004, [XMPP] specified the following text regarding server 1567 identity verification in XMPP: 1569 ###### 1571 14.2. Certificate Validation 1573 When an XMPP peer communicates with another peer securely, it MUST 1574 validate the peer's certificate. There are three possible cases: 1576 Case #1: The peer contains an End Entity certificate which appears 1577 to be certified by a certification path terminating in a trust 1578 anchor (as described in Section 6.1 of [PKIX]). 1579 Case #2: The peer certificate is certified by a Certificate 1580 Authority not known to the validating peer. 1581 Case #3: The peer certificate is self-signed. 1583 In Case #1, the validating peer MUST do one of two things: 1584 1. Verify the peer certificate according to the rules of [PKIX]. 1585 The certificate SHOULD then be checked against the expected 1586 identity of the peer following the rules described in [HTTP-TLS], 1587 except that a subjectAltName extension of type "xmpp" MUST be 1588 used as the identity if present. If one of these checks fails, 1589 user-oriented clients MUST either notify the user (clients MAY 1590 give the user the opportunity to continue with the connection in 1591 any case) or terminate the connection with a bad certificate 1592 error. Automated clients SHOULD terminate the connection (with a 1593 bad certificate error) and log the error to an appropriate audit 1594 log. Automated clients MAY provide a configuration setting that 1595 disables this check, but MUST provide a setting that enables it. 1596 2. The peer SHOULD show the certificate to a user for approval, 1597 including the entire certification path. The peer MUST cache the 1598 certificate (or some non-forgeable representation such as a 1599 hash). In future connections, the peer MUST verify that the same 1600 certificate was presented and MUST notify the user if it has 1601 changed. 1603 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 1605 ###### 1607 At the time of this writing, [XMPPBIS] refers to this document for 1608 rules regarding server identity verification in XMPP. 1610 A.6. NNTP (2006) 1612 In 2006, [NNTP-TLS] specified the following text regarding server 1613 identity verification in NNTP: 1615 ###### 1616 5. Security Considerations 1618 [...] 1620 During the TLS negotiation, the client MUST check its understanding 1621 of the server hostname against the server's identity as presented in 1622 the server Certificate message, in order to prevent man-in-the-middle 1623 attacks. Matching is performed according to these rules: 1625 o The client MUST use the server hostname it used to open the 1626 connection (or the hostname specified in TLS "server_name" 1627 extension [TLS]) as the value to compare against the server name 1628 as expressed in the server certificate. The client MUST NOT use 1629 any form of the server hostname derived from an insecure remote 1630 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1631 done. 1632 o If a subjectAltName extension of type dNSName is present in the 1633 certificate, it SHOULD be used as the source of the server's 1634 identity. 1635 o Matching is case-insensitive. 1636 o A "*" wildcard character MAY be used as the left-most name 1637 component in the certificate. For example, *.example.com would 1638 match a.example.com, foo.example.com, etc., but would not match 1639 example.com. 1640 o If the certificate contains multiple names (e.g., more than one 1641 dNSName field), then a match with any one of the fields is 1642 considered acceptable. 1644 If the match fails, the client SHOULD either ask for explicit user 1645 confirmation or terminate the connection with a QUIT command and 1646 indicate the server's identity is suspect. 1648 Additionally, clients MUST verify the binding between the identity of 1649 the servers to which they connect and the public keys presented by 1650 those servers. Clients SHOULD implement the algorithm in Section 6 1651 of [PKIX] for general certificate validation, but MAY supplement that 1652 algorithm with other validation methods that achieve equivalent 1653 levels of verification (such as comparing the server certificate 1654 against a local store of already-verified certificates and identity 1655 bindings). 1657 ###### 1659 A.7. NETCONF (2006/2009) 1661 In 2006, [NETCONF-SSH] specified the following text regarding server 1662 identity verification in NETCONF: 1664 ###### 1666 6. Security Considerations 1668 The identity of the server MUST be verified and authenticated by the 1669 client according to local policy before password-based authentication 1670 data or any configuration or state data is sent to or received from 1671 the server. The identity of the client MUST also be verified and 1672 authenticated by the server according to local policy to ensure that 1673 the incoming client request is legitimate before any configuration or 1674 state data is sent to or received from the client. Neither side 1675 should establish a NETCONF over SSH connection with an unknown, 1676 unexpected, or incorrect identity on the opposite side. 1678 ###### 1680 In 2009, [NETCONF-TLS] specified the following text regarding server 1681 identity verification in NETCONF: 1683 ###### 1685 3.1. Server Identity 1687 During the TLS negotiation, the client MUST carefully examine the 1688 certificate presented by the server to determine if it meets the 1689 client's expectations. Particularly, the client MUST check its 1690 understanding of the server hostname against the server's identity as 1691 presented in the server Certificate message, in order to prevent man- 1692 in-the-middle attacks. 1694 Matching is performed according to the rules below (following the 1695 example of [NNTP-TLS]): 1697 o The client MUST use the server hostname it used to open the 1698 connection (or the hostname specified in the TLS "server_name" 1699 extension [TLS]) as the value to compare against the server name 1700 as expressed in the server certificate. The client MUST NOT use 1701 any form of the server hostname derived from an insecure remote 1702 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1703 done. 1704 o If a subjectAltName extension of type dNSName is present in the 1705 certificate, it MUST be used as the source of the server's 1706 identity. 1707 o Matching is case-insensitive. 1708 o A "*" wildcard character MAY be used as the leftmost name 1709 component in the certificate. For example, *.example.com would 1710 match a.example.com, foo.example.com, etc., but would not match 1711 example.com. 1713 o If the certificate contains multiple names (e.g., more than one 1714 dNSName field), then a match with any one of the fields is 1715 considered acceptable. 1717 If the match fails, the client MUST either ask for explicit user 1718 confirmation or terminate the connection and indicate the server's 1719 identity is suspect. 1721 Additionally, clients MUST verify the binding between the identity of 1722 the servers to which they connect and the public keys presented by 1723 those servers. Clients SHOULD implement the algorithm in Section 6 1724 of [PKIX] for general certificate validation, but MAY supplement that 1725 algorithm with other validation methods that achieve equivalent 1726 levels of verification (such as comparing the server certificate 1727 against a local store of already-verified certificates and identity 1728 bindings). 1730 If the client has external information as to the expected identity of 1731 the server, the hostname check MAY be omitted. 1733 ###### 1735 A.8. Syslog (2009) 1737 In 2009, [SYSLOG-TLS] specified the following text regarding server 1738 identity verification in Syslog: 1740 ###### 1742 5.2. Subject Name Authorization 1744 Implementations MUST support certification path validation [PKIX]. 1745 In addition, they MUST support specifying the authorized peers using 1746 locally configured host names and matching the name against the 1747 certificate as follows. 1749 o Implementations MUST support matching the locally configured host 1750 name against a dNSName in the subjectAltName extension field and 1751 SHOULD support checking the name against the common name portion 1752 of the subject distinguished name. 1753 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 1754 the subjectAltName extension (and in common name, if used to store 1755 the host name), but only as the left-most (least significant) DNS 1756 label in that value. This wildcard matches any left-most DNS 1757 label in the server name. That is, the subject *.example.com 1758 matches the server names a.example.com and b.example.com, but does 1759 not match example.com or a.b.example.com. Implementations MUST 1760 support wildcards in certificates as specified above, but MAY 1761 provide a configuration option to disable them. 1762 o Locally configured names MAY contain the wildcard character to 1763 match a range of values. The types of wildcards supported MAY be 1764 more flexible than those allowed in subject names, making it 1765 possible to support various policies for different environments. 1766 For example, a policy could allow for a trust-root-based 1767 authorization where all credentials issued by a particular CA 1768 trust root are authorized. 1769 o If the locally configured name is an internationalized domain 1770 name, conforming implementations MUST convert it to the ASCII 1771 Compatible Encoding (ACE) format for performing comparisons, as 1772 specified in Section 7 of [PKIX]. 1773 o Implementations MAY support matching a locally configured IP 1774 address against an iPAddress stored in the subjectAltName 1775 extension. In this case, the locally configured IP address is 1776 converted to an octet string as specified in [PKIX], Section 1777 4.2.1.6. A match occurs if this octet string is equal to the 1778 value of iPAddress in the subjectAltName extension. 1780 ###### 1782 A.9. SIP (2010) 1784 At the time of this writing, [SIP-CERTS] specified text regarding 1785 server identity verification in the Session Initiation Protocol 1786 (SIP). However, that specification has not yet been approved by the 1787 IESG and text cannot be considered final. 1789 The relevant text follows. 1791 ###### 1793 7.2. Comparing SIP Identities 1795 When an implementation (either client or server) compares two values 1796 as SIP domain identities: 1797 Implementations MUST compare only the DNS name component of each 1798 SIP domain identifier; an implementation MUST NOT use any scheme 1799 or parameters in the comparison. 1800 Implementations MUST compare the values as DNS names, which means 1801 that the comparison is case insensitive as specified by 1802 [DNS-CASE]. Implementations MUST handle Internationalized Domain 1803 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 1804 Implementations MUST match the values in their entirety: 1805 Implementations MUST NOT match suffixes. For example, 1806 "foo.example.com" does not match "example.com". 1808 Implemenations MUST NOT match any form of wildcard, such as a 1809 leading "." or "*." with any other DNS label or sequence of 1810 labels. For example, "*.example.com" matches only 1811 "*.example.com" but not "foo.example.com". Similarly, 1812 ".example.com" matches only ".example.com", and does not match 1813 "foo.example.com." 1814 [HTTP-TLS] allows the dNSName component to contain a 1815 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 1816 disallowing this explicitly, leaves the interpretation of 1817 wildcards to the individual specification. [SIP] does not 1818 provide any guidelines on the presence of wildcards in 1819 certificates. Through the rule above, this document 1820 prohibits such wildcards in certificates for SIP domains. 1822 ###### 1824 A.10. GIST (2010) 1826 In 2010, [GIST] specified the following text regarding server 1827 identity verification in the General Internet Signalling Transport: 1829 ###### 1831 5.7.3.1. Identity Checking in TLS 1833 After TLS authentication, a node MUST check the identity presented by 1834 the peer in order to avoid man-in-the-middle attacks, and verify that 1835 the peer is authorised to take part in signalling at the GIST layer. 1836 The authorisation check is carried out by comparing the presented 1837 identity with each Authorised Peer Database (APD) entry in turn, as 1838 discussed in Section 4.4.2. This section defines the identity 1839 comparison algorithm for a single APD entry. 1841 For TLS authentication with X.509 certificates, an identity from the 1842 DNS namespace MUST be checked against each subjectAltName extension 1843 of type dNSName present in the certificate. If no such extension is 1844 present, then the identity MUST be compared to the (most specific) 1845 Common Name in the Subject field of the certificate. When matching 1846 DNS names against dNSName or Common Name fields, matching is case- 1847 insensitive. Also, a "*" wildcard character MAY be used as the left- 1848 most name component in the certificate or identity in the APD. For 1849 example, *.example.com in the APD would match certificates for 1850 a.example.com, foo.example.com, *.example.com, etc., but would not 1851 match example.com. Similarly, a certificate for *.example.com would 1852 be valid for APD identities of a.example.com, foo.example.com, 1853 *.example.com, etc., but not example.com. 1855 Additionally, a node MUST verify the binding between the identity of 1856 the peer to which it connects and the public key presented by that 1857 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 1858 for general certificate validation, but MAY supplement that algorithm 1859 with other validation methods that achieve equivalent levels of 1860 verification (such as comparing the server certificate against a 1861 local store of already-verified certificates and identity bindings). 1863 For TLS authentication with pre-shared keys, the identity in the 1864 psk_identity_hint (for the server identity, i.e. the Responding node) 1865 or psk_identity (for the client identity, i.e. the Querying node) 1866 MUST be compared to the identities in the APD. 1868 ###### 1870 Authors' Addresses 1872 Peter Saint-Andre 1873 Cisco 1874 1899 Wyknoop Street, Suite 600 1875 Denver, CO 80202 1876 USA 1878 Phone: +1-303-308-3282 1879 Email: psaintan@cisco.com 1881 Jeff Hodges 1882 PayPal 1883 2211 North First Street 1884 San Jose, California 95131 1885 US 1887 Email: Jeff.Hodges@PayPal.com