[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

MARID                                                            D. Otis
Internet-Draft                              Mail Abuse Prevention System
Expires: December 17, 2004                                    D. Crocker
                                             Brandenburg InternetWorking
                                                               J. Leslie
                                                                 JLC.net
                                                           June 18, 2004


                    Client SMTP Authorization (CSA)
                      draft-ietf-marid-csv-csa-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on December 17, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   Internet operation has typically required no public mechanism for
   announcing restriction or permission of particular hosts to operate
   clients or servers for particular services on behalf of particular
   domains.  What is missing is an open, interoperable means by which a
   trusted agency can announce authorization for a host to operate a
   service.  The current specification supports this capability for



Otis, et al.           Expires December 17, 2004                [Page 1]


Internet-Draft                  Mail-CSA                       June 2004


   sending SMTP clients.  Specifically, is a sending SMTP client
   permitted to act as a client MTA? Has a separate authority given it
   permission to perform this service? Client SMTP Authorization (CSA)
   specifies a DNS-based record that states whether an associated host
   has permission to operate as a client MTA.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Model  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.   Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.   Client SMTP Authorization SRV Record . . . . . . . . . . . .   5
   6.   Domain administrator advice  . . . . . . . . . . . . . . . .   7
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .   8
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   9
   9.   Working Group Evaluation . . . . . . . . . . . . . . . . . .   9
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10.1   References - Normative . . . . . . . . . . . . . . . . . .   9
   10.2   References - Informative . . . . . . . . . . . . . . . . .  10
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  11
        Intellectual Property and Copyright Statements . . . . . . .  12





























Otis, et al.           Expires December 17, 2004                [Page 2]


Internet-Draft                  Mail-CSA                       June 2004


1.  Introduction

   Internet mail suffers from the operation of hosts acting as mail
   transfer agents (MTA) without any meaningful cross-net
   accountability.  This makes it impossible to vet MTAs or find
   recourse when their operations cause problems.  Many of these hosts
   have been compromised and turned into unwilling participants in large
   networks of hostile MTAs that send spam and worms, and contribute to
   denial of service attacks.  Enhancing the Internet mail transfer
   service to deal with these issues requires identification,
   authentication, authorization and accreditation capabilities about
   the sending SMTP client, as per [ID-Marid-CSV].  The current
   specification addresses the requirement for explicit authorization.

   It is important to distinguish this security function from
   authentication.  Authentication establishes that a name is being used
   legitimately.  Authorization establishes that the name is permitted
   to perform a particular service.  The relationship between these two
   functions is that once a client of an exchange is authenticated, then
   it is possible to query the permission of that client to perform
   specific services.

   This specification defines a mechanism to permit session-time
   verification that a connecting SMTP client is authorized to request
   service as a mail transfer client.  The mechanism uses a DNS SRV
   [RFC2782] record as a basis for verifying that the associated domain
   name is authorized to act as an SMTP client.  The mechanism is small,
   simple and useful.  Separate mechanisms provide the means of
   authenticating that the domain name is associated with the connecting
   host, and accrediting the agency that is authorizing the sending
   host's operation as an SMTP client.

   Use of the mechanism specified here MAY also satisfy the
   authentication requirement.  This can occur as a side-effect of the
   DNS server response optimization that returns IP Address mappings in
   the Additional Information portion of a response.

   Terminology: Terminology conforms to [ID-email-arch].


2.  Definitions

   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].






Otis, et al.           Expires December 17, 2004                [Page 3]


Internet-Draft                  Mail-CSA                       June 2004


3.  Model

   The SMTP [RFC2821], [RFC0821] protocol permits a client to declare
   its affiliation, by asserting a domain name in the HELO or EHLO
   announcement.

   The current proposal has a receiving SMTP server take the domain name
   associated with an SMTP client and do a forward query of the DNS.
   The returned DNS information indicates whether that domain name is
   authorized by the domain administrator to be an SMTP client.

   For efficiency, the DNS response MAY also return authentication
   information, as per [ID-Marid-CSVHNA].  However the authentication
   functionality is outside the scope of this specification.]

4.  Mechanism

   The receiving SMTP server's authorization procedure is:

   1.  Obtain a domain name that is associated with the sending SMTP
       client.

   2.  Perform a DNS lookup of:
       QNAME = _client._smtp.<name>
       QCLASS = IN
       QTYPE = SRV
       where <name> is associated with the host attempting to obtain
       service as an SMTP client.

   3.  If there is no SRV RR matching this QNAME, the CSA information is
       Unknown; otherwise at least one CSA record exists.

   4.  If there is a matching QNAME:

          Target IP addresses MAY be returned in the Additional Data
          section, or a query for address records of the target name may
          be needed to determine the associated address(es).  This MAY
          be used to satisfy the authentication function specified in
          Host Name Authentication [ID-Marid-CSVHNA].

          Examine Priority, Weight, and Port, to assess whether the
          client address is authorized as an SMTP client.

   The results of this mechanism will provide the following
   authorization levels about sending SMTP clients:






Otis, et al.           Expires December 17, 2004                [Page 4]


Internet-Draft                  Mail-CSA                       June 2004


   +----------------------+----------------------+---------------------+
   | CLIENT AUTHORIZATION |        WEIGHT        | SERVER ACTION       |
   +----------------------+----------------------+---------------------+
   | Not Authorized       |           1          | Generate session    |
   |                      |                      | error with "550     |
   |                      |                      | Address not         |
   |                      |                      | authorized"         |
   | Authorized           |           2          | Continue with CSV   |
   |                      |                      | processing          |
   | Authorized but no IP |           3          | Continue according  |
   | addresses            |                      | to local policy; if |
   |                      |                      | session error is    |
   |                      |                      | generated, use "550 |
   |                      |                      | Address validation  |
   |                      |                      | not available"      |
   | Unknown              |   (no RR returned)   | Continue according  |
   |                      |                      | to local policy, as |
   |                      |                      | if CSV had not been |
   |                      |                      | invoked; if session |
   |                      |                      | error is generated, |
   |                      |                      | use "550 Client     |
   |                      |                      | unknown"            |
   +----------------------+----------------------+---------------------+


5.  Client SMTP Authorization SRV Record

   The SRV CSA Record has the following contents:

   _Service._Proto.Name : TTL : Class : SRV : Priority : Weight : Port :
   Target

   Service
      _client

   Protocol
      _smtp

   Name
      Domain name asserted in SMTP EHLO announcements.

      (These first three fields become the QNAME _client._smtp.Name.)

   TTL
      Standard DNS meaning [RFC1035].






Otis, et al.           Expires December 17, 2004                [Page 5]


Internet-Draft                  Mail-CSA                       June 2004


   Class
      Standard DNS meaning [RFC1035].  SRV-CSA records are only defined
      for the IN Class.

   Priority
      The intended use of [RFC2782] SRV records was to aid discovery and
      selection of servers by prospective clients.  Implementing this
      client authentication mechanism for the server, the Priority,
      Weight, and Port fields are no longer used for either discovery or
      selection.  Thus only one SRV-CSA record is needed and these three
      fields are assigned different meanings.  Priority defines the
      revision level of this mechanism starting at 1.

   Weight
      Weight is a group of bit-fields, as follows:

   +----------------------+----------------------+---------------------+
   | Bit Number           |       Bit Value      | Meaning             |
   +----------------------+----------------------+---------------------+
   | Bit 0                |           1          | Empty Set: The list |
   |                      |                      | of IP Addresses is  |
   |                      |                      | an empty list       |
   | Bit 1                |           2          | Authorized: Any     |
   |                      |                      | host with a valid   |
   |                      |                      | claim to this name  |
   |                      |                      | is authorized to    |
   |                      |                      | send email          |
   |                      |                      | Other bits are      |
   |                      |                      | reserved for        |
   |                      |                      | expansion, and must |
   |                      |                      | be set to zero.     |
   +----------------------+----------------------+---------------------+

      The resulting unsigned integer values for weight are:

















Otis, et al.           Expires December 17, 2004                [Page 6]


Internet-Draft                  Mail-CSA                       June 2004


   +---------------------------------+---------------------------------+
   |           Summed Value          | Meaning                         |
   +---------------------------------+---------------------------------+
   |                0                | Should not be used, but         |
   |                                 | receiving SMTP servers MAY      |
   |                                 | interpret it the same as summed |
   |                                 | value 1                         |
   |                1                | No email should be coming from  |
   |                                 | clients with this name          |
   |                2                | Clients with this name are      |
   |                                 | authorized to send email        |
   |                3                | Clients with this name are      |
   |                                 | authorized to send email, but   |
   |                                 | their IP addresses are not      |
   |                                 | listed                          |
   +---------------------------------+---------------------------------+

   Port
      The meaning of Port is reserved for future use.  This field must
      be set to zero.

   Target
      A domain name (typically the same as the EHLO string) that
      resolves to the correct list of IP addresses.  If this record is
      defined with the "Empty List" bit set, this field should be set to
      the Name portion of the QNAME, rather than the "." mentioned in
      RFC2782, as a means to prevent excessive traffic on root DNS
      servers by errant implementations.


6.  Domain administrator advice

   Although a conceptual framework might list the authorization step as
   logically following an authentication step, these steps MAY run in
   parallel.  Thus, those responsible for maintaining CSV DNS records
   should make allowance for the fact that the response of the
   accreditation service (which depends only on the EHLO string or the
   client address) is likely to arrive at the receiving MTA before the
   response to the DNS SRV query detailed here.  As a result, the
   receiving SMTP server may not follow-up partial or truncated UDP
   responses for expediency.  Regardless of what is specified, this
   receiving SMTP server may decide to refuse the client if their chosen
   accreditation service returns "Unknown".  The following
   recommendations explain how to ensure that the complete list of IP
   addresses reaches the receiving SMTP server in the response to its
   SRV query.

   Currently UDP has a limit of 512 octets.  Replies requiring more than



Otis, et al.           Expires December 17, 2004                [Page 7]


Internet-Draft                  Mail-CSA                       June 2004


   512 octets may create UDP fragmentation and, depending upon the
   connection and handling, in addition to a higher rate of packet loss,
   may also cause truncated or partial replies.  Furthermore, delivery
   and resolver handling of truncated and partial responses varies,
   leading to additional delays and queries.  Domain administrators are
   strongly advised to keep DNS replies below 512 octets for these
   reasons.

   With a complete response to an SRV-CSA query, SMTP server is able to
   employ Right Hand Side Black List (RHSBL) services based upon the
   domain name rather than address alone and as well as the
   accreditation services detailed in [ID-Marid-CSVDNA].  These
   domain-based services will not suffer from the same outdated-record
   problems as the IP-Address-based services widely used at the time of
   this writing.  Also, of course, domain-based services will be able to
   accredit those domains which must periodically change their IP
   address.  Reliance on the HELO/EHLO response allows isolation of
   domains which may share common address space as with virtual hosting
   or allow detection of domains for which there is insufficient history
   which may invoke a go-slow approach as example.

   In some cases, domains advertising SRV records will benefit by
   reassigning some EHLO strings so as to limit the number of IP
   addresses to be reported in SRV responses.  Owing to the efficient
   nature of the SRV record, the mechanism discussed here calls for a
   single DNS query per SMTP session (not counting an out-of-band
   accreditation query), which is substantially less network traffic
   than per-message methods.

   To help ensure complete answers are obtained from cached records, TTL
   values of the SRV-CSA and related address records should be the same.
   Beware some DNS server implementation consider the SOA TTL as a
   default rather than a minimum.

7.  Security Considerations

   This proposal pertains to security, namely authentication and
   authorization of peer MTAs.

   The proposal also relies on security of the underlying IP network and
   on the integrity of DNS data.  It performs a basic authentication of
   the peer MTA, based on domain name registration of the peer's IP
   Address.  As such, the mechanism provides a basic building block to a
   larger repertoire of email security services.

   There is no way a site can keep its hosts from being referenced as
   servers.  This could lead to denial of service.




Otis, et al.           Expires December 17, 2004                [Page 8]


Internet-Draft                  Mail-CSA                       June 2004


   With SRV, DNS spoofers can supply false addresses.  Because this
   vulnerability exists already with names and addresses, this is not a
   new vulnerability, merely a slightly extended one.  However, as
   SRV-CSA records are used in an authorization context, the DNS servers
   can be protected by DNSSEC [RFC3008] should this vulnerability become
   intractable.

8.  IANA Considerations

   The tokens "_client" as _Service and "_smtp" as _Proto labels needs
   to be registered as used with DNS SRV records [RFC2782].

9.  Working Group Evaluation

   This section contains responses to the issues put forward by the
   MARID working group chairs.

   1.  Amount of change in software components
       DNS administration, servers and clients MUST support SRV queries.
       Client MTA's MUST put their registered domain name in EHLO
       announcements.
       Server MTA's MUST implement the validation procedure described in
       this specification.

   2.  Configuration complexity
       Requires registering each IP Addresses of an authorized Client
       MTA, whenever the set of Addresses changes.  No other
       configuration is required.

   3.  Current use cases that will no longer be viable
       All current use cases will still be viable.  This mechanism is
       only enabled by the explicit presence of the defined SRV record
       for the domain name in the EHLO announcement.

   4.  Needed infrastructure changes
       Explicit registration of Client MTAs.
       Considerations for use in both IPv4 and IPv6
       Validation mechanism is based on IP Addresses and requires the
       usual query and handling of address types that will be
       encountered from the IP module and the DNS.


10.  References

10.1  References - Normative

   [ID-Marid-CSVDNA]
              Leslie, J., Crocker, D. and D. Otis, "Domain Name



Otis, et al.           Expires December 17, 2004                [Page 9]


Internet-Draft                  Mail-CSA                       June 2004


              Accreditation (DNA)", June 2004.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1034]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
              RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
              2671, August 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.

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

10.2  References - Informative

   [ID-Marid-CSV]



Otis, et al.           Expires December 17, 2004               [Page 10]


Internet-Draft                  Mail-CSA                       June 2004


              Crocker, D., Leslie, J. and D. Otis, "Client SMTP
              Validation (CSV)", June 2004.

   [ID-Marid-CSVHNA]
              Crocker, D., Otis, D. and J. Leslie, "Host Name
              Authentication (HNA)", June 2004.

   [ID-email-arch]
              Crocker, D., "Internet Mail Architecture", May 2004.


Authors' Addresses

   Douglas Otis
   Mail Abuse Prevention System
   1737 North First Street, Suite 680
   San Jose, CA  94043
   USA

   Phone: +1.408.453.6277
   EMail: dotis@mail-abuse.org


   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086
   USA

   Phone: +1.408.246.8253
   EMail: dcrocker@brandenburg.com


   John Leslie
   JLC.net
   10 Souhegan Street
   Milford, NH  03055
   USA

   Phone: +1.603.673.6132
   EMail: john@jlc.net










Otis, et al.           Expires December 17, 2004               [Page 11]


Internet-Draft                  Mail-CSA                       June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Otis, et al.           Expires December 17, 2004               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/