Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS

From: [email-masked] (Peter Gutmann)
Date: Thu, 11 Mar 1999 22:18:52 (NZDT)

I think the way to avoid the "too late for CMS" problem is to publish
PasswordRecipientInfo as its own draft which can follow on to CMS at a
later date.  To handle this all you need to do is add a '...' at the 
end of the RecipientInfo types in CMS (I think the '...' is implied 
anyway, since presumably there'll be more than three different types 
defined at some point).  I submitted a proposed draft covering this a 
few days ago, I guess I'll jump the gun a bit and post it here (it's 
fairly short) to give people a better idea of what it could look like.

Peter

-- Snip --

Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-password-00.txt                    University of Auckland
February 26, 1999
Expires in six months

                    Password-based Encryption for S/MIME

1. Introduction

This document describes a password-based content encryption mechanism for
S/MIME.  This is implemented as a new RecipientInfo type and is an extension to
the RecipientInfo types currently defined in CMS [CMS].

The format of the messages are described in ASN.1:1994 [ASN1].

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].

This draft is being discussed on the 'ietf-smime' mailing list.  To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

1.1 Password-based Content Encryption

CMS currently defineds three recipient information types for public-key key
wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo),
and key agreement (KeyAgreeRecipientInfo).  The recipient information described
here adds a fourth type, PasswordRecipientInfo, which provides for
password-based key wrapping.

1.2 RecipientInfo Types

The new recipient information type is an extension to the RecipientInfo type
defined in section 6.2 of CMS, extending the types to:

    RecipientInfo ::= CHOICE {
      ktri KeyTransRecipientInfo,
      kari [1] KeyAgreeRecipientInfo,
      kekri [2] KEKRecipientInfo,
      pwri [3] PasswordRecipientinfo   -- New RecipientInfo type
      }

Although the recipient information generation process is described in terms of
a password-based operation (since this will be its most common use), the
transformation employed is a general-purpose key derivation one which allows
any type of keying material to be converted into a key specific to a particular
content-encryption algorithm.

1.2.1  PasswordRecipientInfo Type

Recipient information using a user-supplied password is represented in the type
PasswordRecipientInfo.  Each instance of PasswordRecipientInfo will transfer
the content-encryption key to one or more recipients who have the previously
agreed-upon password.

    PasswordRecipientInfo ::= SEQUENCE {
      version CMSVersion,  -- always set to 0
      keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      encryptedKey EncryptedKey }

The fields of type PasswordRecipientInfo have the following meanings:

  version is the syntax version number.  It shall always be 0.

  keyDerivationAlgorithm identifies the key-derivation algorithm, and any
  associated parameters, used to derive the key-encryption key (KEK) from the
  user-supplied password.

  keyEncryptionAlgorithm identifies the content-encryption algorithm, and any
  associated parameters, used to encrypt the content-encryption key with the
  password-derived KEK.

  encryptedKey is the result of encrypting the content-encryption key with the
  password-derived KEK.

1.2.2 Rationale

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 stage in which the
KEK is used to encrypt a content-encryption key.  These two stages are
identified by the two algorithm identifiers.  Although the PKCS #5 standard
wraps these up into a single AlgorithmIdentifier, this design is particular to
that standard and may not be applicable for other password-based key wrapping
standards.  For this reason the two steps are specified separately.

2 Supported Algorithms

This section lists the algorithms that must be implemented.  Additional
algorithms that should be implemented are also included.

2.1 Key Derivation Algorithms

These algorithms are used to convert the password into a KEK.  The key
derivation algorithms are:

    KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
      { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
      ...
      }

CMS implementations must include PBKDF2 [PKCS5v2].

2.2 Key Encryption Algorithms

These algorithms are used to encrypt the content (the key) using the derived
KEK.  The content encryption algorithms are:

    KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs

CMS implementations must include Triple-DES in CBC mode, should include RC2 in
CBC mode, and may include other algorithms (CAST-128, RC5, IDEA, Skipjack) and
modes as required.  CMS implementations should not include any KSG ciphers such
as RC4.

2.3 Symmetric Key Encryption Algorithms

<<Align with CMS KEK algorithm when it's stable.  The content is encrypted is
  as per the KEK algorithm, but using the IV given in the
  KeyEncryptionAlgorithmIdentifier instead of a fixed IV - this is just
  standard CMS content encryption.  The latest CMS KEK stuff looked like it was
  moving in this direction anyway>>

3. Security Considerations

The security of this recipient information type rests on the security of the
underlying mechanisms employed, for which further information can be found in
CMS and PKCS5v2.

Appendix A: ASN.1 Module

PasswordRecipientInfo
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
      modules(0) pwri(n+1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

  FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) }
       PBKDF2-params, PBES2-Encs;

PasswordRecipientInfo ::= SEQUENCE {
  version CMSVersion,  -- always set to 0
  keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
  { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 },
  ...
  }

KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs

END

References

  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation One
        (ASN.1), 1994.

  CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-10.txt, Russ
        Housley, December 1998.

  PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, Third Draft, RSA
        Laboratories, February 1999.
        <<Presumably this will become an RFC as soon as it's finalised, include
          this as the actual reference>>

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, S.Bradner,
        March 1997.

---

From: Magnus Nystrom <[email-masked]>
Date: Thu, 11 Mar 1999 08:29:47 -0500 (Eastern Standard Time)

As an alternative, if the current CMS draft would allow for the 'PBES2'
algorithm identifier defined in PKCS #5 v2 in the set of
KeyEncryptionAlgorithms, there would be no need for changing the ASN.1 in
CMS. Another advantage with this is that it would enable an easy way to
send encrypted email where the key is derived from a previously
agreed-upon password.

I realize that this may require PKCS #5 v2 to be published as an
informational RFC.

-- Magnus

Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000