[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
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]