Network Working Group Lijun Liao, Joerg Schwenk Internet-Draft HGI, Ruhr-University Bochum Intended status: Standards Track June 30, 2009 Expires: December 31, 2009 Header Protection for S/MIME draft-liao-smimeheaderprotect-05 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 December 31, 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. 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 media. 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 December 31, 2009 [Page 1] Internet-Draft Header Protection for S/MIME June 2009 Table of Contents 1. Introduction ............................................. 2 1.1. Terminology .......................................... 3 1.2. Syntactic Notation ................................... 3 1.3 Object Identifiers ................................... 3 1.4. Security Goals of Header Protection .................. 3 1.5. Header Protection in S/MIME Version 3.1 .............. 4 1.6. Prototype Implementation ............................. 4 2. S/MIME Header Protection Entity .......................... 4 2.1. Fieldname List ....................................... 5 2.2. Canonicalization of Headers .......................... 6 3. CMS Fields ............................................... 6 3.1. CanonAlgorithmIdentifier ............................. 6 3.2. SMIME Header Protection .............................. 7 4. Creating Signed S/MIME Messages with Header Protection ... 8 4.1. Preparing an SMIME-Header-Protection Attribute ....... 8 5. Verifying Signed S/MIME Message with Header Protection ... 8 5.1. Verifying an SMIME-Header-Protection Attribute ....... 9 6. Security Considerations .................................. 9 7. References ............................................... 9 7.1 Normative References .................................. 9 7.2 Informative References ................................ 10 A. ASN.1 Module ............................................. 10 B. Examples ................................................. 11 B.1. SMIME-Header-Protection Attribute with "simple" and "SHA256" ........................................... 11 B.2. SMIME-Header-Protection Attribute with "relaxed" and "SHA1" ............................................. 12 C. Authors' Addresses ....................................... 13 1. Introduction Mail message header fields as defined in [RFC5322] contain security critical information that is not protected cryptographically. The only exception is the address portion of the header fields From or Sender. Receiving agents MUST check that the message originator of a mail message matches an Internet mail address, if present, in the signer's certificate. Since there are no standards that cover this issue in S/MIME, each MUA behaves differently. For example, message originator is retrieved always from the "From" field in Outlook Express. Outlook does not check it at all. While in Thunderbird, message originator is retrieved from the "Sender" field if it exists; otherwise from the "From" field. A receiving agent SHOULD provide some explicit alternate processing of the message if the message originator does not match the signer's address, which may be Liao & Schwenk Expires December 31, 2009 [Page 2] Internet-Draft Header Protection for S/MIME June 2009 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 the selected header fields have 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. 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 The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive. The following tokens are imported from [RFC5322]: o "field-name" (name of a header field) Other tokens not defined herein are imported from [RFC4234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc. 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 822 header against manipulation, but to make it possible for the receiving client to detect whether the protected header fields have been changed. Liao & Schwenk Expires December 31, 2009 [Page 3] Internet-Draft Header Protection for S/MIME June 2009 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 media, 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 [RFC5322] 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 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. 1.6. Prototype Implementation A prototype implementation of this memo is available in [FeLi08]. When this memo moves to standards track within the IETF, this section will be removed. 2. S/MIME Header Protection Entity A S/MIME header protection entity contains names of header fields to be protected, the canonicalization algorithm, the digest algorithm and the corresponding digest value. Liao & Schwenk Expires December 31, 2009 [Page 4] Internet-Draft Header Protection for S/MIME June 2009 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 = lowercase-field-name *(":" lowercase-field-name) lowercase-field-name = field-name in lowercase The fieldname-list contains the complete list of header fields input to the hash algorithm. The order of the names in the list does not matter. The header fields specified by the list are presented to the hash algorithm in order of their appearance in the header block, from the top to the bottom. The field name is lowercase. The field may contain names of header fields that do not exist when digested. This is useful to prevent adding of undesired header fields. The fieldname-list is compared against the actual header field names in a case insensitive manner. INFORMATIVE EXAMPLE: Given a mail message as follows: Received: A Message-ID: B Date: C From: D To: E Cc: F Subject: G Comments: H Body If the signer wishes to sign the header fields "From", "To", "Cc" and "Subject", then the fieldname-list may be: from:to:cc:subject and the following header fields will be digested in the order: From: D To: E Cc: F Subject: G If the signer wishes to protect additional header fields "Date", "Comments" and "Message-ID" then the fieldname-list may be: from:to:cc:subject:date:comments:message-id Liao & Schwenk Expires December 31, 2009 [Page 5] Internet-Draft Header Protection for S/MIME June 2009 and the following header fields will be digested in the order: Message-ID: B Date: C From: D To: E Cc: F Subject: G Comments: H Signers MUST NOT digest header fields that might have additional instances added later in the delivery process, since such header fields will change the input of the digest algorithm. To prevent modifying header fields as far as possible, headers fields which are added before the signature creation and will not be modified after that SHOULD be included in the fieldname-list. Thus, a reasonable fieldname-list SHOULD contain at least the following content: date:from:sender:reply-to:to:cc:message-id:in-reply-to:references: subject:comments:keywords. 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 [RFC5322]. To satisfy all requirements, two canonicalization algorithms are defined for each of the header: 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 Liao & Schwenk Expires December 31, 2009 [Page 6] Internet-Draft Header Protection for S/MIME June 2009 AlgorithmIdentifier is defined in [RFC5280] 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 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 } Liao & Schwenk Expires December 31, 2009 [Page 7] Internet-Draft Header Protection for S/MIME June 2009 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, which 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 in the same way as in [RFC3851] except the followings: o Before computing the digest value over the signedAttrs field, the smime-header-protection attribute MUST be prepared (see Section 4.1) and added to the signedAttrs field. 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 to which the smime-header-protection attribute should be added. 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 the fields canonAlgorithm, digestAlgorithm, and headerfieldNames, respectively. Store the digest value from Step 4 in the the field digest. 5. Verifying Signed S/MIME Message with Header Protection The signed S/MIME message with header protection are first verified in the same way as in [RFC3851], then the smime-header-protection attribute is verified as stated in Section 5.1. Liao & Schwenk Expires December 31, 2009 [Page 8] Internet-Draft Header Protection for S/MIME June 2009 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 list of 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. 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. 7. References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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 Liao & Schwenk Expires December 31, 2009 [Page 9] Internet-Draft Header Protection for S/MIME June 2009 [RFC5280] Cooper, D., Santesson S., Farrell S., Boeyen S., Housley R., Polk W., "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, April 2002. [RFC5322] Resnick, P. (Editor), "Internet Message Format", RFC 5322, October 2008.7.2 Informative References 7.2 Informative References [FeLi08] Feldmann, F., Liao, L., Prototype Implementation of Header Protection for S/MIME (this draft). URL: http://nds.hgi.rub.de/liao/works/headerprotect/index.html 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 5280 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} Liao & Schwenk Expires December 31, 2009 [Page 10] Internet-Draft Header Protection for S/MIME June 2009 id-smimeHeaderProtection OBJECT IDENTIFIER :: = {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 101} SMIMEHeaderProtectionEntity ::= SEQUENCE { canonAlgorithm CanonAlgorithmIdentifier, digestAlgorithm DigestAlgorithmIdentifier, headerfieldNames PrintableString, -- The format of a headerfieldNames -- is a "fieldname-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 178 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 "date:from:sender:reply-to:to:cc:message-id:in-reply-to: references:subject:comments:keywords"; (d) the digest value (32 hex). 0 30 178: SEQUENCE { 2 06 11: OBJECT IDENTIFIER : smime-header-protection {1 2 840 113549 1 9 16 2 : 101} 15 31 163: SET { 17 30 161: 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 : } Liao & Schwenk Expires December 31, 2009 [Page 11] Internet-Draft Header Protection for S/MIME June 2009 51 16 93: PrintableString "date:from:sender:reply-to:to:cc: message-id:in-reply-to:references: subject:comments:keywords" 146 04 32: OCTET STRING : BA F1 D4 FD 95 EB 8B FA 55 F6 31 52 E7 86 50 53 AB : 6B 79 C7 93 F1 87 89 A1 11 66 A8 10 83 42 24 : } : } : } B.2. SMIME-Header-Protection Attribute with "relaxed" and "SHA1" This section contains an annotated hex dump of a 163 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 "date:from:sender:reply-to:to:cc:message-id:in-reply-to: references:subject:comments:keywords"; (d) the digest value (20 hex) 0 30 163: SEQUENCE { 2 06 11: OBJECT IDENTIFIER : smime-header-protection {1 2 840 113549 1 9 16 2 : 101} 15 31 147: SET { 17 30 145: 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 93: PrintableString "date:from:sender:reply-to:to:cc: message-id:in-reply-to:references: subject:comments:keywords" Liao & Schwenk Expires December 31, 2009 [Page 12] Internet-Draft Header Protection for S/MIME June 2009 142 04 20: OCTET STRING : 61 8D A3 CA 54 E2 F7 71 38 CD 76 A2 AA 2A 3D ED 79 EC 3A 86 : : } : } : } C. 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 December 31, 2009 [Page 13]