idnits 2.17.00 (12 Aug 2021) /tmp/idnits62664/draft-saintandre-tls-server-id-check-13.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == 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 date (January 5, 2011) is 4153 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: Proposed Standard ---------------------------------------------------------------------------- (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-daboo-srv-email has been published as RFC 6186 -- 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 5953 (ref. 'SNMP-TLS') (Obsoleted by RFC 6353) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-tls-rfc4366-bis has been published as RFC 6066 == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP-OLD') (Obsoleted by RFC 6120) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 16 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: Standards Track J. Hodges 5 Expires: July 9, 2011 PayPal 6 January 5, 2011 8 Representation and Verification of Domain-Based Application Service 9 Identity within Internet Public Key Infrastructure Using X.509 (PKIX) 10 Certificates in the Context of Transport Layer Security (TLS) 11 draft-saintandre-tls-server-id-check-13 13 Abstract 15 Many application technologies enable secure communication between two 16 entities by means of Internet Public Key Infrastructure Using X.509 17 (PKIX) certificates in the context of Transport Layer Security (TLS). 18 This document specifies procedures for representing and verifying the 19 identity of application services in such interactions. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 9, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.3. How to Read This Document . . . . . . . . . . . . . . . . 5 59 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 60 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 6 61 1.6. Generalization from Current Technologies . . . . . . . . . 6 62 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7 65 1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 66 2. Naming of Application Services . . . . . . . . . . . . . . . . 13 67 2.1. Naming Application Services . . . . . . . . . . . . . . . 14 68 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 69 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 16 70 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 71 3. Designing Application Protocols . . . . . . . . . . . . . . . 18 72 4. Representing Server Identity . . . . . . . . . . . . . . . . . 19 73 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 76 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 22 77 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 6.2. Constructing a List of Reference Identifiers . . . . . . . 22 79 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 80 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 81 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 82 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26 83 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 84 6.4.2. Checking of Internationalized Domain Names . . . . . . 27 85 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 86 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 87 6.5. Matching the Application Type Portion . . . . . . . . . . 28 88 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 28 89 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 90 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 92 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 93 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 29 94 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 29 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 96 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 97 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 30 98 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 99 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 101 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 106 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 39 107 Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 41 108 B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 41 109 B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 42 110 B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 43 111 B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 46 112 B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48 113 B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49 114 B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50 115 B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 51 116 B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 52 117 B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 53 118 B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 54 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 121 1. Introduction 123 1.1. Motivation 125 The visible face of the Internet largely consists of services that 126 employ a client-server architecture in which an interactive or 127 automated client communicates with an application service in order to 128 retrieve or upload information, communicate with other entities, or 129 access a broader network of services. When a client communicates 130 with an application service using Transport Layer Security [TLS] or 131 Datagram Transport Layer Security [DTLS], it references some notion 132 of the server's identity (e.g., "the website at example.com") while 133 attempting to establish secure communication. Likewise, during TLS 134 negotiation the server presents its notion of the service's identity 135 in the form of a public-key certificate that was issued by a 136 certification authority (CA) in the context of the Internet Public 137 Key Infrastructure using X.509 [PKIX]. Informally, we can think of 138 these identities as the client's "reference identity" and the 139 server's "presented identity" (these rough ideas are defined more 140 precisely later in this document through the concept of particular 141 identifiers). In general, a client needs to verify that the server's 142 presented identity matches its reference identity so it can 143 authenticate the communication. 145 Many application technologies adhere to the pattern just outlined. 146 Such protocols have traditionally specified their own rules for 147 representing and verifying application service identity. 148 Unfortunately, this divergence of approaches has caused some 149 confusion among certification authorities, application developers, 150 and protocol designers. 152 Therefore, to codify secure procedures for the implementation and 153 deployment of PKIX-based authentication, this document specifies 154 recommended procedures for representing and verifying application 155 service identity in certificates intended for use in application 156 protocols employing TLS. 158 1.2. Audience 160 The primary audience for this document consists of application 161 protocol designers, who can reference this document instead of 162 defining their own rules for the representation and verification of 163 application service identity. Secondarily, the audience consists of 164 certification authorities, service providers, and client developers 165 from technology communities that might re-use the recommendations in 166 this document when defining certificate issuance policies, generating 167 certificate signing requests, or writing software algorithms for 168 identity matching. 170 1.3. How to Read This Document 172 This document is longer than the authors would have liked because it 173 was necessary to carefully define terminology, explain the underlying 174 concepts, define the scope, and specify recommended behavior for both 175 certification authorities and application software implementations. 176 The following sections are of special interest to various audiences: 178 o Protocol designers might want to first read the checklist in 179 Section 3. 181 o Certification authorities might want to first read the 182 recommendations for representation of server identity in 183 Section 4. 185 o Service providers might want to first read the recommendations for 186 requesting of server certificates in Section 5. 187 o Software implementors might want to first read the recommendations 188 for verification of server identity in Section 6. 190 The sections on terminology (Section 1.8), naming of application 191 services (Section 2), document scope (Section 1.7), and the like 192 provide useful background information regarding the recommendations 193 and guidelines that are contained in the above-referenced sections, 194 but are not absolutely necessary for a first reading of this 195 document. 197 1.4. Applicability 199 This document does not supersede the rules for certificate issuance 200 or validation provided in [PKIX]. Therefore, [PKIX] is authoritative 201 on any point that might also be discussed in this document. 202 Furthermore, [PKIX] also governs any certificate-related topic on 203 which this document is silent, including but not limited to 204 certificate syntax, certificate extensions such as name constraints 205 and extended key usage, and handling of certification paths. 207 This document addresses only name forms in the leaf "end entity" 208 server certificate, not any name forms in the chain of certificates 209 used to validate the server certificate. Therefore, in order to 210 ensure proper authentication, application clients need to verify the 211 entire certification path per [PKIX]. 213 This document also does not supersede the rules for verifying service 214 identity provided in specifications for existing application 215 protocols published prior to this document, such as those excerpted 216 under Appendix B. However, the procedures described here can be 217 referenced by future specifications, including updates to 218 specifications for existing application protocols if the relevant 219 technology communities agree to do so. 221 1.5. Overview of Recommendations 223 To orient the reader, this section provides an informational overview 224 of the recommendations contained in this document. 226 For the primary audience of application protocol designers, this 227 document provides recommended procedures for the representation and 228 verification of application service identity within PKIX certificates 229 used in the context of TLS. 231 For the secondary audiences, in essence this document encourages 232 certification authorities, application service providers, and 233 application client developers to coalesce on the following practices: 235 o Move away from including and checking strings that look like 236 domain names in the subject's Common Name. 238 o Move toward including and checking DNS domain names via the 239 subjectAlternativeName extension designed for that purpose: 240 dNSName. 242 o Move toward including and checking even more specific 243 subjectAlternativeName extensions where appropriate for the using 244 protocol (e.g., uniformResourceIdentifier and the otherName form 245 SRVName). 247 o Move away from the issuance of so-called wildcard certificates 248 (e.g., a certificate containing an identifier for 249 "*.example.com"). 251 These suggestions are not entirely consistent with all practices that 252 are currently followed by certification authorities, client 253 developers, and service providers. However, they reflect the best 254 aspects of current practices and are expected to become more widely 255 adopted in the coming years. 257 1.6. Generalization from Current Technologies 259 This document attempts to generalize best practices from the many 260 application technologies that currently use PKIX certificates with 261 TLS. Such technologies include, but are not limited to: 263 o The Internet Message Access Protocol [IMAP] and the Post Office 264 Protocol [POP3], for which see also [USINGTLS] 266 o The Hypertext Transfer Protocol [HTTP], for which see also 267 [HTTP-TLS] 269 o The Lightweight Directory Access Protocol [LDAP], for which see 270 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 272 o The Simple Mail Transfer Protocol [SMTP], for which see also 273 [SMTP-AUTH] and [SMTP-TLS] 275 o The Extensible Messaging and Presence Protocol [XMPP], for which 276 see also [XMPP-OLD] 278 o The Network News Transfer Protocol [NNTP], for which see also 279 [NNTP-TLS] 281 o The NETCONF Configuration Protocol [NETCONF], for which see also 282 [NETCONF-SSH] and [NETCONF-TLS] 284 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] and 285 [SYSLOG-DTLS] 287 o The Session Initiation Protocol [SIP], for which see also 288 [SIP-CERTS] 290 o The Simple Network Management Protocol [SNMP], for which see also 291 [SNMP-TLS] 293 o The General Internet Signalling Transport [GIST] 295 However, as noted, this document does not supersede the rules for 296 verifying service identity provided in specifications for those 297 application protocols. 299 1.7. Scope 301 1.7.1. In Scope 303 This document applies only to service identities associated with 304 fully-qualified DNS domain names, only to TLS and DTLS (or the older 305 Secure Sockets Layer (SSL) technology), and only to PKIX-based 306 systems. As a result, the scenarios described in the following 307 section are out of scope for this specification (although they might 308 be addressed by future specifications). 310 1.7.2. Out of Scope 312 The following topics are out of scope for this specification: 314 o Client or end-user identities. 316 Certificates representing client or end-user identities (e.g., the 317 rfc822Name identifier) can be used for mutual authentication 318 between a client and server or between two clients, thus enabling 319 stronger client-server security or end-to-end security. However, 320 certification authorities, application developers, and service 321 operators have less experience with client certificates than with 322 server certificates, thus giving us fewer models from which to 323 generalize and a less solid basis for defining best practices. 325 o Identifiers other than fully-qualified DNS domain names. 327 Some certification authorities issue server certificates based on 328 IP addresses, but preliminary evidence indicates that such 329 certificates are a very small percentage (less than 1%) of issued 330 certificates. Furthermore, IP addresses are not necessarily 331 reliable identifiers for application services because of the 332 existence of private internets [PRIVATE], host mobility, multiple 333 interfaces on a given host, Network Address Translators (NATs) 334 resulting in different addresses for a host from different 335 locations on the network, the practice of grouping many hosts 336 together behind a single IP address, etc. Most fundamentally, 337 most users find DNS domain names much easier to work with than IP 338 addresses, which is why the domain name system was designed in the 339 first place. We prefer to define best practices for the much more 340 common use case and not to complicate the rules in this 341 specification. 343 Furthermore, we focus here on application service identities, not 344 specific resources located at such services. Therefore this 345 document discusses Uniform Resource Identifiers [URI] only as a 346 way to communicate a DNS domain name (via the URI "host" component 347 or its equivalent), not as a way to communicate other aspects of a 348 service such as a specific resource (via the URI "path" component) 349 or parameters (via the URI "query" component). 351 We also do not discuss attributes unrelated to DNS domain names, 352 such as those defined in [X.520] and other such specifications 353 (e.g., organizational attributes, geographical attributes, company 354 logos, and the like). 356 o Security protocols other than [TLS], [DTLS], or the older Secure 357 Sockets Layer (SSL) technology. 359 Although other secure, lower-layer protocols exist and even employ 360 PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases 361 can differ from those of TLS-based and DTLS-based application 362 technologies. Furthermore, application technologies have less 363 experience with IPsec than with TLS, thus making it more difficult 364 to gather feedback on proposed best practices. 366 o Keys or certificates employed outside the context of PKIX-based 367 systems. 369 Some deployed application technologies use a web of trust model 370 based on or similar to OpenPGP [OPENPGP], or use self-signed 371 certificates, or are deployed on networks that are not directly 372 connected to the public Internet and therefore cannot depend on 373 Certificate Revocation Lists (CRLs) or the Online Certificate 374 Status Protocol [OCSP] to check CA-issued certificates. However, 375 the method for binding a public key to an identifier in OpenPGP 376 differs essentially from the method in X.509, the data in self- 377 signed certificates has not been certified by a third party in any 378 way, and checking of CA-issued certificates via CRLs or OSCP is 379 critically important to maintaining the security of PKIX-based 380 systems. Attempting to define best practices for such 381 technologies would unduly complicate the rules defined in this 382 specification. 384 o Certification authority policies, such as: 386 * What types or "classes" of certificates to issue and whether to 387 apply different policies for them (e.g., allow the wildcard 388 character in certificates issued to individuals who have 389 provided proof of identity but do not allow the wildcard 390 character in "Extended Validation" certificates [EV-CERTS]). 392 * Whether to issue certificates based on IP addresses (or some 393 other form, such as relative domain names) in addition to 394 fully-qualified DNS domain names. 396 * Which identifiers to include (e.g., whether to include SRV-IDs 397 or URI-IDs as defined in the body of this specification). 399 * How to certify or validate fully-qualified DNS domain names and 400 application service types. 402 * How to certify or validate other kinds of information that 403 might be included in a certificate (e.g., organization name). 405 o Resolution of DNS domain names. 407 Although the process whereby a client resolves the DNS domain name 408 of an application service can involve several steps (e.g., this is 409 true of resolutions that depend on DNS SRV resource records, 410 Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and 411 related technologies such as [S-NAPTR]), for our purposes we care 412 only about the fact that the client needs to verify the identity 413 of the entity with which it communicates as a result of the 414 resolution process. Thus the resolution process itself is out of 415 scope for this specification. 417 o User interface issues. 419 In general, such issues are properly the responsibility of client 420 software developers and standards development organizations 421 dedicated to particular application technologies (see for example 422 [WSC-UI]). 424 1.8. Terminology 426 Because many concepts related to "identity" are often too vague to be 427 actionable in application protocols, we define a set of more concrete 428 terms for use in this specification. 430 application service: A service on the Internet that enables 431 interactive and automated clients to connect for the purpose of 432 retrieving or uploading information, communicating with other 433 entities, or connecting to a broader network of services. 435 application service provider: An organization or individual that 436 hosts or deploys an application service. 438 attribute-type-and-value pair: A colloquial name for the ASN.1-based 439 construction comprising a Relative Distinguished Name (RDN), which 440 itself is a building-block component of Distinguished Names. See 441 Section 2 of [LDAP-DN]. 443 automated client: A software agent or device that is not directly 444 controlled by a human user. 446 delegated domain: A domain name or host name that is explicitly 447 configured for communicating with the source domain, by either (a) 448 the human user controlling an interactive client or (b) a trusted 449 administrator. In case (a), one example of delegation is an 450 account setup that specifies the domain name of a particular host 451 to be used for retrieving information or connecting to a network, 452 which might be different from the server portion of the user's 453 account name (e.g., a server at mailhost.example.com for 454 connecting to an IMAP server hosting an email address of 455 juliet@example.com). In case (b), one example of delegation is an 456 admin-configured host-to-address/address-to-host lookup table. 458 derived domain: A domain name or host name that a client has derived 459 from the source domain in an automated fashion (e.g., by means of 460 a [DNS-SRV] lookup). 462 identifier: A particular instance of an identifier type that is 463 either presented by a server in a certificate or referenced by a 464 client for matching purposes. 466 identifier type: A formally defined category of identifier that can 467 be included in a certificate and therefore that can also be used 468 for matching purposes. For conciseness and convenience, we define 469 the following identifier types of interest, which are based on 470 those found in the PKIX specification [PKIX] and various PKIX 471 extensions. 473 * CN-ID = a Relative Distinguished Name (RDN) in the certificate 474 subject field that contains one and only one attribute-type- 475 and-value pair of type Common Name (CN), where the value 476 matches the overall form of a domain name (informally, dot- 477 separated letter-digit-hyphen labels); see [PKIX] and also 478 [LDAP-SCHEMA] 480 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 482 * SRV-ID = a subjectAltName entry of type otherName whose name 483 form is SRVName; see [SRVNAME] 485 * URI-ID = a subjectAltName entry of type 486 uniformResourceIdentifier whose value includes both (i) a 487 "scheme" and (ii) a "host" component (or its equivalent) that 488 matches the "reg-name" rule (where the quoted terms represent 489 the associated [ABNF] productions from [URI]); see [PKIX] and 490 [URI] 492 interactive client: A software agent or device that is directly 493 controlled by a human user. (Other specifications related to 494 security and application protocols, such as [WSC-UI], often refer 495 to this entity as a "user agent". 497 pinning: The act of establishing a cached name association between 498 the application service's certificate and one of the client's 499 reference identifiers, despite the fact that none of the presented 500 identifiers matches the given reference identifier. Pinning is 501 accomplished by allowing a human user to positively accept the 502 mismatch during an attempt to communicate with the application 503 service. Once a cached name association is established, the 504 certificate is said to be pinned to the reference identifier and 505 in future communication attempts the client simply verifies that 506 the service's presented certificate matches the pinned 507 certificate, as described under Section 6.6.2. (A similar 508 definition of "pinning" is provided in [WSC-UI].) 510 PKIX: PKIX is a short name for the Internet Public Key 511 Infrastructure using X.509 defined in RFC 5280 [PKIX], which 512 comprises a profile of the X.509v3 certificate specifications and 513 X.509v2 certificate revocation list (CRL) specifications for use 514 in the Internet. 516 PKIX-based system: A software implementation or deployed service 517 that makes use of X.509v3 certificates and X.509v2 certificate 518 revocation lists (CRLs). 520 PKIX certificate: An X.509v3 certificate generated and employed in 521 the context of PKIX. 523 presented identifier: An identifier that is presented by a server to 524 a client within a PKIX certificate when the client attempts to 525 establish secure communication with the server; the certificate 526 can include one or more presented identifiers of different types, 527 and if the server hosts more than one domain then the certificate 528 might present distinct identifiers for each domain. 530 reference identifier: An identifier, constructed from a source 531 domain and optionally a service type, used by the client for 532 matching purposes when examining presented identifiers. 534 service type: A formal identifier for the application protocol used 535 to provide a particular kind of service at a domain; the service 536 type typically takes the form of a Uniform Resource Identifier 537 scheme [URI] or a DNS SRV Service [DNS-SRV]. 539 source domain: The fully-qualified DNS domain name that a client 540 expects an application service to present in the certificate 541 (e.g., "www.example.com"), typically input by a human user, 542 configured into a client, or provided by reference such as in a 543 hyperlink. The combination of a source domain and, optionally, a 544 service type enables a client to construct one or more reference 545 identifiers. 547 subjectAltName entry: An identifier placed in a subjectAltName 548 extension. 550 subjectAltName extension: A standard PKIX certificate extension 551 [PKIX] enabling identifiers of various types to be bound to the 552 certificate subject -- in addition to, or in place of, identifiers 553 that may be embedded within or provided as a certificate's subject 554 field. 556 subject field: The subject field of a PKIX certificate identifies 557 the entity associated with the public key stored in the subject 558 public key field (see Section 4.1.2.6 of [PKIX]). 560 subject name: In an overall sense, a subject's name(s) can be 561 represented by or in the subject field, the subjectAltName 562 extension, or both (see [PKIX] for details). More specifically, 563 the term often refers to the name of a PKIX certificate's subject, 564 encoded as the X.501 type Name and conveyed in a certificate's 565 subject field (see Section 4.1.2.6 of [PKIX]). 567 TLS client: An entity that assumes the role of a client in a 568 Transport Layer Security [TLS] negotiation; in this specification 569 we generally assume that the TLS client is an (interactive or 570 automated) application client, however in application protocols 571 that enable server-to-server communication the TLS client could be 572 a peer application service. 574 TLS server: An entity that assumes the role of a server in a 575 Transport Layer Security [TLS] negotiation; in this specfication 576 we assume that the TLS server is an application service. 578 Most security-related terms in this document are to be understood in 579 the sense defined in [SECTERMS]; such terms include, but are not 580 limited to, "attack", "authentication", "authorization", 581 "certification authority", "certification path", "certificate", 582 "credential", "identity", "self-signed certificate", "trust", "trust 583 anchor", "trust chain", "validate", and "verify". 585 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 586 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 587 "OPTIONAL" in this document are to be interpreted as described in RFC 588 2119 [KEYWORDS]. 590 2. Naming of Application Services 592 This section discusses naming of application services on the 593 Internet, followed by a brief tutorial about subject naming in PKIX. 595 2.1. Naming Application Services 597 This specification assumes that the name of an application service is 598 based on a DNS domain name (e.g., "example.com") -- supplemented in 599 some circumstances by a service type (e.g., "the IMAP server at 600 example.com"). 602 From the perspective of the application client or user, some names 603 are direct because they are provided directly by a human user (e.g., 604 via runtime input, prior configuration, or explicit acceptance of a 605 client communication attempt) whereas other names are indirect 606 because they are automatically resolved by the client based on user 607 input (e.g., a target name resolved from a source name using DNS SRV 608 or NAPTR records). This dimension matters most for certificate 609 consumption, specifically verification as discussed in this document. 611 From the perspective of the application service, some names are 612 unrestricted because they can be used in any type of service (e.g., a 613 certificate might be re-used for both the HTTP service and the IMAP 614 service at example.com) whereas other names are restricted because 615 they can be used in only one type of service (e.g., a special-purpose 616 certificate that can be used only for an IMAP service). This 617 dimension matters most for certificate issuance. 619 Therefore we can categorize the identifier types of interest as 620 follows: 622 o A CN-ID is direct and unrestricted. 624 o A DNS-ID is direct and unrestricted. 626 o An SRV-ID can be either direct or (more typically) indirect, and 627 is restricted. 629 o A URI-ID is direct and restricted. 631 We summarize this taxonomy in the following table. 633 +-----------+-----------+---------------+ 634 | | Direct | Restricted | 635 +-----------+-----------+---------------+ 636 | CN-ID | Yes | No | 637 +-----------+-----------+---------------+ 638 | DNS-ID | Yes | No | 639 +-----------+-----------+---------------+ 640 | SRV-ID | Either | Yes | 641 +-----------+-----------+---------------+ 642 | URI-ID | Yes | Yes | 643 +-----------+-----------+---------------+ 645 When implementing software, deploying services, and issuing 646 certificates for secure PKIX-based authentication, it is important to 647 keep these distinctions in mind. In particular, best practices 648 differ somewhat for application server implementations, application 649 client implementations, application service providers, and 650 certification authorities. Ideally, protocol specifications that 651 reference this document will specify which identifiers are mandatory- 652 to-implement by servers and clients, which identifiers ought to be 653 supported by certificate issuers, and which identifiers ought to be 654 requested by application service providers. Because these 655 requirements differ across applications, it is impossible to 656 categorically stipulate universal rules (e.g., that all software 657 implementations, service providers, and certification authorities for 658 all application protocols need to use or support DNS-IDs as a 659 baseline for the purpose of interoperability). 661 However, it is preferable that each application protocol will at 662 least define a baseline that applies to the community of software 663 developers, application service providers, and CAs actively using or 664 supporting that technology (one such community, the CA/Browser Forum, 665 has codified such a baseline for "Extended Validation Certificates" 666 in [EV-CERTS]). 668 2.2. DNS Domain Names 670 For the purposes of this specification, the name of an application 671 service is (or is based on) a DNS domain name that conforms to one of 672 the following forms: 674 1. A "traditional domain name", i.e., a fully-qualified DNS domain 675 name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 676 labels" as described in [IDNA-DEFS]. Informally, such labels are 677 constrained to [US-ASCII] letters, digits, and the hyphen, with 678 the hyphen prohibited in the first character position. 679 Additional qualifications apply (please refer to the above- 680 referenced specifications for details) but they are not relevant 681 to this specification. 683 2. An "internationalized domain name", i.e., a DNS domain name that 684 conforms to the overall form of a domain name (informally, dot- 685 separated letter-digit-hyphen labels) but includes at least one 686 label containing appropriately encoded Unicode code points 687 outside the traditional US-ASCII range. That is, it contains at 688 least one U-label or A-label, but otherwise may contain any 689 mixture of NR-LDH labels, A-labels, or U-labels, as described in 690 [IDNA-DEFS] and the associated documents). 692 2.3. Subject Naming in PKIX Certificates 694 In theory, the Internet Public Key Infrastructure using X.509 [PKIX] 695 employs the global directory service model defined in [X.500] and 696 [X.501]. Under that model, information is held in a directory 697 information base (DIB) and entries in the DIB are organized in a 698 hierarchy called the directory information tree (DIT). An object or 699 alias entry in that hierarchy consists of a set of attributes (each 700 of which has a defined type and one or more values) and is uniquely 701 identified by a Distinguished Name (DN). The DN of an entry is 702 constructed by combining the Relative Distinguished Names of its 703 superior entries in the tree (all the way down to the root of the 704 DIT) with one or more specially-nominated attributes of the entry 705 itself (which together comprise the Relative Distinguished Name (RDN) 706 of the entry, so-called because it is relative to the Distinguished 707 Names of the superior entries in the tree). The entry closest to the 708 root is sometimes referred to as the "most significant" entry and the 709 entry farthest from the root is sometimes referred to as the "least 710 significant" entry. An RDN is a set (i.e., an unordered group) of 711 attribute-type-and-value pairs (see also [LDAP-DN]), each of which 712 asserts some attribute about the entry. 714 In practice, the certificates used in [X.509] and [PKIX] borrow key 715 concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify 716 entities, but such certificates are not necessarily part of a global 717 directory information base. Specifically, the subject field of a 718 PKIX certificate is an X.501 type Name that "identifies the entity 719 associated with the public key stored in the subject public key 720 field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly 721 acceptable for the subject field to be empty, as long as the 722 certificate contains a subject alternative name ("subjectAltName") 723 extension that includes at least one subjectAltName entry, because 724 the subjectAltName extension allows various identities to be bound to 725 the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName 726 extension itself is a sequence of typed entries, where each type is a 727 distinct kind of identifier. 729 For our purposes, an application service can be identified by a name 730 or names carried in the subject field (i.e., a CN-ID) and/or in one 731 of the following identifier types within subjectAltName entries: 733 o DNS-ID 734 o SRV-ID 735 o URI-ID 737 Existing certificates often use a CN-ID in the subject field to 738 represent a fully-qualified DNS domain name; for example, consider 739 the following three subject names, where the attribute of type Common 740 Name contains a string whose form matches that of a fully-qualified 741 DNS domain name ("im.example.org", "mail.example.net", and 742 "www.example.com" respectively): 744 CN=im.example.org,O=Example Org,C=GB 746 C=CA,O=Example Internetworking,CN=mail.example.net 748 O=Examples-R-Us,CN=www.example.com,C=US 750 However, the Common Name is not strongly typed because a Common Name 751 might contain a human-friendly string for the service, rather than a 752 string whose form matches that of a fully-qualified DNS domain name 753 (a certificate with such a single Common Name will typically have at 754 least one subjectAltName entry containing the fully-qualified DNS 755 domain name): 757 CN=A Free Chat Service,O=Example Org,C=GB 759 Or, a certificate's subject might contain both a CN-ID as well as 760 another common name attribute containing a human-friendly string: 762 CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB 764 In general, this specification recommends and prefers use of 765 subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the 766 subject field (CN-ID) where possible, as more completely described in 767 the following sections. However, specifications that re-use this one 768 can legitimately encourage continued support for the CN-ID identifier 769 type if they have good reasons to do so, such as backward 770 compatibility with deployed infrastructure (see, for example, 771 [EV-CERTS]). 773 2.3.1. Implementation Notes 775 Confusion sometimes arises from different renderings or encodings of 776 the hierarchical information contained in a certificate. 778 Certificates are binary objects and are encoded using the 779 Distinguished Encoding Rules (DER) specified in [X.690]. However, 780 some implementations generate displayable (a.k.a. printable) 781 renderings of the certificate issuer, subject field, and 782 subjectAltName extension, and these renderings convert the DER- 783 encoded sequences into a "string representation" before being 784 displayed. Because a certificate subject field (of type Name 785 [X.509], the same as for a Distinguished Name (DN) [X.501]) is an 786 ordered sequence, order is typically preserved in subject string 787 representations, although the two most prevalent subject (and DN) 788 string representations differ in employing left-to-right vs. right- 789 to-left ordering. However, because a Relative Distinguished Name 790 (RDN) is an unordered group of attribute-type-and-value pairs, the 791 string representation of an RDN can differ from the canonical DER 792 encoding (and the order of attribute-type-and-value pairs can differ 793 in the RDN string representations or display orders provided by 794 various implementations). Furthermore, various specifications refer 795 to the order of RDNs in DNs or certificate subject fields using 796 terminology that is implicitly related to an information hierarchy 797 (which may or may not actually exist), such as "most specific" vs. 798 "least specific", "left-most" vs. "right-most", "first" vs. "last", 799 or "most significant" vs. "least significant" (see for example 800 [LDAP-DN]). 802 To reduce confusion, in this specification we avoid such terms and 803 instead use the terms provided under Section 1.8; in particular, we 804 do not use the term "(most specific) Common Name field in the subject 805 field" from [HTTP-TLS] and instead state that a CN-ID is a Relative 806 Distinguished Name (RDN) in the certificate subject containing one 807 and only one attribute-type-and-value pair of type Common Name (thus 808 removing the possibility that an RDN might contain multiple AVAs of 809 type CN, one of which could be considered "most specific"). 811 Finally, although theoretically some consider the order of RDNs 812 within a subject field to have meaning, in practice that rule is 813 often not observed. An AVA of type CN is considered to be valid at 814 any position within the subject field. 816 3. Designing Application Protocols 818 This section provides guidelines for designers of application 819 protocols, in the form of a checklist to follow when re-using the 820 recommendations provided in this document. 822 o Does your technology use DNS SRV records to resolve the DNS domain 823 names of application services? If so, consider recommending or 824 requiring support for the SRV-ID identifier type in PKIX 825 certificates issued and used in your technology community. (Note 826 that many application existing technologies use DNS SRV records to 827 resolve the DNS domain names of application services, but do not 828 rely on representations of those records in PKIX certificates by 829 means of SRV-IDs as defined in [SRVNAME].) 831 o Does your technology use URIs to identify application services? 832 If so, consider recommending or requiring support for the URI-ID 833 identifier type. (Note that many existing application 834 technologies use URIs to identify application services, but do not 835 rely on representation of those URIs in PKIX certificates by means 836 of URI-IDs.) 838 o Does your technology need to use DNS domain names in the Common 839 Name of certificates for the sake of backward compatibility? If 840 so, consider recommending support for the CN-ID identifier type as 841 a fallback. 843 o Does your technology need to allow the wildcard character in DNS 844 domain names? If so, consider recommending support for wildcard 845 certificates, and specify exactly where the wildcard character is 846 allowed to occur (e.g., only the complete left-most label of a DNS 847 domain name). 849 Sample text is provided under Appendix A. 851 4. Representing Server Identity 853 This section provides rules and guidelines for issuers of 854 certificates. 856 4.1. Rules 858 When a certification authority issues a certificate based on the 859 fully-qualified DNS domain name at which the application service 860 provider will provide the relevant application, the following rules 861 apply to the representation of application service identities. The 862 reader needs to be aware that some of these rules are cumulative and 863 can interact in important ways that are illustrated later in this 864 document. 866 1. The certificate SHOULD include a "DNS-ID" if possible as a 867 baseline for interoperability. 869 2. If the service using the certificate deploys a technology for 870 which the relevant specification stipulates that certificates 871 ought to include identifiers of type SRV-ID (e.g., this is true 872 of [XMPP]), then the certificate SHOULD include an SRV-ID. 874 3. If the service using the certificate deploys a technology for 875 which the relevant specification stipulates that certificates 876 ought to include identifiers of type URI-ID (e.g., this is true 877 of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] 878 since [HTTP-TLS] does not describe usage of a URI-ID for HTTP 879 services), then the certificate SHOULD include a URI-ID. The 880 scheme SHALL be that of the protocol associated with the service 881 type and the "host" component (or its equivalent) SHALL be the 882 fully-qualified DNS domain name of the service. A specification 883 that re-uses this one MUST specify which URI schemes are to be 884 considered acceptable in URI-IDs contained in PKIX certificates 885 used for the application protocol (e.g., "sip" but not "sips" or 886 "tel" for SIP as described in [SIP-SIPS], or perhaps http and 887 https for HTTP as might be described in a future specification). 889 4. The certificate MAY include other application-specific 890 identifiers for types that were defined before publication of 891 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names 892 or URI schemes do not exist; however, such application-specific 893 identifiers are not applicable to all application technologies 894 and therefore are out of scope for this specification. 896 5. Even though many deployed clients still check for the CN-ID 897 within the certificate subject field, certification authorities 898 are encouraged to migrate away from issuing certificates that 899 represent the server's fully-qualified DNS domain name in a 900 CN-ID. Therefore the certificate SHOULD NOT include a CN-ID 901 unless the certification authority issues the certificate in 902 accordance with a specification that re-uses this one and that 903 explicitly encourages continued support for the CN-ID identifier 904 type in the context of a given application technology. 906 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or 907 URI-ID but SHOULD NOT contain more than one CN-ID, as further 908 explained under Section 7.4. 910 7. Unless a specification that re-uses this one allows continued 911 support for the wildcard character '*', the DNS domain name 912 portion of a presented identifier SHOULD NOT contain the wildcard 913 character, whether as the complete left-most label within the 914 identifier (following the definition of "label" from [DNS], e.g., 915 "*.example.com") or as a fragment thereof (e.g., *oo.example.com, 916 f*o.example.com, or foo*.example.com). A more detailed 917 discussion of so-called "wildcard certificates" is provided under 918 Section 7.2. 920 4.2. Examples 922 Consider a simple website at "www.example.com", which is not 923 discoverable via DNS SRV lookups. Because HTTP does not specify the 924 use of URIs in server certificates, a certificate for this service 925 might include only a DNS-ID of "www.example.com". It might also 926 include a CN-ID of "www.example.com" for backward compatibility with 927 deployed infrastructure. 929 Consider an IMAP-accessible email server at the host 930 "mail.example.net" servicing email addresses of the form 931 "user@example.net" and discoverable via DNS SRV lookups on the 932 application service name of "example.net". A certificate for this 933 service might include SRV-IDs of "_imap.example.net" and 934 "_imaps.example.net" (see [EMAIL-SRV]) along with a DNS-ID of 935 "example.net" and "mail.example.net". It might also include a CN-ID 936 of "example.net" and "mail.example.net" for backward compatibility 937 with deployed infrastructure. 939 Consider a SIP-accessible voice-over-IP (VoIP) server at the host 940 "voice.example.edu" servicing SIP addresses of the form 941 "user@voice.example.edu" and identified by a URI of . A certificate for this service would include a 943 URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along with a 944 DNS-ID of "voice.example.edu". It might also include a CN-ID of 945 "voice.example.edu" for backward compatibility with deployed 946 infrastructure. 948 Consider an XMPP-compatible instant messaging (IM) server at the host 949 "im.example.org" servicing IM addresses of the form 950 "user@im.example.org" and discoverable via DNS SRV lookups on the 951 "im.example.org" domain. A certificate for this service might 952 include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- 953 server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", 954 and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). It 955 might also include a CN-ID of "im.example.org" for backward 956 compatibility with deployed infrastructure. 958 5. Requesting Server Certificates 960 This section provides rules and guidelines for service providers 961 regarding the information to include in certificate signing requests 962 (CSRs). 964 In general, service providers are encouraged to request certificates 965 that include all of the identifier types that are required or 966 recommended for the application service type that will be secured 967 using the certificate to be issued. 969 If the certificate will be used for only a single application service 970 type, then the service provider is encouraged to request a 971 certificate that includes a DNS-ID and, if appropriate for the 972 service type, an SRV-ID or URI-ID that limits the deployment scope of 973 the certificate to only the defined service type. 975 If the certificate will be used for multiple application service 976 types, then the service provider is discouraged from requesting one 977 certificate with multiple kinds of SRV-IDs or URI-IDs identifying 978 each different application service type. Instead, the service 979 provider is encouraged to request either (a) one certificate per 980 service type or (b) a single certificate that contains only an 981 identifier type of DNS-ID representing the DNS domain name(s) for the 982 provided service(s). 984 6. Verifying Service Identity 986 This section provides rules and guidelines for implementers of 987 application client software regarding algorithms for verification of 988 application service identity. 990 6.1. Overview 992 At a high level, the client verifies the application service's 993 identity by performing the actions listed below (which are defined in 994 the following subsections of this document): 996 1. The client constructs a list of acceptable reference identifiers 997 based on the source domain and, optionally, the type of service 998 to which the client is connecting. 1000 2. The server provides its identifiers in the form of a PKIX 1001 certificate. 1003 3. The client checks each of its reference identifiers against the 1004 presented identifiers for the purpose of finding a match. 1006 4. When checking a reference identifier against a presented 1007 identifier, the client matches the source domain of the 1008 identifiers and, optionally, their service type. 1010 Naturally, in addition to checking identifiers, a client might 1011 complete further checks to ensure that the server is authorized to 1012 provide the requested service. However, such checking is not a 1013 matter of verifying the application service identity presented in a 1014 certificate, and therefore methods for doing so (e.g., consulting 1015 local policy information) are out of scope for this document. 1017 6.2. Constructing a List of Reference Identifiers 1019 6.2.1. Rules 1021 The client MUST construct a list of acceptable reference identifiers, 1022 and MUST do so independently of the identifiers presented by the 1023 service. 1025 The inputs used by the client to construct its list of reference 1026 identifiers might be a URI that a user has typed into an interface 1027 (e.g., an HTTPS URL for a web site), configured account information 1028 (e.g., the domain name of a particular host or URI used for 1029 retrieving information or connecting to a network, which might be 1030 different from the DNS domain name portion of a username), a 1031 hyperlink in a web page that triggers a browser to retrieve a media 1032 object or script, or some other combination of information that can 1033 yield a source domain and a service type. 1035 The client might need to extract the source domain and service type 1036 from the input(s) it has received. The extracted data MUST include 1037 only information that can be securely parsed out of the inputs (e.g., 1038 parsing the fully-qualified DNS domain name out of the "host" 1039 component (or its equivalent) of a URI or deriving the service type 1040 from the scheme of a URI) or information that is derived in a manner 1041 not subject to subversion by network attackers (e.g., pulling the 1042 data from a delegated domain that is explicitly established via 1043 client or system configuration, resolving the data via [DNSSEC], or 1044 obtaining the data from a third-party domain mapping service in which 1045 a human user has explicitly placed trust and with which the client 1046 communicates over a connection or association that provides both 1047 mutual authentication and integrity checking). These considerations 1048 apply only to extraction of the source domain from the inputs; 1049 naturally, if the inputs themselves are invalid or corrupt (e.g., a 1050 user has clicked a link provided by a malicious entity in a phishing 1051 attack), then the client might end up communicating with an 1052 unexpected application service. 1054 Example: Given an input URI of , a client 1055 would derive the service type "sip" from the "scheme" and parse 1056 the domain name "example.net" from the "host" component (or its 1057 equivalent). 1059 Each reference identifier in the list SHOULD be based on the source 1060 domain and SHOULD NOT be based on a derived domain (e.g., a host name 1061 or domain name discovered through DNS resolution of the source 1062 domain). This rule is important because only a match between the 1063 user inputs and a presented identifier enables the client to be sure 1064 that the certificate can legitimately be used to secure the client's 1065 communication with the server. There is only one scenario in which 1066 it is acceptable for an interactive client to override the 1067 recommendation in this rule and therefore communicate with a domain 1068 name other than the source domain: because a human user has "pinned" 1069 the application service's certificate to the alternative domain name 1070 as further discussed under Section 6.6.4 and Section 7.1. In this 1071 case, the inputs used by the client to construct its list of 1072 reference identifiers might include more than one fully-qualified DNS 1073 domain name, i.e., both (a) the source domain and (b) the alternative 1074 domain contained in the pinned certificate. 1076 Using the combination of fully-qualified DNS domain name(s) and 1077 service type, the client constructs a list of reference identifiers 1078 in accordance with the following rules: 1080 o The list MUST include a DNS-ID. A reference identifier of type 1081 DNS-ID can be directly constructed from a fully-qualified DNS 1082 domain name that is (a) contained in or securely derived from the 1083 inputs (i.e., the source domain), or (b) explicitly associated 1084 with the source domain by means of user configuration (i.e., a 1085 derived domain). 1087 o If a server for the service type is typically discovered by means 1088 of DNS SRV records, then the list SHOULD include an SRV-ID. 1090 o If a server for the service type is typically associated with a 1091 URI for security purposes (i.e., a formal protocol document 1092 specifies the use of URIs in server certificates), then the list 1093 SHOULD include a URI-ID. 1095 o The list MAY include a CN-ID, mainly for the sake of backward 1096 compatibility with deployed infrastructure. 1098 Implementation Note: It is highly likely that implementers of 1099 client software will need to support CN-IDs for the foreseeable 1100 future, because certificates containing CN-IDs are so widely 1101 deployed. Implementers are advised to monitor the state of the 1102 art with regard to certificate issuance policies and migrate away 1103 from support CN-IDs in the future if possible. 1105 Implementation Note: The client does not need to construct the 1106 foregoing identifiers in the actual formats found in a certificate 1107 (e.g., as ASN.1 types); it only needs to construct the functional 1108 equivalent of such identifiers for matching purposes. 1110 Security Warning: A client MUST NOT construct a reference 1111 identifier corresponding to Relative Distinguished Names (RDNs) 1112 other than those of type Common Name and MUST NOT check for RDNs 1113 other than those of type Common Name in the presented identifiers. 1115 6.2.2. Examples 1117 A web browser that is connecting via HTTPS to the website at 1118 "www.example.com" might have two reference identifiers: a DNS-ID of 1119 "www.example.com" and, as a fallback, a CN-ID of "www.example.com". 1121 A mail user agent that is connecting via IMAP to the email service at 1122 "example.net" (resolved as "mail.example.net") might have two 1123 reference identifiers: an SRV-ID of "_imaps.example.net" (see 1124 [EMAIL-SRV]) and a DNS-ID of "example.net". 1126 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 1127 voice service at "voice.example.edu" might have only one reference 1128 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 1130 An instant messaging (IM) client that is connecting via XMPP to the 1131 IM service at "im.example.org" might have three reference 1132 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), 1133 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of 1134 "im.example.org" (see [XMPP]). 1136 6.3. Preparing to Seek a Match 1138 Once the client has constructed its list of reference identifiers and 1139 has received the server's presented identifiers in the form of a PKIX 1140 certificate, the client checks its reference identifiers against the 1141 presented identifiers for the purpose of finding a match. The search 1142 fails if the client exhausts its list of reference identifiers 1143 without finding a match. The search succeeds if any presented 1144 identifier matches one of the reference identifiers, at which point 1145 the client SHOULD stop the search. 1147 Implementation Note: A client might be configured to perform 1148 multiple searches, i.e., to match more than one reference 1149 identifier; although such behavior is not forbidden by this 1150 specification, rules for matching multiple reference identifiers 1151 are a matter for implementation or future specification. 1153 Security Warning: A client MUST NOT seek a match for a reference 1154 identifier of CN-ID if the presented identifiers include a DNS-ID, 1155 SRV-ID, URI-ID, or any application-specific identifier types 1156 supported by the client. 1158 Before applying the comparison rules provided in the following 1159 sections, the client might need to split the reference identifier 1160 into its DNS domain name portion and its service type portion, as 1161 follows: 1163 o A reference identifier of type DNS-ID does not include a service 1164 type portion and thus can be used directly as the DNS domain name 1165 for comparison purposes. As an example, a DNS-ID of 1166 "www.example.com" would result in a DNS domain name portion of 1167 "www.example.com". 1169 o A reference identifier of type CN-ID also does not include a 1170 service type portion and thus can be used directly as the DNS 1171 domain name for comparison purposes. As previously mentioned, 1172 this document specifies that a CN-ID always contains a string 1173 whose form matches that of a DNS domain name (thus differentiating 1174 a CN-ID from a Common Name containing a human-friendly name). 1176 o For a reference identifier of type SRV-ID, the DNS domain name 1177 portion is the Name and the service type portion is the Service. 1178 As an example, an SRV-ID of "_imaps.example.net" would be split 1179 into a DNS domain name portion of "example.net" and a service type 1180 portion of "imaps" (mapping to an application protocol of IMAP as 1181 explained in [EMAIL-SRV]). 1183 o For a reference identifier of type URI-ID, the DNS domain name 1184 portion is the "reg-name" part of the "host" component (or its 1185 equivalent) and the service type portion is the service type 1186 associated with the scheme name matching the [ABNF] "scheme" rule 1187 from [URI] (not including the ':' separator). As previously 1188 mentioned, this document specifies that a URI-ID always contains a 1189 "host" component (or its equivalent) containing a "reg-name". 1190 (Matching only the "reg-name" rule from [URI] limits verification 1191 to DNS domain names, thereby differentiating a URI-ID from a 1192 uniformResourceIdentifier entry that contains an IP address or a 1193 mere host name, or that does not contain a "host" component at 1194 all.) Furthermore, note that extraction of the "reg-name" might 1195 necessitate normalization of the URI (as explained in [URI]). As 1196 an example, a URI-ID of "sip:voice.example.edu" would be split 1197 into a DNS domain name portion of "voice.example.edu" and a 1198 service type of "sip" (associated with an application protocol of 1199 SIP as explained in [SIP-CERTS]). 1201 Detailed comparison rules for matching the DNS domain name portion 1202 and service type portion of the reference identifier are provided in 1203 the following sections. 1205 6.4. Matching the DNS Domain Name Portion 1207 The client MUST match the DNS domain name portion of a reference 1208 identifier according to the following rules (and SHOULD also check 1209 the service type as described under Section 6.5). The rules differ 1210 depending on whether the domain to be checked is a "traditional 1211 domain name" or an "internationalized domain name" (as defined under 1212 Section 2.2). Furthermore, to meet the needs of clients that support 1213 presented identifiers containing the wildcard character '*', we 1214 define a supplemental rule for so-called "wildcard certificates". 1215 Finally, we also specify the circumstances under which it is 1216 acceptable to check the "CN-ID" identifier type. 1218 6.4.1. Checking of Traditional Domain Names 1220 If the DNS domain name portion of a reference identifier is a 1221 "traditional domain name", then matching of the reference identifier 1222 against the presented identifier is performed by comparing the set of 1223 domain name labels using a case-insensitive ASCII comparison, as 1224 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 1225 to "www.example.com" for comparison purposes). Each label MUST match 1226 in order for the names to be considered to match, except as 1227 supplemented by the rule about checking of wildcard labels 1228 (Section 6.4.3). 1230 6.4.2. Checking of Internationalized Domain Names 1232 If the DNS domain name portion of a reference identifier is an 1233 internationalized domain name, then an implementation MUST convert 1234 any U-labels [IDNA-DEFS] in the domain name to A-labels before 1235 checking the domain name. In accordance with [IDNA-PROTO], A-labels 1236 MUST be compared as case-insensitive ASCII. Each label MUST match in 1237 order for the domain names to be considered to match, except as 1238 supplemented by the rule about checking of wildcard labels 1239 (Section 6.4.3; but see also Section 7.2 regarding wildcards in 1240 internationalized domain names). 1242 6.4.3. Checking of Wildcard Certificates 1244 A client employing this specification's rules MAY match the reference 1245 identifier against a presented identifier whose DNS domain name 1246 portion contains the wildcard character '*' as part or all of a label 1247 (following the definition of "label" from [DNS-CONCEPTS]). 1249 For information regarding the security characteristics of wildcard 1250 certificates, see Section 7.2. 1252 If a client matches the reference identifier against a presented 1253 identifier whose DNS domain name portion contains the wildcard 1254 character '*', the following rules apply: 1256 1. The client SHOULD NOT attempt to match a presented identifier in 1257 which the wildcard character comprises a label other than the 1258 left-most label (e.g., do not match bar.*.example.net). 1260 2. If the wildcard character is the only character of the left-most 1261 label in the presented identifier, the client SHOULD NOT compare 1262 against anything but the left-most label of the reference 1263 identifier (e.g., *.example.com would match foo.example.com but 1264 not bar.foo.example.com or example.com). 1266 3. The client MAY match a presented identifier in which the wildcard 1267 character is not the only character of the label (e.g., 1268 baz*.example.net and *baz.example.net and b*z.example.net would 1269 be taken to match baz1.example.net and foobaz.example.net and 1270 buzz.example.net, respectively). However, the client SHOULD NOT 1271 attempt to match a presented identifier where the wildcard 1272 character is embedded within an NR-LDH label, A-label, or U-label 1273 [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. 1275 6.4.4. Checking of Common Names 1277 As noted, a client MUST NOT seek a match for a reference identifier 1278 of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, 1279 URI-ID, or any application-specific identifier types supported by the 1280 client. 1282 Therefore, if and only if the presented identifiers do not include a 1283 DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types 1284 supported by the client, then the client MAY as a last resort check 1285 for a string whose form matches that of a fully-qualified DNS domain 1286 name in a Common Name field of the subject field (i.e., a CN-ID). If 1287 the client chooses to compare a reference identifier of type CN-ID 1288 against that string, it MUST follow the comparison rules for the DNS 1289 domain name portion of an identifier of type DNS-ID, SRV-ID, or 1290 URI-ID, as described under Section 6.4.1, Section 6.4.2, and 1291 Section 6.4.3. 1293 6.5. Matching the Application Type Portion 1295 When checking identifiers of type SRV-ID and URI-ID, a client SHOULD 1296 also check the service type of the application service with which it 1297 communicates (in addition to checking the domain name as described 1298 above). This is a best practice because typically a client is not 1299 designed to communicate with all kinds of services using all possible 1300 application protocols, but instead is designed to communicate with 1301 one kind of service, such as websites, email services, VoIP services, 1302 or IM services. 1304 The service type is verified by means of an SRV-ID or a URI-ID. 1306 6.5.1. SRV-ID 1308 The service name portion of an SRV-ID (e.g., "imaps") MUST be matched 1309 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 1310 that the "_" character is prepended to the service identifier in DNS 1311 SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to 1312 be included in any comparison. 1314 6.5.2. URI-ID 1316 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1317 a case-insensitive manner, in accordance with [URI]. Note that the 1318 ":" character is a separator between the scheme name and the rest of 1319 the URI, and thus does not need to be included in any comparison. 1321 6.6. Outcome 1323 The outcome of the matching procedure is one of the following cases. 1325 6.6.1. Case #1: Match Found 1327 If the client has found a presented identifier that matches a 1328 reference identifier, then the service identity check has succeeded. 1329 In this case, the client MUST use the matched reference identifier as 1330 the validated identity of the application service. 1332 6.6.2. Case #2: No Match Found, Pinned Certificate 1334 If the client does not find a presented identifier matching any of 1335 the reference identifiers but the client has previously pinned the 1336 application service's certificate to one of the reference identifiers 1337 in the list it constructed for this communication attempt (as 1338 "pinning" is explained under Section 1.8), and the presented 1339 certificate matches the pinned certificate (including the context as 1340 described under Section 7.1), then the service identity check has 1341 succeeded. 1343 6.6.3. Case #3: No Match Found, No Pinned Certificate 1345 If the client does not find a presented identifier matching any of 1346 the reference identifiers and the client has not previously pinned 1347 the certificate to one of the reference identifiers in the list it 1348 constructed for this communication attempt, then the client MUST 1349 proceed as described under Section 6.6.4. 1351 6.6.4. Fallback 1353 If the client is an interactive client that is directly controlled by 1354 a human user, then it SHOULD inform the user of the identity mismatch 1355 and automatically terminate the communication attempt with a bad 1356 certificate error; this behavior is preferable because it prevents 1357 users from inadvertently bypassing security protections in hostile 1358 situations. 1360 Security Warning: Some interactive clients give advanced users the 1361 option of proceeding with acceptance despite the identity 1362 mismatch, thereby "pinning" the certificate to one of the 1363 reference identifiers in the list constructed by the client for 1364 this communication attempt. Although this behavior can be 1365 appropriate in certain specialized circumstances, in general it 1366 ought to be exposed only to advanced users. Even then it needs to 1367 be handled with extreme caution, for example by first encouraging 1368 even an advanced user to terminate the communication attempt and, 1369 if the advanced user chooses to proceed anyway, by forcing the 1370 user to view the entire certification path and only then allowing 1371 the user to pin the certificate (on a temporary or permanent 1372 basis, at the user's option). 1374 Otherwise, if the client is an automated application not directly 1375 controlled by a human user, then it SHOULD terminate the 1376 communication attempt with a bad certificate error and log the error 1377 appropriately. An automated application MAY provide a configuration 1378 setting that disables this behavior, but MUST enable the behavior by 1379 default. 1381 7. Security Considerations 1383 7.1. Pinned Certificates 1385 As defined under Section 1.8, a certificate is said to be "pinned" to 1386 a DNS domain name when a user has explicitly chosen to associate a 1387 service's certificate with that DNS domain name despite the fact that 1388 the certificate contains some other DNS domain name (e.g., the user 1389 has explicitly approved "apps.example.net" as a domain associated 1390 with a source domain of "example.com"). The cached name association 1391 MUST take account of both the certificate presented and the context 1392 in which it was accepted or configured (where the "context" includes 1393 the chain of certificates from the presented certificate to the trust 1394 anchor, the source domain, the service type, the service's derived 1395 domain and port number, and any other relevant information provided 1396 by the user or associated by the client). 1398 7.2. Wildcard Certificates 1400 This document states that the wildcard character '*' SHOULD NOT be 1401 included in presented identifiers but MAY be checked by application 1402 clients (mainly for the sake of backward compatibility with deployed 1403 infrastructure); as a result, the rules provided in this document are 1404 more restrictive than the rules for many existing application 1405 technologies (such as those excerpted under Appendix B). Several 1406 security considerations justify tightening the rules: 1408 o Wildcard certificates automatically vouch for any and all host 1409 names within their domain. This can be convenient for 1410 administrators but also poses the risk of vouching for rogue or 1411 buggy hosts. See for example [Defeating-SSL] (beginning at slide 1412 91) and [HTTPSbytes] (slides 38-40). 1414 o Specifications for existing application technologies are not clear 1415 or consistent about the allowable location of the wildcard 1416 character, such as whether it can be: 1418 * only the complete left-most label (e.g., *.example.com) 1420 * some fragment of the left-most label (e.g., foo*.example.com, 1421 f*o.example.com, or *oo.example.com) 1423 * all or part of a label other than the left-most label (e.g., 1424 www.*.example.com or www.foo*.example.com) 1426 * all or part of a label that identifies a so-called "public 1427 suffix" (e.g., *.co.uk or *.com) 1429 * included more than once in a given label (e.g., 1430 f*b*r.example.com 1432 * included as all or part of more than one label (e.g., 1433 *.*.example.com) 1435 These ambiguities might introduce exploitable differences in 1436 identity checking behavior among client implementations and 1437 necessitate overly complex and inefficient identity checking 1438 algorithms. 1440 o There is no specification that defines how the wildcard character 1441 may be embedded within the NR-LDH labels, A-labels, or U-labels 1442 [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a 1443 result, implementations are strongly discouraged from including or 1444 attempting to check for the wildcard character emdedded within NR- 1445 LDH labels, A-labels, or U-labels of an internationalized domain 1446 name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a 1447 presented domain name identifier MAY contain the wildcard 1448 character as long as that character occupies the entire left-most 1449 label position, where some or all of the remaining labels are NR- 1450 LDH labels, A-labels, or U-labels (e.g., "*.xn-- 1451 kcry6tjko.example.org"). 1453 Notwithstanding the foregoing security considerations, specifications 1454 that re-use this one can legitimately encourage continued support for 1455 the wildcard character if they have good reasons to do so, such as 1456 backward compatibility with deployed infrastructure (see, for 1457 example, [EV-CERTS]). 1459 7.3. Internationalized Domain Names 1461 Allowing internationalized domain names can lead to the inclusion of 1462 visually similar (so-called "confusable") characters in certificates; 1463 for discussion, see for example [IDNA-DEFS]. 1465 7.4. Multiple Identifiers 1467 A given application service might be addressed by multiple DNS domain 1468 names for a variety of reasons, and a given deployment might service 1469 multiple domains (e.g., in so-called "virtual hosting" environments). 1470 In the default TLS handshake exchange, the client is not able to 1471 indicate the DNS domain name with which it wants to communicate, and 1472 the TLS server returns only one certificate for itself. Absent an 1473 extension to TLS, a typical workaround used to facilitate mapping an 1474 application service to multiple DNS domain names is to embed all of 1475 the domain names into a single certificate. 1477 A more recent approach, formally specified in [TLS-EXT], is for the 1478 client to use the TLS "Server Name Indication" (SNI) extension when 1479 sending the client_hello message, stipulating the DNS domain name it 1480 desires or expects of the service. The service can then return the 1481 appropriate certificate in its Certificate message, and that 1482 certificate can represent a single DNS domain name. 1484 To accommodate the workaround that was needed before the development 1485 of the SNI extension, this specification allows multiple DNS-IDs, 1486 SRV-IDs, or URI-IDs in a certificate; however, it explicitly 1487 discourages multiple CN-IDs. Although it would be preferable to 1488 forbid multiple CN-IDs entirely, there are several reasons at this 1489 time why this specification states that they SHOULD NOT (instead of 1490 MUST NOT) be included: 1492 o At least one significant technology community of interest 1493 explicitly allows multiple CN-IDs [EV-CERTS]. 1495 o At least one significant certification authority is known to issue 1496 certificates containing multiple CN-IDs. 1498 o Many service providers often deem inclusion of multiple CN-IDs 1499 necessary in virtual hosting environments because at least one 1500 widely-deployed operating system does not yet support the SNI 1501 extension. 1503 It is hoped that the recommendation regarding multiple CN-IDs can be 1504 further tightened in the future. 1506 8. IANA Considerations 1508 This document specifies no actions for the IANA. 1510 9. Contributors 1512 The following individuals made important contributions to the text of 1513 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 1515 10. Acknowledgements 1517 The editors and contributors wish to thank the following individuals 1518 for their feedback and suggestions: Bernard Aboba, Richard Barnes, 1519 Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott 1520 Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus 1521 Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno 1522 Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love 1523 Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, 1524 Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott 1525 Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, 1526 Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, 1527 Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe 1528 Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael 1529 Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul 1530 Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and 1531 Stefan Winter. 1533 Thanks also to Barry Leiba and Ben Campbell for their reviews on 1534 behalf of the Security Directorate and the General Area Review Team, 1535 respectively. 1537 The responsible Area Director was Alexey Melnikov. 1539 11. References 1541 11.1. Normative References 1543 [DNS] Mockapetris, P., "Domain names - implementation and 1544 specification", STD 13, RFC 1035, November 1987. 1546 [DNS-CONCEPTS] 1547 Mockapetris, P., "Domain names - concepts and facilities", 1548 STD 13, RFC 1034, November 1987. 1550 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1551 specifying the location of services (DNS SRV)", RFC 2782, 1552 February 2000. 1554 [IDNA-DEFS] 1555 Klensin, J., "Internationalized Domain Names for 1556 Applications (IDNA): Definitions and Document Framework", 1557 RFC 5890, August 2010. 1559 [IDNA-PROTO] 1560 Klensin, J., "Internationalized Domain Names in 1561 Applications (IDNA): Protocol", RFC 5891, August 2010. 1563 [KEYWORDS] 1564 Bradner, S., "Key words for use in RFCs to Indicate 1565 Requirement Levels", BCP 14, RFC 2119, March 1997. 1567 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 1568 (LDAP): String Representation of Distinguished Names", 1569 RFC 4514, June 2006. 1571 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1572 Housley, R., and W. Polk, "Internet X.509 Public Key 1573 Infrastructure Certificate and Certificate Revocation List 1574 (CRL) Profile", RFC 5280, May 2008. 1576 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1577 Subject Alternative Name for Expression of Service Name", 1578 RFC 4985, August 2007. 1580 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1581 Resource Identifier (URI): Generic Syntax", STD 66, 1582 RFC 3986, January 2005. 1584 11.2. Informative References 1586 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1587 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1589 [HTTPSbytes] 1590 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1591 Dhabi, November 2010, . 1596 [Defeating-SSL] 1597 Marlinspike, M., "New Tricks for Defeating SSL in 1598 Practice", BlackHat DC, February 2009, . 1602 [DNS-CASE] 1603 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 1604 Clarification", RFC 4343, January 2006. 1606 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1607 Rose, "DNS Security Introduction and Requirements", 1608 RFC 4033, March 2005. 1610 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1611 Security", RFC 4347, April 2006. 1613 [EMAIL-SRV] 1614 Daboo, C., "Use of SRV Records for Locating Email 1615 Submission/Access services", draft-daboo-srv-email-05 1616 (work in progress), May 2010. 1618 [EV-CERTS] 1619 CA/Browser Forum, "Guidelines For The Issuance And 1620 Management Of Extended Validation Certificates", 1621 October 2009, 1622 . 1624 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1625 Signalling Transport", RFC 5971, October 2010. 1627 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1628 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1629 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1631 [HTTP-TLS] 1632 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1634 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1635 4rev1", RFC 3501, March 2003. 1637 [IDNA2003] 1638 Faltstrom, P., Hoffman, P., and A. Costello, 1639 "Internationalizing Domain Names in Applications (IDNA)", 1640 RFC 3490, March 2003. 1642 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1643 September 1981. 1645 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1646 (IPv6) Specification", RFC 2460, December 1998. 1648 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1649 Internet Protocol", RFC 4301, December 2005. 1651 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1652 (LDAP): The Protocol", RFC 4511, June 2006. 1654 [LDAP-AUTH] 1655 Harrison, R., "Lightweight Directory Access Protocol 1656 (LDAP): Authentication Methods and Security Mechanisms", 1657 RFC 4513, June 2006. 1659 [LDAP-SCHEMA] 1660 Sciberras, A., "Lightweight Directory Access Protocol 1661 (LDAP): Schema for User Applications", RFC 4519, 1662 June 2006. 1664 [LDAP-TLS] 1665 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1666 Directory Access Protocol (v3): Extension for Transport 1667 Layer Security", RFC 2830, May 2000. 1669 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1670 Part Three: The Domain Name System (DNS) Database", 1671 RFC 3403, October 2002. 1673 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1674 December 2006. 1676 [NETCONF-SSH] 1677 Wasserman, M. and T. Goddard, "Using the NETCONF 1678 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1679 December 2006. 1681 [NETCONF-TLS] 1682 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1683 RFC 5539, May 2009. 1685 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1686 RFC 3977, October 2006. 1688 [NNTP-TLS] 1689 Murchison, K., Vinocur, J., and C. Newman, "Using 1690 Transport Layer Security (TLS) with Network News Transfer 1691 Protocol (NNTP)", RFC 4642, October 2006. 1693 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1694 Adams, "X.509 Internet Public Key Infrastructure Online 1695 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1697 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1698 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1700 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1701 STD 53, RFC 1939, May 1996. 1703 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1704 E. Lear, "Address Allocation for Private Internets", 1705 BCP 5, RFC 1918, February 1996. 1707 [PKIX-OLD] 1708 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1709 X.509 Public Key Infrastructure Certificate and CRL 1710 Profile", RFC 2459, January 1999. 1712 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1713 Service Location Using SRV RRs and the Dynamic Delegation 1714 Discovery Service (DDDS)", RFC 3958, January 2005. 1716 [SECTERMS] 1717 Shirey, R., "Internet Security Glossary, Version 2", 1718 RFC 4949, August 2007. 1720 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1721 A., Peterson, J., Sparks, R., Handley, M., and E. 1722 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1723 June 2002. 1725 [SIP-CERTS] 1726 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1727 Certificates in the Session Initiation Protocol (SIP)", 1728 RFC 5922, June 2010. 1730 [SIP-SIPS] 1731 Audet, F., "The Use of the SIPS URI Scheme in the Session 1732 Initiation Protocol (SIP)", RFC 5630, October 2009. 1734 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1735 October 2008. 1737 [SMTP-AUTH] 1738 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1739 for Authentication", RFC 4954, July 2007. 1741 [SMTP-TLS] 1742 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1743 Transport Layer Security", RFC 3207, February 2002. 1745 [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An 1746 Architecture for Describing Simple Network Management 1747 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1748 December 2002. 1750 [SNMP-TLS] 1751 Hardaker, W., "Transport Layer Security (TLS) Transport 1752 Model for the Simple Network Management Protocol (SNMP)", 1753 RFC 5953, August 2010. 1755 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1757 [SYSLOG-DTLS] 1758 Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1759 "Datagram Transport Layer Security (DTLS) Transport 1760 Mapping for Syslog", RFC 6012, October 2010. 1762 [SYSLOG-TLS] 1763 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1764 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1765 March 2009. 1767 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1768 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1770 [TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions: 1771 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 1772 (work in progress), September 2010. 1774 [US-ASCII] 1775 American National Standards Institute, "Coded Character 1776 Set - 7-bit American Standard Code for Information 1777 Interchange", ANSI X3.4, 1986. 1779 [USINGTLS] 1780 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1781 RFC 2595, June 1999. 1783 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1784 Interface Guidelines", World Wide Web Consortium 1785 LastCall WD-wsc-ui-20100309, March 2010, 1786 . 1788 [X.500] International Telecommunications Union, "Information 1789 Technology - Open Systems Interconnection - The Directory: 1790 Overview of concepts, models and services", ITU- 1791 T Recommendation X.500, ISO Standard 9594-1, August 2005. 1793 [X.501] International Telecommunications Union, "Information 1794 Technology - Open Systems Interconnection - The Directory: 1795 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1796 August 2005. 1798 [X.509] International Telecommunications Union, "Information 1799 Technology - Open Systems Interconnection - The Directory: 1800 Public-key and attribute certificate frameworks", ITU- 1801 T Recommendation X.509, ISO Standard 9594-8, August 2005. 1803 [X.520] International Telecommunications Union, "Information 1804 Technology - Open Systems Interconnection - The Directory: 1805 Selected attribute types", ITU-T Recommendation X.509, 1806 ISO Standard 9594-6, August 2005. 1808 [X.690] International Telecommunications Union, "Information 1809 Technology - ASN.1 encoding rules: Specification of Basic 1810 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1811 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1812 X.690, ISO Standard 8825-1, August 2008. 1814 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1815 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-22 (work 1816 in progress), December 2010. 1818 [XMPP-OLD] 1819 Saint-Andre, P., Ed., "Extensible Messaging and Presence 1820 Protocol (XMPP): Core", RFC 3920, October 2004. 1822 Appendix A. Sample Text 1824 At the time of this writing, two application technologies re-use the 1825 recommendations in this specfication: email [EMAIL-SRV] and XMPP 1826 [XMPP]. Here we include the text from [XMPP] to illustrate the 1827 thought process that might be followed by protocol designers for 1828 other application technologies. Specifically, because XMPP uses DNS 1829 SRV records for resolution of the DNS domain names for application 1830 services, the XMPP specification recommends the use of SRV-IDs. 1832 The text regarding certificate issuance is as follows: 1834 ###### 1835 In a PKIX certificate to be presented by an XMPP server (i.e., a 1836 "server certificate"), the certificate MUST include one or more XMPP 1837 addresses (i.e., domainparts) associated with XMPP services hosted at 1838 the server. The rules and guidelines defined in [this specification] 1839 apply to XMPP server certificates, with the following XMPP-specific 1840 considerations: 1842 o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP 1843 client and server software implementations. Certification 1844 authorities that issue XMPP-specific certificates MUST support the 1845 DNS-ID identifier type. XMPP service providers SHOULD include the 1846 DNS-ID identifier type in certificate requests. 1848 o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for 1849 XMPP client and server software implementations (for verification 1850 purposes XMPP client implementations need to support only the 1851 "_xmpp-client" service type, whereas XMPP server implementations 1852 need to support both the "_xmpp-client" and "_xmpp-server" service 1853 types). Certification authorities that issue XMPP-specific 1854 certificates SHOULD support the SRV-ID identifier type. XMPP 1855 service providers SHOULD include the SRV-ID identifier type in 1856 certificate requests. 1858 o Support for the XmppAddr identifier type is encouraged in XMPP 1859 client and server software implementations for the sake of 1860 backward-compatibility, but is no longer encouraged in 1861 certificates issued by certification authorities or requested by 1862 XMPP service providers. 1864 o DNS domain names in server certificates MAY contain the wildcard 1865 character '*' as the complete left-most label within the 1866 identifier. 1868 ###### 1870 The text regarding certificate verification is as follows: 1872 ###### 1874 For server certificates, the rules and guidelines defined in [this 1875 specification] apply, with the proviso that the XmppAddr identifier 1876 is allowed as a reference identifier. 1878 The identities to be checked are set as follows: 1880 o The initiating entity sets its reference identifier to the 'to' 1881 address it communicates in the initial stream header; i.e., this 1882 is the identity it expects the receiving entity to provide in a 1883 PKIX certificate. 1885 o The receiving entity sets its reference identifier to the 'from' 1886 address communicated by the initiating entity in the initial 1887 stream header; i.e., this is the identity that the initiating 1888 entity is trying to assert. 1890 ###### 1892 Appendix B. Prior Art 1894 (This section is non-normative.) 1896 The recommendations in this document are an abstraction from 1897 recommendations in specifications for a wide range of application 1898 protocols. For the purpose of comparison and to delineate the 1899 history of thinking about application service identity verification 1900 within the IETF, this informative section gathers together prior art 1901 by including the exact text from various RFCs (the only modifications 1902 are changes to the names of several references to maintain coherence 1903 with the main body of this document, and the elision of irrelevant 1904 text as marked by the characters "[...]"). 1906 B.1. IMAP, POP3, and ACAP (1999) 1908 In 1999, [USINGTLS] specified the following text regarding 1909 application service identity verification in IMAP, POP3, and ACAP: 1911 ###### 1913 2.4. Server Identity Check 1915 During the TLS negotiation, the client MUST check its understanding 1916 of the server hostname against the server's identity as presented in 1917 the server Certificate message, in order to prevent man-in-the-middle 1918 attacks. Matching is performed according to these rules: 1920 o The client MUST use the server hostname it used to open the 1921 connection as the value to compare against the server name as 1922 expressed in the server certificate. The client MUST NOT use any 1923 form of the server hostname derived from an insecure remote source 1924 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1925 o If a subjectAltName extension of type dNSName is present in the 1926 certificate, it SHOULD be used as the source of the server's 1927 identity. 1929 o Matching is case-insensitive. 1930 o A "*" wildcard character MAY be used as the left-most name 1931 component in the certificate. For example, *.example.com would 1932 match a.example.com, foo.example.com, etc. but would not match 1933 example.com. 1934 o If the certificate contains multiple names (e.g. more than one 1935 dNSName field), then a match with any one of the fields is 1936 considered acceptable. 1938 If the match fails, the client SHOULD either ask for explicit user 1939 confirmation, or terminate the connection and indicate the server's 1940 identity is suspect. 1942 ###### 1944 B.2. HTTP (2000) 1946 In 2000, [HTTP-TLS] specified the following text regarding 1947 application service identity verification in HTTP: 1949 ###### 1951 3.1. Server Identity 1953 In general, HTTP/TLS requests are generated by dereferencing a URI. 1954 As a consequence, the hostname for the server is known to the client. 1955 If the hostname is available, the client MUST check it against the 1956 server's identity as presented in the server's Certificate message, 1957 in order to prevent man-in-the-middle attacks. 1959 If the client has external information as to the expected identity of 1960 the server, the hostname check MAY be omitted. (For instance, a 1961 client may be connecting to a machine whose address and hostname are 1962 dynamic but the client knows the certificate that the server will 1963 present.) In such cases, it is important to narrow the scope of 1964 acceptable certificates as much as possible in order to prevent man 1965 in the middle attacks. In special cases, it may be appropriate for 1966 the client to simply ignore the server's identity, but it must be 1967 understood that this leaves the connection open to active attack. 1969 If a subjectAltName extension of type dNSName is present, that MUST 1970 be used as the identity. Otherwise, the (most specific) Common Name 1971 field in the Subject field of the certificate MUST be used. Although 1972 the use of the Common Name is existing practice, it is deprecated and 1973 Certification Authorities are encouraged to use the dNSName instead. 1975 Matching is performed using the matching rules specified by 1976 [PKIX-OLD]. If more than one identity of a given type is present in 1977 the certificate (e.g., more than one dNSName name, a match in any one 1978 of the set is considered acceptable.) Names may contain the wildcard 1979 character * which is considered to match any single domain name 1980 component or component fragment. E.g., *.a.com matches foo.a.com but 1981 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1983 In some cases, the URI is specified as an IP address rather than a 1984 hostname. In this case, the iPAddress subjectAltName must be present 1985 in the certificate and must exactly match the IP in the URI. 1987 If the hostname does not match the identity in the certificate, user 1988 oriented clients MUST either notify the user (clients MAY give the 1989 user the opportunity to continue with the connection in any case) or 1990 terminate the connection with a bad certificate error. Automated 1991 clients MUST log the error to an appropriate audit log (if available) 1992 and SHOULD terminate the connection (with a bad certificate error). 1993 Automated clients MAY provide a configuration setting that disables 1994 this check, but MUST provide a setting which enables it. 1996 Note that in many cases the URI itself comes from an untrusted 1997 source. The above-described check provides no protection against 1998 attacks where this source is compromised. For example, if the URI 1999 was obtained by clicking on an HTML page which was itself obtained 2000 without using HTTP/TLS, a man in the middle could have replaced the 2001 URI. In order to prevent this form of attack, users should carefully 2002 examine the certificate presented by the server to determine if it 2003 meets their expectations. 2005 ###### 2007 B.3. LDAP (2000/2006) 2009 In 2000, [LDAP-TLS] specified the following text regarding 2010 application service identity verification in LDAP: 2012 ###### 2014 3.6. Server Identity Check 2016 The client MUST check its understanding of the server's hostname 2017 against the server's identity as presented in the server's 2018 Certificate message, in order to prevent man-in-the-middle attacks. 2020 Matching is performed according to these rules: 2022 o The client MUST use the server hostname it used to open the LDAP 2023 connection as the value to compare against the server name as 2024 expressed in the server's certificate. The client MUST NOT use 2025 the server's canonical DNS name or any other derived form of name. 2026 o If a subjectAltName extension of type dNSName is present in the 2027 certificate, it SHOULD be used as the source of the server's 2028 identity. 2029 o Matching is case-insensitive. 2030 o The "*" wildcard character is allowed. If present, it applies 2031 only to the left-most name component. 2033 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 2034 bar.com. If more than one identity of a given type is present in the 2035 certificate (e.g. more than one dNSName name), a match in any one of 2036 the set is considered acceptable. 2038 If the hostname does not match the dNSName-based identity in the 2039 certificate per the above check, user-oriented clients SHOULD either 2040 notify the user (clients MAY give the user the opportunity to 2041 continue with the connection in any case) or terminate the connection 2042 and indicate that the server's identity is suspect. Automated 2043 clients SHOULD close the connection, returning and/or logging an 2044 error indicating that the server's identity is suspect. 2046 Beyond the server identity checks described in this section, clients 2047 SHOULD be prepared to do further checking to ensure that the server 2048 is authorized to provide the service it is observed to provide. The 2049 client MAY need to make use of local policy information. 2051 ###### 2053 In 2006, [LDAP-AUTH] specified the following text regarding 2054 application service identity verification in LDAP: 2056 ###### 2058 3.1.3. Server Identity Check 2060 In order to prevent man-in-the-middle attacks, the client MUST verify 2061 the server's identity (as presented in the server's Certificate 2062 message). In this section, the client's understanding of the 2063 server's identity (typically the identity used to establish the 2064 transport connection) is called the "reference identity". 2066 The client determines the type (e.g., DNS name or IP address) of the 2067 reference identity and performs a comparison between the reference 2068 identity and each subjectAltName value of the corresponding type 2069 until a match is produced. Once a match is produced, the server's 2070 identity has been verified, and the server identity check is 2071 complete. Different subjectAltName types are matched in different 2072 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 2073 various subjectAltName types. 2075 The client may map the reference identity to a different type prior 2076 to performing a comparison. Mappings may be performed for all 2077 available subjectAltName types to which the reference identity can be 2078 mapped; however, the reference identity should only be mapped to 2079 types for which the mapping is either inherently secure (e.g., 2080 extracting the DNS name from a URI to compare with a subjectAltName 2081 of type dNSName) or for which the mapping is performed in a secure 2082 manner (e.g., using [DNSSEC], or using user- or admin-configured 2083 host-to-address/address-to-host lookup tables). 2085 The server's identity may also be verified by comparing the reference 2086 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 2087 Relative Distinguished Name (RDN) of the subject field of the 2088 server's certificate (where "last" refers to the DER-encoded order, 2089 not the order of presentation in a string representation of DER- 2090 encoded data). This comparison is performed using the rules for 2091 comparison of DNS names in Section 3.1.3.1, below, with the exception 2092 that no wildcard matching is allowed. Although the use of the Common 2093 Name value is existing practice, it is deprecated, and Certification 2094 Authorities are encouraged to provide subjectAltName values instead. 2095 Note that the TLS implementation may represent DNs in certificates 2096 according to X.500 or other conventions. For example, some X.500 2097 implementations order the RDNs in a DN using a left-to-right (most 2098 significant to least significant) convention instead of LDAP's right- 2099 to-left convention. 2101 If the server identity check fails, user-oriented clients SHOULD 2102 either notify the user (clients may give the user the opportunity to 2103 continue with the LDAP session in this case) or close the transport 2104 connection and indicate that the server's identity is suspect. 2105 Automated clients SHOULD close the transport connection and then 2106 return or log an error indicating that the server's identity is 2107 suspect or both. 2109 Beyond the server identity check described in this section, clients 2110 should be prepared to do further checking to ensure that the server 2111 is authorized to provide the service it is requested to provide. The 2112 client may need to make use of local policy information in making 2113 this determination. 2115 3.1.3.1. Comparison of DNS Names 2117 If the reference identity is an internationalized domain name, 2118 conforming implementations MUST convert it to the ASCII Compatible 2119 Encoding (ACE) format as specified in Section 4 of RFC 3490 2120 [IDNA2003] before comparison with subjectAltName values of type 2121 dNSName. Specifically, conforming implementations MUST perform the 2122 conversion operation specified in Section 4 of RFC 3490 as follows: 2124 o in step 1, the domain name SHALL be considered a "stored string"; 2125 o in step 3, set the flag called "UseSTD3ASCIIRules"; 2126 o in step 4, process each label with the "ToASCII" operation; and 2127 o in step 5, change all label separators to U+002E (full stop). 2129 After performing the "to-ASCII" conversion, the DNS labels and names 2130 MUST be compared for equality according to the rules specified in 2131 Section 3 of RFC3490. 2133 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 2134 values of type dNSName, and then only as the left-most (least 2135 significant) DNS label in that value. This wildcard matches any 2136 left-most DNS label in the server name. That is, the subject 2137 *.example.com matches the server names a.example.com and 2138 b.example.com, but does not match example.com or a.b.example.com. 2140 3.1.3.2. Comparison of IP Addresses 2142 When the reference identity is an IP address, the identity MUST be 2143 converted to the "network byte order" octet string representation 2144 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 2145 string will contain exactly four octets. For IP Version 6, as 2146 specified in RFC 2460, the octet string will contain exactly sixteen 2147 octets. This octet string is then compared against subjectAltName 2148 values of type iPAddress. A match occurs if the reference identity 2149 octet string and value octet strings are identical. 2151 3.1.3.3. Comparison of Other subjectName Types 2153 Client implementations MAY support matching against subjectAltName 2154 values of other types as described in other documents. 2156 ###### 2158 B.4. SMTP (2002/2007) 2160 In 2002, [SMTP-TLS] specified the following text regarding 2161 application service identity verification in SMTP: 2163 ###### 2165 4.1 Processing After the STARTTLS Command 2167 [...] 2168 The decision of whether or not to believe the authenticity of the 2169 other party in a TLS negotiation is a local matter. However, some 2170 general rules for the decisions are: 2172 o A SMTP client would probably only want to authenticate an SMTP 2173 server whose server certificate has a domain name that is the 2174 domain name that the client thought it was connecting to. 2176 [...] 2178 ###### 2180 In 2006, [SMTP-AUTH] specified the following text regarding 2181 application service identity verification in SMTP: 2183 ###### 2185 14. Additional Requirements When Using SASL PLAIN over TLS 2187 [...] 2189 After a successful [TLS] negotiation, the client MUST check its 2190 understanding of the server hostname against the server's identity as 2191 presented in the server Certificate message, in order to prevent man- 2192 in-the-middle attacks. If the match fails, the client MUST NOT 2193 attempt to authenticate using the SASL PLAIN mechanism. Matching is 2194 performed according to the following rules: 2196 The client MUST use the server hostname it used to open the 2197 connection as the value to compare against the server name as 2198 expressed in the server certificate. The client MUST NOT use any 2199 form of the server hostname derived from an insecure remote source 2200 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 2201 If a subjectAltName extension of type dNSName is present in the 2202 certificate, it SHOULD be used as the source of the server's 2203 identity. 2204 Matching is case-insensitive. 2205 A "*" wildcard character MAY be used as the leftmost name 2206 component in the certificate. For example, *.example.com would 2207 match a.example.com, foo.example.com, etc., but would not match 2208 example.com. 2209 If the certificate contains multiple names (e.g., more than one 2210 dNSName field), then a match with any one of the fields is 2211 considered acceptable. 2213 ###### 2215 B.5. XMPP (2004) 2217 In 2004, [XMPP-OLD] specified the following text regarding 2218 application service identity verification in XMPP: 2220 ###### 2222 14.2. Certificate Validation 2224 When an XMPP peer communicates with another peer securely, it MUST 2225 validate the peer's certificate. There are three possible cases: 2227 Case #1: The peer contains an End Entity certificate which appears 2228 to be certified by a certification path terminating in a trust 2229 anchor (as described in Section 6.1 of [PKIX]). 2230 Case #2: The peer certificate is certified by a Certificate 2231 Authority not known to the validating peer. 2232 Case #3: The peer certificate is self-signed. 2234 In Case #1, the validating peer MUST do one of two things: 2235 1. Verify the peer certificate according to the rules of [PKIX]. 2236 The certificate SHOULD then be checked against the expected 2237 identity of the peer following the rules described in [HTTP-TLS], 2238 except that a subjectAltName extension of type "xmpp" MUST be 2239 used as the identity if present. If one of these checks fails, 2240 user-oriented clients MUST either notify the user (clients MAY 2241 give the user the opportunity to continue with the connection in 2242 any case) or terminate the connection with a bad certificate 2243 error. Automated clients SHOULD terminate the connection (with a 2244 bad certificate error) and log the error to an appropriate audit 2245 log. Automated clients MAY provide a configuration setting that 2246 disables this check, but MUST provide a setting that enables it. 2247 2. The peer SHOULD show the certificate to a user for approval, 2248 including the entire certification path. The peer MUST cache the 2249 certificate (or some non-forgeable representation such as a 2250 hash). In future connections, the peer MUST verify that the same 2251 certificate was presented and MUST notify the user if it has 2252 changed. 2254 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 2256 ###### 2258 Although [XMPP-OLD] defined its own rules, [XMPP] re-uses the rules 2259 in this document regarding application service identity verification 2260 in XMPP. 2262 B.6. NNTP (2006) 2264 In 2006, [NNTP-TLS] specified the following text regarding 2265 application service identity verification in NNTP: 2267 ###### 2269 5. Security Considerations 2271 [...] 2273 During the TLS negotiation, the client MUST check its understanding 2274 of the server hostname against the server's identity as presented in 2275 the server Certificate message, in order to prevent man-in-the-middle 2276 attacks. Matching is performed according to these rules: 2278 o The client MUST use the server hostname it used to open the 2279 connection (or the hostname specified in TLS "server_name" 2280 extension [TLS]) as the value to compare against the server name 2281 as expressed in the server certificate. The client MUST NOT use 2282 any form of the server hostname derived from an insecure remote 2283 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2284 done. 2285 o If a subjectAltName extension of type dNSName is present in the 2286 certificate, it SHOULD be used as the source of the server's 2287 identity. 2288 o Matching is case-insensitive. 2289 o A "*" wildcard character MAY be used as the left-most name 2290 component in the certificate. For example, *.example.com would 2291 match a.example.com, foo.example.com, etc., but would not match 2292 example.com. 2293 o If the certificate contains multiple names (e.g., more than one 2294 dNSName field), then a match with any one of the fields is 2295 considered acceptable. 2297 If the match fails, the client SHOULD either ask for explicit user 2298 confirmation or terminate the connection with a QUIT command and 2299 indicate the server's identity is suspect. 2301 Additionally, clients MUST verify the binding between the identity of 2302 the servers to which they connect and the public keys presented by 2303 those servers. Clients SHOULD implement the algorithm in Section 6 2304 of [PKIX] for general certificate validation, but MAY supplement that 2305 algorithm with other validation methods that achieve equivalent 2306 levels of verification (such as comparing the server certificate 2307 against a local store of already-verified certificates and identity 2308 bindings). 2310 ###### 2312 B.7. NETCONF (2006/2009) 2314 In 2006, [NETCONF-SSH] specified the following text regarding 2315 application service identity verification in NETCONF: 2317 ###### 2319 6. Security Considerations 2321 The identity of the server MUST be verified and authenticated by the 2322 client according to local policy before password-based authentication 2323 data or any configuration or state data is sent to or received from 2324 the server. The identity of the client MUST also be verified and 2325 authenticated by the server according to local policy to ensure that 2326 the incoming client request is legitimate before any configuration or 2327 state data is sent to or received from the client. Neither side 2328 should establish a NETCONF over SSH connection with an unknown, 2329 unexpected, or incorrect identity on the opposite side. 2331 ###### 2333 In 2009, [NETCONF-TLS] specified the following text regarding 2334 application service identity verification in NETCONF: 2336 ###### 2338 3.1. Server Identity 2340 During the TLS negotiation, the client MUST carefully examine the 2341 certificate presented by the server to determine if it meets the 2342 client's expectations. Particularly, the client MUST check its 2343 understanding of the server hostname against the server's identity as 2344 presented in the server Certificate message, in order to prevent man- 2345 in-the-middle attacks. 2347 Matching is performed according to the rules below (following the 2348 example of [NNTP-TLS]): 2350 o The client MUST use the server hostname it used to open the 2351 connection (or the hostname specified in the TLS "server_name" 2352 extension [TLS]) as the value to compare against the server name 2353 as expressed in the server certificate. The client MUST NOT use 2354 any form of the server hostname derived from an insecure remote 2355 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2356 done. 2358 o If a subjectAltName extension of type dNSName is present in the 2359 certificate, it MUST be used as the source of the server's 2360 identity. 2361 o Matching is case-insensitive. 2362 o A "*" wildcard character MAY be used as the leftmost name 2363 component in the certificate. For example, *.example.com would 2364 match a.example.com, foo.example.com, etc., but would not match 2365 example.com. 2366 o If the certificate contains multiple names (e.g., more than one 2367 dNSName field), then a match with any one of the fields is 2368 considered acceptable. 2370 If the match fails, the client MUST either ask for explicit user 2371 confirmation or terminate the connection and indicate the server's 2372 identity is suspect. 2374 Additionally, clients MUST verify the binding between the identity of 2375 the servers to which they connect and the public keys presented by 2376 those servers. Clients SHOULD implement the algorithm in Section 6 2377 of [PKIX] for general certificate validation, but MAY supplement that 2378 algorithm with other validation methods that achieve equivalent 2379 levels of verification (such as comparing the server certificate 2380 against a local store of already-verified certificates and identity 2381 bindings). 2383 If the client has external information as to the expected identity of 2384 the server, the hostname check MAY be omitted. 2386 ###### 2388 B.8. Syslog (2009) 2390 In 2009, [SYSLOG-TLS] specified the following text regarding 2391 application service identity verification in Syslog: 2393 ###### 2395 5.2. Subject Name Authorization 2397 Implementations MUST support certification path validation [PKIX]. 2398 In addition, they MUST support specifying the authorized peers using 2399 locally configured host names and matching the name against the 2400 certificate as follows. 2402 o Implementations MUST support matching the locally configured host 2403 name against a dNSName in the subjectAltName extension field and 2404 SHOULD support checking the name against the common name portion 2405 of the subject distinguished name. 2407 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 2408 the subjectAltName extension (and in common name, if used to store 2409 the host name), but only as the left-most (least significant) DNS 2410 label in that value. This wildcard matches any left-most DNS 2411 label in the server name. That is, the subject *.example.com 2412 matches the server names a.example.com and b.example.com, but does 2413 not match example.com or a.b.example.com. Implementations MUST 2414 support wildcards in certificates as specified above, but MAY 2415 provide a configuration option to disable them. 2416 o Locally configured names MAY contain the wildcard character to 2417 match a range of values. The types of wildcards supported MAY be 2418 more flexible than those allowed in subject names, making it 2419 possible to support various policies for different environments. 2420 For example, a policy could allow for a trust-root-based 2421 authorization where all credentials issued by a particular CA 2422 trust root are authorized. 2423 o If the locally configured name is an internationalized domain 2424 name, conforming implementations MUST convert it to the ASCII 2425 Compatible Encoding (ACE) format for performing comparisons, as 2426 specified in Section 7 of [PKIX]. 2427 o Implementations MAY support matching a locally configured IP 2428 address against an iPAddress stored in the subjectAltName 2429 extension. In this case, the locally configured IP address is 2430 converted to an octet string as specified in [PKIX], Section 2431 4.2.1.6. A match occurs if this octet string is equal to the 2432 value of iPAddress in the subjectAltName extension. 2434 ###### 2436 B.9. SIP (2010) 2438 In 2010, [SIP-CERTS] specified the following text regarding 2439 application service identity verification in SIP: 2441 ###### 2443 7.2. Comparing SIP Identities 2445 When an implementation (either client or server) compares two values 2446 as SIP domain identities: 2447 Implementations MUST compare only the DNS name component of each 2448 SIP domain identifier; an implementation MUST NOT use any scheme 2449 or parameters in the comparison. 2450 Implementations MUST compare the values as DNS names, which means 2451 that the comparison is case insensitive as specified by 2452 [DNS-CASE]. Implementations MUST handle Internationalized Domain 2453 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 2455 Implementations MUST match the values in their entirety: 2456 Implementations MUST NOT match suffixes. For example, 2457 "foo.example.com" does not match "example.com". 2458 Implemenations MUST NOT match any form of wildcard, such as a 2459 leading "." or "*." with any other DNS label or sequence of 2460 labels. For example, "*.example.com" matches only 2461 "*.example.com" but not "foo.example.com". Similarly, 2462 ".example.com" matches only ".example.com", and does not match 2463 "foo.example.com." 2464 [HTTP-TLS] allows the dNSName component to contain a 2465 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 2466 disallowing this explicitly, leaves the interpretation of 2467 wildcards to the individual specification. [SIP] does not 2468 provide any guidelines on the presence of wildcards in 2469 certificates. Through the rule above, this document 2470 prohibits such wildcards in certificates for SIP domains. 2472 ###### 2474 B.10. SNMP (2010) 2476 In 2010, [SNMP-TLS] specified the following text regarding 2477 application service identity verification in SNMP: 2479 ###### 2481 If the server's presented certificate has passed certification path 2482 validation [PKIX] to a configured trust anchor, and an active row 2483 exists with a zero-length snmpTlstmAddrServerFingerprint value, then 2484 the snmpTlstmAddrServerIdentity column contains the expected host 2485 name. This expected host name is then compared against the server's 2486 certificate as follows: 2488 o Implementations MUST support matching the expected host name 2489 against a dNSName in the subjectAltName extension field and MAY 2490 support checking the name against the CommonName portion of the 2491 subject distinguished name. 2493 o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName 2494 of the subjectAltName extension (and in common name, if used to 2495 store the host name), but only as the left-most (least 2496 significant) DNS label in that value. This wildcard matches any 2497 left-most DNS label in the server name. That is, the subject 2498 *.example.com matches the server names a.example.com and 2499 b.example.com, but does not match example.com or a.b.example.com. 2500 Implementations MUST support wildcards in certificates as 2501 specified above, but MAY provide a configuration option to disable 2502 them. 2504 o If the locally configured name is an internationalized domain 2505 name, conforming implementations MUST convert it to the ASCII 2506 Compatible Encoding (ACE) format for performing comparisons, as 2507 specified in Section 7 of [PKIX]. 2509 If the expected host name fails these conditions then the connection 2510 MUST be closed. 2512 ###### 2514 B.11. GIST (2010) 2516 In 2010, [GIST] specified the following text regarding application 2517 service identity verification in the General Internet Signalling 2518 Transport: 2520 ###### 2522 5.7.3.1. Identity Checking in TLS 2524 After TLS authentication, a node MUST check the identity presented by 2525 the peer in order to avoid man-in-the-middle attacks, and verify that 2526 the peer is authorised to take part in signalling at the GIST layer. 2527 The authorisation check is carried out by comparing the presented 2528 identity with each Authorised Peer Database (APD) entry in turn, as 2529 discussed in Section 4.4.2. This section defines the identity 2530 comparison algorithm for a single APD entry. 2532 For TLS authentication with X.509 certificates, an identity from the 2533 DNS namespace MUST be checked against each subjectAltName extension 2534 of type dNSName present in the certificate. If no such extension is 2535 present, then the identity MUST be compared to the (most specific) 2536 Common Name in the Subject field of the certificate. When matching 2537 DNS names against dNSName or Common Name fields, matching is case- 2538 insensitive. Also, a "*" wildcard character MAY be used as the left- 2539 most name component in the certificate or identity in the APD. For 2540 example, *.example.com in the APD would match certificates for 2541 a.example.com, foo.example.com, *.example.com, etc., but would not 2542 match example.com. Similarly, a certificate for *.example.com would 2543 be valid for APD identities of a.example.com, foo.example.com, 2544 *.example.com, etc., but not example.com. 2546 Additionally, a node MUST verify the binding between the identity of 2547 the peer to which it connects and the public key presented by that 2548 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 2549 for general certificate validation, but MAY supplement that algorithm 2550 with other validation methods that achieve equivalent levels of 2551 verification (such as comparing the server certificate against a 2552 local store of already-verified certificates and identity bindings). 2554 For TLS authentication with pre-shared keys, the identity in the 2555 psk_identity_hint (for the server identity, i.e. the Responding node) 2556 or psk_identity (for the client identity, i.e. the Querying node) 2557 MUST be compared to the identities in the APD. 2559 ###### 2561 Authors' Addresses 2563 Peter Saint-Andre 2564 Cisco 2565 1899 Wyknoop Street, Suite 600 2566 Denver, CO 80202 2567 USA 2569 Phone: +1-303-308-3282 2570 Email: psaintan@cisco.com 2572 Jeff Hodges 2573 PayPal 2574 2211 North First Street 2575 San Jose, California 95131 2576 US 2578 Email: Jeff.Hodges@PayPal.com