MARID D. Crocker
Internet-Draft Brandenburg InternetWorking
Expires: December 13, 2004 J. Leslie
JLC.net
D. Otis
Mail Abuse Prevention System
June 14, 2004
Client SMTP Validation (CSV)
draft-crocker-marid-smtp-validate-01
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 13, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Internet mail relies on exchanges between systems that have made no
prior arrangement with each other. For reasons of history and
expediency, the current service provides a level of accountability
for participating hosts that is no longer adequate. This makes it
impossible to vet MTAs or find recourse when their operation causes
problems. Client SMTP Validation (CSV) provides an economical
Crocker, et al. Expires December 13, 2004 [Page 1]
Internet-Draft Mail-CSV June 2004
service that permits an SMTP server to decide whether messages sent
by the client SMTP are likely to be well-behaved, or at least to
decide whether the client is sufficiently accountable for its
actions. CSV provides a small, simple and useful improvement to
Internet mail service accountability. It builds upon the existing
practise of service providers that accredit the networks from which
sending systems are connecting.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Identification . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Accreditation . . . . . . . . . . . . . . . . . . . . . . 6
3. Client SMTP Validation Procedures . . . . . . . . . . . . . . 6
3.1 Identification . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Accreditation . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 References - Normative . . . . . . . . . . . . . . . . . . . 8
5.2 References - Informative . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
B. Preventing SMTP-level Joe-Jobs of Well-Known Names . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Crocker, et al. Expires December 13, 2004 [Page 2]
Internet-Draft Mail-CSV 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 have been turned into unwilling
participants in large networks of hostile MTAs that send spam and
worms, and contribute to denial of service attacks.
When a server MTA receives a connection, it must decide whether to
accept the message traffic that is being sent to it, trusting that
its delivery will not be problematic to the operation of the provider
or their users. How can it do this, when operating in the open
Internet? Client SMTP Validation (CSV) defines a service that permits
the receiving SMTP server to decide whether messages sent by the
sending SMTP client are likely to be well-behaved, or at least to
decide whether the client is sufficiently accountable for its
actions.
The process of deciding on this trust of the client requires
performing a series of conceptually discrete steps:
Identification: What is the "name" of the client to be trusted? How
is it referenced?
CSV uses the domain name supplied by a client in the SMTP HELO/
EHLO.
Authentication: Is the client MTA legitimately associated with that
name? Can we prove that the client is who it purports to be?
CSV documents a range of existing techniques that are appropriate
for use with CSV.
Authorization: Is the sending SMTP client permitted to act as a
client MTA? Has a separate authority given it permission to
perform this service?
CSV specifies a DNS-based record that states whether an associated
host has permission to operate as a client MTA.
Accreditation: What is the trust that is to be extended to the entity
that authorized the client MTA? Does the server MTA have a basis
for deciding that the entity providing authorization for the
client MTA can, itself, be trusted to make valid authorizations?
CSV discusses existing techniques for accrediting authorizing
systems. It also defines a DNS record that permits such systems
to announce the accreditation services in which they are listed.
It defines another DNS record that permits accreditation services
to publish their assessments of client MTAs.
Crocker, et al. Expires December 13, 2004 [Page 3]
Internet-Draft Mail-CSV June 2004
A proposal or its implementation well might combine these steps.
However it is important to consider them independently, in order to
ensure that the proposal specifies that they are performed in a valid
manner, or at least that the constraints of the proposal are clear
for each of these conceptual functions. This specification
distinguishes each of these logical steps and defines their operation
separately. It is based on validation of the EHLO domain name. The
proposed mechanism is small, simple and useful. In particular it
permits detecting machines that are prohibited from acting as Client
MTAs and those that are permitted. The mechanism is designed to be
useful between peer MTAs and only requires use of well-established
mechanisms.
Address-based Authentication Currently, service providers often
maintain lists of remote networks that are known to be trustworthy
or untrustworthy as sending SMTP clients. Typically, these lists
are based on the use of IP Addresses of the clients. The IP
Addresses serve as identifiers. The list specifies positive or
negative authorization, and the source of the list is an
organization the service provider deems worthy to assess other
sites.
When used in this way, IP Addresses are authenticated by relying
on their use in the IP routing infrastructure. Packets are routed
to the specified IP Address, over the open Internet. A repeated
exchange using that IP Address is therefore presumed to be an
interaction with the host legitimately associated with that IP
Address.
Increased topological, transfer and access complexities on the
Internet are making IP Addresses increasingly problematic for use
as identifiers. Instead they are viewed as appropriate only for
the most transient task of delivering individual packets.
CSV builds upon this popular model. Besides the considerable benefit
of having operational practice, the model can be extremely efficient.
It permits the service provider to assess the source of an entire
message stream, rather than having to evaluate each message. Also,
CSV makes its assessment before messages cross the Internet, thereby
saving bandwidth and reducing the impact of a distributed denial of
service attack.
CSV verifies that a host is authorized to act as an SMTP client and
that the client is likely to be operated acceptably. CSV enhances
current practice with:
o Identification by persistent domain name rather than transient IP
Address
Crocker, et al. Expires December 13, 2004 [Page 4]
Internet-Draft Mail-CSV June 2004
o Alternative authentication techniques
o Explicit listing of client service authorization
o A standardized method of referencing accreditation services
o A standardized method of querying an accreditation service
Terminology: Terminology conforms to [ID-email-arch].
Discussion: The venue for discussing this proposal is the
<http://ietf.org/html.charters/marid-charter.html>.
NOTE: The current draft makes reference to quite a few underlying
services that need citations (ed.)
2. Requirements
2.1 Identification
The means of identifying a remote host or service requires uniqueness
and is aided by persistence. The identifier must not be ambiguous
and its use is made far more efficient if it is stable over time.
The two usual choices are IP Addresses and Domain Names.
An IP Address typically refers to a single host and can change
relatively frequently, as the host's connection to the Internet
changes. IP Addresses are reported by the Internet infrastructure
and for simple security requirements, transactional use of an IP
Address through the Internet's routing fabric is taken as validation
of the Address. Domain Names are longer-lived but require new
administrative effort. They can be used to refer to multiple hosts
simultaneously. The administrator of a Domain Name may list any IP
Address they wish to associate with the name, independent of the
administrator and the Domain Name having a valid relationship to that
Address. Therefore, authentication of a domain name's reference to a
particular IP Address requires an explicit authentication step.
2.2 Authentication
If the sending SMTP client of an connection can be authenticated,
then it is possible to develop an accountability mechanism based on
that authentication. MUA-MSA exchanges have a substantial number of
useful authentication mechanisms available. These are often very
strong, and involve significant prior arrangement. The same holds
true for MDA-MUA exchanges, and often for MSA-MTA and MTA-MDA
exchanges, such as within an organizations local network.
Crocker, et al. Expires December 13, 2004 [Page 5]
Internet-Draft Mail-CSV June 2004
What is missing is a useful means of authenticating MTA-MTA exchanges
over the open Internet. Prior arrangement between such a pair of
MTAs is antithetical to the history and operation of Internet mail.
Spontaneous communications are at the core of Internet design and
operation. So the challenge is to develop an authentication
mechanism that permits the necessary amount of accountability,
without imposing undue overhead or restrictions.
2.3 Authorization
Internet operation has typically required no public mechanism for
restricting or permitting particular hosts to operate clients or
servers for particular services on behalf of particular domains. The
DNS MX record states where to route mail that is destined for a
specific domain; this implies a degree of authorization for the host
referenced in the MX. However the record is really for routing and
there is no equivalent means of specifying prohibition of other hosts
that might act as intermediaries. Similarly there is no means for
checking the authorization of World Wide Web servers, DNS
servers,telnet clients or other Internet applications.
What is missing is an open, interoperable means by which a trusted
agency can announce its authorization of a particular host to operate
a particular service.
2.4 Accreditation
In non-Internet environments the basis for deciding that an
authorizing agency is, itself, to be trusted, is highly varied and
often is not well-understood. It is expected that this portion of an
Internet mail validation service will therefore need to support be a
variety of accreditation service styles.
What is needed is a means of announcing performance of accreditation
and a means of querying a service to obtain information about the
host it is accrediting.
3. Client SMTP Validation Procedures
CSV defines a mechanism for session-time, domain-based validation of
a peer, sending SMTP client MTA. It is useful across the open
Internet, between MTAs that have made no prior arrangement with each
other. Validation establishes that the operation of the MTA is
authorized by an accredited administrator of the declared domain
name.
The validation requirements are modest, because the system does not
seek to provide long-term vetting of the client host, nor does it
Crocker, et al. Expires December 13, 2004 [Page 6]
Internet-Draft Mail-CSV June 2004
assess the actual content being exchanged. Techniques that would be
wholly inadequate for classic, strong authentication and validation
can be entirely sufficient for CSV's needs.
3.1 Identification
The sending SMTP client host is identified by a Domain Name, supplied
by that host as the first parameter to an opening SMTP HELO or EHLO.
The domain name serves as a unique, topologically-independent,
persistent identifier that is registered in the Domain Name Service.
Hence, parametric values associated with the domain can be obtained
through a DNS query.
For CSV, a sending SMTP client places the domain name into the
<Domain> field specified for a SMTP HELO or EHLO [RFC2821]. The
domain name is any name under which they are claiming authorization
to act as a sending SMTP client. A receiving SMTP server will
extract this name and use it as the identification for the client
claiming authorization.
3.2 Authentication
There is no single, common means of authenticating a host's use of a
domain name. CSV participants SHOULD use one of the techniques
described in Host Name Authentication (HNA) [ID-Marid-CSVHNA]. It
describes techniques that are widely used and acceptable for the
purposes of CSV.
The document highlights the range of techniques and the differences
in their administrative overhead and strength of authentication.
However other techniques can be equally valid.
3.3 Authorization
The purpose of authorization, in CSV, is to establish that an
accountable authority has given permission for the sending SMTP
client host to operate in that role.
CSV participants SHOULD use the method defined in Client SMTP
Authentication (CSA) [ID-Marid-CSVCSA]. It specifies a DNS record
that is associated with the domain name offered by the sending SMTP
client host.
3.4 Accreditation
The utility of any service like CSV is entirely dependent upon the
relevance, reliability and accuracy of the service that accredits the
authorizing agent. It is expected that there will be numerous
Crocker, et al. Expires December 13, 2004 [Page 7]
Internet-Draft Mail-CSV June 2004
services that provide accreditation. CSV is intended to support use
of any service that gains credibility among operators of SMTP
servers.
An initial set of capabilities for specifying CSV-related
accreditation services is specified in Domain Name Accreditation
[ID-Marid-CSVDNA]. CSV participants SHOULD use the methods defined
there.
4. Security Considerations
This entire proposal pertains to security, namely authentication and
authorization of peer MTAs.
The proposal relies on the integrity and authenticity of DNS data.
5. References
5.1 References - Normative
[ID-Marid-CSVCSA]
Otis, D., Crocker, D. and J. Leslie, "sending SMTP client
Authentication (CSA)", June 2004.
[ID-Marid-CSVDNA]
Leslie, J., Crocker, D. and D. Otis, "Domain Name
Accreditation (DNA)", June 2004.
[ID-Marid-CSVHNA]
Crocker, D., Otis, D. and J. Leslie, "Host Name
Authentication (HNA)", 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.
[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.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
Crocker, et al. Expires December 13, 2004 [Page 8]
Internet-Draft Mail-CSV June 2004
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.
5.2 References - Informative
[ID-brand-drip]
Brand, R. and L. Sherzer, "Designated Relays Inquiry
Protocol (DRIP)", draft-brand-drip-02 (work in progress),
October 2003.
[ID-email-arch]
Crocker, D., "Internet Mail Architecture", May 2004.
Authors' Addresses
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
Crocker, et al. Expires December 13, 2004 [Page 9]
Internet-Draft Mail-CSV June 2004
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
Appendix A. Acknowledgements
This proposal is similar to DRIP [ID-brand-drip], however it uses a
different DNS [RFC1035] record.
Appendix B. Preventing SMTP-level Joe-Jobs of Well-Known Names
CSV permits using alternative functional components. This can result
in significant variations of administration and use. Some of these
can require extended effort to configure and use. However some very
simple scenarios can be quite useful.
For example, domain names of well-known services are often used
fraudulently in email, known as joe-jobs. If the well-known service
sends all of its email from its own network, then it can use CSV to
register all authorized sending SMTP clients and list all others
sources of email under its domain name as invalid.
Such a use requires the following:
1. Domain name owner lists a wildcard for its "root" domain name,
with a CSV record saying that client SMTP sending is prohibited.
2. Domain name owner lists the specific host domain names, with
appropriate CSV records to list the hosts as permitted to send
mail.
3. Domain name owner's client SMTP sending hosts include their
domain names in SMTP HELO/EHLO commands.
4. Receiving SMTP servers uses a small, locaol whitelist, to perform
accreditation of the domain administration for the well-known
service.
CSV will ensure that any mail-sending client that uses the well-known
name in the SMTP HELO/EHLO command must do so validly.
It is possible to detect fraudulent use that is not announced in the
SMTP HELO/EHLO. To accomplish this the receiver MAY consult the CSV
Crocker, et al. Expires December 13, 2004 [Page 10]
Internet-Draft Mail-CSV June 2004
information at a later stage of processing. For example:
1. In the message, record the IP Address of the sending SMTP client.
2. Upon detecting that the From field that has a domain name
associated with a well-known service, perform a CSV check using
that domain name and the recorded IP Address.
If the Joe-job scheme is based on the direct content, rather than the
From field, a deeper and stronger validation technique will be
necessary, based on content-signing
Crocker, et al. Expires December 13, 2004 [Page 11]
Internet-Draft Mail-CSV 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.
Crocker, et al. Expires December 13, 2004 [Page 12]