Internet DRAFT - draft-friedl-uta-smtp-mta-certs

draft-friedl-uta-smtp-mta-certs







Using TLS in Applications                                      S. Friedl
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                T. Kaupe
Expires: September 14, 2014                              Microsoft Corp.
                                                                S. Gorti
                                                     Cisco Systems, Inc.
                                                          March 13, 2014


  TLS Certificate Identity Verification Procedure for SMTP MTA to MTA
                              Connections
                   draft-friedl-uta-smtp-mta-certs-00

Abstract

   This document describes TLS server identity verification procedure
   for Message Transfer Agent (MTA) to Message Transfer Agent
   connections in an SMTP email network, with specific guidance on
   identity verification steps associated with delegated email services.
   This document is intended to supplement the identify verification
   procedures described in [RFC6125].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Friedl, et al.         Expires September 14, 2014               [Page 1]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Procedure for TLS Server Identity Verification for MTA to
       Email Server Connections  . . . . . . . . . . . . . . . . . .   4
     4.1.  Server Identification and Validation  . . . . . . . . . .   4
       4.1.1.  Reference Identity  . . . . . . . . . . . . . . . . .   4
       4.1.2.  Presented Identity  . . . . . . . . . . . . . . . . .   5
       4.1.3.  Wildcards . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.4.  Server Identity Validation  . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The TLS security protocol [RFC5246] is typically used to encapsulate
   application protocols to provide privacy, data integrity and server
   identity verification between two application servers which would
   otherwise be conducting their communication in plain text over
   potentially insecure network links.  There are two layers:

   o  The TLS Record protocol provides for private communication and
      message integrity using negotiated encryption and hashing
      algorithms.

   o  The TLS Handshake protocol provides for secure and reliable
      sharing of secrets used for encryption, together with
      identification and authentication of one or both peers.

   There are various RFCs, such as [RFC6125] which describe TLS in the
   context of more general domain based applications, with the canonical
   example being a user-agent (e.g. browser) securely accessing content
   on a server (e.g. web server) [RFC2818].  RFCs also describe TLS in
   the more specific context of SMTP, however these RFCs focus on a
   user-agent (e.g. mobile or PC mail client) submitting email to a mail
   server using the STARTTLS SMTP extension[RFC2595] [RFC3207].  No RFCs
   explicitly describe TLS in the context of SMTP communication between
   two MTAs in an email network.  There exist sufficient differences in



Friedl, et al.         Expires September 14, 2014               [Page 2]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


   the MTA-to-MTA scenario, particularly with respect to server
   identification, which warrant an explicit set of recommendations.
   This document discusses various strategies that a sending MTA can use
   for the identification and authentication of a destination MTA when
   transferring a message within an email network.  It should be noted
   that an email network could be defined with MTA to Message Delivery
   Agent (MDA) connections, in which case the same verification and
   authentication rules should apply to the MTA to MDA scenario.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   o  Email Domain: @example.net, found in the [RFC5321] domain section
      of the RCPT TO command forward path

   o  Email Server Hostname: mail.example.net

   o  Email Server IP Address: the IP address (or addresses) for the
      email server.

   o  MX Record: A type of DNS record that associates an email domain to
      one or more email server hostnames.  @example.net -->
      mail1.example.net, mail2.example.net.

   o  MTA (Message Transfer Agent).  An application that sends messages
      on behalf of one or more users to a destination email server over
      SMTP.  The destination email server will also be an MTA or a
      Message Delivery Agent (MDA) though this document will discuss MTA
      to MTA connections as the difference between MTA to MTA and MTA to
      MDA connections is immaterial with regard to TLS verification and
      authentication.

   o  Self-Hosting: The owner of the email domain also owns and manages
      the email server.  In this case, it's common for the email server
      host name to be rooted to the email domain (e.g. @example.net -->
      mail.example.net), but it's not required.  Many organizations have
      multiple email domains (e.g. @example.net, @sales.example.net,
      @ejemplo.es) all self-hosted on a shared email server (e.g.
      mail.example.net).

   o  Delegated Hosting: The owner of the email domain does not own or
      manage the email server.  Typically, a third-party owns and
      manages an email server for a multiplicity of Email Domain owners.



Friedl, et al.         Expires September 14, 2014               [Page 3]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


      Delegation is achieved through the MX record (e.g. @example.net
      --> mail.delegatedexample.net).

   o  Reference Identity: An instance of a reference identifier,
      constructed from a source domain and optionally a service type,
      used by the client for matching purposes when examining presented
      identifiers [RFC6125].

   o  Presented Identity: An instance of a presented identifier that is
      presented by a server to a client within a PKIX certificate when
      the client attempts to establish secure communication with the
      server; the certificate can include one or more presented
      identifiers of different types, and if the server hosts more than
      one domain then the certificate might present distinct identifiers
      for each domain [RFC6125].

4.  Procedure for TLS Server Identity Verification for MTA to Email
    Server Connections

4.1.  Server Identification and Validation

   Two fundamental aspects govern how an MTA validates the identity of
   an email server when establishing a TLS session:

   o  How the reference identity of the server is determined

   o  How the presented identity of the server is validated against the
      reference identity

   The destination MTA identity is verified through a process of ordered
   comparison of reference and presented identity pairs in conformance
   to the rules defined in [RFC6125].

4.1.1.  Reference Identity

   In the case of an MTA, the reference identity of the destination
   email server is typically expressed via the MX record for the
   recipient email domain.  A user addresses email to a recipient at a
   specific email domain (e.g. recipient@example.net) and the MTA then
   performs a DNS MX query using the [RFC5321] domain section of the
   RCPT TO command forward path to determine the email server hostname
   (e.g. mail.example.net) for the recipient email domain.  It is
   important to note that the email server name will not necessarily be
   a subdomain of the recipient email domain; this will never be the
   case with delegated email hosting.






Friedl, et al.         Expires September 14, 2014               [Page 4]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


4.1.2.  Presented Identity

   The server presented identity SHOULD be a SubjectAltName (SAN) of
   type DNSName of a X.509 public key certificate.  In keeping with
   [RFC6125], SAN entries SHOULD be used for the presented identity, but
   the CN entry of a X.509 public key certificate MAY be used for
   backwards compatibility with deployed infrastructure if no SAN
   entries exist in the certificate.

4.1.3.  Wildcards

   [RFC6125] recommends deprecating support for SAN entries that include
   wildcards for two primary reasons: (1) the lack of clarity in
   existing specification as to the allowable locations of wildcard
   characters and (2) the fact that a wildcard SAN entries vouches for
   all servers in a domain, including possibly rogue or buggy servers.
   In the case of MTA to delegated email service connections, this
   document proposes continued support for DNSNames containing wildcards
   as wildcard DNSNames are needed to support some delegated email
   hosting scenarios.

   For delegated hosting, some third parties may use the same email
   server hostname(s) for all the domains that they host:

      @example1.net --> mail.delegatedexample.net

      @example2.net --> mail.delegatedexample.net

   Alternatively, a third party email service might use a unique
   hostname for each email domain:

      @example1.net --> example1net.mail.delegatedexample.net

      @example2.net --> example2net.mail.delegatedexample.net

   If unique hostnames are associated with each email domain, then there
   will be as many host names as email domains and it will not be
   possible to include all hostnames as SAN DNSName entries in a
   certificate.  Wildcarded SAN entries would then be the only mechanism
   by which a single certificate may be used for all email server
   hostname reference identities.  If all the email server hostnames are
   of the form [domainidentifier].[hostnameroot] (e.g.
   example1net.mail.delegatedexample.net), then the SAN SHOULD include a
   DNSName entry of the form *.[hostnameroot] (e.g.
   *.mail.delegatedexample.net).  The email server certificate SHOULD
   NOT include a wildcard character in the presented identity in any
   position other than the left-most label.




Friedl, et al.         Expires September 14, 2014               [Page 5]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


4.1.4.  Server Identity Validation

   Validation of the server identity entails a comparison of the
   reference identity to the identity presented in the server
   certificate.  There are several approaches for validation, given the
   various reference identifiers that may be used and the fundamental
   difference between the self-hosted and delegated hosting models.

4.1.4.1.  Determination of Reference Identity

   The reference identity for an email server SHOULD be determined using
   the following methods:

      1.  The [RFC5321] domain section of the RCPT TO command forward
      path

      2.  The email server hostname explicitly configured in the MTA by
      an administrator.

      3.  The email server hostname derived via a DNS/MX query against
      the email domain name determined as the [RFC5321] domain section
      of the RCPT TO command forward path.

4.1.4.2.  Exact Match Between SAN and Reference Identity

   An MTA SHOULD validate an email server identity when an exact match
   exists between the presented identity as a SAN DNSName entry in the
   email server's certificate and the email server's reference identity.

4.1.4.3.  Wildcard Match Between SAN and Reference Identity

   An MTA SHOULD validate an email server identity when a [RFC6125]
   Section 6.4.3 compliant wildcard match exists between the presented
   identity as a SAN DNSName entry with wildcards in the email server's
   certificate and the email server's reference identity.

4.1.4.4.  Exact Match Between CN and Reference Identity

   For backward compatibility, if no SAN DNSName entries exist in an
   email server's certificate but a CN entry exists then an MTA SHOULD
   validate an email server identity if an exact match exists between
   the CN and the email server's reference identity.

4.1.4.5.  Wildcard Match Between CN and Reference Identity

   For backward compatibility, if no SAN DNSName entries exist in an
   email server's certificate but a CN entry exists then an MTA SHOULD
   validate an email server identity when a [RFC6125] Section 6.4.3



Friedl, et al.         Expires September 14, 2014               [Page 6]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


   compliant wildcard match exists between the presented identity as a
   CN entry with wildcards in the email server's certificate and the
   email server's reference identity.

4.1.4.6.  Matching Process

   The order of evaluation of the different methods for an MTA to
   validate and email server identity are important and an MTA SHOULD
   use the following ordering of matching tests:

4.1.4.6.1.  SAN Present

   If one or more SAN DNSName entries are present in the email server's
   certificate the following matching tests SHOULD be used in the order
   specified:

      1.  Exact match of SAN entry to [RFC5321] domain section of the
      RCPT TO command forward path

      2.  Wildcard match of SAN entry to [RFC5321] domain section of the
      RCPT TO command forward path

      3.  Exact match of SAN entry to email server hostname explicitly
      configured in the MTA by an administrator.

      4.  Wildcard match of SAN entry to email server hostname
      explicitly configured in the MTA by an administrator.

      5.  Exact match of SAN entry email server hostname derived via a
      DNS/MX query against the [RFC5321] domain section of the RCPT TO
      command forward path.

      6.  Wildcard match of SAN entry email server hostname derived via
      a DNS/MX query against the [RFC5321] domain section of the RCPT TO
      command forward path.

   If one or more SAN DNSName entries are present in the email server's
   certificate and none of the matching tests specified above pass, then
   the MTA will have failed to validate the email server's identity. and
   the MTA SHOULD log an error indicating that the validation process
   failed.

4.1.4.6.2.  No SAN Entries Present but a CN Entry is Present

   An MTA MUST NOT validate an email server identity against the CN
   entry of an email server's certificate if there exist one or more SAN
   DNSName entries in the certificate.  If and only if no SAN DNSName
   entries exist in the email server certificate and a CN is present in



Friedl, et al.         Expires September 14, 2014               [Page 7]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


   the email server's certificate the same matching process detailed in
   4.1.4.6.1 above MUST be used with the CN as the presented identity
   instead of the SAN.

5.  Security Considerations

   This document addresses only the procedure by which an MTA should
   verify the identity of an email server with which it wishes to
   establish a TLS connection.  The procedures described in this
   document do nothing to address or ameliorate the fundamental security
   risk associated with obtaining an email server name through an
   insecure MX query.  In the abscence of DNSSEC there exist a large
   number of techniques whereby a false email server name could be
   returned to the MTA through an insecure MX query.  It should be noted
   that in the absence of DNSSEC, the MX query is no more risk prone
   than a browser A lookup.  Use of TLS eliminates risks of passive
   listening and imposes a requirement that an attacker to obtain a
   certificate that will be trusted by the sending MTA and actively
   participate in the session by terminating the TLS session requested
   by the sending MTA.

   Risks associated with insecure DNS MX lookups may be ameliorated by
   explicit association of the email server name to an email domain in
   the MTA configuration.

6.  IANA Considerations

   This document includes no request to IANA.

7.  Acknowledgements

   Thanks to Dan Wing for multiple reviews of this draft and valuable
   suggestions for improving it.

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.




Friedl, et al.         Expires September 14, 2014               [Page 8]

Internet-Draft     SMTP MTA TLS  Identity Verification        March 2014


   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
              2595, June 1999.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

Authors' Addresses

   Stephan Friedl
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: (720)562-6785
   EMail: sfriedl@cisco.com


   Tom Kaupe
   Microsoft Corp.
   One Microsoft Way
   Redmond, WA  98052
   USA

   EMail: Tom.Kaupe@microsoft.com


   Sriram Gorti
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +91 80 4365 7100
   EMail: sgorti@cisco.com







Friedl, et al.         Expires September 14, 2014               [Page 9]