"Fossies" - the Fresh Open Source Software Archive

Member "courier-1.2.2/courier/doc/draft-varshavchik-security-smtpext.txt" (25 Aug 2013, 8297 Bytes) of package /linux/misc/courier-1.2.2.tar.bz2:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file. 
    1 
    2 
    3 
    4 
    5 
    6 
    7 1. Abstract
    8 
    9    This document describes an [ESMTP] extension that enables the sender
   10    to explicitly indicate the transport security level the mail system
   11    must use in delivering the given message.
   12 
   13    The SECURITY extension can also be used to establish secure mail
   14    delivery channels between trusted hosts, connected by an untrusted
   15    public network.
   16 
   17 2. Introduction
   18 
   19    [STARTTLS] defines an SMTP service extension for using TLS/SSL to
   20    send mail between ESMTP mail relays. [STARTTLS] is an optional SMTP
   21    extension, but sometimes the sender might wish to require that
   22    [STARTTLS], or an equivalent, must be used to deliver a particular
   23    message.  Even if two mail nodes - the sending and the receiving
   24    nodes - are set up to use [STARTTLS], there are known methods of
   25    attack - such as [DNS] cache poisoning - which can be used to
   26    intercept mail traffic.
   27 
   28 3. Framework for the SECURITY SMTP transport extension
   29 
   30    This [ESMTP] transport extension is laid out as follows.
   31 
   32       (1) The name of the SMTP transport extension defined here is
   33           Message Security Level.
   34 
   35       (2) The EHLO keyword associated with this extension is SECURITY.
   36 
   37       (3) The SECURITY EHLO keyword takes a comma-delimited list as a
   38           parameter.
   39 
   40       (4) One optional ESMTP keyword SECURITY is associated with the
   41           MAIL FROM command. This parameter takes a comma-delimited list
   42           as a parameter.
   43 
   44       (5) No additional ESMTP verbs are defined by this extension.
   45 
   46       (6) The next section specifies how support for this extension
   47           affects the behavior of a server and client SMTP.
   48 
   49 4. The SECURITY SMTP extension
   50 
   51    The EHLO keyword SECURITY takes a comma-separated list of words as an
   52    argument.  This document defines two words that may appear in the
   53    EHLO SECURITY list:
   54 
   55 
   56 
   57 
   58 S. Varshavchik            Expires XXX XX, XXXX                  [Page 1]
   59 
   60 SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
   61 
   62 
   63           NONE      - No security.
   64 
   65           STARTTLS  - Must use STARTTLS to deliver the message.
   66 
   67 
   68    The optional SECURITY ESMTP keyword to the MAIL FROM command MUST use
   69    one of these words as a parameter (if the SECURITY keyword is
   70    provided at all).  This is used to select the requested security
   71    level in transmitting this message
   72 
   73    SECURITY=NONE essentially requests no security whatsoever, for this
   74    message.  It is equivalent to complete absence of an explicit
   75    SECURITY setting.
   76 
   77    SECURITY=STARTTLS specifies that the mail relay MUST use [STARTTLS]
   78    with a remote mail node.  The mail relay ignores this option if it
   79    delivers the message to a local mailbox.  The sending mail relay MUST
   80    also verify the X.509 certificate received from the remote mail relay
   81    during TLS negotiation.  The remote relay’s X.509 certificate MUST be
   82    signed by a certificate authority that is known and trusted by the
   83    sending relay.  If the remote relay does not support [STARTTLS], or
   84    is unable to provide a satisfactory X.509 certificate, the message
   85    MUST be returned as undeliverable.
   86 
   87    Note that [STARTTLS] allows the mail node to initially advertise
   88    STARTTLS as its only [ESMTP] extension, until TLS is established.
   89    Therefore, TLS MUST be established first, before checking for the
   90    SECURITY [ESMTP] extension.
   91 
   92    Note that after TLS is established, the EHLO no longer shows
   93    STARTTLS, since TLS is already being used, and EHLO will now list the
   94    SECURITY keyword without a STARTTLS keyword.  SECURITY may also
   95    appear without STARTTLS even if TLS has not been established.  This
   96    situation may happen with a connection over an internal, secure
   97    network, to a mail firewall, essentially instructing the mail
   98    firewall to use SECURITY to deliver the message over an external
   99    network, even though TLS is not necessary to forward the mail from
  100    the sender over the secure, internal, network.
  101 
  102    A mail relay MAY automatically "upgrade" the SECURITY level of a
  103    message based on the mail relay’s administrative policies.  A node
  104    MUST NOT automatically downgrade the SECURITY level.  For the purpose
  105    of determining the security level SECURITY=STARTTLS is considered to
  106    be more secure than SECURITY=NONE.  This allows the implementation of
  107    a secure mail delivery framework between trusted nodes, over an
  108    untrusted network, without any modification to existing mail user
  109    agents.
  110 
  111 
  112 
  113 
  114 S. Varshavchik            Expires XXX XX, XXXX                  [Page 2]
  115 
  116 SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
  117 
  118 
  119 5. Example
  120 
  121        220 example.com ESMTP
  122        EHLO domain.com
  123        250-example.com ESMTP
  124        250 STARTTLS
  125        STARTTLS
  126        220 Go ahead.
  127        (TLS negotiation takes place)
  128        EHLO domain.com
  129        250-example.com ESMTP
  130        250-SECURITY=NONE,STARTTLS
  131        250-SIZE
  132        250-DSN
  133        250 HELP
  134        MAIL FROM:<itny-out@domain.com> SIZE=1250 SECURITY=STARTTLS
  135        250 Ok
  136        (Normal SMTP dialogue continues...)
  137 
  138 6. Delivery Status Notifications
  139 
  140    [DSN] messages generated for a message with any SECURITY keyword MUST
  141    also use the same SECURITY keyword for the DSN.  This is because DSNs
  142    may include portions of the original message.  The presumption is
  143    that if a secure path existed between the sender, and the DSN-
  144    generating node, a return secure path also exists.
  145 
  146 7. Security concerns
  147 
  148    Note that it is not necessary for a mail client to negotiate TLS/SSL
  149    in order to submit the message for delivery.  A mail node SHOULD
  150    advertise and enable SECURITY in both plaintext and TLS/SSL-secured
  151    sessions.
  152 
  153    The SECURITY extension allows a fairly straightforward way to set up
  154    a secure mail transmission infrastructure between trusted hosts over
  155    a public, untrusted, network.  This is done by installing X.509
  156    certificates signed by a trusted certificate authority, then using
  157    SECURITY to require [STARTTLS] (or configuring the mail relay’s
  158    configuration to automatically upgrade SECURITY for outgoing
  159    messages).
  160 
  161    The trusted CA must be a private CA that is used only by these nodes.
  162    The secure mail traffic can still be intercepted if a public CA is
  163    used.  This is because other techniques, such as IP address spoofing
  164    or [DNS] cache poisoning, can be used to redirect mail to a node with
  165    a valid certificate signed by a public CA.
  166 
  167 
  168 
  169 
  170 S. Varshavchik            Expires XXX XX, XXXX                  [Page 3]
  171 
  172 SECURITY SMTP Extension      S. Varshavchik                 XXX XX, XXXX
  173 
  174 
  175    Note that a trusted mail node CAN use DNS cache poisoning to
  176    intercept mail addressed to another trusted mail node, since the
  177    attacker will have a certificate signed by the private CA.  It is
  178    important to understand that the SECURITY extension is designed to
  179    defend against attacks from untrusted mail nodes only.
  180 
  181    The SECURITY extension’s scope is limited to delivery of a message to
  182    the recipient’s mailbox.  Once a message is delivered, it is the
  183    recipient’s responsibility to access the message in a secure
  184    environment, such as by using SSL/TLS-wrapped versions of existing
  185    mailbox access protocols.
  186 
  187 8. References
  188 
  189    [ESMTP]    Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker,
  190               D.  "SMTP Service Extensions", RFC 1425, United Nations
  191               University, Innosoft International, Inc., Dover Beach
  192               Consulting, Inc., Network Management Associates, Inc., The
  193               Branch Office, February 1993
  194 
  195    [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
  196               TLS", RFC 2487, Internet Mail Consortium, January 1999
  197 
  198    [DSN]      Moore, K. "SMTP Service Extension for Delivery Status
  199               Notifications", RFC 1891, University of Tennessee, January
  200               1996.
  201 
  202    [DNS]      Mockapetris, P., "Domain Names - Implementation and
  203               Specification", RFC 1035, ISI, November 1987
  204 
  205 9. Author’s address
  206 
  207    Sam Varshavchik
  208    Double Precision, Inc.
  209    402 Main Street Suite 100-241
  210    Metuchen, NJ 08840
  211    <mrsam@courier-mta.com>
  212 
  213 
  214 
  215 
  216 
  217 
  218 
  219 
  220 
  221 
  222 
  223 
  224 
  225 
  226 S. Varshavchik            Expires XXX XX, XXXX                  [Page 4]