[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

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 <CRLF>
       Message-ID: B <CRLF>
       Date: C <CRLF>
       From: D <CRLF>
       To: E <CRLF>
       Cc: F <CRLF>
       Subject: G <CRLF>
       Comments: H <CRLF>

       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 <CRLF>
       To: E <CRLF>
       Cc: F <CRLF>
       Subject: G <CRLF>

     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 <CRLF>
       Date: C <CRLF>
       From: D <CRLF>
       To: E <CRLF>
       Cc: F <CRLF>
       Subject: G <CRLF>
       Comments: H <CRLF>

   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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/