Draft-irtf-asrg-cri-**.txt Authors: Eric Dean et.al Challenge Response System Interworking Model Abstract RFC821 was designed simply deliver email messages without authenticating sources or senders of email messages. In an effort to reduce sources of spam on the Internet, Challenge Response ("C/R") email systems provide a method for validting message origination for a designated recipient. This document defines an interworking method for Challenge Response "C/R" systems by proposing the use of MIME experimental content-type values for C/R control at either the server or client system level. For compatibility purposes with non-C/R interworking systems this document addresses a set of guidelines for user intervention with existing mail systems and clients. Introduction Challenge Response systems attempt to authenticate senders and determine if each sender originated a message to a designated recipient. This document identifies MIME experimental content-type values for allowing automated C/R system interworking. In addition, this document provides a loose guideline for user intervention C/R interworking. C/R systems try to determine whether a sender email address is valid and whether that sender originally sent a message to a designated recipient. A C/R email system or client software supporting the C/R MIME experimental content-type values would optionally automatically respond to C/R challenge messages using challenge response methods defined herein. If C/R messages are not supported by the original sender's system, then challenge messages would be delivered to the user for manual action. This document identifies C/R MIME experimental content-type values for automated C/R system interworking and provides guidelines for a user manual intervention C/R method. Purposes -Provides a standard method for automatically handling challenge messages and responses -Provide loop avoidance methods -Provides guidelines for supporting incompatible software systems -Provides a level of security to prevent brute force attacks -Not an authentication method for email delivery or security protocol Challenge Response Model The C/R interworking model is based upon a method whereby a sender sends a message to a recipient's SMTP server. The recipient's SMTP server either produces a challenge message or forwards the original message to a recipient's client software that produces a challenge message. The resultant challenge message is sent to the original sender. If the sender's C/R SMTP server supports C/R 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. If the original sender's client system supports C/R methods, then the original sender's client software may automatically respond to the challenge message. In the event that neither the server nor client software are C/R compatible, the C/R message should contain clear instructions to the original sender instructing how to appropriately respond to the challenge request. ------------------------------------------------------------- ---------------------------------------- | | | v v +----------+ +----------+ +------+ | | | | +------+ | User |<-->| | C/R | |<-->| User | +------+ | Sender- |Commands/Replies| Receiver-| +------+ +------+ |SMTP/HTTP |<-------------->|SMTP/HTTP |C/R +------+ |Client|<-->| | | |<-->|Client| |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP Model for C/R Use Figure 1 ------------------------------------------------------------- Challenge Message The Challenge Message contains MIME experimental content-type values defined herein. The Challenge Message will consist of a single MIME header containing two values separated by a comma. The first value will identify the original recipient and the second value will identify the response string. The following MIME experimental content-type values are required for C/R interworking: X-CM:'Recipient','Response String' The X-CM values are defined as follows: Recipient: Identifies the original recipient of the message that is issuing the challenge message. Response String: Identifies an authentication string unique to that sender-recipient pair that ensures the challenge response is from the original sender. If an original sender sends to multiple recipients on the same C/R server, then the server can issue the challenge message with multiple listed X-CM header. Therefore, multiple X-CM headers can be included in a single challenge message. The sender of the C/R message must be a valid RFC 2821 sender address. In the event that a server-based mail system is performing C/R, then the challenge should be sent with an email address local to that server. If multiple servers are delivering email, then the challenge message can be forwarded to peer servers if other synchronization mechanisms are not in place. If client software is performing the C/R, then the challenge message should be sent with a sender email address local to that email client. If neither the original sender's server nor client software support C/R interoperability, then the challenge message should contain as a message that clearly instructs the user how to perform a manual challenge response. Typically, clicking on an embedded HREF or a simple reply-to is sufficient for the original sender to manually reply. Challenge Response For C/R compatible systems that support the MIME experimental content-type values, the challenge response mechanism may be automated. The following MIME experimental content-type values are required for C/R interoperability: X-CR:'Response' The X-CR response values are defined as V='Response String' This C/R response value is sent to the originating C/R system to validate ("V") that the original sender had sent a message to the X-CM Recipient. The response string that was originally supplied with the challenge message is returned prepended by a code, "V=", to signify that the original sender had sent a message to the designated recipient. I='Response String' This C/R response value is sent to the originating C/R system to invalidate ("I") that the original sender had not sent a message to the X-CM Recipient. The response string that was originally supplied with the challenge message is returned prepended by a code, "I=", to signify that the original sender had not sent a message to the designated recipient. Multiple X-CM and X-CR headers can be sent in a single message. Mail Lists Challenge messages should not be sent to mailing lists however it is anticipated that C/R would be an ideal tool for mailing list subscription. Proper identification and handling of user subscribed mailing lists is essential for C/R interworking. While no standard exists for identifying mailing lists, many common methods include use a variety of headers and doing so remains implementation specific. Loop avoidance C/R systems should not issue challenge messages when C/R headers are present. In order to maintain compatibility with non-C/R interworking systems, it is recommended that each C/R system remain stateful in monitoring challenge message sent to original senders. For C/R systems that issue challenge messages, it is also recommended that each C/R system use a local user 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 standard double-bounce methods where appropriate. For client-based C/R software, loop avoidance may be handled using additonal stateful means of tracking outgoing mail. References [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-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-2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1341, Innosoft, First Virtual, Nov 1996. Contact