idnits 2.17.1 draft-friedl-uta-smtp-mta-certs-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6125]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6698' is defined on line 395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Using TLS in Applications S. Friedl 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track T. Kaupe 5 Expires: September 14, 2014 Microsoft Corp. 6 S. Gorti 7 Cisco Systems, Inc. 8 March 13, 2014 10 TLS Certificate Identity Verification Procedure for SMTP MTA to MTA 11 Connections 12 draft-friedl-uta-smtp-mta-certs-00 14 Abstract 16 This document describes TLS server identity verification procedure 17 for Message Transfer Agent (MTA) to Message Transfer Agent 18 connections in an SMTP email network, with specific guidance on 19 identity verification steps associated with delegated email services. 20 This document is intended to supplement the identify verification 21 procedures described in [RFC6125]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Procedure for TLS Server Identity Verification for MTA to 61 Email Server Connections . . . . . . . . . . . . . . . . . . 4 62 4.1. Server Identification and Validation . . . . . . . . . . 4 63 4.1.1. Reference Identity . . . . . . . . . . . . . . . . . 4 64 4.1.2. Presented Identity . . . . . . . . . . . . . . . . . 5 65 4.1.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1.4. Server Identity Validation . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The TLS security protocol [RFC5246] is typically used to encapsulate 75 application protocols to provide privacy, data integrity and server 76 identity verification between two application servers which would 77 otherwise be conducting their communication in plain text over 78 potentially insecure network links. There are two layers: 80 o The TLS Record protocol provides for private communication and 81 message integrity using negotiated encryption and hashing 82 algorithms. 84 o The TLS Handshake protocol provides for secure and reliable 85 sharing of secrets used for encryption, together with 86 identification and authentication of one or both peers. 88 There are various RFCs, such as [RFC6125] which describe TLS in the 89 context of more general domain based applications, with the canonical 90 example being a user-agent (e.g. browser) securely accessing content 91 on a server (e.g. web server) [RFC2818]. RFCs also describe TLS in 92 the more specific context of SMTP, however these RFCs focus on a 93 user-agent (e.g. mobile or PC mail client) submitting email to a mail 94 server using the STARTTLS SMTP extension[RFC2595] [RFC3207]. No RFCs 95 explicitly describe TLS in the context of SMTP communication between 96 two MTAs in an email network. There exist sufficient differences in 97 the MTA-to-MTA scenario, particularly with respect to server 98 identification, which warrant an explicit set of recommendations. 99 This document discusses various strategies that a sending MTA can use 100 for the identification and authentication of a destination MTA when 101 transferring a message within an email network. It should be noted 102 that an email network could be defined with MTA to Message Delivery 103 Agent (MDA) connections, in which case the same verification and 104 authentication rules should apply to the MTA to MDA scenario. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Terminology 114 o Email Domain: @example.net, found in the [RFC5321] domain section 115 of the RCPT TO command forward path 117 o Email Server Hostname: mail.example.net 119 o Email Server IP Address: the IP address (or addresses) for the 120 email server. 122 o MX Record: A type of DNS record that associates an email domain to 123 one or more email server hostnames. @example.net --> 124 mail1.example.net, mail2.example.net. 126 o MTA (Message Transfer Agent). An application that sends messages 127 on behalf of one or more users to a destination email server over 128 SMTP. The destination email server will also be an MTA or a 129 Message Delivery Agent (MDA) though this document will discuss MTA 130 to MTA connections as the difference between MTA to MTA and MTA to 131 MDA connections is immaterial with regard to TLS verification and 132 authentication. 134 o Self-Hosting: The owner of the email domain also owns and manages 135 the email server. In this case, it's common for the email server 136 host name to be rooted to the email domain (e.g. @example.net --> 137 mail.example.net), but it's not required. Many organizations have 138 multiple email domains (e.g. @example.net, @sales.example.net, 139 @ejemplo.es) all self-hosted on a shared email server (e.g. 140 mail.example.net). 142 o Delegated Hosting: The owner of the email domain does not own or 143 manage the email server. Typically, a third-party owns and 144 manages an email server for a multiplicity of Email Domain owners. 146 Delegation is achieved through the MX record (e.g. @example.net 147 --> mail.delegatedexample.net). 149 o Reference Identity: An instance of a reference identifier, 150 constructed from a source domain and optionally a service type, 151 used by the client for matching purposes when examining presented 152 identifiers [RFC6125]. 154 o Presented Identity: An instance of a presented identifier that is 155 presented by a server to a client within a PKIX certificate when 156 the client attempts to establish secure communication with the 157 server; the certificate can include one or more presented 158 identifiers of different types, and if the server hosts more than 159 one domain then the certificate might present distinct identifiers 160 for each domain [RFC6125]. 162 4. Procedure for TLS Server Identity Verification for MTA to Email 163 Server Connections 165 4.1. Server Identification and Validation 167 Two fundamental aspects govern how an MTA validates the identity of 168 an email server when establishing a TLS session: 170 o How the reference identity of the server is determined 172 o How the presented identity of the server is validated against the 173 reference identity 175 The destination MTA identity is verified through a process of ordered 176 comparison of reference and presented identity pairs in conformance 177 to the rules defined in [RFC6125]. 179 4.1.1. Reference Identity 181 In the case of an MTA, the reference identity of the destination 182 email server is typically expressed via the MX record for the 183 recipient email domain. A user addresses email to a recipient at a 184 specific email domain (e.g. recipient@example.net) and the MTA then 185 performs a DNS MX query using the [RFC5321] domain section of the 186 RCPT TO command forward path to determine the email server hostname 187 (e.g. mail.example.net) for the recipient email domain. It is 188 important to note that the email server name will not necessarily be 189 a subdomain of the recipient email domain; this will never be the 190 case with delegated email hosting. 192 4.1.2. Presented Identity 194 The server presented identity SHOULD be a SubjectAltName (SAN) of 195 type DNSName of a X.509 public key certificate. In keeping with 196 [RFC6125], SAN entries SHOULD be used for the presented identity, but 197 the CN entry of a X.509 public key certificate MAY be used for 198 backwards compatibility with deployed infrastructure if no SAN 199 entries exist in the certificate. 201 4.1.3. Wildcards 203 [RFC6125] recommends deprecating support for SAN entries that include 204 wildcards for two primary reasons: (1) the lack of clarity in 205 existing specification as to the allowable locations of wildcard 206 characters and (2) the fact that a wildcard SAN entries vouches for 207 all servers in a domain, including possibly rogue or buggy servers. 208 In the case of MTA to delegated email service connections, this 209 document proposes continued support for DNSNames containing wildcards 210 as wildcard DNSNames are needed to support some delegated email 211 hosting scenarios. 213 For delegated hosting, some third parties may use the same email 214 server hostname(s) for all the domains that they host: 216 @example1.net --> mail.delegatedexample.net 218 @example2.net --> mail.delegatedexample.net 220 Alternatively, a third party email service might use a unique 221 hostname for each email domain: 223 @example1.net --> example1net.mail.delegatedexample.net 225 @example2.net --> example2net.mail.delegatedexample.net 227 If unique hostnames are associated with each email domain, then there 228 will be as many host names as email domains and it will not be 229 possible to include all hostnames as SAN DNSName entries in a 230 certificate. Wildcarded SAN entries would then be the only mechanism 231 by which a single certificate may be used for all email server 232 hostname reference identities. If all the email server hostnames are 233 of the form [domainidentifier].[hostnameroot] (e.g. 234 example1net.mail.delegatedexample.net), then the SAN SHOULD include a 235 DNSName entry of the form *.[hostnameroot] (e.g. 236 *.mail.delegatedexample.net). The email server certificate SHOULD 237 NOT include a wildcard character in the presented identity in any 238 position other than the left-most label. 240 4.1.4. Server Identity Validation 242 Validation of the server identity entails a comparison of the 243 reference identity to the identity presented in the server 244 certificate. There are several approaches for validation, given the 245 various reference identifiers that may be used and the fundamental 246 difference between the self-hosted and delegated hosting models. 248 4.1.4.1. Determination of Reference Identity 250 The reference identity for an email server SHOULD be determined using 251 the following methods: 253 1. The [RFC5321] domain section of the RCPT TO command forward 254 path 256 2. The email server hostname explicitly configured in the MTA by 257 an administrator. 259 3. The email server hostname derived via a DNS/MX query against 260 the email domain name determined as the [RFC5321] domain section 261 of the RCPT TO command forward path. 263 4.1.4.2. Exact Match Between SAN and Reference Identity 265 An MTA SHOULD validate an email server identity when an exact match 266 exists between the presented identity as a SAN DNSName entry in the 267 email server's certificate and the email server's reference identity. 269 4.1.4.3. Wildcard Match Between SAN and Reference Identity 271 An MTA SHOULD validate an email server identity when a [RFC6125] 272 Section 6.4.3 compliant wildcard match exists between the presented 273 identity as a SAN DNSName entry with wildcards in the email server's 274 certificate and the email server's reference identity. 276 4.1.4.4. Exact Match Between CN and Reference Identity 278 For backward compatibility, if no SAN DNSName entries exist in an 279 email server's certificate but a CN entry exists then an MTA SHOULD 280 validate an email server identity if an exact match exists between 281 the CN and the email server's reference identity. 283 4.1.4.5. Wildcard Match Between CN and Reference Identity 285 For backward compatibility, if no SAN DNSName entries exist in an 286 email server's certificate but a CN entry exists then an MTA SHOULD 287 validate an email server identity when a [RFC6125] Section 6.4.3 288 compliant wildcard match exists between the presented identity as a 289 CN entry with wildcards in the email server's certificate and the 290 email server's reference identity. 292 4.1.4.6. Matching Process 294 The order of evaluation of the different methods for an MTA to 295 validate and email server identity are important and an MTA SHOULD 296 use the following ordering of matching tests: 298 4.1.4.6.1. SAN Present 300 If one or more SAN DNSName entries are present in the email server's 301 certificate the following matching tests SHOULD be used in the order 302 specified: 304 1. Exact match of SAN entry to [RFC5321] domain section of the 305 RCPT TO command forward path 307 2. Wildcard match of SAN entry to [RFC5321] domain section of the 308 RCPT TO command forward path 310 3. Exact match of SAN entry to email server hostname explicitly 311 configured in the MTA by an administrator. 313 4. Wildcard match of SAN entry to email server hostname 314 explicitly configured in the MTA by an administrator. 316 5. Exact match of SAN entry email server hostname derived via a 317 DNS/MX query against the [RFC5321] domain section of the RCPT TO 318 command forward path. 320 6. Wildcard match of SAN entry email server hostname derived via 321 a DNS/MX query against the [RFC5321] domain section of the RCPT TO 322 command forward path. 324 If one or more SAN DNSName entries are present in the email server's 325 certificate and none of the matching tests specified above pass, then 326 the MTA will have failed to validate the email server's identity. and 327 the MTA SHOULD log an error indicating that the validation process 328 failed. 330 4.1.4.6.2. No SAN Entries Present but a CN Entry is Present 332 An MTA MUST NOT validate an email server identity against the CN 333 entry of an email server's certificate if there exist one or more SAN 334 DNSName entries in the certificate. If and only if no SAN DNSName 335 entries exist in the email server certificate and a CN is present in 336 the email server's certificate the same matching process detailed in 337 4.1.4.6.1 above MUST be used with the CN as the presented identity 338 instead of the SAN. 340 5. Security Considerations 342 This document addresses only the procedure by which an MTA should 343 verify the identity of an email server with which it wishes to 344 establish a TLS connection. The procedures described in this 345 document do nothing to address or ameliorate the fundamental security 346 risk associated with obtaining an email server name through an 347 insecure MX query. In the abscence of DNSSEC there exist a large 348 number of techniques whereby a false email server name could be 349 returned to the MTA through an insecure MX query. It should be noted 350 that in the absence of DNSSEC, the MX query is no more risk prone 351 than a browser A lookup. Use of TLS eliminates risks of passive 352 listening and imposes a requirement that an attacker to obtain a 353 certificate that will be trusted by the sending MTA and actively 354 participate in the session by terminating the TLS session requested 355 by the sending MTA. 357 Risks associated with insecure DNS MX lookups may be ameliorated by 358 explicit association of the email server name to an email domain in 359 the MTA configuration. 361 6. IANA Considerations 363 This document includes no request to IANA. 365 7. Acknowledgements 367 Thanks to Dan Wing for multiple reviews of this draft and valuable 368 suggestions for improving it. 370 8. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 376 Verification of Domain-Based Application Service Identity 377 within Internet Public Key Infrastructure Using X.509 378 (PKIX) Certificates in the Context of Transport Layer 379 Security (TLS)", RFC 6125, March 2011. 381 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 382 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 384 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 386 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 387 October 2008. 389 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 390 2595, June 1999. 392 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 393 Transport Layer Security", RFC 3207, February 2002. 395 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 396 of Named Entities (DANE) Transport Layer Security (TLS) 397 Protocol: TLSA", RFC 6698, August 2012. 399 Authors' Addresses 401 Stephan Friedl 402 Cisco Systems, Inc. 403 170 West Tasman Drive 404 San Jose, CA 95134 405 USA 407 Phone: (720)562-6785 408 EMail: sfriedl@cisco.com 410 Tom Kaupe 411 Microsoft Corp. 412 One Microsoft Way 413 Redmond, WA 98052 414 USA 416 EMail: Tom.Kaupe@microsoft.com 418 Sriram Gorti 419 Cisco Systems, Inc. 420 170 West Tasman Drive 421 San Jose, CA 95134 422 USA 424 Phone: +91 80 4365 7100 425 EMail: sgorti@cisco.com