Individual submission M. Kucherawy Internet-Draft Sendmail, Inc. Intended status: Standards Track April 17, 2009 Expires: October 19, 2009 IMAP Annotation for Indicating Message Authentication Status draft-kucherawy-sender-auth-imap-01 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), 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 October 19, 2009. Copyright Notice Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Kucherawy Expires October 19, 2009 [Page 1] Internet-Draft Authentication-Results IMAP Annotation April 2009 Abstract This memo defines an application of the IMAP (Internet Message Access Protocol) Annotations facility whereby a server can store and retrieve meta-data about a message relating to message authentication tests performed on the message and the corresponding results. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2. SMTP Server or MDA Implementation . . . . . . . . . . . . . . 6 3. IMAP Server Implementation . . . . . . . . . . . . . . . . . . 7 4. IMAP Client Implementation . . . . . . . . . . . . . . . . . . 8 5. IMAP Annotation Format . . . . . . . . . . . . . . . . . . . . 9 6. Conformance and Usage Requirements . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. Annotation Registration . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Misleading Results . . . . . . . . . . . . . . . . . . . . 12 8.2. Attacks Against Authentication Methods . . . . . . . . . . 12 8.3. Intentionally Malformed Data . . . . . . . . . . . . . . . 12 8.4. Compromised Internal Hosts . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Kucherawy Expires October 19, 2009 [Page 2] Internet-Draft Authentication-Results IMAP Annotation April 2009 1. Introduction Electronic mail, though ubiquitous and highly useful, is also prone to increasing abuse by parties that choose to exploit its lenient design for nefarious purposes such as "spam" and "phishing." Abuse of this leniency has become so widespread as to become an economic problem. Several nascent methods of mitigating this problem such as [SPF] and [DKIM] appear to make strides in this direction but are themselves not sufficient. In many cases the results of attempts to authenticate messages must be relayed to the user for final disposition. This memo defines a new annotation for [IMAP] using the IANA Considerations found in [ANNOTATE] which is used to store and relay message authentication results from upstream (e.g. "border") mail servers to internal mail servers which ultimately do message delivery. This information can then be used by delivery agents or even the users themselves when determining whether or not the content of such messages is trustworthy. The message header defined in [AUTH-RESULTS] serves a similar purpose and is simple to implement but has some moderate security implications, so a more secure channel is required. In particular, the header block of a message is generally unauthenticated and is also typically relayed intact, meaning it is an obvious vector for data forgery. Thus, trusting part of a message header to be secure is a difficult problem. This method and that of [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] establishes a much better trust boundary and removes that obvious attack vector. [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail authentication methods in common use. As various methods emerge, it is necessary to prepare for their appearance and encourage convergence in the area of interfacing these filters to electroic mail servers. 1.1. Purpose The IMAP annotation defined in this memo is expected to serve several purposes: 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the results of various message authentication checks being applied; 2. Provide a common location for the presentation of this data; Kucherawy Expires October 19, 2009 [Page 3] Internet-Draft Authentication-Results IMAP Annotation April 2009 3. Create an extensible framework for specifying results from new authentication methods as such emerge; 4. Convey the results of message authentication tests to later filtering agents within the same "trust domain", as such agents might apply more or less stringent checks based on message authentication results; 5. Do all of this in a way not prone to forgery or misinterpretation. 1.2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or its extensions to format and transport a message. An "MDA" is a Mail Delivery Agent (also sometimes referred to as "LDA" or Local Delivery Agent), or any agent which has access to receive a message from an MTA and write it into the receiving user's "inbox". An "MUA" is a Mail User Agent, or any software which retrieves and displays messages on behalf of a user. A "border MTA" is an MTA which acts as a gateway between the general Internet and the users within an organizational boundary. An "intermediate MTA" is an MTA which handles messages after a border MTAs and before a delivery MTA. Kucherawy Expires October 19, 2009 [Page 4] Internet-Draft Authentication-Results IMAP Annotation April 2009 +-----+ +-----+ +------------+ | MUA |-->| MSA |-->| Border MTA | +-----+ +-----+ +------------+ | | V +----------+ | Internet | +----------+ | | V +-----+ +-----+ +------------------+ +------------+ | MUA |<==| MDA |<==| Intermediate MTA |<--| Border MTA | +-----+ +-----+ +------------------+ +------------+ Generally it is assumed that the work of applying message authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. However, there are some sites at which the entire mail infrastructure consists of a single host. In such cases, such terms as "border MTA" and "delivery MTA" may well apply to the same machine or even the very same agent. It is also possible that message authentication could take place on an intermediate MTA. Although this document doesn't specifically include such cases, they are not meant to be excluded from this specification. See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail system architecture. In the figure shown above, the double-lines indicate the portions of the transport of a message where this protocol would be applied. Note also that the Local Mail Transfer Protocol [LMTP] could benefit from a similar extension. Kucherawy Expires October 19, 2009 [Page 5] Internet-Draft Authentication-Results IMAP Annotation April 2009 2. SMTP Server or MDA Implementation Within the message flow depicted in Section 1.2, message authentication methods can be applied in a variety of places, most commonly the Border MTA, an Intermediate MTA, or the MDA. Where the MDA does the message authentication, its results can be attached, using the annotation defined defined by this memo, to the message for later retrieval by an [IMAP] client. Where the message authentication takes place at one of the earlier MTAs, some method of carrying those results along each hop until mailbox injection at the MDA must be applied. One such proposal can be found in [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] and another in [AUTH-RESULTS], but no specific method is required by this memo. If [AUTH-RESULTS] is used, the header field MAY be deleted on delivery as the data relayed there will be reported via the annotation defined by this memo. An MDA MAY choose to file messages other than in a recipient's message inbox, or discard it altogether, when certain criteria, such as failed authentications, are met. Kucherawy Expires October 19, 2009 [Page 6] Internet-Draft Authentication-Results IMAP Annotation April 2009 3. IMAP Server Implementation An [IMAP] server conforming to this specification MUST implement [ANNOTATE] and MUST report these annotations to the client if they are attached to the message(s) being requested. The name and format of the annotation can be found in Section 5 and Section 7. The [IMAP] server itself may do the message authentication prior to serving the message to the client, or the MDA or one of the upstream MTAs may do so. In the former case, the authentication is being done after delivery and the results could be different (e.g. signatures could expire, sender policies could change, etc.). It is important to be aware that the results of authentication methods evaluated by this server could be notably different from those results returned during the original transit of the message. At the time this memo was prepared, all known methods were intended for evaluation at time of delivery, not at the time the message is served to the end user. Kucherawy Expires October 19, 2009 [Page 7] Internet-Draft Authentication-Results IMAP Annotation April 2009 4. IMAP Client Implementation An [IMAP] client conforming to this specification will request the "authresults" annotation when retrieving a message, and render those results to users in some meaningful way. The name and format of the annotation can be found in Section 5 and Section 7. Kucherawy Expires October 19, 2009 [Page 8] Internet-Draft Authentication-Results IMAP Annotation April 2009 5. IMAP Annotation Format The content of the annotation, as defined using [ABNF], MUST be formatted as follows: authres = version ":" authserv-id ":" 1*resinfo ; relays a single unit of authentication results ; information The "version", "authserv-id" and "resinfo" are as defined in Section 2.2 of [AUTH-RESULTS]. The "version" refers to the version of this memo, not the version of [AUTH-RESULTS] referenced here. Kucherawy Expires October 19, 2009 [Page 9] Internet-Draft Authentication-Results IMAP Annotation April 2009 6. Conformance and Usage Requirements Section 2, Section 3 and Section 4 specify the only requirements for conformance to this specification. Kucherawy Expires October 19, 2009 [Page 10] Internet-Draft Authentication-Results IMAP Annotation April 2009 7. IANA Considerations 7.1. Annotation Registration Per [IANA-CONSIDERATIONS], IANA is requested to register this new IMAP annotation as per [ANNOTATE]. The template to be registered is as follows: To: iana@iana.org Subject: IMAP Annotate Registration Please register the following IMAP Annotate item: [X] Entry [ ] Attribute Name: /authresults Description: Results of message authentication tests, as specified in [AUTH-RESULTS] Content-Type: text-plain; charset=us-ascii Contact person: Murray S. Kucherawy Contact email: msk@sendmail.com Kucherawy Expires October 19, 2009 [Page 11] Internet-Draft Authentication-Results IMAP Annotation April 2009 8. Security Considerations The following security considerations apply when applying or processing the authresults IMAP annotation: 8.1. Misleading Results Until some form of service for querying the reputation of a sending agent is widely deployed, the existence of this annotation indicating a "pass" does not render the message trustworthy. It is possible for an arriving piece of spam or other undesirable mail to pass checks by several of the methods enumerated above (e.g. a piece of spam signed using [DKIM] by the originator of the spam, which might be a spammer or a compromised system). 8.2. Attacks Against Authentication Methods If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this annotation can be misleading. It follows that any attack against the authentication methods supported by this document (and later amendments to it) is also a security consideration here. 8.3. Intentionally Malformed Data It is possible for an attacker to include data in a message which is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in parsing code. Implementors must thoroughly verify all such data received from [IMAP] servers and be robust against intentionally as well as unintentionally malformed data. 8.4. Compromised Internal Hosts An internal MUA or MTA which has been compromised could generate mail with forged data, eventually generating an annotation which endorses it. Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this proposal, this risk can be mitigated by arranging that internal MDAs not attach this data if it claims to have been added by a trusted border MTA (as described above) yet the [SMTP] connection is not coming from an internal machine known to be running an authorized MTA. However, in such a configuration, legitimate MDAs will have to add this data when legitimate internal-only messages are generated. Kucherawy Expires October 19, 2009 [Page 12] Internet-Draft Authentication-Results IMAP Annotation April 2009 9. References 9.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC 5257, June 2008. [AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. 9.2. Informative References [AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4817, May 2007. [DOMAINKEYS] Delany, M., "Domain-based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [I-D.DRAFT-CROCKER-EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", I-D draft-crocker-email-arch, May 2007. [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] Kucherawy, M., "SMTP Service Extension for Indicating Message Authentication Status", I-D draft-kucherawy-sender-auth-esmtp-01, September 2008. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. [LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033, October 1996. Kucherawy Expires October 19, 2009 [Page 13] Internet-Draft Authentication-Results IMAP Annotation April 2009 [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. Kucherawy Expires October 19, 2009 [Page 14] Internet-Draft Authentication-Results IMAP Annotation April 2009 Appendix A. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this proposal: (add names here) Kucherawy Expires October 19, 2009 [Page 15] Internet-Draft Authentication-Results IMAP Annotation April 2009 Appendix B. Examples This section presents some examples of the use of this IMAP annotation. (add examples here) Kucherawy Expires October 19, 2009 [Page 16] Internet-Draft Authentication-Results IMAP Annotation April 2009 Appendix C. Public Discussion [REMOVE BEFORE PUBLICATION] Public discussion of this proposed specification is handled via the mail-vet-discuss@mipassoc.org mailing list. The list is open. Access to subscription forms and to list archives can be found at http://mipassoc.org/mailman/listinfo/mail-vet-discuss. Kucherawy Expires October 19, 2009 [Page 17] Internet-Draft Authentication-Results IMAP Annotation April 2009 Author's Address Murray S. Kucherawy Sendmail, Inc. 6475 Christie Ave., Suite 350 Emeryville, CA 94608 US Phone: +1 510 594 5400 Email: msk+ietf@sendmail.com Kucherawy Expires October 19, 2009 [Page 18]