|Network Working Group||D. Otis|
|INTERNET DRAFT||Mail Abuse Prevention System|
|Category: Standards Track||Brandenburg InternetWorking|
|Expires: January 2005||J. Leslie|
Client SMTP Authorization (CSA)
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 in January 2005.
Copyright (C) The Internet Society (2004). All Rights Reserved.
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 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.
5 Client SMTP Authorization SRV Record
6 Domain administrator advice
7 Security Considerations
8 IANA Considerations
9 Working Group Evaluation
§ References - Normative
§ References - Informative
§ Author's Addresses
§ Intellectual Property and Copyright Statements
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.
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].
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-CSV]. However the authentication functionality is outside the scope of this specification.
The receiving SMTP server's authorization procedure is:
The results of this mechanism will provide the following authorization levels about sending SMTP clients:
|CLIENT AUTHORIZATION||WEIGHT||SERVER ACTION|
|Not Authorized||1||Generate session error with "550 Domain not authorized."|
|Authorized||2||Continue with CSV processing.|
|Authorized with Target Not Valid||3||Continue according to local policy; if session error is generated, use "550 Authentication not resolved."|
|Unknown||(no RR)||Continue according to local policy, as if CSV had not been invoked; if session error is generated, use "550 Client Unknown."|
The SRV CSA Record has the following contents:
|1||Ignore Target: The domain name in the Target field is a placeholder, and any IP addresses it resolves to MUST NOT be used for authentication.|
|2||Authorized: Any host with a valid claim to this name is authorized to send mail.|
|-||Other bit values are reserved for expansion and must be set to zero.|
The resulting unsigned integer values for weight are:
|0||Should not be used, but MAY be interpreted as the summed value 1.|
|1||No mail should be coming from clients with this name.|
|2||Clients with this name are authorized to send mail.|
|3||Clients with this name are authorized to send mail, but IP addresses associated with the Target field MUST NOT be used for authentication.|
Although a conceptual framework might list the accreditation step as logically following the authorization 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 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.
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.
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.
The tokens "_client" as _Service and "_smtp" as _Proto labels needs to be registered as used with DNS SRV records [RFC2782].
This section contains responses to the issues put forward by the MARID working group chairs.
|[RFC0791]||Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.|
|[RFC0821]||Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.|
|[RFC0822]||Crocker, D.H., "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.|
|[ID-email-arch]||Crocker, D., "Internet Mail Architecture", May 2004.|
|[ID-Marid-CSV]||Crocker, D., Otis, D. and J. Leslie, "Client SMTP Validation (CSV)", July 2004.|
|[ID-Marid-CSVDNA]||Leslie, J., Crocker, D. and D. Otis, "Domain Name Accreditation (DNA)", July 2004.|
|Mail Abuse Prevention System|
|1737 North First Street, Suite 680
|San Jose, CA 94043|
|675 Spruce Drive
|Sunnyvale, CA 94086|
|10 Souhegan Street
|Milford, NH 03055|
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 IETF's procedures with respect to rights in IETF 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 firstname.lastname@example.org.
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 (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.
Funding for the RFC Editor function is currently provided by the Internet Society.