idnits 2.17.1 draft-schaad-smime-algorithm-attribute-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 140 has weird spacing: '...version is no...' == Line 147 has weird spacing: '... sid can be...' == Line 154 has weird spacing: '...gorithm the d...' == Line 165 has weird spacing: '...ributes are d...' == Line 169 has weird spacing: '...gorithm has b...' == (5 more instances...) -- The document date (January 24, 2011) is 4834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 135 -- Looks like a reference, but probably isn't: '1' on line 435 -- Looks like a reference, but probably isn't: '2' on line 436 ** Downref: Normative reference to an Informational RFC: RFC 5912 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Standards Track January 24, 2011 5 Expires: July 28, 2011 7 Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection 8 Attribute 9 draft-schaad-smime-algorithm-attribute-05 11 Abstract 13 The Cryptographic Message Syntax (CMS) unlike X.509/PKIX 14 certificates, are venerable to algorithm substitution attacks. In an 15 algorithm substitution attack, the attacker changes either the 16 algorithm being used or parameters of the algorithm in order to 17 change the result of a signature verification process. In X.509 18 certificates, the signature algorithm is protected because it is 19 duplicated in the TBSCertificate.signature field with the proviso 20 that the validater is to compare both fields as part of the signature 21 validation process. This document defines a new attribute that 22 contains a copy of the relevant algorithm identifiers so that they 23 are protected by the signature or authentication process. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 28, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6 62 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8 64 3.2. Authenticated Data Verification Changes . . . . . . . . . 8 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 6.2. Informational References . . . . . . . . . . . . . . . . . 11 70 Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 The Cryptographic Message Syntax (CMS) [CMS] unlike X.509/PKIX 76 certificates [RFC5280], are venerable to algorithm substitution 77 attacks. In an algorithm substitution attack, the attacker changes 78 either the algorithm being used or parameters of the algorithm in 79 order to change the result of a signature verification process. In 80 X.509 certificates, the signature algorithm is protected because it 81 is duplicated in the TBSCertificate.signature field with the proviso 82 that the validater is to compare both fields as part of the signature 83 validation process. This document defines a new attribute that 84 contains a copy of the relevant algorithm identifiers so that they 85 are protected by the signature or authentication process. 87 In an algorithm substitution attack, the attacker looks for a 88 different algorithm that produces the same result as the algorithm 89 used by the signer. As an example, if the creator of the message 90 used SHA-1 as the digest algorithm to hash the message content then 91 the attacker looks for a different hash algorithm that produces a 92 result that is the same length, but with which it is easier to find 93 collisions. Examples of other algorithms that produce a hash value 94 of the same length would be SHA-0 or RIPEMD-160. Similar attacks can 95 be mounted against parameterized algorithm identifiers. When looking 96 at some of the proposed randomized hashing functions, such as that in 97 [RANDOM-HASH], the associated security proofs assume that the 98 parameters are solely under the control of the originator and not 99 subject to selection by the attacker. 101 Some algorithms have been internally designed to be more resistant to 102 this type of attack. Thus an RSA PKCS #1 v.15 signature [RFC3447] 103 cannot have the associated hash algorithm changed because it is 104 encoded as part of the signature. DSA was originally defined so that 105 it would only work with SHA-1 as a hash algorithm, thus by knowing 106 the public key from the certificate, a validator can be assured that 107 the hash algorithm can not be changed. There is a convention, 108 undocumented as far as I can tell, that the same hash algorithm 109 should be used for both the content digest and the signature digest. 110 There are cases, such as third party signers that are only given a 111 content digest, where such a convention cannot be enforced. 113 As with all attacks, the attack is going to be desirable on items 114 that are both long term and high value. One would expect that these 115 attacks are more likely to be made on older documents as the 116 algorithms being used when the message was signed would be more 117 likely to have degraded over time. Countersigning, the classic 118 method of protecting a signature does not provide any additional 119 protection against an algorithm substitution attack because 120 countersignatures sign just the signature, but the algorithm 121 substitution attacks leave the signature value alone while changing 122 the algorithms being used. 124 Using the SignerInfo structure from CMS, let's take a more detailed 125 look at each of the fields in the structure and discuss what fields 126 are and are not protected by the signature. I have included a copy 127 of the ASN.1 here for convenience. A similar analysis of the 128 AuthenticatedData structure is left to the reader, but it can be done 129 in much the same way. 131 SignerInfo ::= SEQUENCE { 132 version CMSVersion, 133 sid SignerIdentifier, 134 digestAlgorithm DigestAlgorithmIdentifier, 135 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 136 signatureAlgorithm SignatureAlgorithmIdentifier, 137 signature SignatureValue, 138 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 140 version is not protected by the signature. As many implementations 141 of CMS today ignore the value of this field that is not a problem. 142 If the value is increased, then no changes in the processing are 143 expected. If the value is decreased, implementations that respect 144 the structure would fail to decode, but an erroneous signature 145 validation would not be completed successfully. 147 sid can be protected using either version of the signing certificate 148 authenticated attribute. SigningCertificateV2 is defined in 149 [RFC5035]. SigningCertificate is defined in [ESS-BASE]. In 150 addition to allowing for the protection of the signer identifier, 151 the specific certificate is protected by including a hash of the 152 certificate to be used for validation. 154 digestAlgorithm the digest algorithm used has been implicitly 155 protected by the fact that CMS has only defined one digest 156 algorithm for each hash value length. (The algorithm RIPEM-160 157 was never standardized). There is also an unwritten convention 158 that the same digest algorithm should be used both here and for 159 the signature algorithm. If newer digest algorithms are defined 160 so that there are multiple algorithms for a given hash length (it 161 is expected that the SHA-3 project will do so), or that parameters 162 are defined for a specific algorithm, much of the implicit 163 protection will be lost. 165 signedAttributes are directly protected by the signature when they 166 are present. The DER encoding of this value is what is hashed for 167 the signature computation. 169 signatureAlgorithm has been protected by implication in the past. 170 The use of an RSA public key implied that the RSA v 1.5 signature 171 algorithm was being used. The hash algorithm and this fact could 172 be checked by the internal padding defined. This is no longer 173 true with the addition of the RSA-PSS signature algorithms. The 174 use of a DSA public key implied the SHA-1 hash algorithm as that 175 was the only possible hash algorithm and the DSA was the public 176 signature algorithm. This is still somewhat true as there is an 177 implicit tie between the length of the DSA public key and the 178 length of the hash algorithm to be used, but this is known by 179 convention and there is no explicit enforcement for this. 181 signature is not directly protected by any other value unless a 182 counter signature is present. However this represents the 183 cryptographically computed value that protects the rest of the 184 signature information. 186 unsignedAttrs is not protected by the signature value. It is also 187 explicitly designed that they not to be protected by the signature 188 value. 190 As can be seen above, the digestAlgorithm and signatureAlgorithm 191 fields have been indirectly rather than explicitly protected in the 192 past. With new algorithms that have been or are being defined this 193 will no longer be the case. This document defines and describes a 194 new attribute that will explicitly protect these fields along with 195 the macAlgorithm field of the AuthenticatedData structure. 197 1.1. Notation 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in [RFC2119]. 203 2. Attribute Structure 205 The following defines the algorithm protection attribute: 207 The algorithm-protection attribute has the ASN.1 type 208 CMSAlgorithmProtection: 210 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 211 TYPE CMSAlgorithmProtection 212 IDENTIFIED BY { id-aa-CMSAlgorithmProtection } 213 } 215 The following object identifier identifies the algorithm-protection 216 attribute: 218 id-aa-CMSAlgorithmProtection OBJECT IDENTIFIER ::= { iso(1) 219 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 52 } 221 The algorithm-protection attribute uses the following ASN.1 type: 223 CMSAlgorithmProtection ::= SEQUENCE { 224 digestAlgorithm DigestAlgorithmIdentifier, 225 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 226 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 227 OPTIONAL 228 } 229 (WITH COMPONENTS { signatureAlgorithm PRESENT, 230 macAlgorithm ABSENT } | 231 WITH COMPONENTS { signatureAlgorithm ABSENT, 232 macAlgorithm PRESENT }) 234 The fields are defined as follows: 236 digestAlgorithm contains a copy of the SignerInfo.digestAlgorithm 237 field or the AuthenticatedData.digestAlgorithm field including any 238 parameters associated with it. 240 signatureAlgorithm contains a copy of the signature algorithm 241 identifier and any parameters associated with it 242 (SignerInfo.signatureAlgorithm). This field is only populated if 243 the attribute is placed in a SignerInfo.signedAttrs sequence. 245 macAlgorithm contains a copy of the message authentication code 246 algorithm identifier and any parameters associated with it 247 (AuthenticatedData.macAlgorithm). This field is only populated if 248 the attribute is placed in an AuthenticatedData.authAttrs 249 sequence. 251 Exactly one of signatureAlgorithm and macAlgorithm SHALL be present. 253 An algorithm-protection attribute MUST have a single attribute value, 254 even though the syntax is defined as a SET OF AttributeValue. There 255 MUST NOT be zero or multiple instances of AttributeValue present. 257 The algorithm-protection attribute MUST be a signed attribute or an 258 authenticated attribute; it MUST NOT be an unsigned attribute, an 259 unauthenticated attribute or an unprotected attribute. 261 The SignedAttributes and AuthAttributes syntax are each defined as a 262 SET of Attributes. The SignedAttributes in a signerInfo MUST include 263 only one instance of the algorithm protection attribute. Similarly, 264 the AuthAttributes in an AuthenticatedData MUST include only one 265 instance of the algorithm protection attribute. 267 3. Verification Process 269 While the exact verification steps depends on the structure that is 270 being validated, there are some common rules that are to be followed 271 when comparing the two algorithm structures: 273 o A field with a default value MUST compare as being the same 274 independent of whether the value is defaulted or is explicitly 275 provided. 277 o It is implementation dependent if, for some algorithms, the 278 absence of a parameter and the presence of a NULL parameter are 279 compared as being equivalent. This behavior SHOULD NOT be 280 expected. This is an issue because some implementations will omit 281 a NULL element, while other will encode a NULL element for some 282 digest algorithms such as SHA-1 (see the comments in section 2.1 283 of [RFC3370]). The issue is even worse because the NULL is absent 284 in some cases ([RFC3370]), but is required in other cases (for 285 example see [RFC4056]). 287 3.1. Signed Data Verification Changes 289 If a CMS validator supports this attribute, the following additional 290 verification steps MUST be performed: 292 1. The SignerInfo.digestAlgorithm field MUST be compared to the 293 digestAlgorithm field in the attribute. If the fields are not the 294 same (modulo encoding) then signature validation MUST fail. 296 2. The SignerInfo.signatureAlgorithm field MUST be compared to the 297 signatureAlgorithm field in the attribute. If the fields are not the 298 same (modulo encoding) then the signature validation MUST fail. 300 3.2. Authenticated Data Verification Changes 302 If a CMS validator supports this attribute, the following additional 303 verification steps MUST be performed: 305 1. The AuthenticatedData.digestAlgorithm field MUST be compared to 306 the digestAlgorithm field in the attribute. If the fields are not 307 same (modulo encoding) then authentication MUST fail. 309 2. The AuthenticatedData.macAlgorithm field MUST be compared to the 310 macAlgorithm field in the attribute. If the fields are not the same 311 (modulo encoding) then the authentication MUST fail. 313 4. IANA Considerations 315 There are no IANA considerations. All identifiers are assigned out 316 of the S/MIME OID arc. 318 5. Security Considerations 320 This document is designed to address the security issue of algorithm 321 substitutions of the algorithms used by the validator. At this time 322 there is no known method to exploit this type of attack. If the 323 attack could be successful, then either a weaker algorithm could be 324 substituted for a stronger algorithm or the parameters could be 325 modified by an attacker to change the behavior of the hashing 326 algorithm used. (One example would be changing the initial parameter 327 value for [XOR-HASH].) 329 The attribute defined in this document is to be placed in a location 330 that is protected by the signature or message authentication code. 331 This attribute does not provide any additional security if placed in 332 an un-signed or un-authenticated location. 334 6. References 336 6.1. Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [ESS-BASE] 342 Hoffman, P., "Enhanced Security Services for S/MIME", 343 RFC 2634, June 1999. 345 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 346 Adding CertID Algorithm Agility", RFC 5035, August 2007. 348 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 349 RFC 5652, September 2009. 351 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 352 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 353 June 2010. 355 [ASN.1-2008] 356 ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and 357 X.683", 2008. 359 6.2. Informational References 361 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 362 Algorithms", RFC 3370, August 2002. 364 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 365 Standards (PKCS) #1: RSA Cryptography Specifications 366 Version 2.1", RFC 3447, February 2003. 368 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 369 Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. 371 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 372 Housley, R., and W. Polk, "Internet X.509 Public Key 373 Infrastructure Certificate and Certificate Revocation List 374 (CRL) Profile", RFC 5280, May 2008. 376 [XOR-HASH] 377 Schaad, J., "Experiment: Hash functions with parameters in 378 CMS and S/MIME", draft-schaad-smime-hash-experiment-06 379 (work in progress), January 2011. 381 [RANDOM-HASH] 382 Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure 383 Digital Signatures without Collision Resistance", IETF 74. 385 Appendix A. 2008 ASN.1 Module 387 The ASN.1 module defined uses the 2008 ASN.1 definitions found in 388 [ASN.1-2008]. This module contains the ASN.1 module which contains 389 the required defintions for the types and values defined in this 390 document. The module uses the ATTRIBUTE class defined in [RFC5912]. 392 CMSAlgorithmProtectionAttribute 393 { iso(1) member-body(2) us(840) rsadsi(113549) 394 pkcs(1) pkcs-9(9) smime(16) modules(0) 395 id-mod-cms-algorithmProtect(52) } 396 DEFINITIONS IMPLICIT TAGS ::= 397 BEGIN 398 IMPORTS 400 -- Cryptographic Message Syntax (CMS) [CMS] 402 DigestAlgorithmIdentifier, MessageAuthenticationCodeAlgorithm, 403 SignatureAlgorithmIdentifier 404 FROM CryptographicMessageSyntax-2009 405 { iso(1) member-body(2) us(840) rsadsi(113549) 406 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } 408 -- Common PKIX structures [RFC5912] 410 ATTRIBUTE 411 FROM PKIX-CommonTypes-2009 412 { iso(1) identified-organization(3) dod(6) internet(1) 413 security(5) mechanisms(5) pkix(7) id-mod(0) 414 id-mod-pkixCommon-02(57)}; 416 -- 417 -- The CMS Algorithm Protection attribute is a Signed Attribute or 418 -- an Authenticated Attribute. 419 -- 420 -- Add this attribute to SignedAttributesSet in [CMS] 421 -- Add this attribute to AuthAttributeSet in [CMS] 422 -- 424 aa-cmsAlgorithmProtection ATTRIBUTE ::= { 425 TYPE CMSAlgorithmProtection 426 IDENTIFIED BY { id-aa-cmsAlgorithmProtect } 427 } 429 id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { 430 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 431 pkcs9(9) 52 } 433 CMSAlgorithmProtection ::= SEQUENCE { 434 digestAlgorithm DigestAlgorithmIdentifier, 435 signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, 436 macAlgorithm [2] MessageAuthenticationCodeAlgorithm 437 OPTIONAL 438 } 439 (WITH COMPONENTS { signatureAlgorithm PRESENT, 440 macAlgorithm ABSENT } | 441 WITH COMPONENTS { signatureAlgorithm ABSENT, 442 macAlgorithm PRESENT }) 444 END 446 Author's Address 448 Jim Schaad 449 Soaring Hawk Consulting 451 Email: ietf@augustcellars.com