idnits 2.17.00 (12 Aug 2021) /tmp/idnits9354/draft-saintandre-tls-server-id-check-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 30, 2010) is 4342 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: draft-ietf-idnabis-protocol has been published as RFC 5891 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: draft-ietf-idnabis-defs has been published as RFC 5890 -- 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) == Outdated reference: draft-ietf-sip-domain-certs has been published as RFC 5922 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 14 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 Systems, Inc. 4 Intended status: BCP J. Hodges 5 Expires: January 1, 2011 PayPal 6 June 30, 2010 8 Representation and Verification of Domain-Based Application Server 9 Identity in Certificates Used with Transport Layer Security 10 draft-saintandre-tls-server-id-check-07 12 Abstract 14 Many application technologies enable a secure connection between two 15 entities using certificates in the context of Transport Layer 16 Security (TLS). This document specifies best current practices for 17 representing and verifying the identity of application servers in 18 such interactions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 1, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 9 61 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 62 1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 63 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 2.1. Naming Applications . . . . . . . . . . . . . . . . . . . 10 65 2.2. Subject Naming in PKIX Certificates . . . . . . . . . . . 11 66 3. Representation of Server Identity . . . . . . . . . . . . . . 12 67 4. Verification of Server Identity . . . . . . . . . . . . . . . 13 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.2. Constructing an Ordered List of Reference Identifiers . . 14 70 4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 16 71 4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 16 72 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 16 73 4.4.2. Checking of Internationalized Domain Names . . . . . . 17 74 4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 17 75 4.4.4. Checking of DNS Domain Names in Common Names . . . . . 18 76 4.5. Verifying an Application Type . . . . . . . . . . . . . . 18 77 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 19 78 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 19 79 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 19 81 4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 19 82 4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 19 83 4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 20 84 4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 20 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 21 87 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 21 88 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 21 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 93 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 26 94 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 26 95 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 27 96 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 28 97 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 31 98 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 33 99 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 34 100 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 35 101 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 36 102 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 37 103 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 38 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 106 1. Introduction 108 1.1. Motivation 110 The visible face of the Internet consists of services that employ a 111 client-server architecture in which an interactive or automated 112 client connects to an application server in order to retrieve or 113 upload information, communicate with other entities, or access a 114 broader network of services. When a client connects to an 115 application server using Transport Layer Security [TLS] (or, less 116 commonly, [DTLS]), it references some conception of the server's 117 identity while attempting to establish a secure connection (e.g., 118 "the web site at example.com"). Likewise, during TLS negotiation the 119 server presents its conception of the server's identity in the form 120 of a public-key certificate that was issued by a certification 121 authority (CA) in the context of the Internet Public Key 122 Infrastructure using X.509 [PKIX]. Informally, we can think of these 123 identities as the client's "reference identity" and the server's 124 "presented identity" (these rough ideas are defined more precisely 125 later in this document through the concept of particular 126 identifiers). In general, a client needs to verify that the server's 127 presented identity matches its reference identity so that it can be 128 sure that the certificate can legitimately be used to authenticate 129 the connection. 131 Many application technologies adhere to the pattern outlined here, 132 including but not limited to the following: 134 o The Internet Message Access Protocol [IMAP] and the Post Office 135 Protocol [POP3], for which see also [USINGTLS] 137 o The Hypertext Transfer Protocol [HTTP], for which see also 138 [HTTP-TLS] 140 o The Lightweight Directory Access Protocol [LDAP], for which see 141 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 143 o The Simple Mail Transfer Protocol [SMTP], for which see also 144 [SMTP-AUTH] and [SMTP-TLS] 146 o The Extensible Messaging and Presence Protocol [XMPP], for which 147 see also [XMPPBIS] 149 o The Network News Transfer Protocol [NNTP], for which see also 150 [NNTP-TLS] 152 o The NETCONF Configuration Protocol [NETCONF], for which see also 153 [NETCONF-SSH] and [NETCONF-TLS] 155 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] 157 o The Session Initiation Protocol [SIP], for which see also 158 [SIP-CERTS] 160 o The General Internet Signalling Transport [GIST] 162 Application protocols have traditionally specified their own rules 163 for representing and verifying server identities. Unfortunately, 164 this divergence of approaches has caused some confusion among 165 certification authorities, application developers, and protocol 166 designers. 168 To codify best current practices regarding the implementation and 169 deployment of secure PKIX-based authentication, this document 170 specifies recommended procedures for representing and verifying 171 server identities in certificates intended for use in applications 172 employing TLS. 174 1.2. Scope 176 1.2.1. In Scope 178 This document applies only to server identities associated with 179 fully-qualified DNS domain names, only to TLS, and only to PKIX-based 180 systems. As a result, the scenarios described in the following 181 section are out of scope for this specification (although they might 182 be addressed by future specifications). 184 1.2.2. Out of Scope 186 o Client or end-user identities. 188 Certificates representing client or end-user identities (e.g., the 189 rfc822Name identifier) can be used for mutual authentication 190 between a client and server or between two clients, thus enabling 191 stronger client-server security or end-to-end security. However, 192 certification authorities, application developers, and service 193 operators have less experience with client certificates than with 194 server certificates, thus gives us fewer models from which to 195 generalize and a less solid basis for defining best practices. 197 o Identifiers other than fully-qualified DNS domain names (e.g., IP 198 addresses). 200 Some certification authorities issue server certificates based on 201 IP addresses, but preliminary evidence indicates that such 202 certificates are a very small percentage of issued certificates 203 (e.g., less than 1%). Furthermore, IP addresses are not 204 necessarily reliable identifiers for application servers because 205 of the existence of private internets [PRIVATE], host mobility, 206 multiple interfaces on a given host, Network Address Translators 207 (NATs) resulting in different addresses for a host from different 208 locations on the network, the practice of grouping many hosts 209 together behind a single IP address, etc. Most fundamentally, 210 most users find DNS domain names much easier to work with than IP 211 addresses, which is why the domain name system was designed in the 212 first place. We prefer to define best practices for the much more 213 common use case and not to complicate the rules in this 214 specification. 216 o Security protocols other than [TLS] or [DTLS]. 218 Although other secure, lower-layer protocols exist and also at 219 times employ PKIX certificates, e.g. [IPSEC], their use cases can 220 differ from those of TLS-based or DTLS-based application 221 technologies. Furtermore, application technologies have less 222 experience with IPsec than with TLS, thus making it more difficult 223 to gather feedback on proposed best practices. 225 o Keys or certificates employed outside the context of PKIX-based 226 systems. 228 Some deployed application technologies use a web of trust model 229 based on or similar to [OPENPGP], or use self-signed certificates, 230 or are deployed on networks are not directly connected to the 231 public Internet and therefore cannot depend on Certificate 232 Revocation Lists (CRLs) or the Online Certificate Status Protocol 233 [OCSP] to check CA-issued certificates. However, the syntax of 234 OpenPGP keys differs significantly from X.509 certificates, the 235 data in self-signed certificates has not been certified by a 236 third-party in any way, and checking of CA-issued certificates via 237 CRLs or OSCP is critically important to maintaining the security 238 of PKIX-based systems. Attempting to define best practices for 239 such technologies would unduly complicate the rules defined in 240 this specification. 242 Furthermore, this document also does not address various 243 certification authority policies, such as: 245 o What classes and types of certificates to issue and whether to 246 apply different policies for them (e.g., allow the wildcard 247 character in Class 2 certificates but not in Class 1 or Extended 248 Validation certificates). 250 o Whether to issue certificates based on IP addresses (or some other 251 form, such as relative domain names) in addition to fully- 252 qualified DNS domain names. 254 o Which identifiers to include (e.g., whether to include the SRVName 255 and uniformResourceIdentifier extensions). 257 o How to certify or validate the information contained in a 258 certificate. 260 Finally, this specification is mostly silent about user interface 261 issues, which in general are properly the responsibility of client 262 software developers and standards development organizations dedicated 263 to particular application technologies (see for example [WSC-UI]. 265 1.3. Terminology 267 Because the concept of "identity" is too vague to be actionable in 268 application protocols, we define a set of more concrete terms: 270 application server: A service on the Internet that enables 271 interactive clients and automated clients to connect for the 272 purpose of retrieving or uploading information, communicate with 273 other entities, or connect to a broader network of services. 275 automated client: A software agent or device that is not directly 276 controlled by a natural person. 278 direct name: A name that is provided directly to a client by a user. 280 identifier: A particular instance of an identifier type that is 281 either presented by a server in a certificate or referenced by a 282 client for matching purposes. 284 identifier type: A formally defined category of identifier that can 285 be included in a certificate and therefore also used for matching 286 purposes; the types covered in this specification are: 288 * CN-ID = a Relative Distinguished Name (RDN) in the certificate 289 subject that contains one and only one attribute-type-and-value 290 pair of type Common Name (CN) 292 * DNS-ID = a subjectAltName identifier of type dNSName 294 * SRV-ID = the SRVName form of otherName from the GeneralName 295 structure in SubjectAltName 297 * URI-ID = a subjectAltName identifier of type 298 uniformResourceIdentifier 300 indirect name: A name that is indirectly resolved by a client based 301 on a direct name provided by a user. 303 interactive client: A software agent or device that is directly 304 controlled by a natural person. (Other specifications related to 305 security and application protocols often refer to this as a "user 306 agent", e.g., [WSC-UI].) 308 PKIX certificate: An X.509v3 certificate generated and employed in 309 the context of the Internet Public Key Infrastructure using X.509 310 [PKIX]. 312 presented identifier: An identifier that is presented by a server to 313 a client within the server's PKIX certificate when the client 314 attempts to establish a secure connection with the server; the 315 certificate can include one or more presented identifiers of 316 different types. 318 reference identifier: An identifier that is used by the client for 319 matching purposes when checking the presented identifiers; the 320 client can attempt to match multiple reference identifiers of 321 different types. 323 restricted name: A name that can be used only for one kind of 324 application at a service provider. 326 service type: A formal identifier for the application protocol used 327 to provide a particular kind of service at a domain; the service 328 type typically takes the form of a URI scheme or a DNS SRV 329 Service. 331 source domain: The fully-qualified DNS domain name that a client 332 expects an application server to present in the certificate. 334 target domain: A domain name or host name that a client has derived 335 from the source domain in an automated fashion (e.g., by means of 336 a [DNS-SRV] lookup) or that a natural person directly controlling 337 an interactive client has explicitly configured for connecting to 338 the source domain. 340 unrestricted name: A name that can be used for any kind of 341 application at a service provider. 343 Most security-related terms in this document are to be understood in 344 the sense defined in [SECTERMS]; such terms include, but are not 345 limited to, "attack", "authentication", "authorization", 346 "certification authority", "certification path", "certificate", 347 "credential", "identity", "self-signed certificate", "trust", "trust 348 anchor", "trust chain", "validate", and "verify". 350 The following capitalized keywords are to be interpreted as described 351 in [KEYWORDS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 352 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 353 "OPTIONAL". 355 1.4. Contributors 357 The following individuals made significant contributions to the text 358 of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 360 1.5. Acknowledgements 362 The editors and contributors wish to thank the following individuals 363 for their feedback and suggestions: Nelson Bolyard, Kaspar Brand, Ben 364 Campbell, Scott Cantor, Dave Crocker, Cyrus Daboo, Charles Gardiner, 365 Philip Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Love 366 Hornquist Astrand, Harry Hotz, Geoff Keating, Scott Lawrence, Matt 367 McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom 368 Petch, Yngven Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, 369 Martin Rex, Joe Salowey, Rob Stradling, Peter Sylvester, Dan Wing, 370 and Dan Winship. 372 1.6. Discussion Venue 374 [[ RFC Editor: please remove this section. ]] 376 The editors are actively seeking input from certification 377 authorities, application developers, and protocol designers regarding 378 the recommendations in this document. Please send feedback to the 379 editors directly or post to the mailing list, for 380 which archives and subscription information are available at 381 . 383 2. Names 385 This section provides an overview of naming of Internet applications, 386 followed by a brief tutorial about subject naming in PKIX. 388 2.1. Naming Applications 390 This specification assumes that an Internet application is named 391 based on a DNS domain name (e.g., "example.com") -- supplemented in 392 some circumstances by an application type (e.g., "the IMAP server at 393 example.com"). 395 From the perspective of the application client or user, some names 396 are direct because they are provided directly by the user (e.g., via 397 runtime input or prior configuration) whereas other names are 398 indirect because they are resolved by the client based on input 399 provided by the user (e.g., a target name resolved from a source name 400 using DNS SRV records). This dimension matters for certificate 401 verification. 403 From the perspective of the application server or service provider, 404 some names are unrestricted because they can be used in any kind of 405 application (e.g., a certificate might be re-used for both the HTTP 406 service and the IMAP service at example.com) whereas other names are 407 restricted because they can be used in only one kind of application 408 (e.g., a special-purpose certificate that can be used only for an 409 IMAP service). This dimension matters for certificate issuance. 411 Therefore: 413 o A CN-ID identifier is direct (provided by a user) and unrestricted 414 (can be used for any application). 415 o A DNS-ID identifier is direct (provided by a user) and 416 unrestricted (can be used for any application). 417 o An SRV-ID identifier is indirect (resolved by a client) and 418 restricted (can be used for only a single application). 419 o A URI-ID identifier is direct (provided by a user) and restricted 420 (can be used for only a single application). 422 We summarize this taxonomy in the following table. 424 +-----------+-----------+---------------+ 425 | | Direct | Restricted | 426 +-----------+-----------+---------------+ 427 | CN-ID | Yes | No | 428 +-----------+-----------+---------------+ 429 | DNS-ID | Yes | No | 430 +-----------+-----------+---------------+ 431 | SRV-ID | No | Yes | 432 +-----------+-----------+---------------+ 433 | URI-ID | Yes | Yes | 434 +-----------+-----------+---------------+ 435 When implementing software, deploying services, and issuing 436 certificates for secure PKIX-based authentication, it is important to 437 keep these distinctions in mind. In particular, best practices 438 differ somewhat for application server implementations, application 439 client implementations, service providers, and certification 440 authorities. Protocol specifications that reference this document 441 MUST specify which identifiers are mandatory-to-implement by servers 442 and clients, which identifiers are to be preferred by service 443 providers, and which identifiers ought to be supported by certificate 444 issuers. Because these requirements differ across applications, it 445 is impossible to categorically stipulate universal rules (e.g., that 446 all software implementations, service providers, and certification 447 authorities for all application protocols need to use or support DNS- 448 IDs as a baseline for the purpose of interoperability); however, it 449 is preferable that each application protocol will at least define a 450 baseline that applies to the community of software developers, 451 service providers, and CAs actively using or supporting that 452 technology. 454 2.2. Subject Naming in PKIX Certificates 456 The application server is the subject of a server certificate. As 457 [PKIX] says, "[the] subject field identifies the entity associated 458 with the public key stored in the subject public key field." 460 The application server is identified by a name or names carried in 461 the subject field and/or the subjectAltName extension of the 462 certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details. 463 This section only briefly introduces distinguished names and their 464 components, as well as subjectAltNames and the particular 465 subjectAltName extension types explicitly mentioned in this 466 specification. 468 The subject field of a PKIX certificate is defined as an X.501 type 469 Name and known as a Distinguished Name (DN) -- see [X.501] and 470 [PKIX]. A DN is an ordered sequence of Relative Distinguished Names 471 (RDNs), where each RDN is a set (i.e., an unordered group) of 472 attribute-type-and-value pairs [LDAP-DN], each of which asserts some 473 attribute about the subject of the certificate. In the DER encoding 474 of a DN, the RDNs are always in order from most significant to least 475 significant (i.e., the first RDN is most significant and the last RDN 476 is least significant); however, in the string representation of a DN 477 as used in various protocols and data formats, the RDNs might be 478 ordered from most significant to least significant (e.g., this is 479 true of LDAP) or from least significant to most significant. 481 It is perfectly acceptable for a PKIX certificate to have an empty 482 subject field as long as there is at least one subjectAltName entry. 484 Certificates are binary objects -- they are encoded using 485 distinguished encoding rules (DER). Thus, the generation of 486 displayable (a.k.a. printable) renderings of certificate subject and 487 issuer names means that the DER-encoded sequences are decoded and 488 converted into a "string representation" before being rendered. 489 Because a DN is an ordered sequence, order is preserved in the string 490 representation of a DN. However, because an RDN is an unordered 491 group of attribute-type-and-value pairs, the string representation of 492 an RDN can differ from the canonical DER encoding; in the canonical 493 encoding, the RDN that is deepest in the tree (and that therefore 494 distinguishes the relative name) is called the "most specific" RDN. 495 See [LDAP-DN] for details. 497 Certificate subjects may also have "alternative" names. These are 498 represented within certificates using the SubjectAltName field. This 499 field is a sequence of typed fields, where each type is a distinct 500 type of identifier. For example, the subjectAltName identifier types 501 noted in this specification are: 503 o dNSName -- a (fully-qualified) DNS domain name [PKIX] 504 o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME] 505 o uniformResourceIdentifier -- a Uniform Resource Identifier [URI] 506 [PKIX] 508 3. Representation of Server Identity 510 When a certification authority issues a certificate based on the 511 fully-qualified DNS domain name at which the service provider will 512 provide the relevant application, the following rules apply to the 513 representation of application server identities. 515 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName 516 identifier of type dNSName). 518 2. If the service using the certificate deploys a technology in 519 which a server is discovered by means of DNS SRV records 520 [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate 521 SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form 522 of otherName from the GeneralName structure in the subjectAltName 523 as specified in [SRVNAME]). 525 3. If the service using the certificate deploys a technology in 526 which a server is typically associated with a URI (e.g., this is 527 true of [SIP]), then the certificate SHOULD include an URI-ID 528 (i.e., a subjectAltName identifier of type 529 uniformResourceIdentifier); the scheme SHALL be that of the 530 protocol associated with the application type and the authority 531 component SHALL be the fully-qualified DNS domain name of the 532 service. 534 4. The certificate MAY include other application-specific 535 identifiers for types that were defined before specification of 536 the SRVName extension (e.g., XmppAddr for [XMPP]) or for which 537 service names or URI schemes do not exist; however, such 538 application-specific identifiers are not generally applicable and 539 therefore are out of scope for this specification. 541 5. The certificate SHOULD NOT represent the server's fully-qualified 542 DNS domain name in a Relative Distinguished Name (RDN) of type 543 Common Name (CN) (see [LDAP-SCHEMA]), even though we recognize 544 that many deployed clients still check for this legacy identifier 545 configuration within certificate subjectName. However, if this 546 legacy identifer configuration is employed, then the server's 547 fully-qualified DNS domain name MUST be placed in the last (most 548 specific) RDN within the RDN sequence making up the certificate's 549 subjectName, as the order of RDNs is determined by the DER- 550 encoded Name within the server's PKIX certificate. Furthermore, 551 the certificate's subject Distinguished Name SHOULD NOT contain 552 more than one Common Name attribute, and MUST NOT contain RDNs 553 which consist of multiple Common Name attributes. 555 6. The fully-qualified DNS domain name portion of the DN-ID or CN-ID 556 MAY contain one instance of the wildcard character '*', but only 557 as the left-most label of the domain name component of the 558 identifier (following the definition of "label" from [DNS]). 559 Specifications that profile the rules defined in this document 560 MUST specify whether the wildcard character is or is not allowed 561 in certificates issued under that profile; by default wildcard 562 certificates SHOULD NOT be allowed. 564 4. Verification of Server Identity 566 4.1. Overview 568 At a high level, the client verifies the server's identity by 569 performing the following actions: 571 1. Before connecting to the server, the client constructs an ordered 572 list of reference identifiers against which to check the 573 presented identifiers. 575 2. The server provides its identifiers in the form of a PKIX 576 certificate. 578 3. The client checks each of its reference identifiers against the 579 presented identifiers for the purpose of finding a match. 581 4. When checking a reference identifier against a presented 582 identifier, the client (a) MUST match the source domain (or, in 583 some cases, target domain) of the identifiers and (b) MAY also 584 match the service type of the identifiers. 586 Implementation Note: Naturally, in addition to checking 587 identifiers, a client might complete further checks to ensure that 588 the server is authorized to provide the requested service. 589 However, such checking is not a matter of verifying the server 590 identity presented in a certificate, and therefore methods for 591 doing so (e.g., consulting local policy information) are out of 592 scope for this document. 594 4.2. Constructing an Ordered List of Reference Identifiers 596 Before connecting to the server, the client MUST construct an ordered 597 list of acceptable reference identifiers. 599 The inputs here might be a URI that a user has typed into an 600 interface (e.g., an HTTP URL for a web site), configured account 601 information (e.g., the username of an IMAP or POP3 account for 602 retrieving email), or some other combination of information that can 603 yield a source domain and an application type. 605 The client might need to derive the source domain and application 606 type from the input(s) it has received. The derived data MUST 607 include only information that can be securely parsed out of the 608 inputs (e.g., extracting the fully-qualified DNS domain name from the 609 authority component of a URI or extracting the application type from 610 the scheme of a URI) or information for which the derivation is 611 performed in a secure manner (e.g., using [DNSSEC]). 613 In some cases the inputs might include more than one fully-qualified 614 DNS domain name, because a user might have explicitly configured the 615 client to associate a target domain with the source domain. Such 616 delegation can occur by means of user-approved DNS SRV records (e.g., 617 _xmpp-server._tcp.im.example.com might yield a hostname of 618 hosting.example.net) or a user-configured lookup table for host-to- 619 address or address-to-host translations (e.g., the Unix "hosts" 620 file). See under Section 5 for further discussion of service 621 delegation. 623 Using the combination of fully-qualified DNS domain name(s) and 624 application type, the client constructs a list of reference 625 identifiers in accordance with the following rules: 627 o The list MUST include a DNS-ID. A reference identifier of type 628 DNS-ID can be directly constructed from a fully-qualified DNS 629 domain name that is (a) contained in or securely derived from the 630 inputs (i.e., the source domain), or (b) explicitly associated 631 with the source domain by means of user configuration (i.e., a 632 target domain). 634 o If a server for the application type is typically discovered by 635 means of DNS SRV records , then the list SHOULD include an SRV-ID. 637 o If a server for the application type is typically associated with 638 a URI, then the list SHOULD include a URI-ID 640 o The list SHOULD NOT include a CN-ID; however, the CN-ID (if 641 included) MUST be constructed only from the source domain and 642 never from a target domain. 644 Implementation Note: The client does not need to actually 645 construct the foregoing identifiers in the formats found in a 646 certificate (e.g., as ASN.1 object identifiers), only the 647 functional equivalent of such identifiers for matching purposes. 649 Security Note: A client MUST NOT construct a reference identifier 650 corresponding to Relative Distinguished Names (RDNs) other than 651 the Common Name and MUST NOT check for such RDNs in the presented 652 identifiers. 654 The client then orders the list in accordance with the following 655 rules: 657 o Reference identifiers that include the source domain MUST be 658 preferred over reference identifiers that include a target domain 659 (if any). 661 o Reference identifiers that include both a fully-qualified DNS 662 domain name and an application type MUST be preferred over 663 reference identifiers that include only a fully-qualified DNS 664 domain name. Therefore an SRV-ID or URI-ID is to be preferred 665 over a DNS-ID. 667 o Notwithstanding any of the foregoing rules, reference identifiers 668 of type CN-ID (if included) MUST always be the lowest-priority 669 reference identifiers in the list. 671 To illustrate the ordering rules, consider the case where the inputs 672 are a source domain of "im.example.com" and an application type of 673 "XMPP" (for which application servers are discovered via DNS SRV 674 records) and the user of the client has also explicitly configured a 675 target domain of "hosting.example.net". In this case, the ordered 676 list would be: 678 1. SRV-ID of "_xmpp.im.example.com" 679 2. DNS-ID of "im.example.com" 680 3. SRV-ID of "_xmpp.hosting.example.net" 681 4. DNS-ID of "hosting.example.net" 682 5. CN-ID of "im.example.com" 684 4.3. Seeking a Match 686 Once the client has constructed its order list of reference 687 identifiers and has received the server's presented identifiers in 688 the form of a PKIX certificate, the client checks its reference 689 identifiers against the presented identifiers for the purpose of 690 finding a match. It does so by seeking a match in preference order 691 and aborting the search if any presented identifier matches one of 692 its reference identifiers. The search fails if the client exhausts 693 its list of reference identifiers without finding a match. Detailed 694 comparison rules for finding a match are provided in the following 695 sections. 697 Security Note: A client MUST NOT seek a match for a reference 698 identifier of CN-ID if the presented identifiers include an 699 SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName 700 extensions supported by the client. Furthermore, a client SHALL 701 check only against the last Common Name RDN in the sequence of 702 RDNs making up the Distinguished Name within the certificate's 703 subjectName (where the term "last" refers to the DER order, which 704 is often not the string order presented to a user; the order that 705 is applied here MUST be the DER order). 707 4.4. Verifying a Domain Name 709 This document assumes that each reference identifier contains a 710 fully-qualified DNS domain name that is a "traditional domain name" 711 or an "internationalized domain name". The client MUST match the 712 source domain of a reference identifier according to the following 713 rules. 715 4.4.1. Checking of Traditional Domain Names 717 The term "traditional domain name" is a contraction of this more 718 formal and accurate name: "traditional US-ASCII letter-digit-hyphen 719 DNS domain name". Traditional domain names are defined in 720 [DNS-CONCEPTS] and [DNS] in conjunction with [HOSTS] as further 721 explained in [IDNA2003]. In essence, a traditional domain name 722 consists of a set of one or more labels (e.g., "www", "example", and 723 "com"), with the labels usually shown separated by dots (e.g., 724 "www.example.com"). Labels nominally consist of only [US-ASCII] 725 uppercase and lowercase letters, digits, and hyphen. There are 726 additional qualifications (please refer to the above-referenced 727 specifications for details) but they are not germane to this 728 specification. 730 If the source domain of a reference identifier is a "traditional 731 domain name", then matching of the reference identifier against the 732 presented identifier is performed by comparing the set of domain 733 components using a case-insensitive ASCII comparison, as clarified by 734 [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to 735 "www.example.com" for comparison purposes). Each label MUST match in 736 order for the names to be considered to match. 738 4.4.2. Checking of Internationalized Domain Names 740 The term "internationalized domain name" refers to a DNS domain name 741 that conforms to the overall form of a domain name (dot-separated 742 labels) but that can include Unicode code points outside the 743 traditional US-ASCII range, as explained by and [IDNA2008]. 745 If the source domain of a reference identifier is an 746 internationalized domain name, then an implementation MUST convert 747 every label in the domain name to an A-label before checking the 748 domain anme. 750 4.4.3. Checking of Wildcard Labels 752 Unless forbidden by a specification that profiles the best practices 753 defined herein, a client employing this specification's rules MAY 754 match the reference identifier against a presented identifier 755 containing one instance of the wildcard character '*', but only as 756 the left-most label of the domain name, e.g. *.example.com (following 757 the definition of "label" from [DNS]). 759 If such a wildcard identifier is presented, the wildcard MUST be used 760 to match only the one position-wise corresponding label (thus 761 *.example.com matches foo.example.com but not bar.foo.example.com or 762 example.com). The client MUST fail to match a presented identifier 763 in which the wildcard character is contained within a label fragment 764 (e.g., baz*.example.net is not allowed and MUST NOT be taken to match 765 baz1.example.net and baz2.example.net), or in which the wildcard 766 character does not comprise the left-most label in the presented 767 identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net 768 are allowed). 770 4.4.4. Checking of DNS Domain Names in Common Names 772 As noted, a client MUST NOT seek a match for a reference identifier 773 of CN-ID if the presented identifiers include an SRV-ID, URI-ID, 774 DNS-ID, or any application-specific subjectAltName extensions 775 supported by the client. 777 Therefore, if and only if the identity set does not include 778 subjectAltName extensions of type dNSName, SRVName, or 779 uniformResourceIdentifier (or any application-specific subjectAltName 780 extensions supported by the client), the client MAY as a fallback 781 check for a fully-qualified DNS domain name in the last Common Name 782 RDN in the sequence of RDNs making up the Distinguished Name within 783 the certificate's subjectName (where the term "last" refers to the 784 DER order, which is often not the string order presented to a user; 785 the order that is applied here MUST be the DER order). 787 In existing certificates, the CN is often used for representing a 788 fully-qualified DNS domain name; for example, consider the following 789 subjectName, where the last RDN is a Common Name that is intended to 790 represent a fully-qualified DNS domain name: 792 cn=www.example.com,c=GB,ou=Web Services 794 Here the Common Name is "www.example.com" (a string whose form 795 matches that of a fully-qualified DNS domain name) and the client 796 could choose to compare a reference identifier of type CN-ID against 797 that string. When doing so, the client MUST follow the comparison 798 rules for the source domain of an identifier of type DNS-ID, SRV-ID, 799 or URI-ID, as described under Section 4.4. 801 4.5. Verifying an Application Type 803 As specified under the ordering rules for reference identifiers, a 804 client SHOULD check not only the domain name but also the application 805 type of the service to which it connects. This is a best practice 806 because typically a client is not designed to connect to all kinds of 807 services using all possible application protocols, but instead is 808 designed to connect to a specific kind of service, such as a web 809 site, an email service, or an instant messaging service. 811 The application type is verified by means of either an SRV-ID or 812 URI-ID. 814 4.5.1. SRV-ID 816 The service name portion of an SRV-ID (e.g., "xmpp") MUST be matched 817 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 818 that the "_" character is prepended to the service identifier in DNS 819 SRV records. 821 4.5.2. URI-ID 823 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 824 a case-insensitive manner, in accordance with [URI]. Note that the 825 ":" character is a separator between the scheme name and the rest of 826 the URI, and therefore does not need to be included in any 827 comparison. 829 4.6. Outcome 831 The outcome of the checking procedure is one of the following cases. 833 4.6.1. Case #1: Match Found 835 If the client has found a presented identifier that matches a 836 reference identifier, matching has succeeded. In this case, the 837 client MUST use the matched reference identifier as the validated 838 identity of the server. 840 4.6.2. Case #2: No Match Found, Cached Certificate 842 If the client finds no presented identifier that matches any of the 843 reference identifiers but a natural person has permanently accepted 844 the certificate during a previous connection attempt or via 845 configured preferences, the certificate is cached. In this case, the 846 client MUST verify that the presented certificate matches the cached 847 certificate and (if it is an interactive client) MUST notify the user 848 if the certificate has changed since the last time a secure 849 connection was successfully negotiated (where causes of change 850 include but are not limited to changes in the DNS domain name, 851 identifiers, issuer, certification path, and expiration date). 853 4.6.3. Case #3: No Match Found, Uncached Certificate 855 If the client finds no presented identifier that matches any of the 856 reference identifiers and a human user has not permanently accepted 857 the certificate for this application server during a previous 858 connection attempt, the client MUST NOT consider the certificate to 859 include a validated identity for the application server. 861 Instead, the client MUST proceed as follows. 863 4.6.3.1. Interactive User Agent 865 If the client is an interactive client that is directly controlled by 866 a natural person, then it MUST either do one of the following: 868 1. Automatically terminate the connection with a bad certificate 869 error; or 871 2. Actively warn the user that the certificate is untrusted and 872 encourage the user to terminate the connection, but give advanced 873 users the option to (a) view the entire certification path, (b) 874 accept the certificate for this application server either 875 temporarily (i.e., for this connection attempt only) or 876 permanently (i.e., for all future connection attempts) despite 877 the identity mismatch, and then (c) continue with the connection 878 attempt. 880 If a user permanently accepts a certificate for this application 881 server despite an identity mismatch (an action referred to in 882 [WSC-UI] as "pinning"), the client MUST cache the certificate (or 883 some non-forgeable representation such as a hash value) and in future 884 connection attempts MUST behave as in "Case #2: No Match Found, 885 Cached Certificate" Section 4.6.2. However, the client MUST provide 886 a method for revoking trust in cached certificates. 888 Security Note: It is the responsibility of the human user to 889 verify the hash value or fingerprint of the certificate with the 890 server over a trusted communication layer. 892 Informational Note: The guidelines provided here are roughly 893 consistent with those provided for web browsers and other HTTP- 894 aware interactive clients in [WSC-UI]. 896 4.6.3.2. Automated Client 898 If the client is an automated application that is not directly 899 controlled by a natural person, then it SHOULD terminate the 900 connection with a bad certificate error and log the error to an 901 appropriate audit log. An automated application MAY provide a 902 configuration setting that disables this check, but MUST enable the 903 check by default. 905 5. Security Considerations 906 5.1. Service Delegation 908 When the connecting application is an interactive client, the source 909 domain name and application type MUST be provided by a human user 910 (e.g. when specifying the server portion of the user's account name 911 on the server or when explicitly configuring the client to connect to 912 a particular host or URI as in [SIP-LOC]) and MUST NOT be derived 913 from the user inputs in an automated fashion (e.g., a hostname 914 address discovered through DNS resolution of the source domain). 915 This rule is important because only a match between the user inputs 916 (in the form of a reference identifier) and a presented identifier 917 enables the client to be sure that the certificate can legitimately 918 be used to secure the connection. 920 However, an interactive client MAY provide a configuration setting 921 that enables a human user to explicitly specify a particular hostname 922 (called a "target domain") to be checked for connection purposes. 924 5.2. Wildcard Certificates 926 Allowing the wildcard character in certificates has led to homograph 927 attacks involving non-ASCII characters that look similar to 928 characters commonly included in HTTP URLs, such as "/" and "?"; for 929 discussion, see for example [Defeating-SSL]. 931 5.3. Internationalized Domain Names 933 In addition to the wildcard certificate attacks previously mentioned, 934 allowing internationalized domain names can lead to the inclusion of 935 visually similar (so-called "confusable") characters in certificates; 936 for discussion, see for example [IDNA-DEFS]. 938 6. IANA Considerations 940 This document specifies no actions for the IANA. 942 7. References 944 7.1. Normative References 946 [DNS] Mockapetris, P., "Domain names - implementation and 947 specification", STD 13, RFC 1035, November 1987. 949 [DNS-CONCEPTS] 950 Mockapetris, P., "Domain names - concepts and facilities", 951 STD 13, RFC 1034, November 1987. 953 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 954 specifying the location of services (DNS SRV)", RFC 2782, 955 February 2000. 957 [IDNA2003] 958 Faltstrom, P., Hoffman, P., and A. Costello, 959 "Internationalizing Domain Names in Applications (IDNA)", 960 RFC 3490, March 2003. 962 [IDNA2008] 963 Klensin, J., "Internationalized Domain Names in 964 Applications (IDNA): Protocol", 965 draft-ietf-idnabis-protocol-18 (work in progress), 966 January 2010. 968 [KEYWORDS] 969 Bradner, S., "Key words for use in RFCs to Indicate 970 Requirement Levels", BCP 14, RFC 2119, March 1997. 972 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 973 (LDAP): String Representation of Distinguished Names", 974 RFC 4514, June 2006. 976 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 977 Housley, R., and W. Polk, "Internet X.509 Public Key 978 Infrastructure Certificate and Certificate Revocation List 979 (CRL) Profile", RFC 5280, May 2008. 981 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 982 Subject Alternative Name for Expression of Service Name", 983 RFC 4985, August 2007. 985 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 986 Resource Identifier (URI): Generic Syntax", STD 66, 987 RFC 3986, January 2005. 989 7.2. Informative References 991 [Defeating-SSL] 992 Marlinspike, M., "New Tricks for Defeating SSL in 993 Practice", February 2009, . 997 [DNS-CASE] 998 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 999 Clarification", RFC 4343, January 2006. 1001 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1002 Rose, "DNS Security Introduction and Requirements", 1003 RFC 4033, March 2005. 1005 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1006 Security", RFC 4347, April 2006. 1008 [GIST] Schulzrinne, H. and M. Stiemerling, "GIST: General 1009 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1010 (work in progress), June 2009. 1012 [HOSTS] Braden, R., "Requirements for Internet Hosts - Application 1013 and Support", STD 3, RFC 1123, October 1989. 1015 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1016 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1017 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1019 [HTTP-TLS] 1020 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1022 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1023 4rev1", RFC 3501, March 2003. 1025 [IDNA-DEFS] 1026 Klensin, J., "Internationalized Domain Names for 1027 Applications (IDNA): Definitions and Document Framework", 1028 draft-ietf-idnabis-defs-13 (work in progress), 1029 January 2010. 1031 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1032 September 1981. 1034 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1035 (IPv6) Specification", RFC 2460, December 1998. 1037 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1038 Internet Protocol", RFC 4301, December 2005. 1040 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1041 (LDAP): The Protocol", RFC 4511, June 2006. 1043 [LDAP-AUTH] 1044 Harrison, R., "Lightweight Directory Access Protocol 1045 (LDAP): Authentication Methods and Security Mechanisms", 1046 RFC 4513, June 2006. 1048 [LDAP-SCHEMA] 1049 Sciberras, A., "Lightweight Directory Access Protocol 1050 (LDAP): Schema for User Applications", RFC 4519, 1051 June 2006. 1053 [LDAP-TLS] 1054 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1055 Directory Access Protocol (v3): Extension for Transport 1056 Layer Security", RFC 2830, May 2000. 1058 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1059 December 2006. 1061 [NETCONF-SSH] 1062 Wasserman, M. and T. Goddard, "Using the NETCONF 1063 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1064 December 2006. 1066 [NETCONF-TLS] 1067 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1068 RFC 5539, May 2009. 1070 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1071 RFC 3977, October 2006. 1073 [NNTP-TLS] 1074 Murchison, K., Vinocur, J., and C. Newman, "Using 1075 Transport Layer Security (TLS) with Network News Transfer 1076 Protocol (NNTP)", RFC 4642, October 2006. 1078 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1079 Adams, "X.509 Internet Public Key Infrastructure Online 1080 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1082 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1083 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1085 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1086 STD 53, RFC 1939, May 1996. 1088 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1089 E. Lear, "Address Allocation for Private Internets", 1090 BCP 5, RFC 1918, February 1996. 1092 [PKIX-OLD] 1093 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1094 X.509 Public Key Infrastructure Certificate and CRL 1095 Profile", RFC 2459, January 1999. 1097 [SECTERMS] 1098 Shirey, R., "Internet Security Glossary, Version 2", 1099 RFC 4949, August 2007. 1101 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1102 A., Peterson, J., Sparks, R., Handley, M., and E. 1103 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1104 June 2002. 1106 [SIP-CERTS] 1107 Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 1108 Certificates in the Session Initiation Protocol (SIP)", 1109 draft-ietf-sip-domain-certs-06 (work in progress), 1110 March 2010. 1112 [SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1113 Protocol (SIP): Locating SIP Servers", RFC 3263, 1114 June 2002. 1116 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1117 October 2008. 1119 [SMTP-AUTH] 1120 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1121 for Authentication", RFC 4954, July 2007. 1123 [SMTP-TLS] 1124 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1125 Transport Layer Security", RFC 3207, February 2002. 1127 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1129 [SYSLOG-TLS] 1130 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1131 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1132 March 2009. 1134 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1135 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1137 [US-ASCII] 1138 American National Standards Institute, "Coded Character 1139 Set - 7-bit American Standard Code for Information 1140 Interchange", ANSI X3.4, 1986. 1142 [USINGTLS] 1143 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1144 RFC 2595, June 1999. 1146 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1147 Interface Guidelines", World Wide Web Consortium 1148 LastCall WD-wsc-ui-20100309, March 2010, 1149 . 1151 [X.501] International Telecommunications Union, "Information 1152 Technology - Open Systems Interconnection - The Directory: 1153 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1154 February 2001. 1156 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1157 Protocol (XMPP): Core", RFC 3920, October 2004. 1159 [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence 1160 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work 1161 in progress), April 2010. 1163 Appendix A. Prior Art 1165 (This section is non-normative.) 1167 The recommendations in this document are an abstraction from 1168 recommendations in specifications for a wide range of application 1169 protocols. For the purpose of comparison and to delineate the 1170 history of thinking about server identity verification within the 1171 IETF, this informative section gathers together prior art by 1172 including the exact text from various RFCs (the only modifications 1173 are changes to the names of several references to maintain coherence 1174 with the main body of this document, and the elision of irrelevant 1175 text as marked by the characters "[...]"). 1177 A.1. IMAP, POP3, and ACAP (1999) 1179 In 1999, [USINGTLS] specified the following text regarding server 1180 identity verification in IMAP, POP3, and ACAP: 1182 ###### 1184 2.4. Server Identity Check 1186 During the TLS negotiation, the client MUST check its understanding 1187 of the server hostname against the server's identity as presented in 1188 the server Certificate message, in order to prevent man-in-the-middle 1189 attacks. Matching is performed according to these rules: 1191 o The client MUST use the server hostname it used to open the 1192 connection as the value to compare against the server name as 1193 expressed in the server certificate. The client MUST NOT use any 1194 form of the server hostname derived from an insecure remote source 1195 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1196 o If a subjectAltName extension of type dNSName is present in the 1197 certificate, it SHOULD be used as the source of the server's 1198 identity. 1199 o Matching is case-insensitive. 1200 o A "*" wildcard character MAY be used as the left-most name 1201 component in the certificate. For example, *.example.com would 1202 match a.example.com, foo.example.com, etc. but would not match 1203 example.com. 1204 o If the certificate contains multiple names (e.g. more than one 1205 dNSName field), then a match with any one of the fields is 1206 considered acceptable. 1208 If the match fails, the client SHOULD either ask for explicit user 1209 confirmation, or terminate the connection and indicate the server's 1210 identity is suspect. 1212 ###### 1214 A.2. HTTP (2000) 1216 In 2000, [HTTP-TLS] specified the following text regarding server 1217 identity verification in HTTP: 1219 ###### 1221 3.1. Server Identity 1223 In general, HTTP/TLS requests are generated by dereferencing a URI. 1224 As a consequence, the hostname for the server is known to the client. 1225 If the hostname is available, the client MUST check it against the 1226 server's identity as presented in the server's Certificate message, 1227 in order to prevent man-in-the-middle attacks. 1229 If the client has external information as to the expected identity of 1230 the server, the hostname check MAY be omitted. (For instance, a 1231 client may be connecting to a machine whose address and hostname are 1232 dynamic but the client knows the certificate that the server will 1233 present.) In such cases, it is important to narrow the scope of 1234 acceptable certificates as much as possible in order to prevent man 1235 in the middle attacks. In special cases, it may be appropriate for 1236 the client to simply ignore the server's identity, but it must be 1237 understood that this leaves the connection open to active attack. 1239 If a subjectAltName extension of type dNSName is present, that MUST 1240 be used as the identity. Otherwise, the (most specific) Common Name 1241 field in the Subject field of the certificate MUST be used. Although 1242 the use of the Common Name is existing practice, it is deprecated and 1243 Certification Authorities are encouraged to use the dNSName instead. 1245 Matching is performed using the matching rules specified by 1246 [PKIX-OLD]. If more than one identity of a given type is present in 1247 the certificate (e.g., more than one dNSName name, a match in any one 1248 of the set is considered acceptable.) Names may contain the wildcard 1249 character * which is considered to match any single domain name 1250 component or component fragment. E.g., *.a.com matches foo.a.com but 1251 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1253 In some cases, the URI is specified as an IP address rather than a 1254 hostname. In this case, the iPAddress subjectAltName must be present 1255 in the certificate and must exactly match the IP in the URI. 1257 If the hostname does not match the identity in the certificate, user 1258 oriented clients MUST either notify the user (clients MAY give the 1259 user the opportunity to continue with the connection in any case) or 1260 terminate the connection with a bad certificate error. Automated 1261 clients MUST log the error to an appropriate audit log (if available) 1262 and SHOULD terminate the connection (with a bad certificate error). 1263 Automated clients MAY provide a configuration setting that disables 1264 this check, but MUST provide a setting which enables it. 1266 Note that in many cases the URI itself comes from an untrusted 1267 source. The above-described check provides no protection against 1268 attacks where this source is compromised. For example, if the URI 1269 was obtained by clicking on an HTML page which was itself obtained 1270 without using HTTP/TLS, a man in the middle could have replaced the 1271 URI. In order to prevent this form of attack, users should carefully 1272 examine the certificate presented by the server to determine if it 1273 meets their expectations. 1275 ###### 1277 A.3. LDAP (2000/2006) 1279 In 2000, [LDAP-TLS] specified the following text regarding server 1280 identity verification in LDAP: 1282 ###### 1284 3.6. Server Identity Check 1286 The client MUST check its understanding of the server's hostname 1287 against the server's identity as presented in the server's 1288 Certificate message, in order to prevent man-in-the-middle attacks. 1290 Matching is performed according to these rules: 1292 o The client MUST use the server hostname it used to open the LDAP 1293 connection as the value to compare against the server name as 1294 expressed in the server's certificate. The client MUST NOT use 1295 the server's canonical DNS name or any other derived form of name. 1296 o If a subjectAltName extension of type dNSName is present in the 1297 certificate, it SHOULD be used as the source of the server's 1298 identity. 1299 o Matching is case-insensitive. 1300 o The "*" wildcard character is allowed. If present, it applies 1301 only to the left-most name component. 1303 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 1304 bar.com. If more than one identity of a given type is present in the 1305 certificate (e.g. more than one dNSName name), a match in any one of 1306 the set is considered acceptable. 1308 If the hostname does not match the dNSName-based identity in the 1309 certificate per the above check, user-oriented clients SHOULD either 1310 notify the user (clients MAY give the user the opportunity to 1311 continue with the connection in any case) or terminate the connection 1312 and indicate that the server's identity is suspect. Automated 1313 clients SHOULD close the connection, returning and/or logging an 1314 error indicating that the server's identity is suspect. 1316 Beyond the server identity checks described in this section, clients 1317 SHOULD be prepared to do further checking to ensure that the server 1318 is authorized to provide the service it is observed to provide. The 1319 client MAY need to make use of local policy information. 1321 ###### 1323 In 2006, [LDAP-AUTH] specified the following text regarding server 1324 identity verification in LDAP: 1326 ###### 1328 3.1.3. Server Identity Check 1330 In order to prevent man-in-the-middle attacks, the client MUST verify 1331 the server's identity (as presented in the server's Certificate 1332 message). In this section, the client's understanding of the 1333 server's identity (typically the identity used to establish the 1334 transport connection) is called the "reference identity". 1336 The client determines the type (e.g., DNS name or IP address) of the 1337 reference identity and performs a comparison between the reference 1338 identity and each subjectAltName value of the corresponding type 1339 until a match is produced. Once a match is produced, the server's 1340 identity has been verified, and the server identity check is 1341 complete. Different subjectAltName types are matched in different 1342 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 1343 various subjectAltName types. 1345 The client may map the reference identity to a different type prior 1346 to performing a comparison. Mappings may be performed for all 1347 available subjectAltName types to which the reference identity can be 1348 mapped; however, the reference identity should only be mapped to 1349 types for which the mapping is either inherently secure (e.g., 1350 extracting the DNS name from a URI to compare with a subjectAltName 1351 of type dNSName) or for which the mapping is performed in a secure 1352 manner (e.g., using [DNSSEC], or using user- or admin-configured 1353 host-to-address/address-to-host lookup tables). 1355 The server's identity may also be verified by comparing the reference 1356 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 1357 Relative Distinguished Name (RDN) of the subjectName field of the 1358 server's certificate (where "last" refers to the DER-encoded order, 1359 not the order of presentation in a string representation of DER- 1360 encoded data). This comparison is performed using the rules for 1361 comparison of DNS names in Section 3.1.3.1, below, with the exception 1362 that no wildcard matching is allowed. Although the use of the Common 1363 Name value is existing practice, it is deprecated, and Certification 1364 Authorities are encouraged to provide subjectAltName values instead. 1365 Note that the TLS implementation may represent DNs in certificates 1366 according to X.500 or other conventions. For example, some X.500 1367 implementations order the RDNs in a DN using a left-to-right (most 1368 significant to least significant) convention instead of LDAP's right- 1369 to-left convention. 1371 If the server identity check fails, user-oriented clients SHOULD 1372 either notify the user (clients may give the user the opportunity to 1373 continue with the LDAP session in this case) or close the transport 1374 connection and indicate that the server's identity is suspect. 1375 Automated clients SHOULD close the transport connection and then 1376 return or log an error indicating that the server's identity is 1377 suspect or both. 1379 Beyond the server identity check described in this section, clients 1380 should be prepared to do further checking to ensure that the server 1381 is authorized to provide the service it is requested to provide. The 1382 client may need to make use of local policy information in making 1383 this determination. 1385 3.1.3.1. Comparison of DNS Names 1387 If the reference identity is an internationalized domain name, 1388 conforming implementations MUST convert it to the ASCII Compatible 1389 Encoding (ACE) format as specified in Section 4 of RFC 3490 1390 [IDNA2003] before comparison with subjectAltName values of type 1391 dNSName. Specifically, conforming implementations MUST perform the 1392 conversion operation specified in Section 4 of RFC 3490 as follows: 1394 o in step 1, the domain name SHALL be considered a "stored string"; 1395 o in step 3, set the flag called "UseSTD3ASCIIRules"; 1396 o in step 4, process each label with the "ToASCII" operation; and 1397 o in step 5, change all label separators to U+002E (full stop). 1399 After performing the "to-ASCII" conversion, the DNS labels and names 1400 MUST be compared for equality according to the rules specified in 1401 Section 3 of RFC3490. 1403 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 1404 values of type dNSName, and then only as the left-most (least 1405 significant) DNS label in that value. This wildcard matches any 1406 left-most DNS label in the server name. That is, the subject 1407 *.example.com matches the server names a.example.com and 1408 b.example.com, but does not match example.com or a.b.example.com. 1410 3.1.3.2. Comparison of IP Addresses 1412 When the reference identity is an IP address, the identity MUST be 1413 converted to the "network byte order" octet string representation 1414 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 1415 string will contain exactly four octets. For IP Version 6, as 1416 specified in RFC 2460, the octet string will contain exactly sixteen 1417 octets. This octet string is then compared against subjectAltName 1418 values of type iPAddress. A match occurs if the reference identity 1419 octet string and value octet strings are identical. 1421 3.1.3.3. Comparison of Other subjectName Types 1423 Client implementations MAY support matching against subjectAltName 1424 values of other types as described in other documents. 1426 ###### 1428 A.4. SMTP (2002/2007) 1430 In 2002, [SMTP-TLS] specified the following text regarding server 1431 identity verification in SMTP: 1433 ###### 1435 4.1 Processing After the STARTTLS Command 1437 [...] 1439 The decision of whether or not to believe the authenticity of the 1440 other party in a TLS negotiation is a local matter. However, some 1441 general rules for the decisions are: 1443 o A SMTP client would probably only want to authenticate an SMTP 1444 server whose server certificate has a domain name that is the 1445 domain name that the client thought it was connecting to. 1447 [...] 1449 ###### 1451 In 2006, [SMTP-AUTH] specified the following text regarding server 1452 identity verification in SMTP: 1454 ###### 1456 14. Additional Requirements When Using SASL PLAIN over TLS 1458 [...] 1460 After a successful [TLS] negotiation, the client MUST check its 1461 understanding of the server hostname against the server's identity as 1462 presented in the server Certificate message, in order to prevent man- 1463 in-the-middle attacks. If the match fails, the client MUST NOT 1464 attempt to authenticate using the SASL PLAIN mechanism. Matching is 1465 performed according to the following rules: 1467 The client MUST use the server hostname it used to open the 1468 connection as the value to compare against the server name as 1469 expressed in the server certificate. The client MUST NOT use any 1470 form of the server hostname derived from an insecure remote source 1471 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1472 If a subjectAltName extension of type dNSName is present in the 1473 certificate, it SHOULD be used as the source of the server's 1474 identity. 1475 Matching is case-insensitive. 1476 A "*" wildcard character MAY be used as the leftmost name 1477 component in the certificate. For example, *.example.com would 1478 match a.example.com, foo.example.com, etc., but would not match 1479 example.com. 1481 If the certificate contains multiple names (e.g., more than one 1482 dNSName field), then a match with any one of the fields is 1483 considered acceptable. 1485 ###### 1487 A.5. XMPP (2004) 1489 In 2004, [XMPP] specified the following text regarding server 1490 identity verification in XMPP: 1492 ###### 1494 14.2. Certificate Validation 1496 When an XMPP peer communicates with another peer securely, it MUST 1497 validate the peer's certificate. There are three possible cases: 1499 Case #1: The peer contains an End Entity certificate which appears 1500 to be certified by a certification path terminating in a trust 1501 anchor (as described in Section 6.1 of [PKIX]). 1502 Case #2: The peer certificate is certified by a Certificate 1503 Authority not known to the validating peer. 1504 Case #3: The peer certificate is self-signed. 1506 In Case #1, the validating peer MUST do one of two things: 1507 1. Verify the peer certificate according to the rules of [PKIX]. 1508 The certificate SHOULD then be checked against the expected 1509 identity of the peer following the rules described in [HTTP-TLS], 1510 except that a subjectAltName extension of type "xmpp" MUST be 1511 used as the identity if present. If one of these checks fails, 1512 user-oriented clients MUST either notify the user (clients MAY 1513 give the user the opportunity to continue with the connection in 1514 any case) or terminate the connection with a bad certificate 1515 error. Automated clients SHOULD terminate the connection (with a 1516 bad certificate error) and log the error to an appropriate audit 1517 log. Automated clients MAY provide a configuration setting that 1518 disables this check, but MUST provide a setting that enables it. 1519 2. The peer SHOULD show the certificate to a user for approval, 1520 including the entire certification path. The peer MUST cache the 1521 certificate (or some non-forgeable representation such as a 1522 hash). In future connections, the peer MUST verify that the same 1523 certificate was presented and MUST notify the user if it has 1524 changed. 1526 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 1528 ###### 1529 At the time of this writing, [XMPPBIS] refers to this document for 1530 rules regarding server identity verification in XMPP. 1532 A.6. NNTP (2006) 1534 In 2006, [NNTP-TLS] specified the following text regarding server 1535 identity verification in NNTP: 1537 ###### 1539 5. Security Considerations 1541 [...] 1543 During the TLS negotiation, the client MUST check its understanding 1544 of the server hostname against the server's identity as presented in 1545 the server Certificate message, in order to prevent man-in-the-middle 1546 attacks. Matching is performed according to these rules: 1548 o The client MUST use the server hostname it used to open the 1549 connection (or the hostname specified in TLS "server_name" 1550 extension [TLS]) as the value to compare against the server name 1551 as expressed in the server certificate. The client MUST NOT use 1552 any form of the server hostname derived from an insecure remote 1553 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1554 done. 1555 o If a subjectAltName extension of type dNSName is present in the 1556 certificate, it SHOULD be used as the source of the server's 1557 identity. 1558 o Matching is case-insensitive. 1559 o A "*" wildcard character MAY be used as the left-most name 1560 component in the certificate. For example, *.example.com would 1561 match a.example.com, foo.example.com, etc., but would not match 1562 example.com. 1563 o If the certificate contains multiple names (e.g., more than one 1564 dNSName field), then a match with any one of the fields is 1565 considered acceptable. 1567 If the match fails, the client SHOULD either ask for explicit user 1568 confirmation or terminate the connection with a QUIT command and 1569 indicate the server's identity is suspect. 1571 Additionally, clients MUST verify the binding between the identity of 1572 the servers to which they connect and the public keys presented by 1573 those servers. Clients SHOULD implement the algorithm in Section 6 1574 of [PKIX] for general certificate validation, but MAY supplement that 1575 algorithm with other validation methods that achieve equivalent 1576 levels of verification (such as comparing the server certificate 1577 against a local store of already-verified certificates and identity 1578 bindings). 1580 ###### 1582 A.7. NETCONF (2006/2009) 1584 In 2006, [NETCONF-SSH] specified the following text regarding server 1585 identity verification in NETCONF: 1587 ###### 1589 6. Security Considerations 1591 The identity of the server MUST be verified and authenticated by the 1592 client according to local policy before password-based authentication 1593 data or any configuration or state data is sent to or received from 1594 the server. The identity of the client MUST also be verified and 1595 authenticated by the server according to local policy to ensure that 1596 the incoming client request is legitimate before any configuration or 1597 state data is sent to or received from the client. Neither side 1598 should establish a NETCONF over SSH connection with an unknown, 1599 unexpected, or incorrect identity on the opposite side. 1601 ###### 1603 In 2009, [NETCONF-TLS] specified the following text regarding server 1604 identity verification in NETCONF: 1606 ###### 1608 3.1. Server Identity 1610 During the TLS negotiation, the client MUST carefully examine the 1611 certificate presented by the server to determine if it meets the 1612 client's expectations. Particularly, the client MUST check its 1613 understanding of the server hostname against the server's identity as 1614 presented in the server Certificate message, in order to prevent man- 1615 in-the-middle attacks. 1617 Matching is performed according to the rules below (following the 1618 example of [NNTP-TLS]): 1620 o The client MUST use the server hostname it used to open the 1621 connection (or the hostname specified in the TLS "server_name" 1622 extension [TLS]) as the value to compare against the server name 1623 as expressed in the server certificate. The client MUST NOT use 1624 any form of the server hostname derived from an insecure remote 1625 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1626 done. 1627 o If a subjectAltName extension of type dNSName is present in the 1628 certificate, it MUST be used as the source of the server's 1629 identity. 1630 o Matching is case-insensitive. 1631 o A "*" wildcard character MAY be used as the leftmost name 1632 component in the certificate. For example, *.example.com would 1633 match a.example.com, foo.example.com, etc., but would not match 1634 example.com. 1635 o If the certificate contains multiple names (e.g., more than one 1636 dNSName field), then a match with any one of the fields is 1637 considered acceptable. 1639 If the match fails, the client MUST either ask for explicit user 1640 confirmation or terminate the connection and indicate the server's 1641 identity is suspect. 1643 Additionally, clients MUST verify the binding between the identity of 1644 the servers to which they connect and the public keys presented by 1645 those servers. Clients SHOULD implement the algorithm in Section 6 1646 of [PKIX] for general certificate validation, but MAY supplement that 1647 algorithm with other validation methods that achieve equivalent 1648 levels of verification (such as comparing the server certificate 1649 against a local store of already-verified certificates and identity 1650 bindings). 1652 If the client has external information as to the expected identity of 1653 the server, the hostname check MAY be omitted. 1655 ###### 1657 A.8. Syslog (2009) 1659 In 2009, [SYSLOG-TLS] specified the following text regarding server 1660 identity verification in Syslog: 1662 ###### 1664 5.2. Subject Name Authorization 1666 Implementations MUST support certification path validation [PKIX]. 1667 In addition, they MUST support specifying the authorized peers using 1668 locally configured host names and matching the name against the 1669 certificate as follows. 1671 o Implementations MUST support matching the locally configured host 1672 name against a dNSName in the subjectAltName extension field and 1673 SHOULD support checking the name against the common name portion 1674 of the subject distinguished name. 1675 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 1676 the subjectAltName extension (and in common name, if used to store 1677 the host name), but only as the left-most (least significant) DNS 1678 label in that value. This wildcard matches any left-most DNS 1679 label in the server name. That is, the subject *.example.com 1680 matches the server names a.example.com and b.example.com, but does 1681 not match example.com or a.b.example.com. Implementations MUST 1682 support wildcards in certificates as specified above, but MAY 1683 provide a configuration option to disable them. 1684 o Locally configured names MAY contain the wildcard character to 1685 match a range of values. The types of wildcards supported MAY be 1686 more flexible than those allowed in subject names, making it 1687 possible to support various policies for different environments. 1688 For example, a policy could allow for a trust-root-based 1689 authorization where all credentials issued by a particular CA 1690 trust root are authorized. 1691 o If the locally configured name is an internationalized domain 1692 name, conforming implementations MUST convert it to the ASCII 1693 Compatible Encoding (ACE) format for performing comparisons, as 1694 specified in Section 7 of [PKIX]. 1695 o Implementations MAY support matching a locally configured IP 1696 address against an iPAddress stored in the subjectAltName 1697 extension. In this case, the locally configured IP address is 1698 converted to an octet string as specified in [PKIX], Section 1699 4.2.1.6. A match occurs if this octet string is equal to the 1700 value of iPAddress in the subjectAltName extension. 1702 ###### 1704 A.9. SIP (2010) 1706 At the time of this writing, [SIP-CERTS] specified text regarding 1707 server identity verification in the Session Initiation Protocol 1708 (SIP). However, that specification has not yet been approved by the 1709 IESG and text cannot be considered final. 1711 The relevant text follows. 1713 ###### 1715 7.2. Comparing SIP Identities 1717 When an implementation (either client or server) compares two values 1718 as SIP domain identities: 1720 Implementations MUST compare only the DNS name component of each 1721 SIP domain identifier; an implementation MUST NOT use any scheme 1722 or parameters in the comparison. 1723 Implementations MUST compare the values as DNS names, which means 1724 that the comparison is case insensitive as specified by 1725 [DNS-CASE]. Implementations MUST handle Internationalized Domain 1726 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 1727 Implementations MUST match the values in their entirety: 1728 Implementations MUST NOT match suffixes. For example, 1729 "foo.example.com" does not match "example.com". 1730 Implemenations MUST NOT match any form of wildcard, such as a 1731 leading "." or "*." with any other DNS label or sequence of 1732 labels. For example, "*.example.com" matches only 1733 "*.example.com" but not "foo.example.com". Similarly, 1734 ".example.com" matches only ".example.com", and does not match 1735 "foo.example.com." 1736 [HTTP-TLS] allows the dNSName component to contain a 1737 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 1738 disallowing this explicitly, leaves the interpretation of 1739 wildcards to the individual specification. [SIP] does not 1740 provide any guidelines on the presence of wildcards in 1741 certificates. Through the rule above, this document 1742 prohibits such wildcards in certificates for SIP domains. 1744 ###### 1746 A.10. GIST (2010) 1748 In 2010, [GIST] specified the following text regarding server 1749 identity verification in the General Internet Signalling Transport: 1751 ###### 1753 5.7.3.1. Identity Checking in TLS 1755 After TLS authentication, a node MUST check the identity presented by 1756 the peer in order to avoid man-in-the-middle attacks, and verify that 1757 the peer is authorised to take part in signalling at the GIST layer. 1758 The authorisation check is carried out by comparing the presented 1759 identity with each Authorised Peer Database (APD) entry in turn, as 1760 discussed in Section 4.4.2. This section defines the identity 1761 comparison algorithm for a single APD entry. 1763 For TLS authentication with X.509 certificates, an identity from the 1764 DNS namespace MUST be checked against each subjectAltName extension 1765 of type dNSName present in the certificate. If no such extension is 1766 present, then the identity MUST be compared to the (most specific) 1767 Common Name in the Subject field of the certificate. When matching 1768 DNS names against dNSName or Common Name fields, matching is case- 1769 insensitive. Also, a "*" wildcard character MAY be used as the left- 1770 most name component in the certificate or identity in the APD. For 1771 example, *.example.com in the APD would match certificates for 1772 a.example.com, foo.example.com, *.example.com, etc., but would not 1773 match example.com. Similarly, a certificate for *.example.com would 1774 be valid for APD identities of a.example.com, foo.example.com, 1775 *.example.com, etc., but not example.com. 1777 Additionally, a node MUST verify the binding between the identity of 1778 the peer to which it connects and the public key presented by that 1779 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 1780 for general certificate validation, but MAY supplement that algorithm 1781 with other validation methods that achieve equivalent levels of 1782 verification (such as comparing the server certificate against a 1783 local store of already-verified certificates and identity bindings). 1785 For TLS authentication with pre-shared keys, the identity in the 1786 psk_identity_hint (for the server identity, i.e. the Responding node) 1787 or psk_identity (for the client identity, i.e. the Querying node) 1788 MUST be compared to the identities in the APD. 1790 ###### 1792 Authors' Addresses 1794 Peter Saint-Andre 1795 Cisco Systems, Inc. 1796 1899 Wyknoop Street, Suite 600 1797 Denver, CO 80202 1798 USA 1800 Phone: +1-303-308-3282 1801 Email: psaintan@cisco.com 1803 Jeff Hodges 1804 PayPal 1806 Email: Jeff.Hodges@PayPal.com