idnits 2.17.00 (12 Aug 2021) /tmp/idnits11407/draft-saintandre-tls-server-id-check-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 4 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 (March 8, 2010) is 4456 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 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) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 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 2459 (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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Hodges, Ed. 5 Expires: September 9, 2010 PayPal 6 March 8, 2010 8 Representation and Verification of Application Server Identity in 9 Certificates Used with Transport Layer Security (TLS) 10 draft-saintandre-tls-server-id-check-03 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 procedures for representing 17 and verifying the identity of application servers in such 18 interactions. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4 66 2. Architectural Assumptions . . . . . . . . . . . . . . . . . . 5 67 3. Representation of Server Identity . . . . . . . . . . . . . . 6 68 4. Verification of Server Identity . . . . . . . . . . . . . . . 7 69 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. Comparison Rules . . . . . . . . . . . . . . . . . . . . . 8 71 4.2.1. Traditional Domain Names . . . . . . . . . . . . . . . 9 72 4.2.2. Internationalized Domain Names . . . . . . . . . . . . 9 73 4.2.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . 9 74 4.2.4. Common Names . . . . . . . . . . . . . . . . . . . . . 10 75 4.2.5. Relative Distinguished Names . . . . . . . . . . . . . 10 76 4.3. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 15 83 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 15 84 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 16 85 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 17 86 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 20 87 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 21 88 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 22 89 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 23 90 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 25 91 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 26 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 1.1. Motivation 98 When a client wishes to establish a secure communication channel with 99 an application server (e.g., "the HTTP server for example.com"), at a 100 minimum the client needs to verify the identity of the server in 101 order to prevent certain passive and active attacks against the 102 connection. To establish secure connections, many application 103 technologies use Transport Layer Security [TLS] with certificates 104 issued by certification authorities that are part of the Internet 105 X.509 Public Key Infrastructure (PKI) as described in [X509]; such 106 application technologies include but are not limited to the 107 following: 109 o The Hypertext Transfer Protocol [HTTP], for which see also 110 [HTTP-TLS] 111 o The Internet Message Access Protocol [IMAP] and the Post Office 112 Protocol [POP3], for which see also [USINGTLS] 113 o The Lightweight Directory Access Protocol [LDAP], for which see 114 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 115 o The NETCONF Configuration Protocol [NETCONF], for which see also 116 [NETCONF-SSH] and [NETCONF-TLS] 117 o The Network News Transfer Protocol [NNTP], for which see also 118 [NNTP-TLS] 119 o The Session Initiation Protocol [SIP], for which see also 120 [SIP-CERTS] 121 o The Simple Mail Transfer Protocol [SMTP], for which see also 122 [SMTP-AUTH] and [SMTP-TLS] 123 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] 124 o The Extensible Messaging and Presence Protocol [XMPP], for which 125 see also [XMPPBIS] 127 Different application protocols have traditionally specified their 128 own rules for representing and verifying server identities. 129 Unfortunately, this divergence of approaches has caused some 130 confusion among certification authorities, protocol designers, and 131 application developers. 133 Futhermore, currently the vast majority of deployed application 134 servers use domain names in their certificates (typically via a 135 subjectAltName extension of dNSName or a subjectName component of 136 Common Name). Ideally, service operators would use application 137 service identities in their certificates (such as an SRVName 138 [SRVNAME], a URI, or an application-specific name form), since this 139 would reduce the possibility of attacks against unrelated services at 140 domain names that provide many different application services. 142 To codify secure authentication practices, this document specifies 143 recommended procedures for representing and verifying server 144 identities in certificates intended for use in applications that 145 employ TLS. 147 1.2. Scope 149 This document applies only to server identities associated with 150 domain names, only to TLS, and only to the PKI. Similar 151 considerations might apply to client identities (e.g., for mutual 152 authentication), to identities other than domain names (e.g., IP 153 addresses), to security protocols other than TLS (e.g., [IPSEC] and 154 [DTLS]), and to keys or certificates created outside the context of 155 the PKI (e.g., where a dependency on Certificate Revocation Lists or 156 the Online Certificate Status Protocol might introduce unacceptable 157 latency or denial of service attacks). Although those scenarios 158 might be able to re-use some aspects of the representation and 159 verification rules provided here, they are outside the scope of this 160 document and need to be addressed by separate specifications. 162 1.3. Terminology 164 Most security-related terms in this document are to be understood in 165 the sense defined in [SECTERMS]; such terms include, but are not 166 limited to, "attack", "authentication", "authorization", 167 "certificate", "credential", "identity", "self-signed certificate", 168 "trust", "trust anchor", "trust chain", "validate", and "verify". 170 The following capitalized keywords are to be interpreted as described 171 in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 172 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 173 "OPTIONAL". 175 1.4. Contributors 177 The following individuals made significant contributions to the text 178 of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 180 1.5. Acknowledgements 182 The editors and contributors wish to thank the following individuals 183 for their feedback and suggestions: Dave Crocker, Cyrus Daboo, Philip 184 Guenther, David Harrington, Paul Hoffman, Scott Lawrence, Alexey 185 Melnikov, Tom Petch, Pete Resnick, Joe Salowey, and Dan Wing. 187 2. Architectural Assumptions 189 Internet applications often use a client-server architecture in which 190 a client connects to a server in order to retrieve or upload data, 191 access a broader network of services, or communicate with other 192 entities on the network. From the security perspective, a client 193 might be a user agent controlled by a human, an automated process 194 such as a bot, or a peer server. We assume that an application 195 server hosts information, enables a provisioned account to perform 196 authorized services, or provides network access on behalf of a 197 particular organization or service that is canonically identified by 198 a domain name (not, e.g., an IP address). The specific application 199 provided (e.g., a web site or an instant messaging system) might 200 further restrict the identity type that is represented or verified in 201 a TLS interaction; such an identity type is often informal (e.g., 202 most people expect a service that is provided on port 443 to be a web 203 server) but can be specified more formally through the use of DNS SRV 204 records [DNS-SRV], a Uniform Resource Identifier [URI] represented by 205 a subjectAltName of uniformResourceIdentifier, the SRVName 206 certificate extension defined in [SRVNAME], or other certificate 207 extensions that have been defined for particular identity types 208 (e.g., the XmppAddr extension for use in [XMPP]). The certificate 209 presented by an application server might contain one identity or it 210 might contain multiple identities of different types (e.g., one 211 identity might be a simple dNSName and another might be an SRVName 212 that restricts the certificate to use in the context of the specified 213 service). 215 When a client connects to an application server, it has some 216 conception of either the server's identity (e.g., "an XMPP server for 217 example.com") or of the server's location (e.g., "the SMTP server at 218 mail.example.com"). The client expects at least one of the server's 219 presented identities to match this reference identity. It is 220 important to note that the reference identity is provided by a human 221 user or configured into the client application (e.g., in the domain 222 part of an "Application Unique String" as described in [SIP-LOC]), 223 and is not an identity that is derived from the reference identity in 224 an automated fashion (e.g., an IP address discovered through DNS 225 resolution of the reference identity). Only a match between the 226 reference identity and a presented identity enables the client to be 227 sure that the certificate can legitimately be used to secure the 228 connection. However, a user-oriented client MAY provide a 229 configuration setting that enables a human user to explicitly specify 230 a particular hostname to be checked for connection purposes, thus 231 explicitly overriding matching rules. 233 To summarize, we define the following terms to assist in 234 understanding the process of representing and verifying server 235 identity: 237 identity set: The set of identities that are presented by a server 238 to a client (in the form of the server's X.509 certificate) when 239 the client attempts to establish a secure connection with the 240 server. 241 identity type: The "natural kind" of identity to which a presented 242 identity or reference identity belongs. For example, the 243 reference identity might be a domain name, an IPv4 or IPv6 244 address, or a particular service in the sense of [DNS-SRV] or 245 [SRVNAME]. This specification does not provide a complete 246 taxonomy of identity types but assumes that an application server 247 is identified by a domain name that could be represented in the 248 form of several identity types (e.g., a dNSName and an SRVName). 249 presented identity: A single member of the identity set. 250 reference identity: The client's conception of the server's identity 251 before it attempts to establish a secure connection with the 252 server, i.e. the identity that the client expects the server to 253 present and to which the client makes reference when attempting to 254 verify the server's identity. The reference identity MUST be 255 provided by the human user controlling the client (if any), e.g. 256 when specifying the server portion of the user's account name on 257 the server or when explicitly configuring the client to connect to 258 a particular host. The reference identity MAY be reflected in the 259 TLS "server_name" extension as specified in [TLS]. 261 3. Representation of Server Identity 263 The following rules apply to the representation of application server 264 identities in certificates issued by certification authorities, i.e., 265 certificates that are to used for securing connections to application 266 servers such as web sites, email services, and instant messaging 267 services. 269 1. The certification authority MUST issue the certificate based on 270 the domain name at which the server will provide the relevant 271 service (not an IP address or host name for a specific machine). 272 2. An identity MAY contain one instance of the wildcard character 273 '*' but only as the left-most label. An application protocol 274 that re-uses the rules specified in this document MUST specify 275 whether the wildcard character is or is not allowed in 276 certificates issued for use with that protocol. 277 3. If the service at which the certificate will be used deploys a 278 technology that is discovered by means of DNS SRV records 279 [DNS-SRV], then the certificate SHOULD include an identity of 280 type SRVName [SRVNAME]. 282 4. If the service is associated with a particular URI, then the 283 certificate MAY include an identity of type 284 uniformResourceIdentifier (i.e., a subjectAltName extension that 285 includes a uniformResourceIdentifier name form whose authority 286 component is the domain name of the service). 287 5. Although the certificate MAY include other application-specific 288 identities for types that were defined before specification of 289 the SRVName extension (e.g., XmppAddr for [XMPP]) or for which 290 service names do not exist, the SRVName extension is preferred. 291 6. If the certificate does not include an SRVName, 292 uniformResourceIdentifier, or other application-specific identity 293 type, then the certificate MUST include an identity of dNSName. 294 7. The certificate SHOULD NOT represent the server's domain name in 295 an identity of Common Name (CN) (see [LDAP-SCHEMA]) in the leaf 296 Relative Distinguished Name (RDN) of the subjectName, even though 297 it is recognized that many deployed clients still check this 298 legacy identity. For example, here the CN is the leaf RDN, which 299 is acceptable: 301 cn=www.example.com, ou=Web Services, c=GB 303 8. The certificate MUST NOT represent the server's domain name in an 304 identity of Common Name (CN) where the CN is in something other 305 than the "leaf" (left-most) position within the Relative 306 Distinguished Names (RDNs) of the subjectName. For example, here 307 the CN is not the leaf RDN, which is unacceptable: 309 c=GB, ou=Web Services, cn=www.example.com 311 9. The certificate MUST NOT represent the server's domain name by 312 means of a series of Domain Component (DC) attributes (because 313 the order of Domain Components is not guaranteed, certain attacks 314 are possible if DC attributes are included). 316 4. Verification of Server Identity 318 4.1. Overview 320 At a high level, the client verifies the server's identity in 321 accordance with the following rules: 323 1. Before connecting to the server, the client determines the 324 possible identity type(s) of the reference identity. 325 2. During the process of attempting to establish a secure 326 connection, the server MUST present its identity set to the 327 client in the form of an X.509 certificate [X509]. 329 3. Upon being presented with the server's identity set, the client 330 MUST check the reference identity against the presented 331 identities for the purpose of finding a match. To do so, the 332 client iterates through all of the subjectAltName extensions it 333 recognizes in the server's certificate and compares the value of 334 each extension to the reference identity until it has either 335 produced a match or exhausted the identities in the identity set 336 (comparison rules for matching particular identity types are 337 provided under Section 4.2, including fallbacks to several 338 subjectName fields). Even if the application technology does not 339 define an application-specific preference order for checking of 340 identities, the client SHOULD check them in order from most 341 specific (e.g., SRVName) to least specific (e.g., dNSName). 342 4. Before attempting to find a match in relation to a particular 343 presented identity, the client MAY map the reference identity to 344 a different identity type. Such a mapping MAY be performed for 345 any available subjectAltName type to which the reference identity 346 can be mapped; however, the reference identity SHOULD be mapped 347 only to types for which the mapping is inherently secure (e.g., 348 extracting the domain name from a URI to match against a 349 subjectAltName of type dNSName or SRVName). 350 5. The client MUST NOT attempt to match against an an identity of 351 type SRVName [SRVNAME] unless the service to which the client has 352 connected deploys a technology that is discovered by means of DNS 353 SRV records [DNS-SRV]. 354 6. If the identity set has more than one member, a match with any of 355 the presented identities is acceptable. 357 Note: A hostname that is resolved via the Domain Name System MUST 358 NOT be used as the reference identity unless an administrator or 359 human user has explicitly configured an application to associate a 360 particular hostname (and potentially port) with the hostname to 361 which the application connects (e.g., to "hardcode" an association 362 between an original hostname of example.net and a configured 363 hostname of connector.example.com:443). 365 In addition to the identity check described in this section, a client 366 might complete further verification to ensure that the server is 367 authorized to provide the service it is requested to provide. 368 Methods for doing so (which might include consulting local policy 369 information) are out of scope for this document. 371 4.2. Comparison Rules 373 This document assumes that the reference identity is a domain name as 374 defined by [RFC1034] and [RFC1035] for "traditional" domain names or 375 by [IDNA2003] or [IDNA2008] for internationalized domain names. The 376 client MUST match the reference identity against subjectAltName 377 extensions of type dNSName and SRVName [SRVNAME] according to the 378 following rules. 380 4.2.1. Traditional Domain Names 382 If the reference identity is a "traditional" domain name, then 383 matching of reference identity against the presented identity is 384 performed by comparing the set of domain components using a case- 385 insensitive ASCII comparison (as clarified by [DNS-CASE]). 387 4.2.2. Internationalized Domain Names 389 Note: This section needs to be updated to reflect [IDNA2008]. 391 If the reference identity is an internationalized domain name, then 392 an implementation MUST convert the reference identity to the ASCII 393 Compatible Encoding (ACE) format as specified in Section 4 of 394 [IDNA2003] before comparison with subjectAltName values of type 395 dNSName; specifically, the conversion operation specified in Section 396 4 of [IDNA2003] MUST be performed as follows: 398 o In step 1, the domain name SHALL be considered a "stored string". 399 o In step 3, set the flag called "UseSTD3ASCIIRules". 400 o In step 4, process each label with the "ToASCII" operation. 401 o In step 5, change all label separators to U+002E (full stop). 403 After performing the "to-ASCII" conversion with regard to an 404 internationalized domain name, the DNS labels and names MUST be 405 compared for equality according to the rules specified in Section 3 406 of [IDNA2003], i.e. once all label separators are replaced with 407 U+002E (dot) they are compared in a case-insensitive manner. 409 4.2.3. Wildcards 411 Unless otherwise specified by an application protocol that re-uses 412 the rules specified in this document, the client MAY match against an 413 identity that contains one instance of the wildcard character '*' as 414 the left-most label of the domain name. If it does so, the client 415 MUST match the reference identity against the entire left-most label 416 only (thus *.example.com matches foo.example.com but not 417 bar.foo.example.com or example.com itself). The client MUST ignore a 418 presented identity in which the wildcard character is contained 419 within a label fragment (e.g., baz*.example.net is not allowed and 420 MUST NOT be taken to match baz1.example.net and baz2.example.net). 422 4.2.4. Common Names 424 If and only if the identity set does not include subjectAltName 425 extensions of type dNSName, SRVName, uniformResourceIdentifier (or 426 other application-specific subjectAltName extensions), the client MAY 427 as a fallback check the value of the Common Name (CN) if presented as 428 the leaf (left-most) Relative Distinguished Name (RND) in the 429 subjectName component of the server's X.509 certificate. In existing 430 certificates, the CN is often used for representing a domain name; 431 for example, consider the following subjectName with a leaf RDN of 432 Common Name: 434 cn=www.example.com, ou=Web Services, c=GB 436 Here the Common Name is "www.example.com" and the client could choose 437 to compare the reference identity against that CN. When doing so, 438 the client MUST follow the comparison rules described above for 439 subjectAltName extensions of type dNSName and SRVName. 441 A client MUST NOT check the Common Name if it is other than the leaf 442 (left-most) Relative Distinguished Name (RDN) in the subjectName. 444 4.2.5. Relative Distinguished Names 446 A client MUST NOT check Relative Distinguished Names (RDNs) other 447 than the Common Name; in particular, this means that a series of 448 Domain Component (DC) attributes MUST NOT be checked (because the 449 order of Domain Components is not guaranteed, certain attacks are 450 possible if DC attributes are checked). 452 4.3. Outcome 454 The outcome of the checking procedure is one of the following: 456 Case #1: The client finds at least one presented identity that 457 matches the reference identity; the entity MUST use this as the 458 validated identity of the server. 459 Case #2: The client finds no subjectAltName or subjectName that 460 matches the reference identity but a human user has permanently 461 accepted the certificate during a previous connection attempt; the 462 client MUST verify that the cached certificate was presented and 463 MUST notify the user if the certificate has changed since the last 464 time that a secure connection was successfully negotiated. 465 Case #3: The client finds no subjectAltName or subjectName that 466 matches the reference identity and a human user has not 467 permanently accepted the certificate during a previous connection 468 attempt. The client MUST NOT use the presented identity (if any). 469 Instead, if the client is a user-oriented application, then it 470 MUST either (1) automatically terminate the connection with a bad 471 certificate error or (2) show the certificate (including the 472 entire certificate chain) to the user and give the user the choice 473 of terminating the connecting or accepting the certificate 474 temporarily (i.e., for this connection attempt only) or 475 permanently (i.e., for all future connection attempts) and then 476 continuing with the connection; if a user permanently accepts a 477 certificate in this way, the client MUST cache the certificate (or 478 some non-forgeable representation such as a hash value) and in 479 future connection MUST attempt behave as in Case #2. (It is the 480 resposibility of the human user to verify the hash value or 481 fingerprint of the certificate with the server over a trusted 482 communication layer.) If the client is an automated application, 483 then it SHOULD terminate the connection with a bad certificate 484 error and log the error to an appropriate audit log; an automated 485 application MAY provide a configuration setting that disables this 486 check, but MUST enable the check by default. 488 5. Security Considerations 490 This entire document discusses security. 492 6. IANA Considerations 494 This document has no actions for the IANA. 496 7. References 498 7.1. Normative References 500 [IDNA2003] 501 Faltstrom, P., Hoffman, P., and A. Costello, 502 "Internationalizing Domain Names in Applications (IDNA)", 503 RFC 3490, March 2003. 505 [IDNA2008] 506 Klensin, J., "Internationalized Domain Names in 507 Applications (IDNA): Protocol", 508 draft-ietf-idnabis-protocol-18 (work in progress), 509 January 2010. 511 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 512 STD 13, RFC 1034, November 1987. 514 [RFC1035] Mockapetris, P., "Domain names - implementation and 515 specification", STD 13, RFC 1035, November 1987. 517 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 518 Subject Alternative Name for Expression of Service Name", 519 RFC 4985, August 2007. 521 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 525 Housley, R., and W. Polk, "Internet X.509 Public Key 526 Infrastructure Certificate and Certificate Revocation List 527 (CRL) Profile", RFC 5280, May 2008. 529 7.2. Informative References 531 [DNS-CASE] 532 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 533 Clarification", RFC 4343, January 2006. 535 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 536 specifying the location of services (DNS SRV)", RFC 2782, 537 February 2000. 539 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 540 Rose, "DNS Security Introduction and Requirements", 541 RFC 4033, March 2005. 543 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 544 Security", RFC 4347, April 2006. 546 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 547 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 548 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 550 [HTTP-TLS] 551 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 553 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 554 4rev1", RFC 3501, March 2003. 556 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 557 September 1981. 559 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 560 (IPv6) Specification", RFC 2460, December 1998. 562 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 563 Internet Protocol", RFC 4301, December 2005. 565 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 566 (LDAP): The Protocol", RFC 4511, June 2006. 568 [LDAP-AUTH] 569 Harrison, R., "Lightweight Directory Access Protocol 570 (LDAP): Authentication Methods and Security Mechanisms", 571 RFC 4513, June 2006. 573 [LDAP-SCHEMA] 574 Sciberras, A., "Lightweight Directory Access Protocol 575 (LDAP): Schema for User Applications", RFC 4519, 576 June 2006. 578 [LDAP-TLS] 579 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 580 Directory Access Protocol (v3): Extension for Transport 581 Layer Security", RFC 2830, May 2000. 583 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 584 December 2006. 586 [NETCONF-SSH] 587 Wasserman, M. and T. Goddard, "Using the NETCONF 588 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 589 December 2006. 591 [NETCONF-TLS] 592 Badra, M., "NETCONF over Transport Layer Security (TLS)", 593 RFC 5539, May 2009. 595 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 596 RFC 3977, October 2006. 598 [NNTP-TLS] 599 Murchison, K., Vinocur, J., and C. Newman, "Using 600 Transport Layer Security (TLS) with Network News Transfer 601 Protocol (NNTP)", RFC 4642, October 2006. 603 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 604 STD 53, RFC 1939, May 1996. 606 [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 607 X.509 Public Key Infrastructure Certificate and CRL 608 Profile", RFC 2459, January 1999. 610 [SECTERMS] 611 Shirey, R., "Internet Security Glossary, Version 2", 612 RFC 4949, August 2007. 614 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 615 A., Peterson, J., Sparks, R., Handley, M., and E. 616 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 617 June 2002. 619 [SIP-CERTS] 620 Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 621 Certificates in the Session Initiation Protocol (SIP)", 622 draft-ietf-sip-domain-certs-04 (work in progress), 623 May 2009. 625 [SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation 626 Protocol (SIP): Locating SIP Servers", RFC 3263, 627 June 2002. 629 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 630 October 2008. 632 [SMTP-AUTH] 633 Siemborski, R. and A. Melnikov, "SMTP Service Extension 634 for Authentication", RFC 4954, July 2007. 636 [SMTP-TLS] 637 Hoffman, P., "SMTP Service Extension for Secure SMTP over 638 Transport Layer Security", RFC 3207, February 2002. 640 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 642 [SYSLOG-TLS] 643 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 644 Security (TLS) Transport Mapping for Syslog", RFC 5425, 645 March 2009. 647 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 648 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 650 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 651 Resource Identifier (URI): Generic Syntax", STD 66, 652 RFC 3986, January 2005. 654 [USINGTLS] 655 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 656 RFC 2595, June 1999. 658 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 659 Protocol (XMPP): Core", RFC 3920, October 2004. 661 [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence 662 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-04 (work 663 in progress), November 2009. 665 Appendix A. Prior Art 667 This section is non-normative. 669 The recommendations in this document are an abstraction from 670 recommendations in specifications for a wide range of application 671 protocols. For the purpose of comparison and to delineate the 672 history of thinking about server identity verification within the 673 IETF, this informative section gathers together prior art by 674 including the exact text from various RFCs (the only modifications 675 are changes to the names of several references to maintain coherence 676 with the main body of this document, and the elision of irrelevant 677 text as marked by the characters "[...]"). 679 A.1. IMAP, POP3, and ACAP (1999) 681 In 1999, [USINGTLS] specified the following text regarding server 682 identity verification in IMAP, POP3, and ACAP: 684 ###### 686 2.4. Server Identity Check 688 During the TLS negotiation, the client MUST check its understanding 689 of the server hostname against the server's identity as presented in 690 the server Certificate message, in order to prevent man-in-the-middle 691 attacks. Matching is performed according to these rules: 693 o The client MUST use the server hostname it used to open the 694 connection as the value to compare against the server name as 695 expressed in the server certificate. The client MUST NOT use any 696 form of the server hostname derived from an insecure remote source 697 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 698 o If a subjectAltName extension of type dNSName is present in the 699 certificate, it SHOULD be used as the source of the server's 700 identity. 701 o Matching is case-insensitive. 702 o A "*" wildcard character MAY be used as the left-most name 703 component in the certificate. For example, *.example.com would 704 match a.example.com, foo.example.com, etc. but would not match 705 example.com. 707 o If the certificate contains multiple names (e.g. more than one 708 dNSName field), then a match with any one of the fields is 709 considered acceptable. 711 If the match fails, the client SHOULD either ask for explicit user 712 confirmation, or terminate the connection and indicate the server's 713 identity is suspect. 715 ###### 717 A.2. HTTP (2000) 719 In 2000, [HTTP-TLS] specified the following text regarding server 720 identity verification in HTTP: 722 ###### 724 3.1. Server Identity 726 In general, HTTP/TLS requests are generated by dereferencing a URI. 727 As a consequence, the hostname for the server is known to the client. 728 If the hostname is available, the client MUST check it against the 729 server's identity as presented in the server's Certificate message, 730 in order to prevent man-in-the-middle attacks. 732 If the client has external information as to the expected identity of 733 the server, the hostname check MAY be omitted. (For instance, a 734 client may be connecting to a machine whose address and hostname are 735 dynamic but the client knows the certificate that the server will 736 present.) In such cases, it is important to narrow the scope of 737 acceptable certificates as much as possible in order to prevent man 738 in the middle attacks. In special cases, it may be appropriate for 739 the client to simply ignore the server's identity, but it must be 740 understood that this leaves the connection open to active attack. 742 If a subjectAltName extension of type dNSName is present, that MUST 743 be used as the identity. Otherwise, the (most specific) Common Name 744 field in the Subject field of the certificate MUST be used. Although 745 the use of the Common Name is existing practice, it is deprecated and 746 Certification Authorities are encouraged to use the dNSName instead. 748 Matching is performed using the matching rules specified by 749 [RFC2459]. If more than one identity of a given type is present in 750 the certificate (e.g., more than one dNSName name, a match in any one 751 of the set is considered acceptable.) Names may contain the wildcard 752 character * which is considered to match any single domain name 753 component or component fragment. E.g., *.a.com matches foo.a.com but 754 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 756 In some cases, the URI is specified as an IP address rather than a 757 hostname. In this case, the iPAddress subjectAltName must be present 758 in the certificate and must exactly match the IP in the URI. 760 If the hostname does not match the identity in the certificate, user 761 oriented clients MUST either notify the user (clients MAY give the 762 user the opportunity to continue with the connection in any case) or 763 terminate the connection with a bad certificate error. Automated 764 clients MUST log the error to an appropriate audit log (if available) 765 and SHOULD terminate the connection (with a bad certificate error). 766 Automated clients MAY provide a configuration setting that disables 767 this check, but MUST provide a setting which enables it. 769 Note that in many cases the URI itself comes from an untrusted 770 source. The above-described check provides no protection against 771 attacks where this source is compromised. For example, if the URI 772 was obtained by clicking on an HTML page which was itself obtained 773 without using HTTP/TLS, a man in the middle could have replaced the 774 URI. In order to prevent this form of attack, users should carefully 775 examine the certificate presented by the server to determine if it 776 meets their expectations. 778 ###### 780 A.3. LDAP (2000/2006) 782 In 2000, [LDAP-TLS] specified the following text regarding server 783 identity verification in LDAP: 785 ###### 787 3.6. Server Identity Check 789 The client MUST check its understanding of the server's hostname 790 against the server's identity as presented in the server's 791 Certificate message, in order to prevent man-in-the-middle attacks. 793 Matching is performed according to these rules: 795 o The client MUST use the server hostname it used to open the LDAP 796 connection as the value to compare against the server name as 797 expressed in the server's certificate. The client MUST NOT use 798 the server's canonical DNS name or any other derived form of name. 799 o If a subjectAltName extension of type dNSName is present in the 800 certificate, it SHOULD be used as the source of the server's 801 identity. 803 o Matching is case-insensitive. 804 o The "*" wildcard character is allowed. If present, it applies 805 only to the left-most name component. 807 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 808 bar.com. If more than one identity of a given type is present in the 809 certificate (e.g. more than one dNSName name), a match in any one of 810 the set is considered acceptable. 812 If the hostname does not match the dNSName-based identity in the 813 certificate per the above check, user-oriented clients SHOULD either 814 notify the user (clients MAY give the user the opportunity to 815 continue with the connection in any case) or terminate the connection 816 and indicate that the server's identity is suspect. Automated 817 clients SHOULD close the connection, returning and/or logging an 818 error indicating that the server's identity is suspect. 820 Beyond the server identity checks described in this section, clients 821 SHOULD be prepared to do further checking to ensure that the server 822 is authorized to provide the service it is observed to provide. The 823 client MAY need to make use of local policy information. 825 ###### 827 In 2006, [LDAP-AUTH] specified the following text regarding server 828 identity verification in LDAP: 830 ###### 832 3.1.3. Server Identity Check 834 In order to prevent man-in-the-middle attacks, the client MUST verify 835 the server's identity (as presented in the server's Certificate 836 message). In this section, the client's understanding of the 837 server's identity (typically the identity used to establish the 838 transport connection) is called the "reference identity". 840 The client determines the type (e.g., DNS name or IP address) of the 841 reference identity and performs a comparison between the reference 842 identity and each subjectAltName value of the corresponding type 843 until a match is produced. Once a match is produced, the server's 844 identity has been verified, and the server identity check is 845 complete. Different subjectAltName types are matched in different 846 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 847 various subjectAltName types. 849 The client may map the reference identity to a different type prior 850 to performing a comparison. Mappings may be performed for all 851 available subjectAltName types to which the reference identity can be 852 mapped; however, the reference identity should only be mapped to 853 types for which the mapping is either inherently secure (e.g., 854 extracting the DNS name from a URI to compare with a subjectAltName 855 of type dNSName) or for which the mapping is performed in a secure 856 manner (e.g., using [DNSSEC], or using user- or admin-configured 857 host-to-address/address-to-host lookup tables). 859 The server's identity may also be verified by comparing the reference 860 identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf 861 Relative Distinguished Name (RDN) of the subjectName field of the 862 server's certificate. This comparison is performed using the rules 863 for comparison of DNS names in Section 3.1.3.1, below, with the 864 exception that no wildcard matching is allowed. Although the use of 865 the Common Name value is existing practice, it is deprecated, and 866 Certification Authorities are encouraged to provide subjectAltName 867 values instead. Note that the TLS implementation may represent DNs 868 in certificates according to X.500 or other conventions. For 869 example, some X.500 implementations order the RDNs in a DN using a 870 left-to-right (most significant to least significant) convention 871 instead of LDAP's right-to-left convention. 873 If the server identity check fails, user-oriented clients SHOULD 874 either notify the user (clients may give the user the opportunity to 875 continue with the LDAP session in this case) or close the transport 876 connection and indicate that the server's identity is suspect. 877 Automated clients SHOULD close the transport connection and then 878 return or log an error indicating that the server's identity is 879 suspect or both. 881 Beyond the server identity check described in this section, clients 882 should be prepared to do further checking to ensure that the server 883 is authorized to provide the service it is requested to provide. The 884 client may need to make use of local policy information in making 885 this determination. 887 3.1.3.1. Comparison of DNS Names 889 If the reference identity is an internationalized domain name, 890 conforming implementations MUST convert it to the ASCII Compatible 891 Encoding (ACE) format as specified in Section 4 of RFC 3490 892 [IDNA2003] before comparison with subjectAltName values of type 893 dNSName. Specifically, conforming implementations MUST perform the 894 conversion operation specified in Section 4 of RFC 3490 as follows: 896 o in step 1, the domain name SHALL be considered a "stored string"; 897 o in step 3, set the flag called "UseSTD3ASCIIRules"; 898 o in step 4, process each label with the "ToASCII" operation; and 899 o in step 5, change all label separators to U+002E (full stop). 901 After performing the "to-ASCII" conversion, the DNS labels and names 902 MUST be compared for equality according to the rules specified in 903 Section 3 of RFC3490. 905 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 906 values of type dNSName, and then only as the left-most (least 907 significant) DNS label in that value. This wildcard matches any 908 left-most DNS label in the server name. That is, the subject 909 *.example.com matches the server names a.example.com and 910 b.example.com, but does not match example.com or a.b.example.com. 912 3.1.3.2. Comparison of IP Addresses 914 When the reference identity is an IP address, the identity MUST be 915 converted to the "network byte order" octet string representation 916 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 917 string will contain exactly four octets. For IP Version 6, as 918 specified in RFC 2460, the octet string will contain exactly sixteen 919 octets. This octet string is then compared against subjectAltName 920 values of type iPAddress. A match occurs if the reference identity 921 octet string and value octet strings are identical. 923 3.1.3.3. Comparison of Other subjectName Types 925 Client implementations MAY support matching against subjectAltName 926 values of other types as described in other documents. 928 ###### 930 A.4. SMTP (2002/2007) 932 In 2002, [SMTP-TLS] specified the following text regarding server 933 identity verification in SMTP: 935 ###### 937 4.1 Processing After the STARTTLS Command 939 [...] 941 The decision of whether or not to believe the authenticity of the 942 other party in a TLS negotiation is a local matter. However, some 943 general rules for the decisions are: 945 o A SMTP client would probably only want to authenticate an SMTP 946 server whose server certificate has a domain name that is the 947 domain name that the client thought it was connecting to. 949 [...] 951 ###### 953 In 2006, [SMTP-AUTH] specified the following text regarding server 954 identity verification in SMTP: 956 ###### 958 14. Additional Requirements When Using SASL PLAIN over TLS 960 [...] 962 After a successful [TLS] negotiation, the client MUST check its 963 understanding of the server hostname against the server's identity as 964 presented in the server Certificate message, in order to prevent man- 965 in-the-middle attacks. If the match fails, the client MUST NOT 966 attempt to authenticate using the SASL PLAIN mechanism. Matching is 967 performed according to the following rules: 969 The client MUST use the server hostname it used to open the 970 connection as the value to compare against the server name as 971 expressed in the server certificate. The client MUST NOT use any 972 form of the server hostname derived from an insecure remote source 973 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 974 If a subjectAltName extension of type dNSName is present in the 975 certificate, it SHOULD be used as the source of the server's 976 identity. 977 Matching is case-insensitive. 978 A "*" wildcard character MAY be used as the leftmost name 979 component in the certificate. For example, *.example.com would 980 match a.example.com, foo.example.com, etc., but would not match 981 example.com. 982 If the certificate contains multiple names (e.g., more than one 983 dNSName field), then a match with any one of the fields is 984 considered acceptable. 986 ###### 988 A.5. XMPP (2004) 990 In 2004, [XMPP] specified the following text regarding server 991 identity verification in XMPP: 993 ###### 995 14.2. Certificate Validation 997 When an XMPP peer communicates with another peer securely, it MUST 998 validate the peer's certificate. There are three possible cases: 1000 Case #1: The peer contains an End Entity certificate which appears 1001 to be certified by a chain of certificates terminating in a trust 1002 anchor (as described in Section 6.1 of [X509]). 1003 Case #2: The peer certificate is certified by a Certificate 1004 Authority not known to the validating peer. 1005 Case #3: The peer certificate is self-signed. 1007 In Case #1, the validating peer MUST do one of two things: 1008 1. Verify the peer certificate according to the rules of [X509]. 1009 The certificate SHOULD then be checked against the expected 1010 identity of the peer following the rules described in [HTTP-TLS], 1011 except that a subjectAltName extension of type "xmpp" MUST be 1012 used as the identity if present. If one of these checks fails, 1013 user-oriented clients MUST either notify the user (clients MAY 1014 give the user the opportunity to continue with the connection in 1015 any case) or terminate the connection with a bad certificate 1016 error. Automated clients SHOULD terminate the connection (with a 1017 bad certificate error) and log the error to an appropriate audit 1018 log. Automated clients MAY provide a configuration setting that 1019 disables this check, but MUST provide a setting that enables it. 1020 2. The peer SHOULD show the certificate to a user for approval, 1021 including the entire certificate chain. The peer MUST cache the 1022 certificate (or some non-forgeable representation such as a 1023 hash). In future connections, the peer MUST verify that the same 1024 certificate was presented and MUST notify the user if it has 1025 changed. 1027 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 1029 ###### 1031 At the time of this writing, [XMPPBIS] refers to this document for 1032 rules regarding server identity verification in XMPP. 1034 A.6. NNTP (2006) 1036 In 2006, [NNTP-TLS] specified the following text regarding server 1037 identity verification in NNTP: 1039 ###### 1040 5. Security Considerations 1042 [...] 1044 During the TLS negotiation, the client MUST check its understanding 1045 of the server hostname against the server's identity as presented in 1046 the server Certificate message, in order to prevent man-in-the-middle 1047 attacks. Matching is performed according to these rules: 1049 o The client MUST use the server hostname it used to open the 1050 connection (or the hostname specified in TLS "server_name" 1051 extension [TLS]) as the value to compare against the server name 1052 as expressed in the server certificate. The client MUST NOT use 1053 any form of the server hostname derived from an insecure remote 1054 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1055 done. 1056 o If a subjectAltName extension of type dNSName is present in the 1057 certificate, it SHOULD be used as the source of the server's 1058 identity. 1059 o Matching is case-insensitive. 1060 o A "*" wildcard character MAY be used as the left-most name 1061 component in the certificate. For example, *.example.com would 1062 match a.example.com, foo.example.com, etc., but would not match 1063 example.com. 1064 o If the certificate contains multiple names (e.g., more than one 1065 dNSName field), then a match with any one of the fields is 1066 considered acceptable. 1068 If the match fails, the client SHOULD either ask for explicit user 1069 confirmation or terminate the connection with a QUIT command and 1070 indicate the server's identity is suspect. 1072 Additionally, clients MUST verify the binding between the identity of 1073 the servers to which they connect and the public keys presented by 1074 those servers. Clients SHOULD implement the algorithm in Section 6 1075 of [X509] for general certificate validation, but MAY supplement that 1076 algorithm with other validation methods that achieve equivalent 1077 levels of verification (such as comparing the server certificate 1078 against a local store of already-verified certificates and identity 1079 bindings). 1081 ###### 1083 A.7. NETCONF (2006/2009) 1085 In 2006, [NETCONF-SSH] specified the following text regarding server 1086 identity verification in NETCONF: 1088 ###### 1090 6. Security Considerations 1092 The identity of the server MUST be verified and authenticated by the 1093 client according to local policy before password-based authentication 1094 data or any configuration or state data is sent to or received from 1095 the server. The identity of the client MUST also be verified and 1096 authenticated by the server according to local policy to ensure that 1097 the incoming client request is legitimate before any configuration or 1098 state data is sent to or received from the client. Neither side 1099 should establish a NETCONF over SSH connection with an unknown, 1100 unexpected, or incorrect identity on the opposite side. 1102 ###### 1104 In 2009, [NETCONF-TLS] specified the following text regarding server 1105 identity verification in NETCONF: 1107 ###### 1109 3.1. Server Identity 1111 During the TLS negotiation, the client MUST carefully examine the 1112 certificate presented by the server to determine if it meets the 1113 client's expectations. Particularly, the client MUST check its 1114 understanding of the server hostname against the server's identity as 1115 presented in the server Certificate message, in order to prevent man- 1116 in-the-middle attacks. 1118 Matching is performed according to the rules below (following the 1119 example of [NNTP-TLS]): 1121 o The client MUST use the server hostname it used to open the 1122 connection (or the hostname specified in the TLS "server_name" 1123 extension [TLS]) as the value to compare against the server name 1124 as expressed in the server certificate. The client MUST NOT use 1125 any form of the server hostname derived from an insecure remote 1126 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1127 done. 1128 o If a subjectAltName extension of type dNSName is present in the 1129 certificate, it MUST be used as the source of the server's 1130 identity. 1131 o Matching is case-insensitive. 1132 o A "*" wildcard character MAY be used as the leftmost name 1133 component in the certificate. For example, *.example.com would 1134 match a.example.com, foo.example.com, etc., but would not match 1135 example.com. 1137 o If the certificate contains multiple names (e.g., more than one 1138 dNSName field), then a match with any one of the fields is 1139 considered acceptable. 1141 If the match fails, the client MUST either ask for explicit user 1142 confirmation or terminate the connection and indicate the server's 1143 identity is suspect. 1145 Additionally, clients MUST verify the binding between the identity of 1146 the servers to which they connect and the public keys presented by 1147 those servers. Clients SHOULD implement the algorithm in Section 6 1148 of [X509] for general certificate validation, but MAY supplement that 1149 algorithm with other validation methods that achieve equivalent 1150 levels of verification (such as comparing the server certificate 1151 against a local store of already-verified certificates and identity 1152 bindings). 1154 If the client has external information as to the expected identity of 1155 the server, the hostname check MAY be omitted. 1157 ###### 1159 A.8. Syslog (2009) 1161 In 2009, [SYSLOG-TLS] specified the following text regarding server 1162 identity verification in Syslog: 1164 ###### 1166 5.2. Subject Name Authorization 1168 Implementations MUST support certification path validation [X509]. 1169 In addition, they MUST support specifying the authorized peers using 1170 locally configured host names and matching the name against the 1171 certificate as follows. 1173 o Implementations MUST support matching the locally configured host 1174 name against a dNSName in the subjectAltName extension field and 1175 SHOULD support checking the name against the common name portion 1176 of the subject distinguished name. 1177 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 1178 the subjectAltName extension (and in common name, if used to store 1179 the host name), but only as the left-most (least significant) DNS 1180 label in that value. This wildcard matches any left-most DNS 1181 label in the server name. That is, the subject *.example.com 1182 matches the server names a.example.com and b.example.com, but does 1183 not match example.com or a.b.example.com. Implementations MUST 1184 support wildcards in certificates as specified above, but MAY 1185 provide a configuration option to disable them. 1186 o Locally configured names MAY contain the wildcard character to 1187 match a range of values. The types of wildcards supported MAY be 1188 more flexible than those allowed in subject names, making it 1189 possible to support various policies for different environments. 1190 For example, a policy could allow for a trust-root-based 1191 authorization where all credentials issued by a particular CA 1192 trust root are authorized. 1193 o If the locally configured name is an internationalized domain 1194 name, conforming implementations MUST convert it to the ASCII 1195 Compatible Encoding (ACE) format for performing comparisons, as 1196 specified in Section 7 of [X509]. 1197 o Implementations MAY support matching a locally configured IP 1198 address against an iPAddress stored in the subjectAltName 1199 extension. In this case, the locally configured IP address is 1200 converted to an octet string as specified in [X509], Section 1201 4.2.1.6. A match occurs if this octet string is equal to the 1202 value of iPAddress in the subjectAltName extension. 1204 ###### 1206 A.9. SIP (2010) 1208 At the time of this writing, [SIP-CERTS] specified text regarding 1209 server identity verification in the Session Initiation Protocol 1210 (SIP). However, that specification has not yet been approved by the 1211 IESG and text cannot be considered final. 1213 The relevant text follows. 1215 ###### 1217 7.2. Comparing SIP Identities 1219 When an implementation (either client or server) compares two values 1220 as SIP domain identities: 1221 Implementations MUST compare only the DNS name component of each 1222 SIP domain identifier; an implementation MUST NOT use any scheme 1223 or parameters in the comparison. 1224 Implementations MUST compare the values as DNS names, which means 1225 that the comparison is case insensitive as specified by 1226 [DNS-CASE]. Implementations MUST handle Internationalized Domain 1227 Names (IDNs) in accordance with Section 7.2 of [X509]. 1228 Implementations MUST match the values in their entirety: 1229 Implementations MUST NOT match suffixes. For example, 1230 "foo.example.com" does not match "example.com". 1232 Implemenations MUST NOT match any form of wildcard, such as a 1233 leading "." or "*." with any other DNS label or sequence of 1234 labels. For example, "*.example.com" matches only 1235 "*.example.com" but not "foo.example.com". Similarly, 1236 ".example.com" matches only ".example.com", and does not match 1237 "foo.example.com." 1238 [HTTP-TLS] allows the dNSName component to contain a 1239 wildcard; e.g., "DNS:*.example.com". [X509], while not 1240 disallowing this explicitly, leaves the interpretation of 1241 wildcards to the individual specification. [SIP] does not 1242 provide any guidelines on the presence of wildcards in 1243 certificates. Through the rule above, this document 1244 prohibits such wildcards in certificates for SIP domains. 1246 ###### 1248 Authors' Addresses 1250 Peter Saint-Andre (editor) 1251 Cisco 1253 Email: psaintan@cisco.com 1255 Jeff Hodges (editor) 1256 PayPal 1258 Email: Jeff.Hodges@PayPal.com