Network Working Group Eric Dean Internet Draft: Crystal Ball Inc. draft-irtf-asrg-cri-01.txt Yakov Shafranovich Expires: DD MMMM YYYY SolidMatrix Technologies, Inc. DD MMM YYYY Interworking Framework for Challenge/Response Systems A working document of the Anti Spam Research Group (ASRG) of the Internet Research Task Force (IRTF) 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 Copyright (C) The Internet Society (2003). All Rights Reserved. This Internet-Draft will expire on DD MMMM, YYYY. Abstract RFC821 was designed simply to deliver email messages without authenticating sources or senders of email messages. In an effort to reduce spam on the Internet, Challenge/Response ("C/R") email systems provide a method for validating message origination for an intended recipient. This document defines an for Challenge Response Interworking ("CRI") method by proposing the use of SMTP extensions as well as MIME headers for C/R control at either the server or user system level. For compatibility purposes with non-CRI compatible systems, this document addresses a set of guidelines for continued use with existing non-CRI mail systems and clients. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 1 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Purpose Introduction . . . . . . . . . . . . . . . . 1 1.3. C/R Interworking General Model. . . . . . . . . . . . 1 2. MIME Headers . . . . . . . . . . . . . . . . . . . . . 1 2.1. MIME Type . . . . . . . . . . . . . . . . . . . . . . 1 2.2. Using Delivery Status Notifications (DSNs) for CRI . 1 2.2.1. Overview of DSN . . . . . . . . . . . . . . . . . . 1 2.2.2. Use of DNS for CRI . . . . . . . . . . . . . . . . 1 2.3. The CRI MIME Headers. . . . . . . . . . . . . . . . . 1 3. SMTP for CRI . . . . . . . . . . . . . . . . . . . . . 1 3.1. The CRI ESMTP Extension . . . . . . . . . . . . . . . 1 3.1.1. IANA Considerations. . . . . . . . . . . . . . . . 1 3.1.2. SMTP Examples . . . . . . . . . . . . . . . . . . . 1 4.0 Loop Avoidance. . . . . . . . . . . . . . . . . . . . 1 5. Additional Information. . . . . . . . . . . . . . . . . 1 5.1. Security considerations. . . . . . . . . . . . . . . 1 5.2. Privacy Considerations. . . . . . . . . . . . . . . . 1 5.3. References . . . . . . . . . . . . . . . . . . . . . 1 5.4. Acknowledgements. . . . . . . . . . . . . . . . . . . 1 5.5. Author(s) Addresses. . . . . . . . . . . . . . . . . 1 5.6. Full Copyright Statement. . . . . . . . . . . . . . . 1 5.7. Document History. . . . . . . . . . . . . . . . . . 1 Table of Contents 1. Introduction. 1.1 Scope. Challenge response systems attempt to authenticate senders and determine if each sender originated a message to an intended recipient. This document defines MIME headers and a SMTP extension for an interworking of challenge response systems while providing loose guidelines for user intervention. 1.2 PURPOSE. There are various opportunites for a CRI protocol to possibly operate: via MIME headers, via DSNs defined in RFC 3464, via SMTP/ESMTP, and via the Message Tracking Protocol defined by the MSTRK WG. This document proposes specific CRI methods intended to achieve the following objectives: -Interoperability between CRI capable systems methods using MIME and SMTP while remaining transparent and non-conflicting to non-CRI capable systems. -A messaging protocol method using defined headers for automatically handling challenge messages and responses -Loop avoidance methods that prevent CRI systems from challenging challenge messages -Exception handling for mailing lists or other systems so that lists do not receive challenge messages -Guidelines for supporting software systems incompatible with CRI so that email is not disrupted and therefore CRI can be realistically deployed -A level of security that handles authentication, brute force attacks, and other known vulnerabilities -Ability to support authenticated messages and responses CRI is not an authentication method for email delivery nor security protocol. 1.3 CHALLENGE RESPONSE INTERWORKING MODEL. The challenge response model is based upon the following method: a) An original sender sends a message to a recipient's SMTP server b) The recipient's SMTP server then either produces a challenge message or forwards the original message to a recipient's user software that produces a challenge message. c) The resultant challenge message is sent to the original sender. d) If the sender's C/R SMTP server supports CRI methods, then the original sender's SMTP server may automatically respond to the challenge message. Otherwise, the original sender's server should forward the message to the original sender. e) If the original sender's client system supports CRI methods, then the original sender's client software may automatically respond to the challenge message. f) In the event that neither the server nor client software are CRI compatible, the C/R message should contain clear, legible instructions to the original sender instructing how to appropriately respond to the challenge request. ---------------------------------------- | | | v v +----------+ +----------+ +------+ | | | | +------+ | User |<-->| | | |<-->| User | +------+ | Sender- | CRI Messages | Receiver-| +------+ +------+ |SMTP/HTTP |<-------------->|SMTP/HTTP |C/R +------+ |Client|<-->| | | |<-->|Client| |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP Model for C/R Use Figure 1 There are three basic levels of C/R systems, each one building upon the prior: 1. Sender verification - Attempt to verify whether the original sender's address is valid. 2. Message verification - Attempts to verify whether the original sender actually originated the original message. 3. Turing test - Attempts to verify whether the original sender is human or a machine. Level 1 addresses an inherent loophole within SMTP that allows delivery of messages with invalid sender addresses. Level 2 addresses address spoofing sender email addresses with valid sender addresses. With C/R systems, the intent is that senders will only respond to C/R messages if they in fact sent a message to an actual recipient. Level 3 ensures that the sender is actually a human being and not an automated spam system. One of the problems with C/R systems is that they do not interoperate with each other using any standard methods. In many cases, C/R systems seek only sender and message verification (levels 1 and 2), and do not require a Turing test to verify that the sender is human. 1. MIME HEADERS. RFC 822/2822 headers are limited in length per line, thus limiting C/R systems that may require communicating to a large number of users and/or use extensions such as digital signatures and certificates. For this reason, MIME headers might be preferred. There are several ways MIME headers can be used to transmit CRI information: custom MIME types/headers or as part of the DSN protocol (RFC 3464). 1.1. MIME TYPE. RFC 3462 defines a MIME type called multipart/report to be used reporting of mail system administrative messages and as a general "family" or "container" type for electronic mail reports of any kind. This MIME type defines three parts for every multipart/report message as follows: 1. First part provides a human readable message which is intended for humans only. In the CRI model, this would possibly contain the original message along with the instructions to the user for non-CRI compatible systems. This instruction should include a brief explanation of C/R and a hyperlink or an instruction for an acknolwdgement or reply. 2. Second part provides a message to be used for CRI compatible machines with additional details for human beings. In the CRI model, this would contain the CRI MIME headers plus any additional information such as digital certificates, signatures, hashcash codes, etc. 3. Third part contains either the entire original message or portions of it such as headers. There are several issues when using the multipart/report MIME type. First, not all email systems and clients handle this type. Second, it is intended for one way communications such as delivery failure notifications by the receiver's SMTP server and not necessarily intended for CRI. Third, if two C/R systems are communicating in regards to multiple users and messages, more than one machine readable part might be needed. Another alternative would be defining a custom MIME type such as message/cri or multipart/cri patterned after this MIME type which would provide the same three parts as the multipart/report type. OR we might extend the MIME type of multipart/report to include CRI. In either case, this MIME type would contain the following: 1. A human readable body with C/R instructions. 2. A machine-readable body intended for machines (MIME type of message/cri). 3. A third optional body containing the original message (either message/rfc822 or text/rfc822) or possibly an MD5 or checksum of the message. 1.2. USING DSNs FOR CRI. The Delivery Status Notification (DSN) format is defined RFC 3464 as an extension of MIME type multipart/report. It is intended to notify the sender of a message of any of several conditions: failed delivery, delayed delivery, successful delivery, or the gatewaying of a message into an environment that may not support DSNs. In our case, C/R falls under delayed delivery. However, one major issue that has been raised with using DSNs, is that they are intended for one-way notification and do no anticipate a response unlike C/R systems. Also, current systems often handle DSNs in a specific way and using CRI inside DSNs might break those systems. 1.2.1. OVERVIEW OF DSN. RFC 3464 defines a MIME type of message/delivery-status which is used for the second machine readable part of multipart/report. It defines the following helper DSN headers that are included in DSN: - Original-Envelope-Id: identifies the original SMTP transaction - Reporting-MTA: the MTA that is reporting the failure, not necessarily the MTA that is delivering it - DSN-Gateway: names of the gateway or MTA that translated the DSN to Internet format - Received-From-MTA: MTA from the message was received (for SMTP the domain used in HELO or EHLO command) and MTA type (currently only one MTA type defined DNS for Internet) - Arrival-Date: when the message arrived Additionally the following headers are used for each recipient of the message: - Original-Recipient: whom the original message was addressed to and the address type (rfc822 for Internet) - Final-Recipient: final address after forwarding - Action: indicates the action taken on this message, may be set to failed, delayed, delivered, etc. - Status: indicates delivery status (defined in RFC 3463) - Final-Log-ID, Diagnostic-Code and Remote-MTA: additional information which is optional - Last-Attempt-Date and Will-Retry-Until: last attempt for delivery and how long will retry till Minimal conformance with the DSN RFC requires Reporting-MTA, Final-Recipient, Action and Status fields. Additionally, section 2.4 of the RFC, allows for extension fields. 1.2.2. USE OF DSN FOR CRI. To encapsulate the CRI protocol in DSNs, the following approach can be taken: 1. Final-Recipient: would indicate the recipient's address. 2. Reporting-MTA: would be the C/R system of the recipient. 3. Action: field would be set to "delayed" while waiting for response, or "failed" when the wait period expires or the response notifies the C/R system that the message was not sent by the sender (level2), and "delivered" after receiving a response and successfully delivering the message. Only the "delayed" value would be required, the other two would be optional in order to reduce network traffic. 4. Status: status codes would be used as defined in RFC 3463. - 4.XXX.XXX series status codes indicating temporary failure would be used while waiting for the message - 2.XXX.XXX series status codes indicating success would be used when the message is delivered - 5.XXX.XXX series status codes indicating permanent failure would be used when the message is rejected or expired. The actual codes used might be - 4.7.1: Delivery not authorized, message refused. - 4.1.0: Other address status while waiting. - 2.1.5: Destination mailbox address valid. - 5.7.1: Delivery not authorized, message refused might be used. Additonal codes may be established in accordance with RFC 3463. Additional fields that may be used: 1. Last-Attempt-Date and Will-Retry-Until: indicate how long the C/R system will hold the message 2. Original-Envelope-Id, Received-From-MTA, and Arrival-Date: provide information on the original MTA that sent the message. This encapsulation routine described herein is used to encapsulate the CRI message. The actual CRI information is handled using the MIME headers defined in the next section. We may also pass CRI information via custom diagnostic types. Additionally, RFC 3461 defines an ESMTP extension for DSN which may be used as well. NOTE: Please note that passing back the Final-Recipient might be a problem since it allows the sender to verify the validity of the receiver. 1.3. MIME HEADERS FOR CRI. This section will define various MIME headers that are used for CRI. We need to pass the following information: - Sender's email address - Receiver's email address - Type of C/R message: challenge, response or informational - C/R level desired: 1-sender, 2-message, or 3-turing test - Challenge and response tokens - Identification of the C/R systems - How much time does the sender have to respond to the challenge - If responded, how long the address will stay in the whitelist until challenged again - Extensions The following headers are defined global for the entire C/R message: 1. CRI-Recipient-Agent: identifies the receiver's C/R system 2. CRI-Reply-Until: how much time is given for response reply 3. CRI-Whitelist-Period: how much time will the sender stay on the whitelist for 4. CRI-Recipient-Accept-Token: lists types of tokens the recipient will accept 5. CRI-Sender-Exempt: identifies that the sender desires to not receive a CRI message. i.e. mailing list The following headers are specific per each sender: 1. CRI-Sender: the orignal sender of the original message, usually the RFC 822/2822 sender 2. CRI-Recipient: the original receiver of the message, usually the RFC 822/2822 receiver 3. CRI-Verification-Level: at the least must be "1" - sender, maybe also "2" - message, and "3" - human 4. CRI-Message-Type: maybe either "challenge", "response" or "informational" 5. CRI-Sender-Agent: identifies the sender's C/R system 6. CRI-Recipient-Accept-Type: lists types of tokens the recipient will accept 7. CRI-Token-Type: consists of token-type and subtype, token-type is defined as "challenge" or "response"; subtypes are defined as needed 8. CRI-Token: - consists of the actual CRI token 9. CRI-Sender-Accept-Token: - lists types of token types the sender will accept 2. SMTP AND CRI. Another possibility for the CRI protocol is to allow for the exchange of CRI data to take place via SMTP. Since DSN ESMTP extension does not allow for extensions and only allows for requesting a DSN, it would not be used here. 2.1. CRI ESMTP EXTENSION. SMTP Extensions are defined in RFC 1869 and RFC 2821. The following service extension is hereby defined: 1) The name of the CRI ESMTP extension is "CRI". 2) The EHLO keyword value associated with this extension is "CRI". 3) Several optional parameters are allows with this EHLO keyword value. The first parameter is the verification level supported and is defined as follows: cri-level = SENDER / MESSAGE / HUMAN SP If no verification level is specified, then SENDER level is assumed. This is followed by a list of CRI extensions supported by the receiver's system separated by spaces as follows: cri-ext = EXT SP EXT SP EXT SP .... EXT = [ALPHA] If extensions are specified, then the level must be specified as well. Examples of extensions are digital signatures, hashcash, etc. An IANA registry will be established for registering CRI extensions. The CRI extension list is limited in line length in accordance with existing guidelines. 4) There are not additional verbs associated with this extension 5) New parameters are defined for the RCPT-TO and VRFY commands: CRI-TOKEN-TYPE=type; REQUIRED CRI-TOKEN=token; OPTIONAL For the DATA command: CRI-TOKEN-TYPE=type; OPTIONAL The CRI Token Type defines the token type, and the CRI token parameter carries the actual token. An IANA registry will be e stablished for registering CRI extensions. Each token type will define whether it is carried in the CRI-TOKEN field or in the message body. One token is defined: Token Type: plain Token field used: YES 6) The following behavior changes are being made: a. For the RCPT TO command, a 452 error code is defined which indicates that a challenge is being issued. b. For the VRFY command, a requirement is added that it is issued after the MAIL FROM command when used in CRI. c. For the VRFY command, after challenge is issued and successfully accepted, the QUIT command is used to end the SMTP session. d. For the VRFY command, the DATA command is used for transfer of very large tokens inside the message body. 2.1.1. IANA CONSIDERATIONS. Two IANA registries will be established, one for registered CRI extensions and the second for registering CRI token types. 2.1.2. SAMPLES. Sample CRI ESMTP conversation from sender to the recipient with both systems supporting CRI: S: C: S: 220 mail.ietf.org -- Welcome C: EHLO solidmatrix.com S: 250-mail.ietf.org S: 250-HELP S: 250 CRI SENDER PKI HASHCASH C: MAIL FROM: S: 250 OK. C: RCPT TO: S: 250 asrg(_at_)irtf(_dot_)org OK C: RCPT TO: S: 452 Unverified sender, issuing challenge, retry with CRI token ..... .....recipient connects to sender's MTA and issues challenge ..... S: RCPT TO: CRI-TOKEN-TYPE=plain; CRI-TOKEN=token; C: 250 Sender approved for C: DATA S: 354 Send message, ending in CRLF.CRLF. ... C: . S: 250 OK C: QUIT S: 221 Goodbye Recipient's MTA issuing a challenge with both systems supporting CRI: S: C: S: 220 mail.solidmatrix.com -- Welcome C: EHLO mail.irtf.org S: 250-mail.solidmatrix.com S: 250-HELP S: 250 CRI SENDER PKI HASHCASH C: MAIL FROM: S: 250 OK. C: VRFY: CRI-TOKEN-TYPE=plain; CRI-TOKEN: token; S: 250 CRI challenge accepted for OK C: VRFY: CRI-TOKEN-TYPE=plain; CRI-TOKEN: token; S: 550 Mailbox not found C: QUIT S: 221 Goodbye Recipient's MTA issuing a challenge with both systems supporting CRI and token carried in message body: S: C: S: 220 mail.solidmatrix.com -- Welcome C: EHLO mail.irtf.org S: 250-mail.solidmatrix.com S: 250-HELP S: 250 CRI SENDER PKI HASHCASH C: MAIL FROM: S: 250 OK. C: VRFY: CRI-TOKEN-TYPE=big; S: 250 CRI challenge accepted for OK C: DATA CRI-TOKEN-TYPE=big; S: Send data followed by ô.ö C: ... data ... S: 250 Challenge token accepted for C: QUIT S: 221 Goodbye Recipient's MTA issuing a challenge with sender's system not supporting CRI: S: C: S: 220 mail.solidmatrix.com -- Welcome C: EHLO mail.irtf.org S: 250-mail.solidmatrix.com S: 250-HELP C: MAIL FROM: S: 250 OK. C: RCPT TO: S: 250 OK C: DATA S: 354 Send mail data followed by CRLF C: ...sends email challenge message ... S: 250 Message accepted for delivery C: QUIT S: 221 Goodbye 4. Interoperability Considerations. 4.1. Loop Avoidance. CRI systems should not issue challenge messages when C/R headers are present. CRI systems should not challenge messages with CRI-Message-Type: response or challenge. In order to maintain compatibility with non-CRI compatible interworking systems, it is recommended that each CRI system miantain stateful monitoring of challenge messages sent to original senders. For CRI systems that issue challenge messages,it is also recommended that each CRI system use a local systemwide user, such as cri(_at_)foo(_dot_)com, for issuing challenges rather than preserving the original sender's email address as the sender of the challenge message. Doing so, allows for loop avoidance to be handled using double-bounce methods where appropriate. For client-based CRI software, loop avoidance may be handled using additonal stateful means of tracking outgoing mail. 4.2. Mailing Lists. Mailing lists may include CRI-Sender-Exempt headers to indicate that challenge messages should not be posted to the mailing list. Most mailing lists supply various headers to indicate that the messages has been sent from a mailing list. Such mailing list detection methods should result in suppressed challenge messages. 5. Additional Information. 5.1. Security Considerations. CRI is not an authentication method for email delivery or security protocol. 5.2. Privacy Considerations. Since C/R systems keep track of the senders email addresses, this raises privacy issues. 5.3. References. [RFC-821] Postel, J.; "Simple Mail Transfer Protocol"; STD 10, RFC 821; ISI/USC; August 1982 [RFC-822] Crocker, D.; "Standard For The Format Of ARPA Internet Text Messages"; STD 11, RFC 822; University of Delaware.; August, 1982 [RFC-934] Rose, M., and E. Stefferud; "Proposed Standard for Message Encapsulation"; RFC 934; Delaware and NMA; January 1985. [RFC-1049] Sirbu, M.; "Content-Type Header Field for Internet Messages"; STD 11, RFC 1049; CMU; March 1988. [RFC-1344] Borenstein, N.; "Implications of MIME for Internet Mail Gateways"; RFC 1344; Bellcore; June 1992. [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and Crocker, D.; "SMTP Service Extensions"; RFC 1869; MCI, Innosoft, Dover Beach Consulting, Network Management Associates, Brandenburg Consulting; November 1995 [RFC-2045] Borenstein, N., and Freed, N.; "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"; RFC 1341; Innosoft, First Virtual; Nov 1996. [RFC-2821] Klensin, J.; "Simple Mail Transfer Protocol"; RFC 2821; AT&T Laboratories; April, 2001. [RFC-2822] Resnick, P.; "Internet Message Format"; RFC 2822; QUALCOMM Incorporated; April 2001. [RFC-3461] Moore, K.; "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)"; University of Tennessee; January 2003 [RFC-3462] Vaudreuil, G; "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages"; Lucent Technologies; January 2003 [RFC-3463] Vaudreuil, G; "Enhanced Mail System Status Codes"; Lucent Technologies; January 2003 [RFC-3464] Moore, K. and Vaudreuil, G; "An Extensible Message Format for Delivery Status Notifications"; University of Tennessee, Lucent Technologies; January 2003 5.4. Acknowledgements. A lot of information in this note has been based on the discussions on the Anti-Spam Research Group (ASRG) mailing list. The authors would like to acknowledge the contributions of all members of the group. 5.5. Author(s) Addresses. Eric Dean Crystal Ball Inc. eric(_at_)crystalballinc(_dot_)com Yakov Shafranovich SolidMatrix Technologies, Inc. research(_at_)solidmatrix(_dot_)com www.shaftek.org 5.6. Full Copyright Statement. Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 5.7. Document History. v0.0.3 / YS / 07-23-2003 / Some editing and cleanup