Network Working Group Lijun Liao, Joerg Schwenk Internet-Draft HGI, Ruhr-University Bochum Intended status: Standards Track November 22, 2007 Expires: May 25, 2008 Header Protection for S/MIME draft-liao-smimeheaderprotect-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 May 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In the current S/MIME Version 3.1 specification, the header protection is achieved by encoding the whole message as a message/rfc822 MIME object. Since this approach poses some practical problems, we propose to use signed attributes to implement a fully backward compatible S/MIME header protection scheme. Liao & Schwenk Expires May 25, 2008 [Page 1] Internet-Draft Header Protection for S/MIME November 2007 Table of Contents 1. Introduction ............................................. 3 1.1. Terminology ............................................ 3 1.2. Syntactic Notation ..................................... 3 1.3 Object Identifiers ..................................... 4 1.4. Security Goals of Header Protection .................... 4 1.5. Header Protection in S/MIME Version 3.1 ................ 4 2. S/MIME Header Protection Entity .......................... 5 2.1. Fieldname List ......................................... 5 2.2. Canonicalization of Headers ............................ 8 3. CMS Fields ............................................... 8 3.1. CanonAlgorithmIdentifier ............................... 8 3.2. SMIME Header Protection ................................ 9 4. Creating Signed S/MIME Messages with Header Protection ... 9 4.1. Preparing an SMIME-Header-Protection Attribute ......... 10 5. Verifying Signed S/MIME Message with Header Protection ... 10 5.1. Verifying an SMIME-Header-Protection Attribute ......... 10 6. Security Considerations .................................. 11 A. ASN.1 Module ............................................. 11 B. Examples ................................................. 12 B.1. SMIME-Header-Protection Attribute with "simple" and "SHA256" ........................................... 12 B.2. SMIME-Header-Protection Attribute with "relaxed" and "SHA1" ............................................. 13 C. References ............................................... 14 C.1 Normative References .................................... 14 D. Authors' Addresses ....................................... 14 Full Copyright Statement ..................................... 15 Intellectual Property ........................................ 15 Acknowledgment ............................................... 15 Liao & Schwenk Expires May 25, 2008 [Page 2] Internet-Draft Header Protection for S/MIME November 2007 1. Introduction Mail message header fields as defined in [RFC2822] contain security critical information that is not protected cryptographically. The only exception is the header fields From and Sender. Receiving agents MUST check that the address in the header field From or Sender of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails, which may be to display a message that shows the recipient the addresses in the certificate or other certificate details [RFC3850]. Other header fields like "To", "Date", "Reply-To" and "Subject" remain totally unprotected. In the solution described in this specification, a digest value is computed over the canonicalized version of some selected header fields. This technique resembles header protection in [RFC4871]. Then the digest value is included in a signed attribute field of a CMS signature. This solution allows conforming clients to check if one of the selected header fields has been altered by simply re-computing the digest value. Non-conforming legacy clients will simply ignore that the signed attribute contains a digest value, and will only check the digest value computed over the message body according to S/MIME. By including separate signed attributes for different header fields, each field can be protected separately. 1.1. Terminology 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]. 1.2. Syntactic Notation Section 2.1 in this specification uses the Augmented Backus-Naur Form (ABNF) notation specified in [RFC4234] for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A). See [RFC4234] for the full description of the notation. Liao & Schwenk Expires May 25, 2008 [Page 3] Internet-Draft Header Protection for S/MIME November 2007 The following notations are used in this specification: CR: The carriage-return character, ASCII value 13 LF: The line-feed character, ASCII value 10 SP: The space character, ASCII value 32 1.3. Object Identifiers The object identifiers defined in this specification is only for the experiment. When this memo moves to standards track within the IETF, it is intended that the IANA will maintain this registry. 1.4. Security Goals of Header Protection The main security goal of mail message header protection is not to protect the whole RFC 2822 header against manipulation, but to make it possible for the receiving client to detect which headers have been changed. 1.5. Header Protection in S/MIME Version 3.1 S/MIME Version 3.1 [RFC3851] addresses the header protection by including all header fields as generated by the sending mail client, together with the body of the message, in a message/rfc822 mime object, which can then be protected by S/MIME. It is up to the receiving client to decide how to present this message to the user. This approach has, however, some limitations: If some of the message headers are changed during transport (e.g. when sent to a mailing list), this will either invalidate the whole message, or not be detected at all, depending on the receiving mail client's behavior. This approach has the following disadvantages: o All inner header fields must also appear in the outer header (i.e., those headers must be presented doubly) so that the mail message is conform to [RFC2822] and the mail server and relay systems know how to send the mail message. o Only the inner header fields are protected, but not the outer header fields. As stated in [RFC3851], it is up to the receiving client to decide how to present the inner header along with the unprotected outer header. Usually the following header fields, if present, are shown in most clients: "From", "Sender", "To", "CC", "Date", and "Subject". If the same header field is present in both inner and outer header, only the one in the inner header is presented. If a header field is only presented in the outer header, it will be also shown. Most mail messages Liao & Schwenk Expires May 25, 2008 [Page 4] Internet-Draft Header Protection for S/MIME November 2007 do not contain the headers "Sender" and "CC", hence one can add these header fields in the outer header to confuse the receivers. o It complicates the receiver to show the mail message. It is difficult to determine whether the message within the message/rfc822 wrapper is the top-level message or the complete message/rfc822 MIME entity is another encapsulated mail message. 2. S/MIME Header Protection Entity A smime header protection entity contains names of header fields to be protected, the canonicalization algorithm, the digest algorithm and the corresponding digest value. 2.1. Fieldname List The fieldname-list is a colon-separated list of header field names that identify the header fields presented to the digest algorithm; it is defined as follows: fieldname-list = fieldname *(":" fieldname) fieldname = "Return-Path" / "Received" / "Resent-Date" / "Resent-From" / "Resent-Sender" / "Resent-To" / "Resent-CC" / "Resent-Message-ID" / "Date" / "From" / "Sender" / "Reply-To" / "To" / "CC" / "Message-ID" / "References" / "Subject" / "Comments" / "Keywords" / optional-field-name optional-field-name = 1*ftext ftext = %d33-57 / ; Any character except %d59-126 ; controls, SP, and ":". The fieldname-list MUST contain the complete list of header fields in the order presented to the digest algorithm. The field MAY contain names of header fields that do not exist when digested; nonexistent header fields do not contribute to the digest value computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator). The fieldname-list is compared against actual header field names in a case insensitive manner. Signers choosing to protect an existing header field that occurs more Liao & Schwenk Expires May 25, 2008 [Page 5] Internet-Draft Header Protection for S/MIME November 2007 than once in the message (such as "Resent-From") MUST protect the physically last instance of that header field in the header block. Signers wishing to protect multiple instances of such a header field MUST include the header field name multiple times and MUST protect such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. INFORMATIVE EXAMPLE: Given a mail message as follows: Resent-From: Resent-From: From: To: CC: Subject: Body If the signer wishes to sign the header fields "To", "CC", "From", and "Subject" in that order, then the fieldname-list is: To:CC:From:Subject and the following header fields will be digested in the order: To: CC: From: Subject: If the signer wishes to protect the header fields "To", "CC", "From", "Subject", and the "Resent-From" header field with the value , then the fieldname-list is: To:CC:From:Subject:Resent-From and the following header fields will be digested in the order: To: CC: From: Subject: Resent-From: Liao & Schwenk Expires May 25, 2008 [Page 6] Internet-Draft Header Protection for S/MIME November 2007 If the signer wishes to protect the header fields "To", "CC", "From", "Subject", and both "Resent-From" header fields, and wishes to prevent from adding new "Resent-From" header field, then the fieldname-list is: To:CC:From:Subject:Resent-From:Resent-From:Resent-From and the following header fields will be digested in the order: To: CC: From: Subject: Resent-From: Resent-From: If the receiving agents receives the message with a third Resent-From: that is inserted before Resent-From:, then the following header fields will be used to verify S/MIME header protection entity: To: CC: From: Subject: Resent-From: Resent-From: Resent-From: then the verification fails. Signers should be careful of digesting header fields that might have additional instances added later in the delivery process, since such header fields might be inserted after the digested instance or otherwise reordered. Trace header fields (such as "Received") and Resent-* blocks are the only fields prohibited by [RFC2822] from being reordered. INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits header fields to be reordered (with the exception of Received header fields), reordering of digested header fields with multiple instances by intermediate MTAs will cause S/MIME header protection entity in this specification to be broken; such anti-social behavior should be avoided. INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this specification, all end-user visible header fields should be digested to avoid possible "indirect spamming". For example, if Liao & Schwenk Expires May 25, 2008 [Page 7] Internet-Draft Header Protection for S/MIME November 2007 the "Subject" header field is not digested, a spammer can resend a previously digested mail, replacing the legitimate subject with a one-line spam. 2.2. Canonicalization of Headers Mail message, specially the mail message header, may be modified by some mail servers and relay systems. Some signers may demand that any modification of the mail message header result in a signature failure, while some other signers may accept modification of the header within the bounds of mail message standards such as [RFC2822]. To satisfy all requirements, two canonicalization algorithms are defined for each of the header and the body: a "simple" algorithm stated in Section 3.4.1 of [RFC4871] that tolerates almost no modification and a "relaxed" algorithm stated in Section 3.4.2 of [RFC4871] that tolerates common modifications such as white-space replacement and header field line re-wrapping. 3. CMS Fields 3.1. CanonAlgorithmIdentifier The CanonAlgorithmIdentifier type identifies a canonicalization algorithm. Examples include "simple" header canonicalization, and "relaxed" header canonicalization. CanonAlgorithmIdentifier ::= AlgorithmIdentifier AlgorithmIdentifier is defined in [RFC3280] as follows: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } The algorithm identifier is used to identify a canonicalization algorithm. The "simple" canonicalization algorithm is identified by the following object: id-alg-simpleHeaderCanon OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 101} The "relaxed" canonicalization algorithm is identified by the Liao & Schwenk Expires May 25, 2008 [Page 8] Internet-Draft Header Protection for S/MIME November 2007 following object: id-alg-relaxedHeaderCanon OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 102} For the canonicalization algorithms "simple" and "relaxed" the parameters field is NULL. 3.2. SMIME Header Protection The smime-header-protection attribute type specifies the S/MIME header protection entity. It MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute in CMS signature. The following object identifier identifies the smime-header-protection attribute: id-smimeHeaderProtection OBJECT IDENTIFIER :: = {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 101} The attrValues of the smime-header-protection attribute contains only one value that has ASN.1 type SMIMEHeaderProtectionEntity: SMIMEHeaderProtectionEntity ::= SEQUENCE { canonAlgorithm CanonAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier, headerfieldNames PrintableString, digest Digest } The canonAlgorithm field specifies the canonicalization algorithm. The digestAlgorithm field specifies the digest algorithm. The format of an headerfieldNames is a "headername-list" field specified in Section 2.1. The headerfieldNames field specifies the list of header field names. The digest field carries the the digest value. 4. Creating Signed S/MIME Messages with Header Protection The signed S/MIME messages with header protection are created same as in [RFC3851] except the followings: o Before computing the digest value over the signedAttrs, the smime-header-protection attribute MUST be prepared (see Section 4.1) and added to the signedAttrs. Liao & Schwenk Expires May 25, 2008 [Page 9] Internet-Draft Header Protection for S/MIME November 2007 o All header fields that are protected MUST be prepared before the preparing the smime-header-protection. 4.1. Preparing an SMIME-Header-Protection Attribute An smime-header-protection attribute is prepared as follows: Step 1. Choose the canonicalization algorithm, the digest algorithm, and the list of names of message header fields to be digested. The digest algorithm SHOULD be the same as the digest algorithm in the SignerInfo which the smime-header-protection attribute should be added to. Step 2. Retrieve the message header fields from the message according to the protected header fields from Step 1. Step 3. Canonicalize the retrieved header fields from Step 2 according to the canonicalization algorithm. Step 4. Compute the digest value over the canonicalization result in Step 3 according to the digest algorithm. Step 5. Create an smime-header-protection attribute. Store the chosen canonicalization algorithm, the digest algorithm, and the list of names from Step 1 in ASN.1 fields canonAlgorithm, digestAlgorithm, and headerfieldNames, respectively. Store the digest value from Step 4 in the ASN.1 field digest. 5. Verifying Signed S/MIME Message with Header Protection The signed S/MIME message with header protection are verified first same as in [RFC3851], then the smime-header-protection attribute is verified as stated in Section 5.1. 5.1. Verifying an SMIME-Header-Protection Attribute An smime-header-protection attribute is verified as follows: Step 1. Retrieve the canonicalization algorithm, the digest algorithm, and the list of names of message header fields, and the digest value from the smime-header-protection attribute. Step 2. Retrieve the message header fields from the message according to the protected header fields from Step 1. Step 3. Canonicalize the retrieved header fields from Step 2 according to the canonicalization algorithm. Step 4. Compute the digest value over the canonicalization result in Liao & Schwenk Expires May 25, 2008 [Page 10] Internet-Draft Header Protection for S/MIME November 2007 Step 3 according to the digest algorithm. Step 5. Compares the computed digest value from Step 4 and the stored one from Step 1. If both digest values are different, then the verification fails; otherwise the verification successes. 6. Security Considerations All security considerations from [RFC3851] and [RFC3852] apply to applications that use procedures described in this document. A. ASN.1 Module SMIMEHeaderProtectionService { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) shps(101) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Imports from RFC 3280 AlgorithmIdentifier FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) pkix1-explicit(18) } -- Imports from RFC 3852 DigestAlgorithmIdentifier, Digest FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)} CanonAlgorithmIdentifier ::= AlgorithmIdentifier id-alg-simpleHeaderCanon OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 101} id-alg-relaxedHeaderCanon OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 102} id-smimeHeaderProtection OBJECT IDENTIFIER :: = {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 101} Liao & Schwenk Expires May 25, 2008 [Page 11] Internet-Draft Header Protection for S/MIME November 2007 SMIMEHeaderProtectionEntity ::= SEQUENCE { canonAlgorithm CanonAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier, headerfieldNames PrintableString, -- The format of a headerfieldNames -- is a "headername-list" field -- specified in Section 2.1. digest Digest } END B. Examples B.1. SMIME-Header-Protection Attribute with "simple" and "SHA256" This section contains an annotated hex dump of a 115 byte smime-header-protection attribute which is contained in the signedAttrs of a signature. The attribute contains the following information: (a) the canocalization algorithm is "simple" header canonicalization; (b) the digest algorithm is "SHA256"; (c) the list of header field names is "From:Sender:To:Cc:Date:Subject"; (d) the digest value (32 hex) 0 30 115: SEQUENCE { 2 06 11: OBJECT IDENTIFIER : smime-header-protection {1 2 840 113549 1 9 16 2 : 101} 15 31 100: SET { 17 30 98: SEQUENCE { 19 30 15: SEQUENCE { 21 06 11: OBJECT IDENTIFIER : simple { 1 2 840 113549 1 9 16 3 101 } 34 05 0: NULL : } 36 30 13: SEQUENCE { 38 06 9: OBJECT IDENTIFIER : SHA256 { 2 16 840 1 101 3 4 2 1 } 49 05 0: NULL : } 51 16 30: PrintableString "From:Sender:To:Cc:Date:Subject" Liao & Schwenk Expires May 25, 2008 [Page 12] Internet-Draft Header Protection for S/MIME November 2007 83 04 32: OCTET STRING : 6B 79 C7 93 F1 87 89 A1 11 66 A8 10 83 42 24 53 AB : BA F1 D4 FD 95 EB 8B FA 55 F6 31 52 E7 86 50 : } : } : } B.2. SMIME-Header-Protection Attribute with "relaxed" and "SHA1" This section contains an annotated hex dump of a 100 byte smime-header-protection attribute which is contained in the signedAttrs of a signature. The attribute contains the following information: (a) the canocalization algorithm is "relaxed" header canonicalization; (b) the digest algorithm is "SHA1"; (c) the list of header field names is "From:Sender:To:Cc:Date:Subject"; (d) the digest value (20 hex) 0 30 100: SEQUENCE { 2 06 11: OBJECT IDENTIFIER : smime-header-protection {1 2 840 113549 1 9 16 2 : 101} 15 31 84: SET { 17 30 82: SEQUENCE { 19 30 15: SEQUENCE { 21 06 11: OBJECT IDENTIFIER : relaxed { 1 2 840 113549 1 9 16 3 102 } 34 05 0: NULL : } 36 30 9: SEQUENCE { 38 06 5: OBJECT IDENTIFIER : SHA1 { 1 3 14 3 2 26 } 45 05 0: NULL : } 47 16 30: PrintableString "From:Sender:To:Cc:Date:Subject" 79 04 20: OCTET STRING : CA 54 E2 F7 71 38 CD 76 A2 AA 2A 3D ED 79 EC 3A 86 : 61 8D A3 : } : } : } Liao & Schwenk Expires May 25, 2008 [Page 13] Internet-Draft Header Protection for S/MIME November 2007 C. References C.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2822] Resnick, P. (Editor), "Internet Message Format", RFC 2822, April 2001. [RFC3280] Housley, R., Polk, W., Ford W., Solo, D., "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3850] Ramsdell, B. (Editor), "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. [RFC3851] Ramsdell, B. (Editor), " Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS), RFC 3852, July 2004. [RFC4234] Crocker, D. (Editor), Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005 [RFC4871] Allman, E. et. al., "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007 D. Authors' Addresses Lijun Liao Chair for Network and Data Security Ruhr-University Bochum 44780 Bochum Germany Mail message: lijun.liao@nds.rub.de Joerg Schwenk Chair for Network and Data Security Ruhr-University Bochum 44780 Bochum Germany Mail message: joerg.schwenk@nds.rub.de Liao & Schwenk Expires May 25, 2008 [Page 14] Internet-Draft Header Protection for S/MIME November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Liao & Schwenk Expires May 25, 2008 [Page 15]