INTERNET-DRAFT                                           Hadmut Danisch
Category: Experimental                                         Dec 2002
Expires: Jun 3, 2003

            A DNS RR for simple SMTP sender authentication
                  draft-danisch-dns-rr-smtp-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This memo suggests a new DNS RR type to provide a very simple
   scheme of domain name authentication for SMTP mails based on sender
   IP address authorization.


















Danisch                       Experimental                      [Page 1]


INTERNET-DRAFT                 DNS RMX RR                       Dec 2002


                           Table of Contents


1.  Threat description . . . . . . . . . . . . . . . . . . . . . . .   3
    1.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   3
    1.2.  SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Problem analysis . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Shortcomings of strong authentication mechanisms . . . . . . . .   3
4.  DNS based sender address verification  . . . . . . . . . . . . .   4
    4.1.  Suggested method . . . . . . . . . . . . . . . . . . . . .   4
    4.2.  Simple approach  . . . . . . . . . . . . . . . . . . . . .   4
    4.3.  APL RR based approach  . . . . . . . . . . . . . . . . . .   4
5.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . . .   5
    5.1.  Compatibility with old mail receivers  . . . . . . . . . .   5
    5.2.  Compatibility with old mail senders  . . . . . . . . . . .   5
    5.3.  Compatibility with old DNS clients . . . . . . . . . . . .   5
    5.4.  Compatibility with old DNS servers . . . . . . . . . . . .   5
6.  Enforcement policy . . . . . . . . . . . . . . . . . . . . . . .   5
Security Considerations  . . . . . . . . . . . . . . . . . . . . . .   6
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .   6






























Danisch                       Experimental                      [Page 2]


INTERNET-DRAFT                 DNS RMX RR                       Dec 2002


1.  Threat description

1.1.  Mail sender forgery

   Security surveillances found a significant increase in the number
   of e-mails with forged sender addresses.  As a consequence, damage
   caused by such e-mails increased as well. In the majority of
   examined e-mails the domain name of the envelope sender address was
   forged, and the e-mail was sent from an IP address which does not
   belong to a network used by the actual owner of the domain.

1.2.  SPAM

   A common and well known problem is the dramatic increase of
   unsolicited e-mail, commonly called "SPAM". Again, the majority of
   examined e-mails had forged sender addresses.  The abused domains
   were mainly those of common webmailers as hotmail or yahoo, or
   well-known companies.

2.  Problem analysis

   The real cause for forged e-mail is the lack of the Simple Mail
   Transfer Protocol SMTP[1] to provide any kind of sender
   authentication, authorisation, or verification. Efforts have been
   made to block such e-mails by requiring the sender address domain
   part to be resolvable (e.g. latest sendmail configurations). This
   method provides protection from e-mails with non-existing sender
   domains, and indeed, for some time it blocked most SPAM e-mails.
   However, since attackers and SPAM senders began to abuse existing
   domain names, this method was rendered ineffective.

3.  Shortcomings of strong authentication mechanisms

   Without any doubt, SMTP needs to be improved and reengineered in
   the future in order to resist against these kinds of threat.
   Cryptographical or organisational security mechanisms have to be
   designed an implemented for some sort of SMTPng.

   Unfortunately, it is impossible to seamlessly switch to a new
   protocol, since most of the SMTP servers and client programs can't
   be replaced or updated easily and quickly. Any kind of security
   mechanism has to be simple and backward compatible in order to be
   accepted. That's why extensions like SMTP with TLS are not widely
   spread.







Danisch                       Experimental                      [Page 3]


INTERNET-DRAFT                 DNS RMX RR                       Dec 2002


4.  DNS based sender address verification

4.1.  Suggested method

   To gain at least some improvement in e-mail authenticity while
   keeping as much SMTP compatibility as possible, a method is
   suggested which doesn't change SMTP at all.

   When the sender has issued the "MAIL FROM:" SMTP command, the
   receiving mail transfer agent (MTA) can - and modern MTAs do -
   perform some authorization checks, e.g. run a local rule database
   or check whether the sender domain is resolvable.

   The suggested method is to let the DNS server for the sender domain
   provide informations about which IP addresses are authorized to use
   the domain within a sender's address. After receiving the "MAIL
   FROM:" SMTP command, the receiving MTA can verify, whether the IP
   address of the sending MTA is authorized to send mails with this
   domain name.  Therefore, a list of authorized IP addresses is
   provided by the authoritative DNS server of that domain.

   This is some kind of "reverse MX record", therefore it is
   temporarily called "RMX", until a better name is found.

4.2.  Simple approach

   The RMX records for a domain could simply contain a list of network
   addresses and masks to define IP address ranges, which are allowed
   to use that domain, e.g.

      @   IN RMX 213.133.101.23/32
      @   IN RMX 1.2.3.0/24

4.3.  APL RR based approach

   The simple approach described above explains the method, but ends
   up in reinventing what already has been invented. Keeping address
   lists in DNS records was already defined in RFC 3123 [2] Therefore,
   instead of reinventing address ranges, we should use APL records.
   Here, an RMX record would contain a list of DNS names, which
   finally resolve to APL records. Mail is accepted if the sender IP
   address belongs to one of the listed networks. A configuration
   could look like this:

      danisch.de.        IN RMX ( relays.danisch.de   )
      relays.danisch.de. IN APL ( 1:213.133.101.23/32 1:1.2.3.0/24 )

   where the machine with the example address 213.133.101.23 and the



Danisch                       Experimental                      [Page 4]


INTERNET-DRAFT                 DNS RMX RR                       Dec 2002


   machines in the example subnet 1.2.3.0/24 are the only machines
   allowed to send e-mails with an envelope sender address of domain
   danisch.de. Since the APL records do not necessarily belong to the
   same domain or zone table as the RMX records, this easily allows to
   refer to APL records defined by someone else, e.g. the internet
   access or server hosting provider, thus reducing administrative
   overhead to a minimum.

5.  Compatibility

5.1.  Compatibility with old mail receivers

   Since the suggested extension doesn't change the SMTP protocol at
   all, it is fully compatible with old mail receivers. They simply
   don't ask for the RMX records and don't perform the check.

5.2.  Compatibility with old mail senders

   Since the SMTP protocol is unchanged and the SMTP sender is not
   involved in the check, the method is fully compatible with old mail
   senders.

5.3.  Compatibility with old DNS clients

   Since the RMX is a new RR, the existing DNS protocol and zone
   informations remain completely untouched.

5.4.  Compatibility with old DNS servers

   If a server can't provide RMX records or a zone doesn't contain
   them, the check can't be performed, while compatibility is still
   guaranteed.

6.  Enforcement policy

   Obviously, for reasons of backward compatibility and smooth
   introduction of this scheme, RMX records can't be required
   immediately. Domains without RMX records must temporarily be
   treated the same way as they are treated right now, i.e. e-mail
   must be accepted from anywhere. But once the scheme becomes
   sufficiently widespread, mail relays can start to refuse e-mails
   with sender addresses from domains without RMX records, thus
   forcing the owner of the domain to include a statement of
   authorization into the domain's zone table.  Domain owners will
   still be free to have an RMX record with a network and mask
   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
   On the other hand, mail receivers will be free to refuse mails from
   domains without RMX records or RMX records which are too loose.



Danisch                       Experimental                      [Page 5]


INTERNET-DRAFT                 DNS RMX RR                       Dec 2002


   Advanced MTAs might have a configuration option to set the maximum
   number of IP addresses authorized to use a domain. E-mails from a
   domain, which's RMX records exceed this limit, would be rejected.
   For example, a relay could reject e-mails from domains which
   authorize more than 8 IP addresses. That allows to accept e-mails
   only from domains with a reasonable security policy.

Security Considerations

   It is important to stress, that the suggested method does not
   provide high level security and does not completely block forged e-
   mails or SPAM. It is not a reliable and completely secure security
   mechanism. It is to be considered as a very cheap and simple
   lightweight mechanism, which can provide at least some improvement
   in mail security against a certain class of attacks, until a
   successor of SMTP has been defined and commonly accepted.

References



1.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).

2.   P. Koch, "A DNS RR Type for Lists of Address Prefixes (APL RR),"
     RFC 3123 (June 2001).


Author's Address

   Hadmut Danisch

   Tennesseeallee 58
   76149 Karlsruhe
   Germany

   Phone:  ++49-721-843004
   E-Mail: rfc@danisch.de

Comments

   Please send comments to rfc@danisch.de.

Expiry

   This drafts expires on Jun 3, 2003






Danisch                       Experimental                      [Page 6]