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

Versions: 00

INTERNET-DRAFT                                         D. Balenson (TIS)
<draft-balenson-secure-email-00.txt>                       J. Cook (TIS)
                                                     R. Housley (SPYRUS)
                                                      September 30, 1996



                     Internet Secure Electronic Mail:
       Algorithms, Modes, and Identifiers for FORTEZZA Cryptography


Status of This Memo

   This document is an Internet Draft.  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 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''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in one of the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).



Abstract

   This document provides definitions, formats, references, and
   citations for cryptographic algorithms, usage modes, and associated
   identifiers and parameters used in support of the FORTEZZA suite of
   cryptographic algorithms with Privacy Enhanced Mail (PEM) [4,5] and
   MIME Object Security Services (MOSS) [10].  This document is
   organized in the same manner as RFC 1423 [5].  It is divided into
   four primary sections, dealing with message encryption algorithms,
   message integrity check algorithms, symmetric key management
   algorithms, and asymmetric key management algorithms (including both
   asymmetric encryption and asymmetric signature algorithms).


Acknowledgments

   The authors would like to thank Mark Feldman, Jim Galvin, and Sandy
   Murphy from TIS for their contributions to this document.


Table of Contents
   1.  Message Encryption Algorithms ....................... 2
   1.1  SKIPJACK in CBC Mode (SKIPJACK-CBC) ................ 2



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 1]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



   2.  Message Integrity Check Algorithms .................. 3
   2.1  Secure Hash Algorithm (SHA-1) ...................... 3
   3.  Symmetric Key Management Algorithms ................. 4
   4.  Asymmetric Key Management Algorithms ................ 4
   4.1  Asymmetric Keys .................................... 4
   4.1.1  KEA-DSA Keys ..................................... 4
   4.2  Asymmetric Encryption Algorithms ................... 5
   4.2.1  Key Exchange Algorithm (KEA) ..................... 6
   4.3  Asymmetric Signature Algorithms .................... 7
   4.3.1  Digital Signature Algorithm (DSA) ................ 7
   5.  Descriptive Grammar ................................. 8
   References .............................................. 8
   Patent Statement ........................................ 9
   Security Considerations ................................ 10
   Authors' Addresses ..................................... 10



1  Message Encryption Algorithms

   This section identifies the alternative message encryption algorithms
   and modes that shall be used to encrypt message text.  Character
   string identifiers are assigned and any parameters required by the
   message encryption algorithm are defined for incorporation in a
   "DEK-Info:" header field.

   Only one alternative is currently defined in this category.



1.1  SKIPJACK in CBC Mode (SKIPJACK-CBC)

   Message text is encrypted using the SKIPJACK algorithm in the Cipher
   Block Chaining (CBC) mode of operation. SKIPJACK is a symmetric 64-
   bit block cipher designed to the requirements of the Escrowed
   Encryption Standard (EES) [9].  It uses an 80-bit cryptographic key.
   The FORTEZZA PCMCIA crypto card incorporates a "Capstone" chip which
   implements the SKIPJACK algorithm.  Further details of the SKIPJACK
   algorithm are beyond the scope of this document.

   The SKIPJACK CBC mode of operation of is similar to that provided in
   ISO IS 8372 [1].  The character string "SKIPJACK-CBC" within the
   "DEK-Info:" header field indicates the use of this algorithm/mode
   combination.

   The input to the SKIPJACK CBC encryption process shall be padded to a
   multiple of 8 octets, in the following manner.  Let n be the length
   in octets of the input.  Pad the input by appending 8-(n mod 8)
   octets to the end of the message, each having the value 8-(n mod 8),
   the number of octets being added.  In hexadecimal, the possible



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 2]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



   paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606,
   07070707070707, and 0808080808080808.  All input is padded with 1 to
   8 octets to produce a multiple of 8 octets in length.  The padding
   can be removed unambiguously after decryption.

   The SKIPJACK CBC encryption process requires a 80-bit cryptographic
   key.  A new, pseudorandom key is generated for each ENCRYPTED
   message.

   The SKIPJACK CBC encryption process also requires a 192-bit
   Initialization Vector (IV).  A new, pseudorandom IV shall be
   generated for each ENCRYPTED message.  The IV is transmitted with the
   message within the "DEK-Info:" header field.

   When this algorithm/mode combination is used for message text
   encryption, the "DEK-Info:" header field carries exactly two
   arguments.  The first argument identifies the SKIPJACK CBC
   algorithm/mode using the character string defined above.  The second
   argument contains the IV, represented as a contiguous string of 48
   ASCII hexadecimal digits.

   No symmetric key management is employed with this algorithm/mode.



2  Message Integrity Check Algorithms

   This section identifies the alternative algorithms that shall be used
   to compute Message Integrity Check (MIC) values for messages.
   Character string identifiers and ASN.1 object identifiers are
   assigned for incorporation in "MIC-Info:" header fields to indicate
   the choice of MIC algorithm employed.

   Only one alternative is defined in this category.



2.1  Secure Hash Algorithm (SHA-1)

   The Secure Hash Algorithm (SHA-1) message digest is computed using
   the algorithm defined in FIPS 180-1 [7].  The character string "SHA-
   1" within a "MIC-Info:" header field indicates the use of this
   algorithm.

   As specified in the SDNS Message Security Protocol (MSP) [2], the
   ASN.1 object identifier

       id-mosaicUpdatedIntegrityAlgorithm OBJECT IDENTIFIER ::= {
           joint-iso-ccitt (2) country (16) us (840) organization (1)
           u.s.government (101) dod (2) 1 1 21)



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 3]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



       }

   identifies the SHA-1 algorithm. When this object identifier is used
   with the ASN.1 type AlgorithmIdentifier, the parameters component of
   that type is the ASN.1 type NULL.

   The SHA-1 accepts as input a message of any length and produces as
   output a 20-octet (160-bit) quantity.



3  Symmetric Key Management Algorithms

   There are no symmetric key management algorithms for FORTEZZA.



4  Asymmetric Key Management Algorithms

   This section identifies the alternative asymmetric keys and the
   alternative asymmetric key management algorithms with which those
   keys shall be used, namely the asymmetric encryption algorithms with
   which DEKs and MICs are encrypted, and the asymmetric signature
   algorithms with which certificates and certificate revocation lists
   (CRLs) are signed.



4.1  Asymmetric Keys

   This section describes the asymmetric keys that shall be used with
   the asymmetric encryption algorithms and the signature algorithms
   described later.  ASN.1 object identifiers are identified for
   incorporation in a public-key certificate to identify the
   algorithm(s) with which the accompanying public keys are to be
   employed.




4.1.1  KEA-DSA Keys

   A KEA-DSA set of asymmetric key pairs is comprised of two sets of
   matching public and private keys.  The first set is a Key Exchange
   Algorithm (KEA) public/private key pair and the second set is a
   Digital Signature Algorithm (DSA) public/private key pair.

   As specified in SDNS Message Security Protocol (MSP) [2], the
   following ASN.1 object identifier identifies KEA-DSA public key
   pairs:



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 4]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



     id-mosaicKMandUpdSigAlgorithms OBJECT IDENTIFIER ::= {
       joint-iso-ccitt (2) country (16) us (840) organization (1)
       u.s.government (101) dod (2) 1 1 20)
     }

   When this object identifier is used with the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type is the
   ASN.1 type Kea-Dss-Parms, which is specified in [2] as:

           Kea-Dss-Parms ::= CHOICE {
               [0]         Different-Parms,
               [1]         Common-Parms
           }

           Different-Parms ::= SEQUENCE {
               Kea-Parms,
               Dss-Parms
           }

           Kea-Parms ::= SEQUENCE {
               p           OCTET STRING,
               q           OCTET STRING,
               g           OCTET STRING
           }

           Dss-Parms ::= SEQUENCE {
               p           OCTET STRING,
               q           OCTET STRING,
               g           OCTET STRING
           }

           Common-Parms ::= SEQUENCE {
               p           OCTET STRING,
               q           OCTET STRING,
               g           OCTET STRING
           }

   The format of the KEA-DSA public key pair carried in a FORTEZZA
   public-key certificate is described in detail in the FORTEZZA
   Application Implementors Guide [3].



4.2  Asymmetric Encryption Algorithms

   This section identifies the alternative algorithms that shall be used
   when asymmetric key management is employed to encrypt DEKs and sign
   MICs.  Character string identifiers are assigned for incorporation in
   "Key-Info:" and "DEK-Info:" header fields to indicate the choice of
   algorithm employed.



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 5]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



   Only one alternative for each of asymmetric encryption and asymmetric
   signatures is presently defined in this category.



4.2.1  Key Exchange Algorithm (KEA)

   The asymmetric Key Exchange Algorithm (KEA) is used for DEK exchange.
   The character string "KEA-SJ" within a "Key-Info:" header field
   indicates the use of this algorithm.

   The only type of DEK that undergoes KEA processing is a DEK generated
   for the SKIPJACK algorithm.  The KEA process employs a 128-octet
   (1024-bit) random value, Ra, to create a token encrypting key (TEK).
   The TEK is then used to "wrap" (encrypt) the DEK.

   When KEA is used, the second argument in a "Key-Info:" header field
   is represented using the "base 64" printable encoding technique
   defined in Section 4.3.2.4 of RFC 1421 [4].  This second argument is
   a printably encoded ASN.1 sequence of three items: (a) the TEK-
   wrapped DEK (12 octets), (b) the random Ra value (128 octets), and
   (c) the KEA public key Y (128 octets) used to generate the TEK. In
   particular, the ASN.1 sequence is defined as:

           SEQUENCE {
               wrappedDEK  OCTET STRING  -- 12 octets
               ra          OCTET STRING  -- 128 octets
               y           OCTET STRING  -- 128 octets
           }

   The Ra and Y values are needed by the recipient to generate the TEK
   needed to decrypt the DEK (the value of the "random" value Rb is
   always one).

   Section 4.2.1 of RFC 1423 [5] indicates that, for RSA Encryption [6],
   only the printably encoded RSA-encrypted DEK is included in the
   second argument of the "Key-Info:" header field.  This would not be a
   viable solution for FORTEZZA, as the recipient must obtain the random
   value Ra and the KEA public key Y of the originator before the DEK
   can be decrypted (unwrapped).  The KEA public key could be extracted
   from the originator's certificate if the message was signed, but for
   encrypted-only messages the originator is not identified and
   therefore the KEA public key of the originator must be provided to
   permit the recipient to decrypt the DEK.

   The appearance of the KEA public key Y of the originator within a
   "Key-Info:" header field associated with an encrypted MOSS body part
   is required for message decryption, but Y can also be used to infer
   the identity of the originator and thus can provide a form of
   authentication.  The Y value is the minimum amount of originator



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 6]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



   information required and thus provides the weakest implication
   possible as to the identity of the originator.  This information
   shall not be used by MOSS to provide authentication, because
   confidentiality is the only security service provided by MOSS for
   encrypted body parts.  Authentication is provided by MOSS for signed
   body parts only.



4.3  Asymmetric Signature Algorithms

   A description of the algorithms used to asymmetrically sign
   certificates and certificate revocation lists (CRLs) for FORTEZZA is
   outside the scope of this document.

   This section identifies the alternative algorithms which shall be
   used to asymmetrically sign messages, public-key certificates and
   certificate revocation lists (CRLs).  An ASN.1 object identifier is
   identified for incorporation in certificates and CRLs to indicate the
   choice of algorithm employed.

   Only one alternative is presently defined in this category.




4.3.1  Digital Signature Algorithm (DSA)

   The Digital Signature Algorithm (DSA) defined in FIPS 186 [8], is
   used for digital signatures.  The character string "DSA" within a
   "MIC-Info:" header field indicates the use of this algorithm.

   The only type of MIC value that undergoes DSA encryption is a 20-
   octet MIC generated by the SHA-1 algorithm.  The result is a 40-octet
   signed MIC.

   As specified in the SDNS Message Security Protocol (MSP) [2], the
   ASN.1 object identifier

       id-mosaicUpdatedSigAlgorithm OBJECT IDENTIFIER ::= {
           joint-iso-ccitt (2) country (16) us (840) organization (1)
           u.s.government (101) dod (2) 1 1 19)
       }

   identifies the combination of the DSA and SHA-1 algorithms.  When
   this object identifier is used with the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type is the
   ASN.1 type Dss-Parms, which is specified in [2] as:

           Dss-Parms ::= SEQUENCE {



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 7]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



               p           OCTET STRING,
               q           OCTET STRING,
               g           OCTET STRING
           }

   When DSA encryption is used to sign a MIC, the third argument in a
   "MIC-Info:" header field, an asymmetrically signed MIC, is
   represented using the printable encoding technique defined in Section
   4.3.2.4 of RFC 1421."



5  Descriptive Grammar

   ; Addendum to PEM BNF representation, using RFC 822 notation
   ; Provides specification for FORTEZZA cryptographic algorithms,
   ; modes, identifiers and formats.

   ; Imports <hexchar> and <encbin> from RFC 1421

       <dekalgid> ::= "SKIPJACK-CBC"
       <ikalgid>  ::= "KEA-SJ"
       <sigalgid> ::= "DSA"
       <micalgid> ::= "SHA-1"

       <dekparameters> ::= <SkipjackCBCparameters>
       <SkipjackCBCparameters> ::= <IV>
       <IV> ::= <hexchar48>

       <asymsignmic> ::= <encbin>

       <asymencdek> ::= <encbin>

       <hexchar48> ::= 48*48<hexchar>



References:

   [1]  ISO 8372, Information Processing Systems: Data Encipherment:
        Modes of Operation of a 64-bit Block Cipher.

   [2]  "SDNS Message Security Protocol (MSP)", Specification SDN.701,
        Revision 4.0, 1996-01-16.

   [3]  "FORTEZZA Application Implementors Guide for the FORTEZZA Crypto
        Card (Production Version)", Document #PD4002103-1.01, SPYRUS,
        1995.

   [4]  Linn, J., "Privacy Enhancement for Internet Electronic Mail:



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 8]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



        Part I: Message Encryption and Authentication Procedures", RFC
        1421, February, 1993.

   [5]  Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
        Part III: Algorithms, Modes, and Identifiers", RFC 1423,
        February 1993.

   [6]  PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data
        Security, Inc., June 3, 1991.

   [7]  Federal Information Processing Standard (FIPS) 180-1, Secure
        Hash Standard, National Institute of Standards and Technology,
        May 31, 1994.

   [8]  Federal Information Processing Standard (FIPS) 186, Digital
        Signature Standard, National Institute of Standards and
        Technology, May 19, 1994.

   [9]  Federal Information Processing Standard (FIPS) 185, Escrowed
        Encryption Standard, National Institute of Standards and
        Technology, February 9, 1994.

   [10] S. Crocker, N. Freed, J, Galvin, and S. Murphy, MIME Object
        Security Services, RFC 1848, October 1995.


Patent Statement

   FORTEZZA cryptography relies on the use of patented public key
   technology, namely DSA.  The Internet Standards Process as defined in
   RFC 1310 requires a written statement from the Patent holder that a
   license will be made available to applicants under reasonable terms
   and conditions prior to approving a specification as a Proposed,
   Draft or Internet Standard.

   A patent statement for DSA follows.  This statement has been supplied
   by the patent holder, not the authors of this profile.

   Digital Signature Algorithm (DSA)

   The U.S. Government holds patent 5,231,668 on the Digital Signature
   Algorithm (DSA), which has been incorporated into Federal Information
   Processing Standard (FIPS) 186.  The patent was issued on July 27,
   1993.

   The National Institute of Standards and Technology (NIST) has a long
   tradition of supplying U.S. Government-developed techniques
   committees and working groups for inclusion into standards on a
   royalty-free basis.  NIST has made the DSA patent available royalty-
   free to users worldwide.



Balenson/Cook/Housley  Document Expiration: Apr 5, 1997         [Page 9]


Internet Draft     PEM & MOSS: FORTEZZA Cryptography      September 1996



   Regarding patent infringement, FIPS 186 summarizes our position; the
   Department of Commerce is not aware of any patents that would be
   infringed by the DSA.  Questions regarding this matter may be
   directed to the Deputy Chief Counsel for NIST.


Security Considerations

   This documents defines the use of FORTEZZA cryptographic algorithms
   with secure Internet electronic mail.


Authors' Addresses:

   David Balenson
   Trusted Information Systems
   3060 Washington Road
   Glenwood, Maryland 21738  USA
   EMail: balenson@tis.com


   Jeff Cook
   Trusted Information Systems
   11340 W. Olympic Blvd.
   Los Angeles, California 90064  USA
   EMail: jvc@tis.com


   Russell Housley
   SPYRUS
   PO Box 1198
   Herndon, VA 22070  USA
   EMail: housley@spyrus.com




















Balenson/Cook/Housley  Document Expiration: Apr 5, 1997        [Page 10]


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