INTERNET-DRAFT S. Varshavchik Expires XXX XX, XXXX Double Precision, Inc. XXX XX, XXXX SECURITY SMTP Service Extension draft-varshavchik-security-smtpext.txt Status Of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 0. Revision history 1. Abstract This document describes an [ESMTP] extension that enables the sender to explicitly indicate the transport security level the mail system must use in delivering the given message. The SECURITY extension can also be used to establish secure mail delivery channels between trusted hosts, connected by an untrusted public network. 2. Introduction [STARTTLS] defines an SMTP service extension for using TLS/SSL to send mail between ESMTP mail relays. [STARTTLS] is an optional SMTP extension, but sometimes the sender might wish to require that [STARTTLS], or an equivalent, must be used to deliver a particular message. Even if two mail nodes - the sending and the receiving S. Varshavchik Expires XXX XX, XXXX [Page 1] SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX nodes - are set up to use [STARTTLS], there are known methods of attack - such as [DNS] cache poisoning - which can be used to intercept mail traffic. 3. Framework for the SECURITY SMTP transport extension This [ESMTP] transport extension is laid out as follows. (1) The name of the SMTP transport extension defined here is Message Security Level. (2) The EHLO keyword associated with this extension is SECURITY. (3) The SECURITY EHLO keyword takes a comma-delimited list as a parameter. (4) One optional ESMTP keyword SECURITY is associated with the MAIL FROM command. This parameter takes a comma-delimited list as a parameter. (5) No additional ESMTP verbs are defined by this extension. (6) The next section specifies how support for this extension affects the behavior of a server and client SMTP. 4. The SECURITY SMTP extension The EHLO keyword SECURITY takes a comma-separated list of words as an argument. This document defines two words that may appear in the EHLO SECURITY list: NONE - No security. STARTTLS - Must use STARTTLS to deliver the message. The optional SECURITY ESMTP keyword to the MAIL FROM command MUST use one of these words as a parameter (if the SECURITY keyword is provided at all). This is used to select the requested security level in transmitting this message SECURITY=NONE essentially requests no security whatsoever, for this message. It is equivalent to complete absence of an explicit SECURITY setting. SECURITY=STARTTLS specifies that the mail relay MUST use [STARTTLS] with a remote mail node. The mail relay ignores this option if it delivers the message to a local mailbox. The sending mail relay MUST S. Varshavchik Expires XXX XX, XXXX [Page 2] SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX also verify the X.509 certificate received from the remote mail relay during TLS negotiation. The remote relay's X.509 certificate MUST be signed by a certificate authority that is known and trusted by the sending relay. If the remote relay does not support [STARTTLS], or is unable to provide a satisfactory X.509 certificate, the message MUST be returned as undeliverable. Note that [STARTTLS] allows the mail node to initially advertise STARTTLS as its only [ESMTP] extension, until TLS is established. Therefore, TLS MUST be established first, before checking for the SECURITY [ESMTP] extension. Note that after TLS is established, the EHLO no longer shows STARTTLS, since TLS is already being used, and EHLO will now list the SECURITY keyword without a STARTTLS keyword. SECURITY may also appear without STARTTLS even if TLS has not been established. This situation may happen with a connection over an internal, secure network, to a mail firewall, essentially instructing the mail firewall to use SECURITY to deliver the message over an external network, even though TLS is not necessary to forward the mail from the sender over the secure, internal, network. A mail relay MAY automatically "upgrade" the SECURITY level of a message based on the mail relay's administrative policies. A node MUST NOT automatically downgrade the SECURITY level. For the purpose of determining the security level SECURITY=STARTTLS is considered to be more secure than SECURITY=NONE. This allows the implementation of a secure mail delivery framework between trusted nodes, over an untrusted network, without any modification to existing mail user agents. 5. Example 220 example.com ESMTP EHLO domain.com 250-example.com ESMTP 250 STARTTLS STARTTLS 220 Go ahead. _(_T_L_S _n_e_g_o_t_i_a_t_i_o_n _t_a_k_e_s _p_l_a_c_e_) EHLO domain.com 250-example.com ESMTP 250-SECURITY=NONE,STARTTLS 250-SIZE 250-DSN 250 HELP MAIL FROM: SIZE=1250 SECURITY=STARTTLS 250 Ok S. Varshavchik Expires XXX XX, XXXX [Page 3] SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX _(_N_o_r_m_a_l _S_M_T_P _d_i_a_l_o_g_u_e _c_o_n_t_i_n_u_e_s_._._._) 6. Delivery Status Notifications [DSN] messages generated for a message with any SECURITY keyword MUST also use the same SECURITY keyword for the DSN. This is because DSNs may include portions of the original message. The presumption is that if a secure path existed between the sender, and the DSN- generating node, a return secure path also exists. 7. Security concerns Note that it is not necessary for a mail client to negotiate TLS/SSL in order to submit the message for delivery. A mail node SHOULD advertise and enable SECURITY in both plaintext and TLS/SSL-secured sessions. The SECURITY extension allows a fairly straightforward way to set up a secure mail transmission infrastructure between trusted hosts over a public, untrusted, network. This is done by installing X.509 certificates signed by a trusted certificate authority, then using SECURITY to require [STARTTLS] (or configuring the mail relay's configuration to automatically upgrade SECURITY for outgoing messages). The trusted CA must be a private CA that is used only by these nodes. The secure mail traffic can still be intercepted if a public CA is used. This is because other techniques, such as IP address spoofing or [DNS] cache poisoning, can be used to redirect mail to a node with a valid certificate signed by a public CA. Note that a trusted mail node CAN use DNS cache poisoning to intercept mail addressed to another trusted mail node, since the attacker will have a certificate signed by the private CA. It is important to understand that the SECURITY extension is designed to defend against attacks from untrusted mail nodes only. The SECURITY extension's scope is limited to delivery of a message to the recipient's mailbox. Once a message is delivered, it is the recipient's responsibility to access the message in a secure environment, such as by using SSL/TLS-wrapped versions of existing mailbox access protocols. 8. References [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. "SMTP Service Extensions", RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach S. Varshavchik Expires XXX XX, XXXX [Page 4] SECURITY SMTP Extension S. Varshavchik XXX XX, XXXX Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, Internet Mail Consortium, January 1999 [DSN] Moore, K. "SMTP Service Extension for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996. [DNS] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, ISI, November 1987 9. Author's address Sam Varshavchik Double Precision, Inc. PO Box 668 Greenwood Lake, NY 10925 S. Varshavchik Expires XXX XX, XXXX [Page 5]