Network Working Group XingWei. Wang Internet-Draft ZhanKao. Wen Intended status: Standards Track Jun. Liu Expires: May 8, 2011 WeiDong. Wang PengCheng. Liu NEU November 4, 2010 TESF Based on True IPv6 Address Access draft-xwwang-ipv6tesf-00.txt Abstract The current Email infrastructure has the property that any host sending mail to the mail system can identify itself as any user name it wants. Furthermore, the current Email framework neither authenticates the sender nor traces the source of the mail, so even find a spam, the method is just to reject the mail or insert the mail source into "blacklist", and both of these methods can!_t deracinate the generation of spam. This document design a Email source address authentication based on true IPv6 address access to identify and authenticate the mail source address, to trace the mail sender effectively, and to deracinate the generation of spam. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 8, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Wang, et al. Expires May 8, 2011 [Page 1] Internet-Draft TESF Based on True IPv6 Address Access November 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. TESF Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3. TESF detailed view . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Intra-domain authentication . . . . . . . . . . . . . . . 7 3.1.1. IPv6 address . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. IPv6 address authentication . . . . . . . . . . . . . 7 3.1.3. Update of variational IP address list . . . . . . . . 8 3.2. Inter-domain authentication . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Intra-domain authentication . . . . . . . . . . . . . . . 12 4.1.1. IP address authentication faild . . . . . . . . . . . 12 4.1.2. IP address authentication sucess . . . . . . . . . . . 12 4.2. Inter-domain authentication . . . . . . . . . . . . . . . 13 4.2.1. Original mail . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Mail dealed by sender domain . . . . . . . . . . . . . 13 4.2.3. Mail passed inter-domain authentication . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Key management . . . . . . . . . . . . . . . . . . . . . . 16 5.3. DNS spoofing . . . . . . . . . . . . . . . . . . . . . . . 16 6. Notes to Implementers . . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Wang, et al. Expires May 8, 2011 [Page 2] Internet-Draft TESF Based on True IPv6 Address Access November 2010 1. Introduction The current e-mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any user name it wants. While this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). Furthermore, the current email framework on Internet can!_t trace the source of Email, so it can't deracinate the generation of spam. This document design a Email source address authentication based on true IPv6 address access. The authentication is devided into inter- domain authentication and intra-domain authentication. For the purposes of this document, authentication is seen from a user perspective, and is intended to answer the question "who sent this email and if the IP address he used has passed the authentication." where "who" is the email address the recipient sees and IP address pass the authentication means we can find out the sender of the spam using this IP address. This document defines a protocol by which domain owners may authorize its user and the user's IP addressto use their domain name in the "MAIL FROM" or "HELO" identity. For other domain's mail, authenticate the domain included in "MAIL FROM" and "FROM" fields, because these two fields are mostly abused. 1.1. Motivation TESF(Trusted Email System Framework) is a simple and effective mail source authentication mechanism which is used to trace the sender of the spam by sender domain and affirm the sender domain by the receiver domain. TESF has the following characteristic: 1. Using IP address authentication to avoid the sender denies his mail; 2. Using variational IP address to support user mobility; 3. It can trace the spam sender by binding user's fixed IP address; 4. Using two levels authentication methanism to improve authentation efficency; 5. Support both of mail forwarding and mailing list. Wang, et al. Expires May 8, 2011 [Page 3] Internet-Draft TESF Based on True IPv6 Address Access November 2010 1.2. Terminology In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "RECOMMENDED, "MAY" and "OPTIONAL"in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels"[KEYWORDS]. Wang, et al. Expires May 8, 2011 [Page 4] Internet-Draft TESF Based on True IPv6 Address Access November 2010 2. TESF Overview TESF divides the authentication to inter-domain and intra-domain authentication. Inter-domain authentication is used to authenticate the mail sender!_s domain. It combines path authentication-based, cryptographic authentication-based and reputation and accreditation system-based methods in order to support both of mail forwarding and mail list. Authentication efficiency can be further improved by organizing authentication order properly. Intra-domain is used to affirm the sender!_s IP address which is used to trace the sender. It supports user!_s mobility by combining the fixed and variational IP address. For intra-domain user's sending request, mail server first request his username and password, and then authenticae his IP address, if both pass, send the mail and add a Domainkeys signature on the mail header. For inter-domain's mail, mail source authenticaion flow isGBPo 1. Black-white list authentication; 2. SPF authentication; 3. Domainkeys authentication. For these three authentication, if anyone of them success, the finial authenticated result is success so that it can support both of mail forwording and mailing list, otherwise, authentication result is failed. Wang, et al. Expires May 8, 2011 [Page 5] Internet-Draft TESF Based on True IPv6 Address Access November 2010 Interdomain Authetication / \ / +-------+ \ +----------------->| DNS |--------------------+ | +-------+ | | V +------------+ Email +------------+ | sender MTA |--------------------------------->|receiver MTA| +------------+ +------------+ A |<--------Intradomain | Authetication +------------+ | sender | +------------+ Figure 1 Wang, et al. Expires May 8, 2011 [Page 6] Internet-Draft TESF Based on True IPv6 Address Access November 2010 3. TESF detailed view 3.1. Intra-domain authentication This module is used to authenticate user's identity, and it contain SASL and IPv6 address authentication. It first authenticates user's username and password using SASL, and then authenticates user's IP address. If either one of them failed, reject this user. +--------+ Yes +---------+ No +-----------+ Yes login----->| SASL |----->| IP used |----->|IP Password|----->accept +--------+ +---------+ +-----------+ |No |Yes |No V V V reject accept reject Figure 2 3.1.1. IPv6 address According to RFC3513, even the same host computer, at the different time, its IPv6 address is different. So, match IPv6 address can't match all of the 128bits while match part of them, for example, just match first 64 bits, and this means the authentication precision is a link of a network. Further more, IP address in this document is means IPv6 address. 3.1.2. IPv6 address authentication For every user, his corresponding information include a fixed IP address and a variational IP address list. IPv6 address authentication algorithm is as follows: 1. If user's current IP address equal to his fixed IP address, authenticaion success, goto 4, otherwise goto 2. 2. If user's current IP address exsit in his variational IP address list, authenticaion success, goto 4, otherwise goto 3. 3. Request user to input his IP auth password, if match, update the variational IP address list, authenticaion success, goto 4, otherwise authentication failed, goto 4. 4. Algorithm Ends. Wang, et al. Expires May 8, 2011 [Page 7] Internet-Draft TESF Based on True IPv6 Address Access November 2010 3.1.3. Update of variational IP address list Variational IP address list storage user's variational IP addresses (mobility user's temporary address). It's organised as a list, and every element in the list contain a IP address and a counter. If user's current IP address is neither his fixed IP address nor in his variational IP address list, update the variational IP address list according to the LRU algorithm. a. If variational IP address list doesn't reach its max length, add the current IP address into the variational IP address list and then set all the couter to 0. b. If current IP address exist in the variational IP address list, add its counter by 1. c. If don't match these two rules, find out the minimaze counter in the list (if there are more than one of these IP address, find out the last one), delete it and add the current IP address into the variational IP address list and then set all the couter to 0. We expatiate these three rules bellow, suppose max list size is 5, current user jack@mail.neu6.edu.cn's list size is 4. a. If jack@mail.neu6.edu.cn use a new IP address 2001:200:0:8002:* to send mail, IP address list change as follows, suppose there just match first 64 bits of IPv6 address, so the last 64 ones is ignored. +----------------------+---+ +----------------------+---+ | 2001:da8:9000:b255:* | 5 | | 2001:da8:9000:b255:* | 0 | +----------------------+---+ +----------------------+---+ | 5f1b:df0:ce3e:e200:* | 2 | | 5f1b:df0:ce3e:e200:* | 0 | +----------------------+---+ +----------------------+---+ | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 0 | +----------------------+---+ +----------------------+---+ | 2001:200:20:4819:* | 1 | | 2001:200:20:4819:* | 0 | +----------------------+---+ +----------------------+---+ | | | | 2001:200:20:8002:* | 0 | +----------------------+---+ +----------------------+---+ Figure 3 b. If jack@mail.neu6.edu.cn use 5f1b:df0:ce3e:e200:* to send mail, because this address is already exsit in the address list, so just add the counter by 1. Wang, et al. Expires May 8, 2011 [Page 8] Internet-Draft TESF Based on True IPv6 Address Access November 2010 +----------------------+---+ +----------------------+---+ | 2001:da8:9000:b255:* | 5 | | 2001:da8:9000:b255:* | 5 | +----------------------+---+ +----------------------+---+ | 5f1b:df0:ce3e:e200:* | 2 | | 5f1b:df0:ce3e:e200:* | 3 | +----------------------+---+ +----------------------+---+ | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 4 | +----------------------+---+ +----------------------+---+ | 2001:200:20:4819:* | 1 | | 2001:200:20:4819:* | 1 | +----------------------+---+ +----------------------+---+ | 2001:200:20:8002:* | 3 | | 2001:200:20:8002:* | 3 | +----------------------+---+ +----------------------+---+ Figure 4 c. If jack@mail.neu6.edu.cn use a new address 2001:288:3b0:1c04:* to send mail, because this address isn't in the address list, so replace the least and recently used IP address, and then clear the couter of every address. +----------------------+---+ +----------------------+---+ | 2001:da8:9000:b255:* | 5 | | 2001:da8:9000:b255:* | 0 | +----------------------+---+ +----------------------+---+ | 5f1b:df0:ce3e:e200:* | 3 | | 5f1b:df0:ce3e:e200:* | 0 | +----------------------+---+ +----------------------+---+ | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 0 | +----------------------+---+ +----------------------+---+ | 2001:200:20:4819:* | 1 | | 2001:288:3b0:1c04:* | 0 | +----------------------+---+ +----------------------+---+ | 2001:200:20:8002:* | 3 | | 2001:200:20:8002:* | 0 | +----------------------+---+ +----------------------+---+ Figure 5 3.2. Inter-domain authentication Inter-domain authentication is used to affirm the mail's domain. It conbines multi-methanisms to offset the weakness of just use one methanism. It combines path authentication-based, cryptographic authentication-based and reputation and accreditation system-based methods in order to support both of mail forwarding and mail list. Authentication efficiency can be further improved by organizing authentication order properly. The path authentication-based method is SPF, cryptographic authentication-based is Domainkeys and reputation and accreditation system-based method is blacklist. Because reputation can't affirm if the mail sender domain is true, it can just affirm which domain always sends spam, so first do the Wang, et al. Expires May 8, 2011 [Page 9] Internet-Draft TESF Based on True IPv6 Address Access November 2010 reputation authentication, reject the domain exsiting in the blacklist. For SPF and Domainkeys, SFP is authenticted before the mail body is send while Domainkeys is authenticated after all the mail is send, meanwhile SPF's effiency is better then Domainkeys, so do SPF first and then do Domainkeys authentication. So, if SPF is success, there is no need to do the Domainkeys, which can further improve the authenticaiton effiency. Inter-domain authenticaion flow is as follows: 1. Do the DNS blacklist authenticaion, if the sender domain is in the blacklist, reject it, otherwise do the SPF authentication. 2. Do SPF authenticaion, if success, add "X-Mail-Source-Auth: Pass" into mail's header, inter-domain authenticaion success, otherwise do Domainkeys authentication. 3. If Domainkeys authentication successGBP[not]add "X-Mail-Source- Auth: Pass" into mail's header, inter-domain authenticaion success, otherwise inter-domain authenticaion failed, reject the sending request. The Inter-domain authenticaion flow is: Wang, et al. Expires May 8, 2011 [Page 10] Internet-Draft TESF Based on True IPv6 Address Access November 2010 +-------------+ hate | Reputation |-----+ +-------------+ | | | |love/shrug | V | pass +-------------+ | +----------| SPF | | | +-------------+ | | |fail/ | | |unknown | | V | | pass +-------------+ | | <--------| Domainkeys | | | +-------------+ | | |fail/ | | |unknown | | |<-----------+ V V +-------+ +-------+ | pass | | fail | +-------+ +-------+ Figure 6 Wang, et al. Expires May 8, 2011 [Page 11] Internet-Draft TESF Based on True IPv6 Address Access November 2010 4. Examples 4.1. Intra-domain authentication This module is a extension of SASL. If IPv6 address authentication success, it same as the normal SASL, otherwise need user to input his IP auth password. 4.1.1. IP address authentication faild If user's current IP address isn't his fixed IP and doesn't exsit in his variational IP address, mail server request user to input his IP auth password. S: 220 smtp.example.com ESMTP server ready C: EHLO mail.example.com S: 250-smtp.example.com S: 250 AUTH PLAIN LOGIN C: AUTH LOGIN S: 334 C: bGl1cGNAdGVzdG1haWwubmV1Ni5lZHUuY24= S: 334 C: dGVzdA== S: 334 C: YWJjQGV4YW1wbGUuY29t S: 235 Authentication successful Figure 7 4.1.2. IP address authentication sucess If user's current IP address is his fixed IP or exsit in his variational IP address, it's the same as the traditional SASL. Wang, et al. Expires May 8, 2011 [Page 12] Internet-Draft TESF Based on True IPv6 Address Access November 2010 S: 220 smtp.example.com ESMTP server ready C: EHLO mail.example.com S: 250-smtp.example.com S: 250 AUTH PLAIN LOGIN C: AUTH LOGIN S: 334 C: bGl1cGNAdGVzdG1haWwubmV1Ni5lZHUuY24= S: 334 C: dGVzdA== S: 235 Authentication successful Figure 8 4.2. Inter-domain authentication 4.2.1. Original mail The example mail is: From: "liupc" To: liupc@testmail.neu.edu.cn Subject: test Date: Sun, 19 Nov 2006 15:48:18 +0800 HI this is a test bye Figure 9 4.2.2. Mail dealed by sender domain User's mail is dealed at his domain MTA, which add some header fields and Domainkeys signature. For the example mail above, the mail is changed to: Wang, et al. Expires May 8, 2011 [Page 13] Internet-Draft TESF Based on True IPv6 Address Access November 2010 DomainKey-Signature: a=rsa-sha1; b=YouIbq+DaoJud3Jc34oOqAvCdecqp/6x57 Jpw+dlcZTOWIUv57gtSfdkdCtDYPbzWWeeZFYchoTG8h8i+m MKH/qTymjsObPk2c6fhhR/QCula/R1l73nOyehtl9ktZ5JPd U2ZHxkLCZ8DgpzsajnGiRoqNFgb1VkBhDUAQ7k2cM=; c=no fws; d=testmail2.neu6.edu.cn; q=dns; s=selector1 Received: by testmail2.neu6.edu.cn (Postfix, from userid 502) id 8F08994511; Sun, 19 Nov 2006 15:48:18 +0800 (CST) From: "" To: liupc@testmail.neu6.edu.cn Subject: =?gb2312?B?dGVzdA==?= Date: Sun, 19 Nov 2006 15:48:18 +0800 X-Originating-IP: [2001:da8:9000:b255:cc22:18a4:4732:f6c2] Message-Id: <20061119074818.8F08994511@testmail2.neu6.edu.cn> HI this is a test bye Figure 10 4.2.3. Mail passed inter-domain authentication Receiver's domain MTA add the "X-Mail-Source-Auth-Domain: PASS" and some other headers. Suppose the mail above passes Domainkeys while fail SPF, and the mail is changed to: Wang, et al. Expires May 8, 2011 [Page 14] Internet-Draft TESF Based on True IPv6 Address Access November 2010 Received: from testmail.neu6.edu.cn (localhost.localdomain [IPv6:::1]) by testmail.neu6.edu.cn (Postfix) with ESMTP id 3410CF3A8A for ; Sun, 19 Nov 2006 15:59:01 +0800 (CST) Received: from testmail.neu6.edu.cn (localhost.localdomain [IPv6:::1]) by testmail.neu6.edu.cn (Postfix) with ESMTP id 1592EF3A1E for ; Sun, 19 Nov 2006 15:59:01 +0800 (CST) X-Mail-Source-Auth-Domain: PASS Authentication-Results: localhost.localdomain from=liupc@testmail2.neu 6.edu.cn; domainkey=pass Received-SPF-IPv6: reject Please see http://spf.pobox.com/why.html?sen der=liupc%40testmail2.neu6.edu.cn&ip=2001%3ada8%3a9 000%3ab255%3a202%3ab3ff%3afeb7%3a27f2&receiver=loca lhost.localdomain Received: from testmail2.neu6.edu.cn (unknown [IPv6:2001:da8:9000:b255 :202:b3ff:feb7:27f2]) by testmail.neu6.edu.cn (Postfix) with ESMTP for ; Sun, 19 Nov 2006 15:59:01 +0800 (CST) Figure 11 Wang, et al. Expires May 8, 2011 [Page 15] Internet-Draft TESF Based on True IPv6 Address Access November 2010 5. Security Considerations 5.1. DNS The objective of the SAAF is to authenticate the sender domain by a reliable ways, but SAAF mostly depends on DNS, which is vulnerable. The SAAF increases the load of the DNS servers, for it has to provide SPF records and Domainkey records for receiver MTA. Frequent using The SAAF makes the DNS query increase sharply, and then lots of cheat IP addresses appear, which makes the situation more and more worse. 5.2. Key management Because Domainkeys is one of the main part of the SASF, one of problems is to guarantee the security of the private key. Once the private key is lost, the whole mechanism will be disable. 5.3. DNS spoofing If there is a spam sender applies an independent domain, configures SPF and Domainkeys in it, then the SAAF will be disable. And with the growth of the spam senders under this domain, the domain will be added into blacklist, then the successive spams will rejected directedly. But the spams before that will be delivered. Wang, et al. Expires May 8, 2011 [Page 16] Internet-Draft TESF Based on True IPv6 Address Access November 2010 6. Notes to Implementers Besides the modifications of the e-mail system, one of the most important works is to make DNS to support TESF, that is, configures TXT records of the SPF and Domainkeys in the DNS servers. Wang, et al. Expires May 8, 2011 [Page 17] Internet-Draft TESF Based on True IPv6 Address Access November 2010 7. Normative References [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. Wang, et al. Expires May 8, 2011 [Page 18] Internet-Draft TESF Based on True IPv6 Address Access November 2010 Authors' Addresses XingWei Wang Northeastern University No.11, Lane 3, WenHua Road, HePing District Shenyang, Liaoning, China 110004 Phone: Email: wangxw@mail.neu.edu.cn URI: ZhanKao Wen Northeastern University Phone: Email: wzk@mail.neu.edu.cn URI: Jun Liu Northeastern University Phone: Email: liuj@mail.neu.edu.cn URI: WeiDong Wang Northeastern University Phone: Email: wangwd@mail.neu.edu.cn URI: PengCheng Liu Northeastern University Phone: Email: lpengcheng@126.com URI: Wang, et al. Expires May 8, 2011 [Page 19]