|Network Working Group||D. Crocker|
|Internet Draft||Brandenburg InternetWorking|
|Intended status: Experimental||M. Kucherawy|
|Expires: October 27, 2011||Cloudmark|
|April 25, 2011|
MIME Content Authentication using DOSETA (MIMEAUTH)
MIME is a method of packaging and labeling aggregations of data; it is used both for email and the Web. Many usage scenarios would benefit by having an objective method of assessing the validity of MIME data, based on an authenticated identity. MIMEAUTH leverages technology developed for DKIM to provide such a method. Its use can be extended to cover specific header-fields of a containing email message or World Wide Web HTTP content. Existing authentication mechanisms have achieved only limited success due to challenges with administration and use. MIMEAUTH has very low administration and use overhead, through self-certifying keys in the DNS and a labeling method that can be transparent to end-users. For relayed and mediated sequences, MIMEAUTH can be implemented within a service and therefore can be transparent to end-system software.
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 in October 27, 2011.
Copyright © 2011 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 (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 BSD License.
MIME is a core data-packaging mechanism for Internet applications; it is used both for email and the Web. Many usage scenarios would benefit by having an objective method of assessing the validity of MIME data, based on an authenticated identity. Existing authentication mechanisms have achieved only limited use. MIMEAUTH is based on DOSETA [I-D.DOSETA] to provide such a method. Its use can be extended to cover specific header-fields of a containing email message or World Wide Web HTTP content. MIMEAUTH has very low administration and use overhead, through self-certifying keys in the DNS and a labeling method that can be transparent to end-users. For relayed and mediated sequences, MIMEAUTH can be implemented within a service and therefore can be transparent to end-system software.
The approach taken by MIMEAUTH differs from previous approaches to message authentication, such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847] and OpenPGP [RFC4880], in that:
MIMEAUTH separates specification of the identity of the MIMEAUTH signer from the purported author of the content. Verifiers can use the signing information to decide how they want to process the data. In particular, the authentication identity specified by a MIMEAUTH signature is not required to match any other identifier the content or the header. However when the identity does match other, specific identities, specific semantics are assigned.
This specification incorporates the terminology defined in [I-D.DOSETA].
Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
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].
Still to be resolved:
MIMEAUTH uses the DOSETA "Generic Header/Content Signing Service Template" [I-D.DOSETA] as its base.
The DOSETA Template specifies features labeled TEMPLATE that need to be tailored to a specific signing service. For MIMEAUTH, the tailored features are:
This section contains specifications that are added to the basic DOSETA H/C Signing Template.
These are MIMEAUTH-specific tags:
sig-i-tag = %x69 [FWS] "=" [FWS] [ local-part ] "@" domain-name
sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy *( "|" [FWS] sig-z-tag-copy ) sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value
Some header fields have semantics that are relevant to end users and often are presented to them. If MIMEAUTH is used to sign an email message, it is useful to cover such header fields, in addition to the MIME content. This section provides a generic recommendation intended to apply to the general case of signing a message; specific senders might wish to modify these guidelines as required by their unique situations. Verifiers MUST be capable of verifying signatures even if one or more of the recommended header fields is not signed or if one or more of the dis-recommended header fields is signed. Note that verifiers do have the option of ignoring signatures that do not cover a sufficient portion of the header or content, just as they might ignore signatures from an identity they do not trust.
The signer is encouraged to consider carefully which fields are important to the interpretation of the content and which ones are not. As an example, note what fields are typically displayed to recipients. The following header fields are listed as a default set and SHOULD be included in the signature, if they are present in the message being signed:
The following header fields SHOULD NOT be included in the signature:
Optional header fields (those not mentioned above) normally SHOULD NOT be included in the signature, due to the possibility of having additional header fields, of the same name, that are added or reordered legitimately, prior to verification. There are likely to be reasonable exceptions to this rule, given the wide variety of application-specific header fields that might be applied to a message, some of which are unlikely to be duplicated, modified, or reordered.
MIMEAUTH uses registries assigned to DOSETA [I-D.DOSETA]. This section specifies additions to these registries.
These values are added to the registry that is now defined in [I-D.DOSETA]:
|i||(this document, Section 3.1)|
|z||(this document, Section 3.1)|
IANA has added MIME Content‑Authentication: to the "Permanent Message Header Fields" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference.
|[I-D.DOSETA]||Crocker, D., Ed. and M. Kucherawy, Ed., “DomainKeys Security Tagging (DOSETA)”, I-D draft-ietf-crocker-doseta-base, 2011.|
|[RFC2045]||Freed, N. and N.S. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.|
|[RFC2047]||Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Content”, RFC 2047, November 1996.|
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.|
|[RFC5234]||Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 4234, January 2008.|
|[RFC5890]||Klensin, J., “Internationalizing Domain Names in Applications (IDNA): Definitions and Document Framework”, RFC 5890, August 2010.|
|[RFC1847]||Galvin, J., Murphy, S., Crocker, S., and N. Freed, “Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted”, RFC 1847, October 1995.|
|[RFC3864]||Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.|
|[RFC4871]||Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures”, RFC 4871, May 2007.|
|[RFC4880]||Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, “OpenPGP Message Format”, RFC 4880, November 2007.|