draft-ietf-smime-password-00.txt   draft-ietf-smime-password-01.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-00.txt University of Auckland draft-ietf-smime-password-01.txt University of Auckland
June 15, 1999 November 20, 1999
Expires December 1999 Expires May 2000
Password-based Encryption for S/MIME Password-based Encryption for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 32 skipping to change at line 32
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Cryptographic Message Syntax data format doesn't currently contain The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption. This document any provisions for password-based data encryption. This document
provides a method of encrypting data using user-supplied passwords provides a method of encrypting data using user-supplied passwords and,
(and, by extension, any form of variable-length keying material which by extension, any form of variable-length keying material which isn't
isn't necessarily an algorithm-specific fixed-format key). necessarily an algorithm-specific fixed-format key.
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the "ietf-smime" mailing list. To
join the list, send a message to <ietf-smime-request@imc.org> with the join the list, send a message to <ietf-smime-request@imc.org> with the
single word "subscribe" in the body of the message. Also, there is a single word "subscribe" in the body of the message. Also, there is a
Web site for the mailing list at <http://www.imc.org/ietf-smime>. Web site for the mailing list at <http://www.imc.org/ietf-smime>.
1. Introduction 1. Introduction
This document describes a password-based content encryption mechanism This document describes a password-based content encryption mechanism
for S/MIME. This is implemented as a new RecipientInfo type and is an for S/MIME. This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in CMS [CMS]. extension to the RecipientInfo types currently defined in RFC 2640
[RFC2640].
The format of the messages are described in ASN.1:1994 [ASN1]. The format of the messages are described in ASN.1:1994 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.1 Password-based Content Encryption 1.1 Password-based Content Encryption
CMS currently defined three recipient information types for public-key CMS currently defined three recipient information types for public-key
skipping to change at line 77 skipping to change at line 78
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type pwri [3] PasswordRecipientinfo -- New RecipientInfo type
} }
Although the recipient information generation process is described in Although the recipient information generation process is described in
terms of a password-based operation (since this will be its most common terms of a password-based operation (since this will be its most common
use), the transformation employed is a general-purpose key derivation use), the transformation employed is a general-purpose key derivation
one which allows any type of keying material to be converted into a key one which allows any type of keying material to be converted into a key
specific to a particular content-encryption algorithm. specific to a particular content-encryption algorithm. Since the most
common use for password-based encryption is to encrypt files which are
stored locally (rather than being transmitted across a network), the
term "recipient" is somewhat misleading, but is used here because the
other key transport mechanisms have always been described in similar
terms.
1.2.1 PasswordRecipientInfo Type 1.2.1 PasswordRecipientInfo Type
Recipient information using a user-supplied password is represented in Recipient information using a user-supplied password or previously
the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo agreed-upon key is represented in the type PasswordRecipientInfo. Each
will transfer the content-encryption key (CEK) to one or more instance of PasswordRecipientInfo will transfer the content-encryption
recipients who have the previously agreed-upon password. key (CEK) to one or more recipients who have the previously agreed-upon
password or key-encryption key (KEK).
PasswordRecipientInfo ::= SEQUENCE { PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0 version CMSVersion, -- Always set to 0
keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier, keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings: The fields of type PasswordRecipientInfo have the following meanings:
version is the syntax version number. It shall always be 0. version is the syntax version number. It shall always be 0.
keyDerivationAlgorithm identifies the key-derivation algorithm, and keyDerivationAlgorithm identifies the key-derivation algorithm, and
any associated parameters, used to derive the key-encryption key any associated parameters, used to derive the KEK from the
(KEK) from the user-supplied password. user-supplied password. If this field is absent, the KEK is supplied
from an external source, for example a crypto token such as a smart
card.
keyEncryptionAlgorithm identifies the content-encryption algorithm, keyEncryptionAlgorithm identifies the content-encryption algorithm,
and any associated parameters, used to encrypt the CEK with the and any associated parameters, used to encrypt the CEK with the KEK.
password-derived KEK.
encryptedKey is the result of encrypting the content-encryption key encryptedKey is the result of encrypting the content-encryption key
with the password-derived KEK. with the KEK.
1.2.2 Rationale 1.2.2 Rationale
Password-based key wrapping is a two-stage process, a first stage in Password-based key wrapping is a two-stage process, a first stage in
which the user-supplied password is converted into a KEK, and a second which a user-supplied password is converted into a KEK if required, and
stage in which the KEK is used to encrypt a CEK. These two stages are a second stage in which the KEK is used to encrypt a CEK. These two
identified by the two algorithm identifiers. Although the PKCS #5 stages are identified by the two algorithm identifiers. Although the
standard goes one step further to wrap these up into a single algorithm PKCS #5 standard goes one step further to wrap these up into a single
identifier, this design is particular to that standard and may not be algorithm identifier, this design is particular to that standard and
applicable for other password-based key wrapping standards. For this may not be applicable for other key wrapping mechanisms. For this
reason the two steps are specified separately. reason the two steps are specified separately.
2 Supported Algorithms 2 Supported Algorithms
This section lists the algorithms that must be implemented. Additional This section lists the algorithms that must be implemented. Additional
algorithms that should be implemented are also included. algorithms that should be implemented are also included.
2.1 Key Derivation Algorithms 2.1 Key Derivation Algorithms
These algorithms are used to convert the password into a KEK. The key These algorithms are used to convert the password into a KEK. The key
derivation algorithms are: derivation algorithms are:
KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
{ SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
... ...
} }
CMS implementations must include PBKDF2 [PKCS5v2]. CMS implementations MUST include PBKDF2 [PKCS5v2].
2.2 Key Encryption Algorithms 2.2 Key Encryption Algorithms
These algorithms are used to encrypt the content (the key) using the These algorithms are used to encrypt the content (the key) using the
derived KEK. The content encryption algorithms are: derived KEK. The content encryption algorithms are:
KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
CMS implementations must include Triple-DES in CBC mode, should include CMS implementations MUST include Triple-DES in CBC mode, SHOULD include
RC2 in CBC mode, and may include other algorithms such as CAST-128, RC2 in CBC mode, and MAY include other algorithms such as CAST-128,
RC5, IDEA, Skipjack, and encryption modes as required. CMS RC5, IDEA, Skipjack, and encryption modes as required. CMS
implementations should not include any KSG ciphers such as RC4 or a implementations SHOULD NOT include any KSG ciphers such as RC4 or a
block cipher in OFB mode, and should not include a block cipher in ECB block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB
mode. The use of RC2 has special requirements, see section 2.4 for mode. The use of RC2 has special requirements, see section 2.4 for
details. details.
2.3 Symmetric Key Encryption Algorithms 2.3 Symmetric Key Encryption Algorithms
The key wrap algorithm is used to wrap the CEK with the KEK. There is The key wrap algorithm is used to wrap the CEK with the KEK. There is
no requirement that the content-encryption algorithm match the KEK no requirement that the content-encryption algorithm match the KEK
algorithm, although care should be taken to ensure that, if different algorithm, although care should be taken to ensure that, if different
algorithms are used, they offer an equivalent level of security (for algorithms are used, they offer an equivalent level of security (for
example wrapping a Triple-DES key with an RC2/40 key leads to a severe example wrapping a Triple-DES key with an RC2/40 key leads to a severe
skipping to change at line 231 skipping to change at line 240
key. key.
2.3.4 Rationale for the Double Wrapping 2.3.4 Rationale for the Double Wrapping
If many CEK's are encrypted in a standard way with the same KEK and the If many CEK's are encrypted in a standard way with the same KEK and the
KEK has a 64-bit block size then after about 2^32 encryptions there is KEK has a 64-bit block size then after about 2^32 encryptions there is
a high probability of a collision between different blocks of encrypted a high probability of a collision between different blocks of encrypted
CEK's. If an opponent manages to obtain a CEK, they may be able to CEK's. If an opponent manages to obtain a CEK, they may be able to
solve for other CEK's. The double-encryption wrapping process, which solve for other CEK's. The double-encryption wrapping process, which
makes every bit of ciphertext dependent on every bit of the CEK, makes every bit of ciphertext dependent on every bit of the CEK,
eliminates this collision problem. Since the IV is applied to the eliminates this collision problem (as well as preventing other
inner layer of encryption, even wrapping the same CEK with the same KEK potential problems such as bit-flipping attacks). Since the IV is
will result in a completely different wrapped key each time. applied to the inner layer of encryption, even wrapping the same CEK
with the same KEK will result in a completely different wrapped key
each time.
2.4 Special Handling for RC2 Keys 2.4 Special Handling for RC2 Keys
For a variety of historical, political, and software-peculiarity For a variety of historical, political, and software-peculiarity
reasons which are beyond the scope of this document, the handling of reasons which are beyond the scope of this document, the handling of
keys for the RC2 algorithm [RC2] by different implementations is keys for the RC2 algorithm [RFC2268] by different implementations is
somewhat arbitrary. In particular, the choice of actual vs effective somewhat arbitrary. In particular, the choice of actual vs effective
key bits used in the algorithm is often unclear. The standard RC2 key bits used in the algorithm is often unclear. The standard RC2
AlgorithmIdentifier only allows the effective key bits to be specified, AlgorithmIdentifier only allows the effective key bits to be specified,
leaving the actual key bits to be communicated via out-of-band means, leaving the actual key bits to be communicated via out-of-band means,
which in some cases means hardcoding them into applications. Solving which in some cases means hardcoding them into applications. Solving
this problem requires two things, a precise definition of how keys this problem requires two things, a precise definition of how keys
represented with the standard RC2 AlgorithmIdentifier are handled, and represented with the standard RC2 AlgorithmIdentifier are handled, and
a new RC2 AlgorithmIdentifier which allows keys currently in use by a new RC2 AlgorithmIdentifier which allows keys currently in use by
different applications to be handled. different applications to be handled.
skipping to change at line 267 skipping to change at line 278
RC2-CBCParameter ::= CHOICE { RC2-CBCParameter ::= CHOICE {
iv IV, iv IV,
params SEQUENCE { params SEQUENCE {
version INTEGER, version INTEGER,
iv OCTET STRING iv OCTET STRING
} }
} }
where the version field encodes the effective key size in a complex where the version field encodes the effective key size in a complex
manner specified in the RFC. Where this algorithm identifier is used, manner specified in the RFC. Where this algorithm identifier is used,
the actual key size shall be 128 bits, and the effective key size is the actual key size shall be the same size as the effective key size as
given by the version field. When RC2 is to be used, implementations given by the version field. When RC2 is to be used, implementations
should use this AlgorithmIdentifier and parameters, and when this should use this AlgorithmIdentifier and parameters, and when this
AlgorithmIdentifier is used the actual key size must not be a value AlgorithmIdentifier is used the actual key size MUST NOT be a value
other than 128 bits (to use a different size, see section 2.4.2). other than the effective key size (to use a different size, see section
2.4.2).
2.4.2 Handling of RC2 with Other Key Sizes 2.4.2 Handling of RC2 with Other Key Sizes
If the use of an actual key size of other than 128 bits is required, If the use of an actual key size of other than the effective key size
implementations must use the following AlgorithmIdentifier: is required, implementations MUST use the following
AlgorithmIdentifier:
rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13} (provisional) rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13}
RC2-CBCParameter ::= SEQUENCE { RC2-CBCParameter ::= SEQUENCE {
actualKeySize INTEGER, -- Actual key size in bits actualKeySize INTEGER, -- Actual key size in bits
effectiveKeySize INTEGER, -- Effective key size in bits effectiveKeySize INTEGER, -- Effective key size in bits
iv OCTET STRING iv OCTET STRING
} }
This allows arbitrary actual and effective key sizes to be specified This allows arbitrary actual and effective key sizes to be specified
for compatibility with existing usage. Although implementations should for compatibility with existing usage. Although implementations SHOULD
not use this alternative (using instead the one in section 2.4.1) NOT use this alternative (using instead the one in section 2.4.1)
experience has shown that implementors will continue to use oddball RC2 experience has shown that implementors will continue to use oddball RC2
parameters anyway, so new implementations should be prepared to parameters anyway, so new implementations should be prepared to
encounter and handle actual and effective key sizes ranging from 40 up encounter and handle actual and effective key sizes ranging from 40 up
to around 200 bits. to around 200 bits.
[It has been suggested that there may be yet another parameter which
needs to be specified, the actual (rather than effective) key size
of a wrapped RC2 CEK. This can be added as a third integer
parameter if necessary]
2.4.3 Rationale 2.4.3 Rationale
The reason for providing for the handling of oddball key sizes is The reason for providing for the handling of oddball key sizes is
compatibility with existing applications, for example a mailing-list compatibility with existing applications, for example a mailing-list
exploder or mail gateway may take an RSA-wrapped CEK generated by a exploder or mail gateway may take an RSA-wrapped CEK generated by a
current application and repackage it with a KEK, so we need a mechanism current application and repackage it with a KEK, so we need a mechanism
for handling strange key lengths in a manner which is compatible with for handling strange key lengths in a manner which is compatible with
existing usage. The alternative RC2 AlgorithmIdentifier, although not existing usage. The alternative RC2 AlgorithmIdentifier, although not
recommended, provides a means of ensuring this compatibility. recommended, provides a means of ensuring this compatibility.
3. Security Considerations 3. Security Considerations
The security of this recipient information type rests on the security The security of this recipient information type rests on the security
of the underlying mechanisms employed, for which further information of the underlying mechanisms employed, for which further information
can be found in CMS and PKCS5v2. can be found in RFC 2640 and PKCS5v2. More importantly, however, when
used with a password the security of this information type rests on the
entropy of the user-selected password, which is typically quite low.
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
although it should be recognized that even with pass phrases it will be
difficult to use this recipient information type to derive a KEK with
sufficient entropy to properly protect a 128-bit (or higher) CEK.
Author Address Author Address
Peter Gutmann Peter Gutmann
University of Auckland University of Auckland
Private Bag 92019 Private Bag 92019
Auckland, New Zealand Auckland, New Zealand
pgut001@cs.auckland.ac.nz pgut001@cs.auckland.ac.nz
References References
ASN1 Recommendation X.680: Specification of Abstract Syntax Notation ASN1 Recommendation X.680: Specification of Abstract Syntax Notation
One (ASN.1), 1994. One (ASN.1), 1994.
CMS Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
Housley, April 1999.
PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA
Laboratories, 25 March 1999. Laboratories, 25 March 1999.
RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels,
S.Bradner, March 1997. S.Bradner, March 1997.
RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest, RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest,
March 1998. March 1998.
RFC2640 Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
Housley, April 1999.
PACKAGE All-or-Nothing Encryption and the Package Transform, PACKAGE All-or-Nothing Encryption and the Package Transform,
R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, R.Rivest, Proceedings of Fast Software Encryption '97, Haifa,
Israel, January 1997. Israel, January 1997.
Appendix A: ASN.1 Module Appendix A: ASN.1 Module
PasswordRecipientInfo PasswordRecipientInfo
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(n+1) } smime(16) modules(0) pwri(n+1) }
skipping to change at line 355 skipping to change at line 379
BEGIN BEGIN
IMPORTS IMPORTS
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) } pkcs-5(5) }
PBKDF2-params, PBES2-Encs; PBKDF2-params, PBES2-Encs;
PasswordRecipientInfo ::= SEQUENCE { PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0 version CMSVersion, -- Always set to 0
keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier, keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey } encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
{ SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
... ...
} }
KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/