idnits 2.17.1 draft-saintandre-tls-server-id-check-14.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 12, 2011) is 4824 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) -- 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 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- 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) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP-OLD') (Obsoleted by RFC 6120) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 17 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 16, 2011 PayPal 6 January 12, 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-14 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 16, 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 . . . . . . . 23 79 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 23 80 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 25 81 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 82 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 27 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 . . . . . . . . . . 29 88 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . 30 94 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 96 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 97 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 105 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 106 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40 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) . . . . . . . . . . . . . . . . . . . . . 44 111 B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47 112 B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48 113 B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49 114 B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50 115 B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52 116 B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 53 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 might be used for any type of application service, 970 then the service provider is encouraged to request a certificate that 971 includes only a DNS-ID. 973 If the certificate will be used for only a single type of application 974 service, then the service provider is encouraged to request a 975 certificate that includes a DNS-ID and, if appropriate for the 976 service type, an SRV-ID or URI-ID that limits the deployment scope of 977 the certificate to only the defined service type. 979 If a service provider offering multiple service types (e.g., a world 980 wide web service, an email service, and an instant messaging service) 981 wishes to limit the applicability of certificates using SRV-IDs or 982 URI-IDs, then the service provider is encouraged to request multiple 983 certificates, i.e., one certificate per service type. Conversely, 984 the service provider is discouraged from requesting a single 985 certificate containing multiple SRV-IDs or URI-IDs identifying each 986 different application service type. This guideline does not apply to 987 service type "bundles" that are used to identify manifold distinct 988 access methods to the same underlying application (e.g., an email 989 application with access methods denoted by the service types of 990 "imap", "imaps", "pop3", "pop3s", and "submission" as described in 991 [EMAIL-SRV]). 993 6. Verifying Service Identity 995 This section provides rules and guidelines for implementers of 996 application client software regarding algorithms for verification of 997 application service identity. 999 6.1. Overview 1001 At a high level, the client verifies the application service's 1002 identity by performing the actions listed below (which are defined in 1003 the following subsections of this document): 1005 1. The client constructs a list of acceptable reference identifiers 1006 based on the source domain and, optionally, the type of service 1007 to which the client is connecting. 1009 2. The server provides its identifiers in the form of a PKIX 1010 certificate. 1012 3. The client checks each of its reference identifiers against the 1013 presented identifiers for the purpose of finding a match. 1015 4. When checking a reference identifier against a presented 1016 identifier, the client matches the source domain of the 1017 identifiers and, optionally, their service type. 1019 Naturally, in addition to checking identifiers, a client might 1020 complete further checks to ensure that the server is authorized to 1021 provide the requested service. However, such checking is not a 1022 matter of verifying the application service identity presented in a 1023 certificate, and therefore methods for doing so (e.g., consulting 1024 local policy information) are out of scope for this document. 1026 6.2. Constructing a List of Reference Identifiers 1028 6.2.1. Rules 1030 The client MUST construct a list of acceptable reference identifiers, 1031 and MUST do so independently of the identifiers presented by the 1032 service. 1034 The inputs used by the client to construct its list of reference 1035 identifiers might be a URI that a user has typed into an interface 1036 (e.g., an HTTPS URL for a web site), configured account information 1037 (e.g., the domain name of a particular host or URI used for 1038 retrieving information or connecting to a network, which might be 1039 different from the DNS domain name portion of a username), a 1040 hyperlink in a web page that triggers a browser to retrieve a media 1041 object or script, or some other combination of information that can 1042 yield a source domain and a service type. 1044 The client might need to extract the source domain and service type 1045 from the input(s) it has received. The extracted data MUST include 1046 only information that can be securely parsed out of the inputs (e.g., 1047 parsing the fully-qualified DNS domain name out of the "host" 1048 component (or its equivalent) of a URI or deriving the service type 1049 from the scheme of a URI) or information that is derived in a manner 1050 not subject to subversion by network attackers (e.g., pulling the 1051 data from a delegated domain that is explicitly established via 1052 client or system configuration, resolving the data via [DNSSEC], or 1053 obtaining the data from a third-party domain mapping service in which 1054 a human user has explicitly placed trust and with which the client 1055 communicates over a connection or association that provides both 1056 mutual authentication and integrity checking). These considerations 1057 apply only to extraction of the source domain from the inputs; 1058 naturally, if the inputs themselves are invalid or corrupt (e.g., a 1059 user has clicked a link provided by a malicious entity in a phishing 1060 attack), then the client might end up communicating with an 1061 unexpected application service. 1063 Example: Given an input URI of , a client 1064 would derive the service type "sip" from the "scheme" and parse 1065 the domain name "example.net" from the "host" component (or its 1066 equivalent). 1068 Each reference identifier in the list SHOULD be based on the source 1069 domain and SHOULD NOT be based on a derived domain (e.g., a host name 1070 or domain name discovered through DNS resolution of the source 1071 domain). This rule is important because only a match between the 1072 user inputs and a presented identifier enables the client to be sure 1073 that the certificate can legitimately be used to secure the client's 1074 communication with the server. There is only one scenario in which 1075 it is acceptable for an interactive client to override the 1076 recommendation in this rule and therefore communicate with a domain 1077 name other than the source domain: because a human user has "pinned" 1078 the application service's certificate to the alternative domain name 1079 as further discussed under Section 6.6.4 and Section 7.1. In this 1080 case, the inputs used by the client to construct its list of 1081 reference identifiers might include more than one fully-qualified DNS 1082 domain name, i.e., both (a) the source domain and (b) the alternative 1083 domain contained in the pinned certificate. 1085 Using the combination of fully-qualified DNS domain name(s) and 1086 service type, the client constructs a list of reference identifiers 1087 in accordance with the following rules: 1089 o The list MUST include a DNS-ID. A reference identifier of type 1090 DNS-ID can be directly constructed from a fully-qualified DNS 1091 domain name that is (a) contained in or securely derived from the 1092 inputs (i.e., the source domain), or (b) explicitly associated 1093 with the source domain by means of user configuration (i.e., a 1094 derived domain). 1096 o If a server for the service type is typically discovered by means 1097 of DNS SRV records, then the list SHOULD include an SRV-ID. 1099 o If a server for the service type is typically associated with a 1100 URI for security purposes (i.e., a formal protocol document 1101 specifies the use of URIs in server certificates), then the list 1102 SHOULD include a URI-ID. 1104 o The list MAY include a CN-ID, mainly for the sake of backward 1105 compatibility with deployed infrastructure. 1107 Implementation Note: It is highly likely that implementers of 1108 client software will need to support CN-IDs for the foreseeable 1109 future, because certificates containing CN-IDs are so widely 1110 deployed. Implementers are advised to monitor the state of the 1111 art with regard to certificate issuance policies and migrate away 1112 from support CN-IDs in the future if possible. 1114 Implementation Note: The client does not need to construct the 1115 foregoing identifiers in the actual formats found in a certificate 1116 (e.g., as ASN.1 types); it only needs to construct the functional 1117 equivalent of such identifiers for matching purposes. 1119 Security Warning: A client MUST NOT construct a reference 1120 identifier corresponding to Relative Distinguished Names (RDNs) 1121 other than those of type Common Name and MUST NOT check for RDNs 1122 other than those of type Common Name in the presented identifiers. 1124 6.2.2. Examples 1126 A web browser that is connecting via HTTPS to the website at 1127 "www.example.com" might have two reference identifiers: a DNS-ID of 1128 "www.example.com" and, as a fallback, a CN-ID of "www.example.com". 1130 A mail user agent that is connecting via IMAP to the email service at 1131 "example.net" (resolved as "mail.example.net") might have four 1132 reference identifiers: SRV-IDs of "_imaps.example.net" and 1133 "_imaps.mail.example.net" (see [EMAIL-SRV]) and DNS-IDs of 1134 "example.net" and "mail.example.net". (A legacy email user agent 1135 would not support [EMAIL-SRV] and therefore would probably be 1136 explicitly configured to connect to "mail.example.net", whereas an 1137 SRV-aware user agent would derive "example.net" from an email address 1138 of the form "user@example.net" but might also accept 1139 "mail.example.net" as the DNS domain name portion of reference 1140 identifiers for the service.) 1142 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 1143 voice service at "voice.example.edu" might have only one reference 1144 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 1146 An instant messaging (IM) client that is connecting via XMPP to the 1147 IM service at "im.example.org" might have three reference 1148 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), 1149 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of 1150 "im.example.org" (see [XMPP]). 1152 6.3. Preparing to Seek a Match 1154 Once the client has constructed its list of reference identifiers and 1155 has received the server's presented identifiers in the form of a PKIX 1156 certificate, the client checks its reference identifiers against the 1157 presented identifiers for the purpose of finding a match. The search 1158 fails if the client exhausts its list of reference identifiers 1159 without finding a match. The search succeeds if any presented 1160 identifier matches one of the reference identifiers, at which point 1161 the client SHOULD stop the search. 1163 Implementation Note: A client might be configured to perform 1164 multiple searches, i.e., to match more than one reference 1165 identifier; although such behavior is not forbidden by this 1166 specification, rules for matching multiple reference identifiers 1167 are a matter for implementation or future specification. 1169 Security Warning: A client MUST NOT seek a match for a reference 1170 identifier of CN-ID if the presented identifiers include a DNS-ID, 1171 SRV-ID, URI-ID, or any application-specific identifier types 1172 supported by the client. 1174 Before applying the comparison rules provided in the following 1175 sections, the client might need to split the reference identifier 1176 into its DNS domain name portion and its service type portion, as 1177 follows: 1179 o A reference identifier of type DNS-ID does not include a service 1180 type portion and thus can be used directly as the DNS domain name 1181 for comparison purposes. As an example, a DNS-ID of 1182 "www.example.com" would result in a DNS domain name portion of 1183 "www.example.com". 1185 o A reference identifier of type CN-ID also does not include a 1186 service type portion and thus can be used directly as the DNS 1187 domain name for comparison purposes. As previously mentioned, 1188 this document specifies that a CN-ID always contains a string 1189 whose form matches that of a DNS domain name (thus differentiating 1190 a CN-ID from a Common Name containing a human-friendly name). 1192 o For a reference identifier of type SRV-ID, the DNS domain name 1193 portion is the Name and the service type portion is the Service. 1194 As an example, an SRV-ID of "_imaps.example.net" would be split 1195 into a DNS domain name portion of "example.net" and a service type 1196 portion of "imaps" (mapping to an application protocol of IMAP as 1197 explained in [EMAIL-SRV]). 1199 o For a reference identifier of type URI-ID, the DNS domain name 1200 portion is the "reg-name" part of the "host" component (or its 1201 equivalent) and the service type portion is the service type 1202 associated with the scheme name matching the [ABNF] "scheme" rule 1203 from [URI] (not including the ':' separator). As previously 1204 mentioned, this document specifies that a URI-ID always contains a 1205 "host" component (or its equivalent) containing a "reg-name". 1206 (Matching only the "reg-name" rule from [URI] limits verification 1207 to DNS domain names, thereby differentiating a URI-ID from a 1208 uniformResourceIdentifier entry that contains an IP address or a 1209 mere host name, or that does not contain a "host" component at 1210 all.) Furthermore, note that extraction of the "reg-name" might 1211 necessitate normalization of the URI (as explained in [URI]). As 1212 an example, a URI-ID of "sip:voice.example.edu" would be split 1213 into a DNS domain name portion of "voice.example.edu" and a 1214 service type of "sip" (associated with an application protocol of 1215 SIP as explained in [SIP-CERTS]). 1217 Detailed comparison rules for matching the DNS domain name portion 1218 and service type portion of the reference identifier are provided in 1219 the following sections. 1221 6.4. Matching the DNS Domain Name Portion 1223 The client MUST match the DNS domain name portion of a reference 1224 identifier according to the following rules (and SHOULD also check 1225 the service type as described under Section 6.5). The rules differ 1226 depending on whether the domain to be checked is a "traditional 1227 domain name" or an "internationalized domain name" (as defined under 1228 Section 2.2). Furthermore, to meet the needs of clients that support 1229 presented identifiers containing the wildcard character '*', we 1230 define a supplemental rule for so-called "wildcard certificates". 1231 Finally, we also specify the circumstances under which it is 1232 acceptable to check the "CN-ID" identifier type. 1234 6.4.1. Checking of Traditional Domain Names 1236 If the DNS domain name portion of a reference identifier is a 1237 "traditional domain name", then matching of the reference identifier 1238 against the presented identifier is performed by comparing the set of 1239 domain name labels using a case-insensitive ASCII comparison, as 1240 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 1241 to "www.example.com" for comparison purposes). Each label MUST match 1242 in order for the names to be considered to match, except as 1243 supplemented by the rule about checking of wildcard labels 1244 (Section 6.4.3). 1246 6.4.2. Checking of Internationalized Domain Names 1248 If the DNS domain name portion of a reference identifier is an 1249 internationalized domain name, then an implementation MUST convert 1250 any U-labels [IDNA-DEFS] in the domain name to A-labels before 1251 checking the domain name. In accordance with [IDNA-PROTO], A-labels 1252 MUST be compared as case-insensitive ASCII. Each label MUST match in 1253 order for the domain names to be considered to match, except as 1254 supplemented by the rule about checking of wildcard labels 1255 (Section 6.4.3; but see also Section 7.2 regarding wildcards in 1256 internationalized domain names). 1258 6.4.3. Checking of Wildcard Certificates 1260 A client employing this specification's rules MAY match the reference 1261 identifier against a presented identifier whose DNS domain name 1262 portion contains the wildcard character '*' as part or all of a label 1263 (following the definition of "label" from [DNS-CONCEPTS]). 1265 For information regarding the security characteristics of wildcard 1266 certificates, see Section 7.2. 1268 If a client matches the reference identifier against a presented 1269 identifier whose DNS domain name portion contains the wildcard 1270 character '*', the following rules apply: 1272 1. The client SHOULD NOT attempt to match a presented identifier in 1273 which the wildcard character comprises a label other than the 1274 left-most label (e.g., do not match bar.*.example.net). 1276 2. If the wildcard character is the only character of the left-most 1277 label in the presented identifier, the client SHOULD NOT compare 1278 against anything but the left-most label of the reference 1279 identifier (e.g., *.example.com would match foo.example.com but 1280 not bar.foo.example.com or example.com). 1282 3. The client MAY match a presented identifier in which the wildcard 1283 character is not the only character of the label (e.g., 1284 baz*.example.net and *baz.example.net and b*z.example.net would 1285 be taken to match baz1.example.net and foobaz.example.net and 1286 buzz.example.net, respectively). However, the client SHOULD NOT 1287 attempt to match a presented identifier where the wildcard 1288 character is embedded within an A-label or U-label [IDNA-DEFS] of 1289 an internationalized domain name [IDNA-PROTO]. 1291 6.4.4. Checking of Common Names 1293 As noted, a client MUST NOT seek a match for a reference identifier 1294 of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, 1295 URI-ID, or any application-specific identifier types supported by the 1296 client. 1298 Therefore, if and only if the presented identifiers do not include a 1299 DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types 1300 supported by the client, then the client MAY as a last resort check 1301 for a string whose form matches that of a fully-qualified DNS domain 1302 name in a Common Name field of the subject field (i.e., a CN-ID). If 1303 the client chooses to compare a reference identifier of type CN-ID 1304 against that string, it MUST follow the comparison rules for the DNS 1305 domain name portion of an identifier of type DNS-ID, SRV-ID, or 1306 URI-ID, as described under Section 6.4.1, Section 6.4.2, and 1307 Section 6.4.3. 1309 6.5. Matching the Application Type Portion 1311 If a client supports checking of identifiers of type SRV-ID and 1312 URI-ID, it MUST also check the service type of the application 1313 service with which it communicates (in addition to checking the 1314 domain name as described above). This is a best practice because 1315 typically a client is not designed to communicate with all kinds of 1316 services using all possible application protocols, but instead is 1317 designed to communicate with one kind of service, such as websites, 1318 email services, VoIP services, or IM services. 1320 The service type is verified by means of an SRV-ID or a URI-ID. 1322 6.5.1. SRV-ID 1324 The service name portion of an SRV-ID (e.g., "imaps") MUST be matched 1325 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 1326 that the "_" character is prepended to the service identifier in DNS 1327 SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to 1328 be included in any comparison. 1330 6.5.2. URI-ID 1332 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1333 a case-insensitive manner, in accordance with [URI]. Note that the 1334 ":" character is a separator between the scheme name and the rest of 1335 the URI, and thus does not need to be included in any comparison. 1337 6.6. Outcome 1339 The outcome of the matching procedure is one of the following cases. 1341 6.6.1. Case #1: Match Found 1343 If the client has found a presented identifier that matches a 1344 reference identifier, then the service identity check has succeeded. 1345 In this case, the client MUST use the matched reference identifier as 1346 the validated identity of the application service. 1348 6.6.2. Case #2: No Match Found, Pinned Certificate 1350 If the client does not find a presented identifier matching any of 1351 the reference identifiers but the client has previously pinned the 1352 application service's certificate to one of the reference identifiers 1353 in the list it constructed for this communication attempt (as 1354 "pinning" is explained under Section 1.8), and the presented 1355 certificate matches the pinned certificate (including the context as 1356 described under Section 7.1), then the service identity check has 1357 succeeded. 1359 6.6.3. Case #3: No Match Found, No Pinned Certificate 1361 If the client does not find a presented identifier matching any of 1362 the reference identifiers and the client has not previously pinned 1363 the certificate to one of the reference identifiers in the list it 1364 constructed for this communication attempt, then the client MUST 1365 proceed as described under Section 6.6.4. 1367 6.6.4. Fallback 1369 If the client is an interactive client that is directly controlled by 1370 a human user, then it SHOULD inform the user of the identity mismatch 1371 and automatically terminate the communication attempt with a bad 1372 certificate error; this behavior is preferable because it prevents 1373 users from inadvertently bypassing security protections in hostile 1374 situations. 1376 Security Warning: Some interactive clients give advanced users the 1377 option of proceeding with acceptance despite the identity 1378 mismatch, thereby "pinning" the certificate to one of the 1379 reference identifiers in the list constructed by the client for 1380 this communication attempt. Although this behavior can be 1381 appropriate in certain specialized circumstances, in general it 1382 ought to be exposed only to advanced users. Even then it needs to 1383 be handled with extreme caution, for example by first encouraging 1384 even an advanced user to terminate the communication attempt and, 1385 if the advanced user chooses to proceed anyway, by forcing the 1386 user to view the entire certification path and only then allowing 1387 the user to pin the certificate (on a temporary or permanent 1388 basis, at the user's option). 1390 Otherwise, if the client is an automated application not directly 1391 controlled by a human user, then it SHOULD terminate the 1392 communication attempt with a bad certificate error and log the error 1393 appropriately. An automated application MAY provide a configuration 1394 setting that disables this behavior, but MUST enable the behavior by 1395 default. 1397 7. Security Considerations 1399 7.1. Pinned Certificates 1401 As defined under Section 1.8, a certificate is said to be "pinned" to 1402 a DNS domain name when a user has explicitly chosen to associate a 1403 service's certificate with that DNS domain name despite the fact that 1404 the certificate contains some other DNS domain name (e.g., the user 1405 has explicitly approved "apps.example.net" as a domain associated 1406 with a source domain of "example.com"). The cached name association 1407 MUST take account of both the certificate presented and the context 1408 in which it was accepted or configured (where the "context" includes 1409 the chain of certificates from the presented certificate to the trust 1410 anchor, the source domain, the service type, the service's derived 1411 domain and port number, and any other relevant information provided 1412 by the user or associated by the client). 1414 7.2. Wildcard Certificates 1416 This document states that the wildcard character '*' SHOULD NOT be 1417 included in presented identifiers but MAY be checked by application 1418 clients (mainly for the sake of backward compatibility with deployed 1419 infrastructure); as a result, the rules provided in this document are 1420 more restrictive than the rules for many existing application 1421 technologies (such as those excerpted under Appendix B). Several 1422 security considerations justify tightening the rules: 1424 o Wildcard certificates automatically vouch for any and all host 1425 names within their domain. This can be convenient for 1426 administrators but also poses the risk of vouching for rogue or 1427 buggy hosts. See for example [Defeating-SSL] (beginning at slide 1428 91) and [HTTPSbytes] (slides 38-40). 1430 o Specifications for existing application technologies are not clear 1431 or consistent about the allowable location of the wildcard 1432 character, such as whether it can be: 1434 * only the complete left-most label (e.g., *.example.com) 1436 * some fragment of the left-most label (e.g., foo*.example.com, 1437 f*o.example.com, or *oo.example.com) 1439 * all or part of a label other than the left-most label (e.g., 1440 www.*.example.com or www.foo*.example.com) 1442 * all or part of a label that identifies a so-called "public 1443 suffix" (e.g., *.co.uk or *.com) 1445 * included more than once in a given label (e.g., 1446 f*b*r.example.com 1448 * included as all or part of more than one label (e.g., 1449 *.*.example.com) 1451 These ambiguities might introduce exploitable differences in 1452 identity checking behavior among client implementations and 1453 necessitate overly complex and inefficient identity checking 1454 algorithms. 1456 o There is no specification that defines how the wildcard character 1457 may be embedded within the A-labels or U-labels [IDNA-DEFS] of an 1458 internationalized domain name [IDNA-PROTO]; as a result, 1459 implementations are strongly discouraged from including or 1460 attempting to check for the wildcard character embedded within the 1461 A-labels or U-labels of an internationalized domain name (e.g., 1462 "xn--kcry6tjko*.example.org"). Note, however, that a presented 1463 domain name identifier MAY contain the wildcard character as long 1464 as that character occupies the entire left-most label position, 1465 where all of the remaining labels are valid NR-LDH labels, 1466 A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). 1468 Notwithstanding the foregoing security considerations, specifications 1469 that re-use this one can legitimately encourage continued support for 1470 the wildcard character if they have good reasons to do so, such as 1471 backward compatibility with deployed infrastructure (see, for 1472 example, [EV-CERTS]). 1474 7.3. Internationalized Domain Names 1476 Allowing internationalized domain names can lead to the inclusion of 1477 visually similar (so-called "confusable") characters in certificates; 1478 for discussion, see for example [IDNA-DEFS]. 1480 7.4. Multiple Identifiers 1482 A given application service might be addressed by multiple DNS domain 1483 names for a variety of reasons, and a given deployment might service 1484 multiple domains (e.g., in so-called "virtual hosting" environments). 1485 In the default TLS handshake exchange, the client is not able to 1486 indicate the DNS domain name with which it wants to communicate, and 1487 the TLS server returns only one certificate for itself. Absent an 1488 extension to TLS, a typical workaround used to facilitate mapping an 1489 application service to multiple DNS domain names is to embed all of 1490 the domain names into a single certificate. 1492 A more recent approach, formally specified in [TLS-EXT], is for the 1493 client to use the TLS "Server Name Indication" (SNI) extension when 1494 sending the client_hello message, stipulating the DNS domain name it 1495 desires or expects of the service. The service can then return the 1496 appropriate certificate in its Certificate message, and that 1497 certificate can represent a single DNS domain name. 1499 To accommodate the workaround that was needed before the development 1500 of the SNI extension, this specification allows multiple DNS-IDs, 1501 SRV-IDs, or URI-IDs in a certificate; however, it explicitly 1502 discourages multiple CN-IDs. Although it would be preferable to 1503 forbid multiple CN-IDs entirely, there are several reasons at this 1504 time why this specification states that they SHOULD NOT (instead of 1505 MUST NOT) be included: 1507 o At least one significant technology community of interest 1508 explicitly allows multiple CN-IDs [EV-CERTS]. 1510 o At least one significant certification authority is known to issue 1511 certificates containing multiple CN-IDs. 1513 o Many service providers often deem inclusion of multiple CN-IDs 1514 necessary in virtual hosting environments because at least one 1515 widely-deployed operating system does not yet support the SNI 1516 extension. 1518 It is hoped that the recommendation regarding multiple CN-IDs can be 1519 further tightened in the future. 1521 8. IANA Considerations 1523 This document specifies no actions for the IANA. 1525 9. Contributors 1527 The following individuals made important contributions to the text of 1528 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 1530 10. Acknowledgements 1532 The editors and contributors wish to thank the following individuals 1533 for their feedback and suggestions: Bernard Aboba, Richard Barnes, 1534 Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott 1535 Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus 1536 Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno 1537 Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love 1538 Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, 1539 Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott 1540 Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, 1541 Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, 1542 Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe 1543 Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael 1544 Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul 1545 Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and 1546 Stefan Winter. 1548 Thanks also to Barry Leiba and Ben Campbell for their reviews on 1549 behalf of the Security Directorate and the General Area Review Team, 1550 respectively. 1552 The responsible Area Director was Alexey Melnikov. 1554 11. References 1556 11.1. Normative References 1558 [DNS] Mockapetris, P., "Domain names - implementation and 1559 specification", STD 13, RFC 1035, November 1987. 1561 [DNS-CONCEPTS] 1562 Mockapetris, P., "Domain names - concepts and facilities", 1563 STD 13, RFC 1034, November 1987. 1565 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1566 specifying the location of services (DNS SRV)", RFC 2782, 1567 February 2000. 1569 [IDNA-DEFS] 1570 Klensin, J., "Internationalized Domain Names for 1571 Applications (IDNA): Definitions and Document Framework", 1572 RFC 5890, August 2010. 1574 [IDNA-PROTO] 1575 Klensin, J., "Internationalized Domain Names in 1576 Applications (IDNA): Protocol", RFC 5891, August 2010. 1578 [KEYWORDS] 1579 Bradner, S., "Key words for use in RFCs to Indicate 1580 Requirement Levels", BCP 14, RFC 2119, March 1997. 1582 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 1583 (LDAP): String Representation of Distinguished Names", 1584 RFC 4514, June 2006. 1586 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1587 Housley, R., and W. Polk, "Internet X.509 Public Key 1588 Infrastructure Certificate and Certificate Revocation List 1589 (CRL) Profile", RFC 5280, May 2008. 1591 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1592 Subject Alternative Name for Expression of Service Name", 1593 RFC 4985, August 2007. 1595 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1596 Resource Identifier (URI): Generic Syntax", STD 66, 1597 RFC 3986, January 2005. 1599 11.2. Informative References 1601 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1602 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1604 [HTTPSbytes] 1605 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1606 Dhabi, November 2010, . 1611 [Defeating-SSL] 1612 Marlinspike, M., "New Tricks for Defeating SSL in 1613 Practice", BlackHat DC, February 2009, . 1617 [DNS-CASE] 1618 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 1619 Clarification", RFC 4343, January 2006. 1621 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1622 Rose, "DNS Security Introduction and Requirements", 1623 RFC 4033, March 2005. 1625 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1626 Security", RFC 4347, April 2006. 1628 [EMAIL-SRV] 1629 Daboo, C., "Use of SRV Records for Locating Email 1630 Submission/Access services", draft-daboo-srv-email-05 1631 (work in progress), May 2010. 1633 [EV-CERTS] 1634 CA/Browser Forum, "Guidelines For The Issuance And 1635 Management Of Extended Validation Certificates", 1636 October 2009, 1637 . 1639 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1640 Signalling Transport", RFC 5971, October 2010. 1642 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1643 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1644 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1646 [HTTP-TLS] 1647 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1649 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1650 4rev1", RFC 3501, March 2003. 1652 [IDNA2003] 1653 Faltstrom, P., Hoffman, P., and A. Costello, 1654 "Internationalizing Domain Names in Applications (IDNA)", 1655 RFC 3490, March 2003. 1657 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1658 September 1981. 1660 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1661 (IPv6) Specification", RFC 2460, December 1998. 1663 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1664 Internet Protocol", RFC 4301, December 2005. 1666 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1667 (LDAP): The Protocol", RFC 4511, June 2006. 1669 [LDAP-AUTH] 1670 Harrison, R., "Lightweight Directory Access Protocol 1671 (LDAP): Authentication Methods and Security Mechanisms", 1672 RFC 4513, June 2006. 1674 [LDAP-SCHEMA] 1675 Sciberras, A., "Lightweight Directory Access Protocol 1676 (LDAP): Schema for User Applications", RFC 4519, 1677 June 2006. 1679 [LDAP-TLS] 1680 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1681 Directory Access Protocol (v3): Extension for Transport 1682 Layer Security", RFC 2830, May 2000. 1684 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1685 Part Three: The Domain Name System (DNS) Database", 1686 RFC 3403, October 2002. 1688 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1689 December 2006. 1691 [NETCONF-SSH] 1692 Wasserman, M. and T. Goddard, "Using the NETCONF 1693 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1694 December 2006. 1696 [NETCONF-TLS] 1697 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1698 RFC 5539, May 2009. 1700 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1701 RFC 3977, October 2006. 1703 [NNTP-TLS] 1704 Murchison, K., Vinocur, J., and C. Newman, "Using 1705 Transport Layer Security (TLS) with Network News Transfer 1706 Protocol (NNTP)", RFC 4642, October 2006. 1708 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1709 Adams, "X.509 Internet Public Key Infrastructure Online 1710 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1712 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1713 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1715 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1716 STD 53, RFC 1939, May 1996. 1718 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1719 E. Lear, "Address Allocation for Private Internets", 1720 BCP 5, RFC 1918, February 1996. 1722 [PKIX-OLD] 1723 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1724 X.509 Public Key Infrastructure Certificate and CRL 1725 Profile", RFC 2459, January 1999. 1727 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1728 Service Location Using SRV RRs and the Dynamic Delegation 1729 Discovery Service (DDDS)", RFC 3958, January 2005. 1731 [SECTERMS] 1732 Shirey, R., "Internet Security Glossary, Version 2", 1733 RFC 4949, August 2007. 1735 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1736 A., Peterson, J., Sparks, R., Handley, M., and E. 1737 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1738 June 2002. 1740 [SIP-CERTS] 1741 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1742 Certificates in the Session Initiation Protocol (SIP)", 1743 RFC 5922, June 2010. 1745 [SIP-SIPS] 1746 Audet, F., "The Use of the SIPS URI Scheme in the Session 1747 Initiation Protocol (SIP)", RFC 5630, October 2009. 1749 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1750 October 2008. 1752 [SMTP-AUTH] 1753 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1754 for Authentication", RFC 4954, July 2007. 1756 [SMTP-TLS] 1757 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1758 Transport Layer Security", RFC 3207, February 2002. 1760 [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An 1761 Architecture for Describing Simple Network Management 1762 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1763 December 2002. 1765 [SNMP-TLS] 1766 Hardaker, W., "Transport Layer Security (TLS) Transport 1767 Model for the Simple Network Management Protocol (SNMP)", 1768 RFC 5953, August 2010. 1770 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1772 [SYSLOG-DTLS] 1773 Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1774 "Datagram Transport Layer Security (DTLS) Transport 1775 Mapping for Syslog", RFC 6012, October 2010. 1777 [SYSLOG-TLS] 1778 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1779 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1780 March 2009. 1782 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1783 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1785 [TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions: 1786 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 1787 (work in progress), September 2010. 1789 [US-ASCII] 1790 American National Standards Institute, "Coded Character 1791 Set - 7-bit American Standard Code for Information 1792 Interchange", ANSI X3.4, 1986. 1794 [USINGTLS] 1795 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1796 RFC 2595, June 1999. 1798 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1799 Interface Guidelines", World Wide Web Consortium 1800 LastCall WD-wsc-ui-20100309, March 2010, 1801 . 1803 [X.500] International Telecommunications Union, "Information 1804 Technology - Open Systems Interconnection - The Directory: 1805 Overview of concepts, models and services", ITU- 1806 T Recommendation X.500, ISO Standard 9594-1, August 2005. 1808 [X.501] International Telecommunications Union, "Information 1809 Technology - Open Systems Interconnection - The Directory: 1810 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1811 August 2005. 1813 [X.509] International Telecommunications Union, "Information 1814 Technology - Open Systems Interconnection - The Directory: 1815 Public-key and attribute certificate frameworks", ITU- 1816 T Recommendation X.509, ISO Standard 9594-8, August 2005. 1818 [X.520] International Telecommunications Union, "Information 1819 Technology - Open Systems Interconnection - The Directory: 1820 Selected attribute types", ITU-T Recommendation X.509, 1821 ISO Standard 9594-6, August 2005. 1823 [X.690] International Telecommunications Union, "Information 1824 Technology - ASN.1 encoding rules: Specification of Basic 1825 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1826 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1827 X.690, ISO Standard 8825-1, August 2008. 1829 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1830 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-22 (work 1831 in progress), December 2010. 1833 [XMPP-OLD] 1834 Saint-Andre, P., Ed., "Extensible Messaging and Presence 1835 Protocol (XMPP): Core", RFC 3920, October 2004. 1837 Appendix A. Sample Text 1839 At the time of this writing, two application technologies re-use the 1840 recommendations in this specfication: email [EMAIL-SRV] and XMPP 1841 [XMPP]. Here we include the text from [XMPP] to illustrate the 1842 thought process that might be followed by protocol designers for 1843 other application technologies. Specifically, because XMPP uses DNS 1844 SRV records for resolution of the DNS domain names for application 1845 services, the XMPP specification recommends the use of SRV-IDs. 1847 The text regarding certificate issuance is as follows: 1849 ###### 1851 In a PKIX certificate to be presented by an XMPP server (i.e., a 1852 "server certificate"), the certificate MUST include one or more XMPP 1853 addresses (i.e., domainparts) associated with XMPP services hosted at 1854 the server. The rules and guidelines defined in [this specification] 1855 apply to XMPP server certificates, with the following XMPP-specific 1856 considerations: 1858 o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP 1859 client and server software implementations. Certification 1860 authorities that issue XMPP-specific certificates MUST support the 1861 DNS-ID identifier type. XMPP service providers SHOULD include the 1862 DNS-ID identifier type in certificate requests. 1864 o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for 1865 XMPP client and server software implementations (for verification 1866 purposes XMPP client implementations need to support only the 1867 "_xmpp-client" service type, whereas XMPP server implementations 1868 need to support both the "_xmpp-client" and "_xmpp-server" service 1869 types). Certification authorities that issue XMPP-specific 1870 certificates SHOULD support the SRV-ID identifier type. XMPP 1871 service providers SHOULD include the SRV-ID identifier type in 1872 certificate requests. 1874 o Support for the XmppAddr identifier type is encouraged in XMPP 1875 client and server software implementations for the sake of 1876 backward-compatibility, but is no longer encouraged in 1877 certificates issued by certification authorities or requested by 1878 XMPP service providers. 1880 o DNS domain names in server certificates MAY contain the wildcard 1881 character '*' as the complete left-most label within the 1882 identifier. 1884 ###### 1886 The text regarding certificate verification is as follows: 1888 ###### 1890 For server certificates, the rules and guidelines defined in [this 1891 specification] apply, with the proviso that the XmppAddr identifier 1892 is allowed as a reference identifier. 1894 The identities to be checked are set as follows: 1896 o The initiating entity sets its reference identifier to the 'to' 1897 address it communicates in the initial stream header; i.e., this 1898 is the identity it expects the receiving entity to provide in a 1899 PKIX certificate. 1901 o The receiving entity sets its reference identifier to the 'from' 1902 address communicated by the initiating entity in the initial 1903 stream header; i.e., this is the identity that the initiating 1904 entity is trying to assert. 1906 ###### 1908 Appendix B. Prior Art 1910 (This section is non-normative.) 1912 The recommendations in this document are an abstraction from 1913 recommendations in specifications for a wide range of application 1914 protocols. For the purpose of comparison and to delineate the 1915 history of thinking about application service identity verification 1916 within the IETF, this informative section gathers together prior art 1917 by including the exact text from various RFCs (the only modifications 1918 are changes to the names of several references to maintain coherence 1919 with the main body of this document, and the elision of irrelevant 1920 text as marked by the characters "[...]"). 1922 B.1. IMAP, POP3, and ACAP (1999) 1924 In 1999, [USINGTLS] specified the following text regarding 1925 application service identity verification in IMAP, POP3, and ACAP: 1927 ###### 1929 2.4. Server Identity Check 1931 During the TLS negotiation, the client MUST check its understanding 1932 of the server hostname against the server's identity as presented in 1933 the server Certificate message, in order to prevent man-in-the-middle 1934 attacks. Matching is performed according to these rules: 1936 o The client MUST use the server hostname it used to open the 1937 connection as the value to compare against the server name as 1938 expressed in the server certificate. The client MUST NOT use any 1939 form of the server hostname derived from an insecure remote source 1940 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1941 o If a subjectAltName extension of type dNSName is present in the 1942 certificate, it SHOULD be used as the source of the server's 1943 identity. 1944 o Matching is case-insensitive. 1945 o A "*" wildcard character MAY be used as the left-most name 1946 component in the certificate. For example, *.example.com would 1947 match a.example.com, foo.example.com, etc. but would not match 1948 example.com. 1949 o If the certificate contains multiple names (e.g. more than one 1950 dNSName field), then a match with any one of the fields is 1951 considered acceptable. 1953 If the match fails, the client SHOULD either ask for explicit user 1954 confirmation, or terminate the connection and indicate the server's 1955 identity is suspect. 1957 ###### 1959 B.2. HTTP (2000) 1961 In 2000, [HTTP-TLS] specified the following text regarding 1962 application service identity verification in HTTP: 1964 ###### 1966 3.1. Server Identity 1968 In general, HTTP/TLS requests are generated by dereferencing a URI. 1969 As a consequence, the hostname for the server is known to the client. 1970 If the hostname is available, the client MUST check it against the 1971 server's identity as presented in the server's Certificate message, 1972 in order to prevent man-in-the-middle attacks. 1974 If the client has external information as to the expected identity of 1975 the server, the hostname check MAY be omitted. (For instance, a 1976 client may be connecting to a machine whose address and hostname are 1977 dynamic but the client knows the certificate that the server will 1978 present.) In such cases, it is important to narrow the scope of 1979 acceptable certificates as much as possible in order to prevent man 1980 in the middle attacks. In special cases, it may be appropriate for 1981 the client to simply ignore the server's identity, but it must be 1982 understood that this leaves the connection open to active attack. 1984 If a subjectAltName extension of type dNSName is present, that MUST 1985 be used as the identity. Otherwise, the (most specific) Common Name 1986 field in the Subject field of the certificate MUST be used. Although 1987 the use of the Common Name is existing practice, it is deprecated and 1988 Certification Authorities are encouraged to use the dNSName instead. 1990 Matching is performed using the matching rules specified by 1991 [PKIX-OLD]. If more than one identity of a given type is present in 1992 the certificate (e.g., more than one dNSName name, a match in any one 1993 of the set is considered acceptable.) Names may contain the wildcard 1994 character * which is considered to match any single domain name 1995 component or component fragment. E.g., *.a.com matches foo.a.com but 1996 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1998 In some cases, the URI is specified as an IP address rather than a 1999 hostname. In this case, the iPAddress subjectAltName must be present 2000 in the certificate and must exactly match the IP in the URI. 2002 If the hostname does not match the identity in the certificate, user 2003 oriented clients MUST either notify the user (clients MAY give the 2004 user the opportunity to continue with the connection in any case) or 2005 terminate the connection with a bad certificate error. Automated 2006 clients MUST log the error to an appropriate audit log (if available) 2007 and SHOULD terminate the connection (with a bad certificate error). 2008 Automated clients MAY provide a configuration setting that disables 2009 this check, but MUST provide a setting which enables it. 2011 Note that in many cases the URI itself comes from an untrusted 2012 source. The above-described check provides no protection against 2013 attacks where this source is compromised. For example, if the URI 2014 was obtained by clicking on an HTML page which was itself obtained 2015 without using HTTP/TLS, a man in the middle could have replaced the 2016 URI. In order to prevent this form of attack, users should carefully 2017 examine the certificate presented by the server to determine if it 2018 meets their expectations. 2020 ###### 2022 B.3. LDAP (2000/2006) 2024 In 2000, [LDAP-TLS] specified the following text regarding 2025 application service identity verification in LDAP: 2027 ###### 2029 3.6. Server Identity Check 2031 The client MUST check its understanding of the server's hostname 2032 against the server's identity as presented in the server's 2033 Certificate message, in order to prevent man-in-the-middle attacks. 2035 Matching is performed according to these rules: 2037 o The client MUST use the server hostname it used to open the LDAP 2038 connection as the value to compare against the server name as 2039 expressed in the server's certificate. The client MUST NOT use 2040 the server's canonical DNS name or any other derived form of name. 2041 o If a subjectAltName extension of type dNSName is present in the 2042 certificate, it SHOULD be used as the source of the server's 2043 identity. 2044 o Matching is case-insensitive. 2045 o The "*" wildcard character is allowed. If present, it applies 2046 only to the left-most name component. 2048 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 2049 bar.com. If more than one identity of a given type is present in the 2050 certificate (e.g. more than one dNSName name), a match in any one of 2051 the set is considered acceptable. 2053 If the hostname does not match the dNSName-based identity in the 2054 certificate per the above check, user-oriented clients SHOULD either 2055 notify the user (clients MAY give the user the opportunity to 2056 continue with the connection in any case) or terminate the connection 2057 and indicate that the server's identity is suspect. Automated 2058 clients SHOULD close the connection, returning and/or logging an 2059 error indicating that the server's identity is suspect. 2061 Beyond the server identity checks described in this section, clients 2062 SHOULD be prepared to do further checking to ensure that the server 2063 is authorized to provide the service it is observed to provide. The 2064 client MAY need to make use of local policy information. 2066 ###### 2068 In 2006, [LDAP-AUTH] specified the following text regarding 2069 application service identity verification in LDAP: 2071 ###### 2073 3.1.3. Server Identity Check 2075 In order to prevent man-in-the-middle attacks, the client MUST verify 2076 the server's identity (as presented in the server's Certificate 2077 message). In this section, the client's understanding of the 2078 server's identity (typically the identity used to establish the 2079 transport connection) is called the "reference identity". 2081 The client determines the type (e.g., DNS name or IP address) of the 2082 reference identity and performs a comparison between the reference 2083 identity and each subjectAltName value of the corresponding type 2084 until a match is produced. Once a match is produced, the server's 2085 identity has been verified, and the server identity check is 2086 complete. Different subjectAltName types are matched in different 2087 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 2088 various subjectAltName types. 2090 The client may map the reference identity to a different type prior 2091 to performing a comparison. Mappings may be performed for all 2092 available subjectAltName types to which the reference identity can be 2093 mapped; however, the reference identity should only be mapped to 2094 types for which the mapping is either inherently secure (e.g., 2095 extracting the DNS name from a URI to compare with a subjectAltName 2096 of type dNSName) or for which the mapping is performed in a secure 2097 manner (e.g., using [DNSSEC], or using user- or admin-configured 2098 host-to-address/address-to-host lookup tables). 2100 The server's identity may also be verified by comparing the reference 2101 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 2102 Relative Distinguished Name (RDN) of the subject field of the 2103 server's certificate (where "last" refers to the DER-encoded order, 2104 not the order of presentation in a string representation of DER- 2105 encoded data). This comparison is performed using the rules for 2106 comparison of DNS names in Section 3.1.3.1, below, with the exception 2107 that no wildcard matching is allowed. Although the use of the Common 2108 Name value is existing practice, it is deprecated, and Certification 2109 Authorities are encouraged to provide subjectAltName values instead. 2110 Note that the TLS implementation may represent DNs in certificates 2111 according to X.500 or other conventions. For example, some X.500 2112 implementations order the RDNs in a DN using a left-to-right (most 2113 significant to least significant) convention instead of LDAP's right- 2114 to-left convention. 2116 If the server identity check fails, user-oriented clients SHOULD 2117 either notify the user (clients may give the user the opportunity to 2118 continue with the LDAP session in this case) or close the transport 2119 connection and indicate that the server's identity is suspect. 2120 Automated clients SHOULD close the transport connection and then 2121 return or log an error indicating that the server's identity is 2122 suspect or both. 2124 Beyond the server identity check described in this section, clients 2125 should be prepared to do further checking to ensure that the server 2126 is authorized to provide the service it is requested to provide. The 2127 client may need to make use of local policy information in making 2128 this determination. 2130 3.1.3.1. Comparison of DNS Names 2132 If the reference identity is an internationalized domain name, 2133 conforming implementations MUST convert it to the ASCII Compatible 2134 Encoding (ACE) format as specified in Section 4 of RFC 3490 2135 [IDNA2003] before comparison with subjectAltName values of type 2136 dNSName. Specifically, conforming implementations MUST perform the 2137 conversion operation specified in Section 4 of RFC 3490 as follows: 2139 o in step 1, the domain name SHALL be considered a "stored string"; 2140 o in step 3, set the flag called "UseSTD3ASCIIRules"; 2141 o in step 4, process each label with the "ToASCII" operation; and 2142 o in step 5, change all label separators to U+002E (full stop). 2144 After performing the "to-ASCII" conversion, the DNS labels and names 2145 MUST be compared for equality according to the rules specified in 2146 Section 3 of RFC3490. 2148 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 2149 values of type dNSName, and then only as the left-most (least 2150 significant) DNS label in that value. This wildcard matches any 2151 left-most DNS label in the server name. That is, the subject 2152 *.example.com matches the server names a.example.com and 2153 b.example.com, but does not match example.com or a.b.example.com. 2155 3.1.3.2. Comparison of IP Addresses 2157 When the reference identity is an IP address, the identity MUST be 2158 converted to the "network byte order" octet string representation 2159 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 2160 string will contain exactly four octets. For IP Version 6, as 2161 specified in RFC 2460, the octet string will contain exactly sixteen 2162 octets. This octet string is then compared against subjectAltName 2163 values of type iPAddress. A match occurs if the reference identity 2164 octet string and value octet strings are identical. 2166 3.1.3.3. Comparison of Other subjectName Types 2167 Client implementations MAY support matching against subjectAltName 2168 values of other types as described in other documents. 2170 ###### 2172 B.4. SMTP (2002/2007) 2174 In 2002, [SMTP-TLS] specified the following text regarding 2175 application service identity verification in SMTP: 2177 ###### 2179 4.1 Processing After the STARTTLS Command 2181 [...] 2183 The decision of whether or not to believe the authenticity of the 2184 other party in a TLS negotiation is a local matter. However, some 2185 general rules for the decisions are: 2187 o A SMTP client would probably only want to authenticate an SMTP 2188 server whose server certificate has a domain name that is the 2189 domain name that the client thought it was connecting to. 2191 [...] 2193 ###### 2195 In 2006, [SMTP-AUTH] specified the following text regarding 2196 application service identity verification in SMTP: 2198 ###### 2200 14. Additional Requirements When Using SASL PLAIN over TLS 2202 [...] 2204 After a successful [TLS] negotiation, the client MUST check its 2205 understanding of the server hostname against the server's identity as 2206 presented in the server Certificate message, in order to prevent man- 2207 in-the-middle attacks. If the match fails, the client MUST NOT 2208 attempt to authenticate using the SASL PLAIN mechanism. Matching is 2209 performed according to the following rules: 2211 The client MUST use the server hostname it used to open the 2212 connection as the value to compare against the server name as 2213 expressed in the server certificate. The client MUST NOT use any 2214 form of the server hostname derived from an insecure remote source 2215 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 2216 If a subjectAltName extension of type dNSName is present in the 2217 certificate, it SHOULD be used as the source of the server's 2218 identity. 2219 Matching is case-insensitive. 2220 A "*" wildcard character MAY be used as the leftmost name 2221 component in the certificate. For example, *.example.com would 2222 match a.example.com, foo.example.com, etc., but would not match 2223 example.com. 2224 If the certificate contains multiple names (e.g., more than one 2225 dNSName field), then a match with any one of the fields is 2226 considered acceptable. 2228 ###### 2230 B.5. XMPP (2004) 2232 In 2004, [XMPP-OLD] specified the following text regarding 2233 application service identity verification in XMPP: 2235 ###### 2237 14.2. Certificate Validation 2239 When an XMPP peer communicates with another peer securely, it MUST 2240 validate the peer's certificate. There are three possible cases: 2242 Case #1: The peer contains an End Entity certificate which appears 2243 to be certified by a certification path terminating in a trust 2244 anchor (as described in Section 6.1 of [PKIX]). 2245 Case #2: The peer certificate is certified by a Certificate 2246 Authority not known to the validating peer. 2247 Case #3: The peer certificate is self-signed. 2249 In Case #1, the validating peer MUST do one of two things: 2250 1. Verify the peer certificate according to the rules of [PKIX]. 2251 The certificate SHOULD then be checked against the expected 2252 identity of the peer following the rules described in [HTTP-TLS], 2253 except that a subjectAltName extension of type "xmpp" MUST be 2254 used as the identity if present. If one of these checks fails, 2255 user-oriented clients MUST either notify the user (clients MAY 2256 give the user the opportunity to continue with the connection in 2257 any case) or terminate the connection with a bad certificate 2258 error. Automated clients SHOULD terminate the connection (with a 2259 bad certificate error) and log the error to an appropriate audit 2260 log. Automated clients MAY provide a configuration setting that 2261 disables this check, but MUST provide a setting that enables it. 2263 2. The peer SHOULD show the certificate to a user for approval, 2264 including the entire certification path. The peer MUST cache the 2265 certificate (or some non-forgeable representation such as a 2266 hash). In future connections, the peer MUST verify that the same 2267 certificate was presented and MUST notify the user if it has 2268 changed. 2270 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 2272 ###### 2274 Although [XMPP-OLD] defined its own rules, [XMPP] re-uses the rules 2275 in this document regarding application service identity verification 2276 in XMPP. 2278 B.6. NNTP (2006) 2280 In 2006, [NNTP-TLS] specified the following text regarding 2281 application service identity verification in NNTP: 2283 ###### 2285 5. Security Considerations 2287 [...] 2289 During the TLS negotiation, the client MUST check its understanding 2290 of the server hostname against the server's identity as presented in 2291 the server Certificate message, in order to prevent man-in-the-middle 2292 attacks. Matching is performed according to these rules: 2294 o The client MUST use the server hostname it used to open the 2295 connection (or the hostname specified in TLS "server_name" 2296 extension [TLS]) as the value to compare against the server name 2297 as expressed in the server certificate. The client MUST NOT use 2298 any form of the server hostname derived from an insecure remote 2299 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2300 done. 2301 o If a subjectAltName extension of type dNSName is present in the 2302 certificate, it SHOULD be used as the source of the server's 2303 identity. 2304 o Matching is case-insensitive. 2305 o A "*" wildcard character MAY be used as the left-most name 2306 component in the certificate. For example, *.example.com would 2307 match a.example.com, foo.example.com, etc., but would not match 2308 example.com. 2310 o If the certificate contains multiple names (e.g., more than one 2311 dNSName field), then a match with any one of the fields is 2312 considered acceptable. 2314 If the match fails, the client SHOULD either ask for explicit user 2315 confirmation or terminate the connection with a QUIT command and 2316 indicate the server's identity is suspect. 2318 Additionally, clients MUST verify the binding between the identity of 2319 the servers to which they connect and the public keys presented by 2320 those servers. Clients SHOULD implement the algorithm in Section 6 2321 of [PKIX] for general certificate validation, but MAY supplement that 2322 algorithm with other validation methods that achieve equivalent 2323 levels of verification (such as comparing the server certificate 2324 against a local store of already-verified certificates and identity 2325 bindings). 2327 ###### 2329 B.7. NETCONF (2006/2009) 2331 In 2006, [NETCONF-SSH] specified the following text regarding 2332 application service identity verification in NETCONF: 2334 ###### 2336 6. Security Considerations 2338 The identity of the server MUST be verified and authenticated by the 2339 client according to local policy before password-based authentication 2340 data or any configuration or state data is sent to or received from 2341 the server. The identity of the client MUST also be verified and 2342 authenticated by the server according to local policy to ensure that 2343 the incoming client request is legitimate before any configuration or 2344 state data is sent to or received from the client. Neither side 2345 should establish a NETCONF over SSH connection with an unknown, 2346 unexpected, or incorrect identity on the opposite side. 2348 ###### 2350 In 2009, [NETCONF-TLS] specified the following text regarding 2351 application service identity verification in NETCONF: 2353 ###### 2355 3.1. Server Identity 2357 During the TLS negotiation, the client MUST carefully examine the 2358 certificate presented by the server to determine if it meets the 2359 client's expectations. Particularly, the client MUST check its 2360 understanding of the server hostname against the server's identity as 2361 presented in the server Certificate message, in order to prevent man- 2362 in-the-middle attacks. 2364 Matching is performed according to the rules below (following the 2365 example of [NNTP-TLS]): 2367 o The client MUST use the server hostname it used to open the 2368 connection (or the hostname specified in the TLS "server_name" 2369 extension [TLS]) as the value to compare against the server name 2370 as expressed in the server certificate. The client MUST NOT use 2371 any form of the server hostname derived from an insecure remote 2372 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2373 done. 2374 o If a subjectAltName extension of type dNSName is present in the 2375 certificate, it MUST be used as the source of the server's 2376 identity. 2377 o Matching is case-insensitive. 2378 o A "*" wildcard character MAY be used as the leftmost name 2379 component in the certificate. For example, *.example.com would 2380 match a.example.com, foo.example.com, etc., but would not match 2381 example.com. 2382 o If the certificate contains multiple names (e.g., more than one 2383 dNSName field), then a match with any one of the fields is 2384 considered acceptable. 2386 If the match fails, the client MUST either ask for explicit user 2387 confirmation or terminate the connection and indicate the server's 2388 identity is suspect. 2390 Additionally, clients MUST verify the binding between the identity of 2391 the servers to which they connect and the public keys presented by 2392 those servers. Clients SHOULD implement the algorithm in Section 6 2393 of [PKIX] for general certificate validation, but MAY supplement that 2394 algorithm with other validation methods that achieve equivalent 2395 levels of verification (such as comparing the server certificate 2396 against a local store of already-verified certificates and identity 2397 bindings). 2399 If the client has external information as to the expected identity of 2400 the server, the hostname check MAY be omitted. 2402 ###### 2404 B.8. Syslog (2009) 2406 In 2009, [SYSLOG-TLS] specified the following text regarding 2407 application service identity verification in Syslog: 2409 ###### 2411 5.2. Subject Name Authorization 2413 Implementations MUST support certification path validation [PKIX]. 2414 In addition, they MUST support specifying the authorized peers using 2415 locally configured host names and matching the name against the 2416 certificate as follows. 2418 o Implementations MUST support matching the locally configured host 2419 name against a dNSName in the subjectAltName extension field and 2420 SHOULD support checking the name against the common name portion 2421 of the subject distinguished name. 2422 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 2423 the subjectAltName extension (and in common name, if used to store 2424 the host name), but only as the left-most (least significant) DNS 2425 label in that value. This wildcard matches any left-most DNS 2426 label in the server name. That is, the subject *.example.com 2427 matches the server names a.example.com and b.example.com, but does 2428 not match example.com or a.b.example.com. Implementations MUST 2429 support wildcards in certificates as specified above, but MAY 2430 provide a configuration option to disable them. 2431 o Locally configured names MAY contain the wildcard character to 2432 match a range of values. The types of wildcards supported MAY be 2433 more flexible than those allowed in subject names, making it 2434 possible to support various policies for different environments. 2435 For example, a policy could allow for a trust-root-based 2436 authorization where all credentials issued by a particular CA 2437 trust root are authorized. 2438 o If the locally configured name is an internationalized domain 2439 name, conforming implementations MUST convert it to the ASCII 2440 Compatible Encoding (ACE) format for performing comparisons, as 2441 specified in Section 7 of [PKIX]. 2442 o Implementations MAY support matching a locally configured IP 2443 address against an iPAddress stored in the subjectAltName 2444 extension. In this case, the locally configured IP address is 2445 converted to an octet string as specified in [PKIX], Section 2446 4.2.1.6. A match occurs if this octet string is equal to the 2447 value of iPAddress in the subjectAltName extension. 2449 ###### 2451 B.9. SIP (2010) 2453 In 2010, [SIP-CERTS] specified the following text regarding 2454 application service identity verification in SIP: 2456 ###### 2458 7.2. Comparing SIP Identities 2460 When an implementation (either client or server) compares two values 2461 as SIP domain identities: 2462 Implementations MUST compare only the DNS name component of each 2463 SIP domain identifier; an implementation MUST NOT use any scheme 2464 or parameters in the comparison. 2465 Implementations MUST compare the values as DNS names, which means 2466 that the comparison is case insensitive as specified by 2467 [DNS-CASE]. Implementations MUST handle Internationalized Domain 2468 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 2469 Implementations MUST match the values in their entirety: 2470 Implementations MUST NOT match suffixes. For example, 2471 "foo.example.com" does not match "example.com". 2472 Implemenations MUST NOT match any form of wildcard, such as a 2473 leading "." or "*." with any other DNS label or sequence of 2474 labels. For example, "*.example.com" matches only 2475 "*.example.com" but not "foo.example.com". Similarly, 2476 ".example.com" matches only ".example.com", and does not match 2477 "foo.example.com." 2478 [HTTP-TLS] allows the dNSName component to contain a 2479 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 2480 disallowing this explicitly, leaves the interpretation of 2481 wildcards to the individual specification. [SIP] does not 2482 provide any guidelines on the presence of wildcards in 2483 certificates. Through the rule above, this document 2484 prohibits such wildcards in certificates for SIP domains. 2486 ###### 2488 B.10. SNMP (2010) 2490 In 2010, [SNMP-TLS] specified the following text regarding 2491 application service identity verification in SNMP: 2493 ###### 2495 If the server's presented certificate has passed certification path 2496 validation [PKIX] to a configured trust anchor, and an active row 2497 exists with a zero-length snmpTlstmAddrServerFingerprint value, then 2498 the snmpTlstmAddrServerIdentity column contains the expected host 2499 name. This expected host name is then compared against the server's 2500 certificate as follows: 2502 o Implementations MUST support matching the expected host name 2503 against a dNSName in the subjectAltName extension field and MAY 2504 support checking the name against the CommonName portion of the 2505 subject distinguished name. 2507 o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName 2508 of the subjectAltName extension (and in common name, if used to 2509 store the host name), but only as the left-most (least 2510 significant) DNS label in that value. This wildcard matches any 2511 left-most DNS label in the server name. That is, the subject 2512 *.example.com matches the server names a.example.com and 2513 b.example.com, but does not match example.com or a.b.example.com. 2514 Implementations MUST support wildcards in certificates as 2515 specified above, but MAY provide a configuration option to disable 2516 them. 2518 o If the locally configured name is an internationalized domain 2519 name, conforming implementations MUST convert it to the ASCII 2520 Compatible Encoding (ACE) format for performing comparisons, as 2521 specified in Section 7 of [PKIX]. 2523 If the expected host name fails these conditions then the connection 2524 MUST be closed. 2526 ###### 2528 B.11. GIST (2010) 2530 In 2010, [GIST] specified the following text regarding application 2531 service identity verification in the General Internet Signalling 2532 Transport: 2534 ###### 2536 5.7.3.1. Identity Checking in TLS 2538 After TLS authentication, a node MUST check the identity presented by 2539 the peer in order to avoid man-in-the-middle attacks, and verify that 2540 the peer is authorised to take part in signalling at the GIST layer. 2541 The authorisation check is carried out by comparing the presented 2542 identity with each Authorised Peer Database (APD) entry in turn, as 2543 discussed in Section 4.4.2. This section defines the identity 2544 comparison algorithm for a single APD entry. 2546 For TLS authentication with X.509 certificates, an identity from the 2547 DNS namespace MUST be checked against each subjectAltName extension 2548 of type dNSName present in the certificate. If no such extension is 2549 present, then the identity MUST be compared to the (most specific) 2550 Common Name in the Subject field of the certificate. When matching 2551 DNS names against dNSName or Common Name fields, matching is case- 2552 insensitive. Also, a "*" wildcard character MAY be used as the left- 2553 most name component in the certificate or identity in the APD. For 2554 example, *.example.com in the APD would match certificates for 2555 a.example.com, foo.example.com, *.example.com, etc., but would not 2556 match example.com. Similarly, a certificate for *.example.com would 2557 be valid for APD identities of a.example.com, foo.example.com, 2558 *.example.com, etc., but not example.com. 2560 Additionally, a node MUST verify the binding between the identity of 2561 the peer to which it connects and the public key presented by that 2562 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 2563 for general certificate validation, but MAY supplement that algorithm 2564 with other validation methods that achieve equivalent levels of 2565 verification (such as comparing the server certificate against a 2566 local store of already-verified certificates and identity bindings). 2568 For TLS authentication with pre-shared keys, the identity in the 2569 psk_identity_hint (for the server identity, i.e. the Responding node) 2570 or psk_identity (for the client identity, i.e. the Querying node) 2571 MUST be compared to the identities in the APD. 2573 ###### 2575 Authors' Addresses 2577 Peter Saint-Andre 2578 Cisco 2579 1899 Wyknoop Street, Suite 600 2580 Denver, CO 80202 2581 USA 2583 Phone: +1-303-308-3282 2584 Email: psaintan@cisco.com 2585 Jeff Hodges 2586 PayPal 2587 2211 North First Street 2588 San Jose, California 95131 2589 US 2591 Email: Jeff.Hodges@PayPal.com