Network Working Group                                          J. Schaad
Internet-Draft                                   Soaring Hawk Consulting
Intended status: Standards Track                        January 6, 24, 2011
Expires: July 10, 28, 2011

               Signer Info

  Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection
                               Attribute
               draft-schaad-smime-algorithm-attribute-04
               draft-schaad-smime-algorithm-attribute-05

Abstract

   A new attribute is defined that allows for protection

   The Cryptographic Message Syntax (CMS) unlike X.509/PKIX
   certificates, are venerable to algorithm substitution attacks.  In an
   algorithm substitution attack, the attacker changes either the
   algorithm being used or parameters of the digest
   and signature algorithm structures in an authenticated data or order to
   change the result of a
   signer info structure.  Using signature verification process.  In X.509
   certificates, the signature algorithm is protected because it is
   duplicated in the TBSCertificate.signature field with the proviso
   that the validater is to compare both fields as part of the signature
   validation process.  This document defines a new attribute includes that
   contains a copy of the relevant algorithm
   definition information in identifiers so that they
   are protected by the integrity protection signature or authentication process.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 10, 28, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Attribute Structure  . . . . . . . . . . . . . . . . . . . . .  6
   3.  Verification Process . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Signed Data Verification Changes . . . . . . . . . . . . .  8
     3.2.  Authenticated Data Verification Changes  . . . . . . . . .  8
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informational References . . . . . . . . . . . . . . . . . 11
   Appendix A.  2008 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 15

1.  Introduction

   Over past 20 years since

   The Cryptographic Message Syntax (CMS) [CMS] unlike X.509/PKIX
   certificates [RFC5280], are venerable to algorithm substitution
   attacks.  In an algorithm substitution attack, the original definition attacker changes
   either the algorithm being used or parameters of CMS as PKCS #7 the algorithm in
   1991,
   order to change the number result of signature and digest algorithms has grown from a
   small number to a fairly substantial number and signature verification process.  In
   X.509 certificates, the trend signature algorithm is expected
   to accelerate protected because it
   is duplicated in the future.  This has led TBSCertificate.signature field with the proviso
   that the validater is to compare both fields as part of the signature
   validation process.  This document defines a new possible attack attribute that was not addressed at the time,
   contains a copy of the relevant algorithm substitution
   attack.  In identifiers so that they
   are protected by the signature or authentication process.

   In an algorithm substitution attack, the attacker looks for
   collisions not only within a
   different algorithm that produces the same algorithm result as the creator of algorithm
   used by the
   message used, but in all algorithms that have similar
   characteristics.  Thus signer.  As an example, if the creator of the message
   used SHA-1 as the digest algorithm to hash the content, an attacker could look for
   collisions in SHA-1, SHA-0 or RIPEMD-160 if those algorithms were in
   use at the time the message was created.  Once a collision had been
   found, the attacker would change both the message content and the
   digest identifier in the message.

   If one looks at parameterized algorithms, then
   the attacker could also
   potentially attack looks for a different hash algorithm that produces a
   result that is the set same length, but with which it is easier to find
   collisions.  Examples of parameters other algorithms that are chosen by the
   message creator.  We currently have RSASSA-PSS as produce a hash value
   of the same length would be SHA-0 or RIPEMD-160.  Similar attacks can
   be mounted against parameterized
   signature algorithm and a number different hash algorithms have been identifiers.  When looking
   at some of the proposed (such as randomized hashing functions, such as that in [RANDOM-HASH]).  Part of
   [RANDOM-HASH], the associated security proof for these algorithms assumes proofs assume that the attacker does
   not have
   parameters are solely under the ability to select control of the parameters, although in originator and not
   subject to selection by the case
   of a choice of digest attacker.

   Some algorithms it may influence them.

   Algorithm substitution attacks are of greater interest to situations
   where messages are expected have been internally designed to be long-lived than for very short term
   messages.  It is much simpler more resistant to prove what the current set of
   constraints
   this type of a system are in attack.  Thus an RSA PKCS #1 v.15 signature [RFC3447]
   cannot have the present time than associated hash algorithm changed because it is for a
   great deal
   encoded as part of time in the past.  Thus this attribute signature.  DSA was originally defined so that
   it would only work with SHA-1 as a hash algorithm, thus by knowing
   the public key from the certificate, a validator can be assured that
   the hash algorithm can not be changed.  There is expected to a convention,
   undocumented as far as I can tell, that the same hash algorithm
   should be of greater interest in used for both the timestamping content digest and archiving communities
   than in the S/MIME community.

   In the current definition of [CMS], there signature digest.
   There are fields cases, such as third party signers that are not
   protected for either signature or authentication validation.  In this
   document only given a new signed or authenticated attribute
   content digest, where such a convention cannot be enforced.

   As with all attacks, the attack is defined which
   permits going to be desirable on items
   that are both long term and high value.  One would expect that these fields
   attacks are more likely to be protected made on older documents as part the
   algorithms being used when the message was signed would be more
   likely to have degraded over time.  Countersigning, the classic
   method of protecting a signature does not provide any additional
   protection against an algorithm substitution attack because
   countersignatures sign just the validation
   process. signature, but the algorithm
   substitution attacks leave the signature value alone while changing
   the algorithms being used.

   Using the SignerInfo structure from CMS, let's take a more detailed
   look at each of the fields in that the structure and discuss what is fields
   are and is are not protected by the signature.  The ASN.1 is  I have included a copy
   of the ASN.1 here for convenience.  (The  A similar analysis of the
   AuthenticatedData structure is similar.) left to the reader, but it can be done
   in much the same way.

         SignerInfo ::= SEQUENCE {
           version CMSVersion,
           sid SignerIdentifier,
           digestAlgorithm DigestAlgorithmIdentifier,
           signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
           signatureAlgorithm SignatureAlgorithmIdentifier,
           signature SignatureValue,
           unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

   version  is not protected by the signature.  Many  As many implementations
      of CMS today just ignore the value of this field. field that is not a problem.
      If the structure
      decodes then this value is considered sufficient to continue processing.
      Using most decoders on increased, then no changes in the market processing are
      expected.  If the value of this field does not
      control how the decoding is processed. decreased, implementations that respect
      the structure would fail to decode, but an erroneous signature
      validation would not be completed successfully.

   sid  can be protected by the use of using either version of the signing certificate
      authenticated attribute.  SigningCertificateV2 is defined in
      [RFC5035].  SigningCertificate is defined in [ESS-BASE].  In
      addition to allowing for the protection of the signer identifier,
      the specific certificate is protected by including a hash of the
      certificate to be used for validation.

   digestAlgorithm  the digest algorithm used has been implicitly
      protected by the fact that CMS has only defined one digest
      algorithm for each hash value length.  (The algorithm RIPEM-160
      was never standardized).  There is also an unwritten convention
      that the same digest algorithm should be used both here and for
      the signature algorithm.  If newer digest algorithms are defined
      where
      so that there are multiple algorithms for a given hash length, length (it
      is expected that the SHA-3 project will do so), or
      where that parameters
      are defined for a specific algorithm, this much of the implicit
      protection will no longer exist. be lost.

   signedAttributes  are directly protected by the signature when they
      are present.  The DER encoding of this value is what is hashed for
      the signature computation.

   signatureAlgorithm  has been protected by implication in the past.
      The use of an RSA public key implied that the RSA v 1.5 signature
      algorithm was being used.  The hash algorithm and this fact could
      be checked by the internal padding defined.  This is no longer
      true with the addition of the RSA-PSS signature algorithms.  The
      use of a DSA public key implied the SHA-1 hash algorithm as that
      was the only possible hash algorithm and the DSA was the public
      signature algorithm.  This is longer still somewhat true with as there is an
      implicit tie between the addition length of the
      SHA2 signature algorithms. DSA public key and the
      length of the hash algorithm to be used, but this is known by
      convention and there is no explicit enforcement for this.

   signature  is not directly protected by any other value unless a
      counter signature is present.  However this represents the
      cryptographically computed value that protects the rest of the
      signature information.

   unsignedAttrs  is not protected by the signature value.  It is also
      explicitly designed that they not to be protected by the signature
      value.

   As can be seen above, the digestAlgorithm and signatureAlgorithm
   fields have been indirectly rather than explicitly protected in the
   past.  With new algorithms that have been or are being defined this
   will no longer be the case.  This document defines and describes a
   new attribute that will explicitly protect these fields along with
   the macAlgorithm field of the AuthenticatedData structure.

1.1.  Notation

   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].

2.  Attribute Structure

   The following defines the algorithm protection attribute:

   The algorithm-protection attribute has the ASN.1 type
   CMSAlgorithmProtection:

       aa-cmsAlgorithmProtection ATTRIBUTE ::= {
           TYPE CMSAlgorithmProtection
           IDENTIFIED BY { id-aa-CMSAlgorithmProtection }
       }

   The following object identifier identifies the algorithm-protection
   attribute:

       id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1)
            member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 }

   The algorithm-protection attribute uses the following ASN.1 type:

      CMSAlgorithmProtection ::= SEQUENCE {
          digestAlgorithm         DigestAlgorithmIdentifier,
          signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
          macAlgorithm        [2] MessageAuthenticationCodeAlgorithm
                                           OPTIONAL
      }
      (WITH COMPONENTS { signatureAlgorithm PRESENT,
                         macAlgorithm ABSENT } |
       WITH COMPONENTS { signatureAlgorithm ABSENT,
                         macAlgorithm PRESENT })

   The fields are defined as follows:

   digestAlgorithm  contains a copy of the SignerInfo.digestAlgorithm
      field or the AuthenticatedData.digestAlgorithm field including any
      parameters associated with it.

   signatureAlgorithm  contains a copy of the signature algorithm
      identifier and any parameters associated with it
      (SignerInfo.signatureAlgorithm).  This field is only populated if
      the attribute is placed in a SignerInfo.signedAttrs sequence.

   macAlgorithm  contains a copy of the message authentication code
      algorithm identifier and any parameters associated with it
      (AuthenticatedData.macAlgorithm).  This field is only populated if
      the attribute is placed in an AuthenticatedData.authAttrs
      sequence.

   Exactly one of signatureAlgorithm and macAlgorithm SHALL be present.

   An algorithm-protection attribute MUST have a single attribute value,
   even though the syntax is defined as a SET OF AttributeValue.  There
   MUST NOT be zero or multiple instances of AttributeValue present.

   The algorithm-protection attribute MUST be a signed attribute or an
   authenticated attribute; it MUST NOT be an unsigned attribute, an
   unauthenticated attribute or an unprotected attribute.

   The SignedAttributes and AuthAttributes syntax are each defined as a
   SET of Attributes.  The SignedAttributes in a signerInfo MUST include
   only one instance of the algorithm protection attribute.  Similarly,
   the AuthAttributes in an AuthenticatedData MUST include only one
   instance of the algorithm protection attribute.

3.  Verification Process

   The

   While the exact verification process steps depends on the structure that is
   being dealt
   with.

   When doing comparisons of validated, there are some common rules that are to be followed
   when comparing the fields, a two algorithm structures:

   o  A field whose value is with a default value and one which is explicitly provided MUST compare as
   equivalent. being the same
      independent of whether the value is defaulted or is explicitly
      provided.

   o  It is not required that implementation dependent if, for some algorithms, the
      absence of a field which is absent in one
   case parameter and present in another case be the presence of a NULL parameter are
      compared as being equivalent.  (This
   means that  This behavior SHOULD NOT be
      expected.  This is an algorithm identifier with absent parameters and one
   with issue because some implementations will omit
      a NULL parameters are not expected to compare element, while other will encode a NULL element for some
      digest algorithms such as equivalent.) SHA-1 (see the comments in section 2.1
      of [RFC3370]).  The issue is even worse because the NULL is absent
      in some cases ([RFC3370]), but is required in other cases (for
      example see [RFC4056]).

3.1.  Signed Data Verification Changes

   If a CMS validator supports this attribute, the following additional
   verification steps MUST be performed:

   1.  The SignerInfo.digestAlgorithm field MUST be compared to the
   digestAlgorithm field in the attribute.  If the fields are not the
   same (modulo encoding) then signature validation MUST fail.

   2.  The SignerInfo.signatureAlgorithm field MUST be compared to the
   signatureAlgorithm field in the attribute.  If the fields are not the
   same (modulo encoding) then the signature validation MUST fail.

3.2.  Authenticated Data Verification Changes

   If a CMS validator supports this attribute, the following additional
   verification steps MUST be performed:

   1.  The AuthenticatedData.digestAlgorithm field MUST be compared to
   the digestAlgorithm field in the attribute.  If the fields are not
   same (modulo encoding) then authentication MUST fail.

   2.  The AuthenticatedData.macAlgorithm field MUST be compared to the
   macAlgorithm field in the attribute.  If the fields are not the same
   (modulo encoding) then the authentication MUST fail.

4.  IANA Considerations

   There are no IANA considerations.  All identifiers are assigned out
   of the S/MIME OID arc.

5.  Security Considerations

   This document is designed to address the security issue of algorithm
   substitutions of the algorithms used by the validator.  At this time
   there is no known method to exploit this type of attack.  If the
   attack could be successful, then either a weaker algorithm could be
   substituted for a stronger algorithm or the parameters could be
   modified by an attacker to change the behavior of the hashing
   algorithm used.  (One example would be changing the initial parameter
   value for [XOR-HASH].)

   The attribute defined in this document is to be placed in a location
   that is protected by the signature or message authentication code.
   This attribute does not provide any additional security if placed in
   an un-signed or un-authenticated location.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ESS-BASE]
              Hoffman, P., "Enhanced Security Services for S/MIME",
              RFC 2634, June 1999.

   [RFC5035]  Schaad, J., "Enhanced Security Services (ESS) Update:
              Adding CertID Algorithm Agility", RFC 5035, August 2007.

   [CMS]      Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 5652, September 2009.

   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
              June 2010.

   [ASN.1-2008]
              ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and
              X.683", 2008.

6.2.  Informational References

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC4056]  Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
              Cryptographic Message Syntax (CMS)", RFC 4056, June 2005.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [XOR-HASH]
              Schaad, J., "Experiment: Hash functions with parameters in
              CMS and S/MIME", draft-schaad-smime-hash-experiment-01 draft-schaad-smime-hash-experiment-06
              (work in progress), December 2009. January 2011.

   [RANDOM-HASH]
              Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure
              Digital Signatures without Collision Resistance", IETF 74.

Appendix A.  2008 ASN.1 Module

   The ASN.1 module defined uses the 2008 ASN.1 definitions found in
   [ASN.1-2008].  This module contains the ASN.1 module which contains
   the required defintions for the types and values defined in this
   document.  The module uses the ATTRIBUTE class defined in [RFC5912].

  CMSAlgorithmProtectionAttribute
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0)
      id-mod-cms-algorithmProtect(52) }
  DEFINITIONS IMPLICIT TAGS ::=
  BEGIN
   IMPORTS

     -- Cryptographic Message Syntax (CMS) [CMS]

     DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm,
     SignatureAlgorithmIdentifier
     FROM  CryptographicMessageSyntax-2009
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

     -- Common PKIX structures [RFC5912]

     ATTRIBUTE
     FROM PKIX-CommonTypes-2009
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkixCommon-02(57)};

     --
     --  The CMS Algorithm Protection attribute is a Signed Attribute or
     --  an Authenticated Attribute.
     --
     --  Add this attribute to SignedAttributesSet in [CMS]
     --  Add this attribute to AuthAttributeSet in [CMS]
     --

     aa-cmsAlgorithmProtection ATTRIBUTE ::= {
        TYPE CMSAlgorithmProtection
        IDENTIFIED BY { id-aa-cmsAlgorithmProtect }
     }

     id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs9(9) 52 }

     CMSAlgorithmProtection ::= SEQUENCE {
        digestAlgorithm         DigestAlgorithmIdentifier,
        signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
        macAlgorithm        [2] MessageAuthenticationCodeAlgorithm
                                          OPTIONAL
     }
     (WITH COMPONENTS { signatureAlgorithm PRESENT,
                        macAlgorithm ABSENT } |
      WITH COMPONENTS { signatureAlgorithm ABSENT,
                        macAlgorithm PRESENT })

  END

Author's Address

   Jim Schaad
   Soaring Hawk Consulting
   PO Box 675
   Gold Bar, WA  98251

   Email: ietf@augustcellars.com