Network Working Group J. W. Nicolls (NSA) Internet Draft R. Housley (SPYRUS) expires in six months May 1996 MIME with the Message Security Protocol Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This is the second draft of the MIME with the Message Security Protocol (MSP) specification. This document defines the conventions for using MIME and MSP together. For the most part, this specification is not controversial. However, there is some debate about signed only MSP contents. This draft documents the consensus from the MSP BOF held at the March 1996 IETF meeting. One open question was not discussed at the March 1996 IETF, and inputs are desired on this topic. Should the MIME format indicate whether a management message is being carried within the multipart/signed or multipart/encrypted content? CRL distribution is one example of such a management message. Table Of Contents 1. Introduction Nicolls & Housley [Page 1] INTERNET DRAFT May 1996 2. Content-Type application/msp 3. MSP Control Information Content 3.1. Protected MIME Message Format 3.2. Required Protected MIME Message Header Fields 3.3. Optional Protected MIME Message Header Fields 3.4. Optional Protection of Message Header Information 4. Use of Security Subtypes of Multipart 4.1. Use of Multipart/Signed 4.2. Use of Multipart/Encrypted 5. Forwarding MIME with MSP Messages 6. MIME with MSP Signed Receipt Message Format 7. Example Protected Messages 8. Summary 9. References 10. Security Considerations 11. Author Addresses 1 Introduction Message Security Protocol (MSP) is a electronic messaging security protocol which operates between the originator and recipients of messages. As an end-user-to-end-user protocol which does not involve the intermediate message transfer system, MSP provides writer-to- reader security. The security services provided by this protocol include: confidentiality (symmetric encryption), data origin authentication (digital signature and/or symmetric key management), integrity (one-way hash), and access control (security labels), non- repudiation with proof of origin (digital signature), and non- repudiation with proof of delivery (signed receipt). The MSP is independent of the cryptographic algorithms used for encryption, key management, one-way hash, and digital signature. MSP operates by performing security operations on messages at the originator and recipient mail applications. These functions are performed in an independent but consistent fashion at each end of the message exchange based on user security information. This security information includes the user's identity, authorizations, and cryptographic material. MSP processing includes both per-message operations and information and per-recipient operations and information. These operations involve the parsing and generation of elements of the MSP heading based on the services requested by the originator, and the encryption, when requested, of the message content. This document utilizes the security services framework defined in RFC 1847 which defines security multipart formats for MIME. Specific Nicolls & Housley [Page 2] INTERNET DRAFT May 1996 security multipart values for MSP revision 4.0 are defined in this document. This document pertains only to the encapsulation of MSP protected MIME messages within the MIME environment. No changes to the syntax or semantics for objects defined in the primary specifications are intended. 2 Content-Type application/msp This section defines the format of data used in application/msp. For the MIME with MSP body, the "application" Content-Type value and the "msp" subtype value are used. The version number corresponds to the revision number for the MSP specification. This specification shall be used with MSP Revision 4.0 and later. application-type := "application" "/" application-subtype application-subtype := "msp" protect-param version-param protect-param := ";" "protect" "=" security-applied ; all values are case-insensitive security-applied := "signed" / "signed&encrypted" / "encrypted" ; all values are case-insensitive version-param := ";" "version" "=" 1*DIGIT "." 1*DIGIT ; all values are case-insensitive ; for use with MSP Revision 4.0 and later 3 MSP Content The MSP content is an ASN.1 encoded structure as defined in SDN.701 which has been converted to ASCII as specified by the content transfer encoding field. << At some future date, SDN.701 be publlished as an RFC. >> 3.1 Protected MIME Message Format The MSP specification, SDN.701, does not specify a format for the content it protects. For MIME with MSP implementations, the content that is MSP protected must be a compliant MIME entity. The protected MIME entity must be in canonical format. This is necessary to ensure writer-to-reader interoperability when the protected MIME entity is received and processed on a different platform, with different local formatting conventions, than it was Nicolls & Housley [Page 3] INTERNET DRAFT May 1996 created. In general, the body part to be protected is prepared according to a local convention, is transformed into a MIME body part in canonical MIME format that includes an appropriate set of MIME headers, and is constrained to 7 bits. The '7 bit' constraint is necessary to ensure unaltered transfer over the standard Internet SMTP infrastructure. A common example of the need to convert to canonical is the differences in end of line delimiter format. Data of MIME type text/plain must have each end of line delimiter converted to . Another example is that local character sets must be converted to standard character sets. Note: Implementors are strongly urged to reference the latest MIME RFCs for complete canonical format details. 3.2 Required Protected MIME Message Header Fields The protected MIME entity may include a Content-Classification header field. This may be used to indicate in MIME the security classification of the MSP protected message. The security classification field can be set by the user to a security clearance value authorized in the user's certificate. The security classification field must represent the same hierarchical classification as the MSP security label. classification := "Content-Classification" ":" security- classification ; all values are case-insensitive security-classification := "unclassified" / "confidential" / "secret" / "top-secret" / "unclassified-but-sensitive" 3.3 Optional Protected MIME Message Header Fields Users may wish to add other optional fields for conveying information to the recipient (e.g., MSP privacy mark or trusted time from a hardware token). All fields must use appropriate MIME format. Examples: privacy-mark := "Content-Privacy-Mark" ":" token / quoted-string trusted-time := "Content-Trusted-Time" ":" gmt-date-time "Z" gmt-date-time := year ; month ; day ; hour; minutes; seconds year := 4*DIGIT month := 2*DIGIT Nicolls & Housley [Page 4] INTERNET DRAFT May 1996 day := 2*DIGIT hour := 2*DIGIT minutes := 2*DIGIT seconds := 2*DIGIT 3.4 Optional Protection of Message Header Information Users may wish to protect SMTP header information that is outside of the security multipart protection boundary. This can easily be accomplished by putting the From:, To:, Cc:, Subject:, or Date: header lines into a text/plain body part prior to the message text within the security multipart body part. 4. Use of Security Subtypes of Multipart 4.1 Use of Multipart/Signed The multipart/signed content type offers clear advantages over multipart/mixed and multipart/alternative. The protected body part is not obscured by the protection protocol which allows originators to send digitally signed messages to security unaware recipients without duplicating the message text outside of the encoded body part. The multipart/signed content type contains exactly two MIME body parts. The first body part is the body part which is digitally signed, including its MIME headers. The second body part contains the control information necessary to verify the digital signature. The first body part may contain any valid MIME content type, labeled accordingly. The second body part is labeled according to the value of the protocol parameter. The attribute token for the protocol parameter is "protocol". The value token is comprised of the type and sub-type tokens of the Content-Type: header from the second body part where the type and subtype tokens for MIME with MSP are defined as follows: parameter := "protocol" "=" value value := <"> type "/" subtype <"> type := "multipart" subtype := "msp" The attribute token for the micalg parameter is "micalg". The Nicolls & Housley [Page 5] INTERNET DRAFT May 1996 Message Integrity Check (MIC) is the name given to the quantity computed over the body part with a message digest or one-way hash function in support of the digital signature mechanism. Valid tokens are defined by the specification for the value of the protocol parameter. The micalg parameter value used for the Secure Hash Algorithm 1 (SHA-1) as specified in Federal Information Processing Standard 180- 1) is "sha-1". Of course, other MIC algorithms may be used as long as the micalg value must agree with the MSP Integrity Algorithm Identifier. parameter := "micalg" "=" value value:= "sha-1" The signature in a multipart/signed only applies to the material that is actually within the multipart/signed object. In particular, it does not apply to entities that are referenced by but not included in the signed content. When creating a multipart/signed body part, the MSP encapsulatedContent is omitted since the protected information is in the first body part. 4.2 Use of Multipart/Encrypted The multipart/encrypted content type offers clear advantages over multipart/mixed and multipart/alternative. The multipart/encrypted content type implies that the result must be returned to the MIME parser before it can be displayed to the user. With MSP, an encrypted content may also be digitally signed. Messages that are both signed and encrypted use the multipart/encrypted content type, not the multipart/signed content type. The multipart/encrypted content type contains exactly two body parts. The first body part contains the control information necessary to decrypt the data in the second body part and is labeled according to the value of the protocol parameter. The second body part contains the data which was encrypted and is always labeled application/octet-stream. The attribute token for the protocol parameter is "protocol". The value token is comprised of the type and sub-type tokens of the Content-Type: header from the second body part where the type and subtype tokens for MIME with MSP are defined as follows: Nicolls & Housley [Page 6] INTERNET DRAFT May 1996 parameter := "protocol" "=" value value := <"> type "/" subtype <"> type := "multipart" subtype := "msp" 5 Forwarding MIME with MSP Messages Forwarding of messages is a standard part of electronic mail, and forwarding of signed messages provides the ability to establish the identity of the original originator to a third party. A MSP enabled mail application should support forwarding of MIME with MSP messages. SDN.701 states that "any number of forwarded MSP messages may be conveyed within a new message" and "forwarded MSP messages may be nested within one another". Forwarded MIME with MSP messages shall be included using proper MIME forwarding techniques. 6 MIME with MSP Signed Receipt Message Format A signed receipt is generated by a MSP enabled mail application when the MSP ReceiptsIndicator is set by the originator to indicate that the recipient should return a signed receipt. In addition to the MSP ReceiptInformation included in a signed receipt sent by a recipient in response to the originator's request, the original message protected header date, subject and SMTP message-id, and the following statement must also be included in the multipart/signed body part of the MIME MSP signed receipt message. "This signed receipt confirms that the original message identified above was received and cryptographically verified by the recipient. This signed receipt along with the original message may be used to prove delivery of the original message to the recipient who signed this receipt." 7 Example MIME with MSP Messages The following are examples of MIME with MSP messages. Examples 1 and 2 illustrate messages which have been signed and encrypted. Examples 3, 4, and 5 illustrate messages which have been signed but not encrypted. Example 4 shows a signed forwarded signed message. Example 5 shows a signed receipt message. Additional MIME message examples can be found in RFC 1521. Example 1: MIME with MSP Signed and Encrypted Message Nicolls & Housley [Page 7] INTERNET DRAFT May 1996 Date: Whenever From: Whoever To: Someone Subject: Whatever MIME-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/msp"; boundary="example1-boundary" --example1-boundary Content-Type: application/msp; protect=signed&encrypted; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 Encoded MSP Security Header as Defined in SDN.701 Revision 4.0 --example1-boundary Content-Type: application/octet-stream [Encapsulated Content - Start] Content-Type: text/plain Content-Classification: Unclassified Date: Whenever From: Whoever To: Someone Subject: Whatever This is the sensitive message. Please reply today. Bob. [Encapsulated Content - End] --example1-boundary-- Example 2: MIME with MSP Signed and Encrypted Message with File Inclusion Date: Whenever From: Whoever To: Someone Subject: Whatever MIME-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/msp"; boundary="example2-boundary" Nicolls & Housley [Page 8] INTERNET DRAFT May 1996 --example2-boundary Content-Type: application/msp; protect=signed&encrypted; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 Encoded MSP Security Header as Defined in SDN.701 Revision 4.0 --example2-boundary Content-Type: application/octet-stream [Encapsulated Content - Start] Content-Type: multipart/mixed; boundary="example2-inner-boundary" Content-Classification: Unclassified --example2-inner-boundary Content-Type: text/plain This is the sensitive message. Attached is the pricing information for your eyes only. Please reply today. Bob. -- example2-inner-boundary Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Base 64 Encoded File Attachment -- example2-inner-boundary-- [Encrypted Data - End] --example2- boundary-- Example 3: MIME with MSP Signed Message with File Inclusion Date: Whenever From: Whoever To: Someone Subject: Whatever MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/msp"; micalg="sha-1"; boundary="example3-boundary" --example3-boundary Nicolls & Housley [Page 9] INTERNET DRAFT May 1996 Content-Type: multipart/mixed; boundary="example3-inner-boundary" --example3-inner-boundary Content-Type: text/plain Date: Whenever From: Whoever To: Someone Subject: Whatever This is the text protected against modification. A document is also attached and protected. Bob. --example3-inner-boundary Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Base 64 Encoded File Attachment --example3-inner-boundary-- --example3-boundary Content-Type: application/msp; protect=signed; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 MSP Security Header as Defined in SDN.701 Revision 4.0 --example3-boundary-- Example 4: MIME with MSP Signed Message with Forwarded Signed Message Date: Whenever From: Whoever To: Someone Subject: Whatever MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/msp"; micalg="sha-1"; boundary="example4-boundary" --example4-boundary Content-Type: multipart/mixed; boundary="example4-inner-boundary" Content-Classification: Unclassified Nicolls & Housley [Page 10] INTERNET DRAFT May 1996 --example4-inner-boundary Content-Type: text/plain This is the text protected against modification. I've forwarded a message from DB. Bob --example4-inner-boundary Content-Type: message/rfc822 Content-Type: multipart/signed; protocol="application/msp"; micalg="sha-1"; boundary="example4-forward-boundary" --example4-forward-boundary Content-Classification: Unclassified Date: Whenever From: Whoever To: Someone Subject: Whatever This is the text protected against modification. DB --example4-forward-boundary Content-Type: application/msp; protect=signed; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 MSP Security Header as Defined in SDN.701 Revision 4.0 --example4-forward-boundary-- --example4-boundary Content-Type: application/msp; protect=signed; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 MSP Security Header as Defined in SDN.701 Revision 4.0 --example4-boundary-- Example 5: MIME with MSP Signed Receipt Message Date: Whenever Nicolls & Housley [Page 11] INTERNET DRAFT May 1996 From: Receipt Generator To: Receipt Recipient Subject: Signed Receipt: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/msp"; micalg="sha-1"; boundary="example5-boundary" --example5-boundary Content-Type: text/plain Content-Classification: Unclassified Original-Message-Subject: Whatever Original-Message-Date: Whenever Original-Message-ID: 123-45-6789 This signed receipt confirms that the original message identified above was received and cryptographically verified by the recipient. This signed receipt along with the original message may be used to prove delivery of the original message to the recipient who signed this receipt. --example5-boundary Content-Type: application/msp; protect=signed; version=4.0 Content-Transfer-Encoding: Base64 ASN.1 MSP Security Header as Defined in SDN.701 Revision 4.0 --example5-boundary-- 8 Summary << Write this last. >> 9 References [RFC 822] Crocker, D., "Standard For The Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [RFC 1521] Borenstein, N. and N. Freed, "Multipurpose Internet Extensions (MIME) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", Bellcore, September 1993. [RFC 1847] Galvin, J., S. Murphy, S. Crocker, and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Nicolls & Housley [Page 12] INTERNET DRAFT May 1996 Multipart/Encrypted", TIS, October 1995. [SDN.701] National Security Agency, "Message Security Protocol", Specification SDN.701, Revision 3.0, March 1994. { ftp://ftp.netcom.com/pub/sp/spyrus/sdn701.ps } << Revision 4.0 will be available shortly. >> 10 Security Considerations This document specifies the conventions for using MSP with MIME to provide writer-to-reader security over the standard Internet SMTP infrastructure. Though implementation of MSP will protect the data in transit, neither this document nor SDN.701 address all the issues for a MIME with MSP user agent. These issues are beyond the scope of the document; however, in the future we hope to issue an Information RFC "Implementation Guidelines for MSP Enabled E-Mail Applications" to address many of these issues. 11 Author Addresses J. Weston Nicolls National Security Agency Attn: X22 9800 Savage Rd Ft Meade, MD 20755-6000 USA jwnicol@missi.ncsc.mil Russell Housley SPYRUS PO Box 1198 Herndon, VA 22070 USA housley@spyrus.com Nicolls & Housley [Page 13]