Ladies and Gentlemen of PEM-DEV,
Please find attached my proposed Internet Draft (ID) for a fifth RFC that
further defines the future PEM standard. I would appreciate it if you
could take a few minutes to review this document prior to the up coming
PEM meeting and give me any feedback you may have. Thank you very much
for your time and effort.
Jonathan M. Backus
------------------------ cut along dotted line ----------------------------
INTERNET-DRAFT J. Backus
draft- July 1994
Privacy Enhancement for Internet Electronic Mail:
Part V: ANSI X9.17-Based Key Management
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 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.''
To learn the current status of any Internet-Draft, please
check the ``1id-abstracts.txt'' listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US
East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West
Coast), or munnari.oz.au (Pacific Rim).
Abstract
This document provides definitions, formats, references, and
citations for the use of ANSI X9.17 compliant key management
in support of Privacy Enhanced Mail (PEM) in the Internet
community. It is intended to become one member of the set
of related PEM RFCs.
Acknowledgements
This document is the product of many discussions about the
four pre-existing RFCs on this topic. Contributors include
D. Balenson, J. Linn, S. Kent, and P. Rajaram. I would also
like to thank contributors to the PEM-DEV mailing list who
have provided valuable input which is reflected in this
memo.
Brief History
In 1985, the American National Standards Institute (ANSI)
set forth a standard that defined a means of generating,
distributing, and maintaining secret cryptographic keys to
be used for encryption and/or authentication of data in
conjunction with the ANSI Data Encryption Algorithm [1](DEA,
Backus [Page 1]
draft- ANSI X9.17-Based Key Management July 1994
also known as DES). This standard, known as X9.17 [2], was
originally created for financial institutions, but it has
since been widely accepted by the federal government and
many parts of the commercial sector. In 1992, the National
Institute of Standards and Technology (NIST) published
Federal Information Processing Standard Publication (FIPS
PUB) 171 [3], which interprets and defines the use of ANSI
X9.17 within the federal government.
This method of key management presumes that the generation,
distribution, and maintenance of the secret keys is
occurring externally and separate from an application. The
specific application with regards to this memo is Privacy
Enhanced Mail (PEM).
1. Executive Summary
The ANSI X9.17 standard defines a means of distributing
symmetric data keys for later use in DES-based encryption
(ANSI X9.23 [4]) and authentication (ANSI X9.9 [5]). This
document describes how these secret keys can be used to
provide privacy-enhanced mail (PEM) integrity and encryption
services. It does not define the use of these secret keys
for DES-base message authentication. It gives an overview
on the workings of the X9.17 standard, a description and
example of X9.17 within PEM, and the necessary changes to
RFC1421 and RFC1423 to accommodate the identification and
use of X9.17 keys.
2. Overview of ANSI X9.17
Since DES is a "secret key" based algorithm, by definition
both parties in a relationship have the same key value.
This means that the exchanging of keys must be done in a
secure fashion (e.g. split knowledge mailers by certified
mail, SmartCards by bonded carrier, etc.). If keys are
changed very often this can be expensive, human intensive,
and potentially prone to human error or attack. To provide
the greatest flexibility the X9.17 standard has defined the
ability to use either 1, 2, or 3-layer key hierarchies. In
all cases, the highest layer is manually exchanged, and the
lowest layer is a data key (KD) which is used to do the
actual protection of user data. In a 1-layer hierarchy, the
KD is manually exchanged. In the 2 and 3-layer hierarchies,
the highest layer is a manually exchanged key encrypting key
(KK) which is used to secure and exchange the next lowest
layer. In the 2-layer hierarchy, the manually exchanged KK
is used to automatically secure and exchange the KD. In the
3-layer relationship, the manually exchanged KK is used to
automatically secure and exchange another KK, which is, in
Backus [Page 2]
draft- ANSI X9.17-Based Key Management July 1994
turn, used to automatically secure and exchange the KD.
Again, in all three cases, the lowest layer is the KD which
is used to do the actual protection of user data. Once
KD(s) have been exchanged they are stored at each end of the
relationship in some secure fashion, typically by encrypting
them with a unique Local Master Key (LMK), named, and given
some time period within which they may be used. The X9.17
standard defines the use of cryptographic service messages
(CSM), and the full protocol within, that are to be used
between two parties that wish to exchange keying
information. Within the cryptographic service message (CSM)
there are subfields that identify the originator of the
message (ORG), the recipient of the message (RCV), and the
name of the key (IDK1). These three fields are pointed out
because of their significance in later sections of this
memo.
3. Conveying use of ANSI X9.17 keys
Within the PEM protocol, as defined in RFC1421 [6], an IK is
identified in a pair of "Originator-ID-Symmetric:" and
"Recipient-ID-Symmetric:" header fields, and a corresponding
"Key-Info:" header field conveys usage indicators and DEK
and MIC values.
In PEM, the first item carried in both the
"Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:"
header fields is an Entity Identifier subfield. For use
with ANSI X9.17, the Entity Identifier subfield names the
originator and recipient of the previously exchanged KD that
is used to protect the PEM message. In particular, the
entity identifier subfield of the "Originator-ID-Symmetric:"
header contains the name of the KD originator, taken from
the ORG subfield of the CSM used to exchange the KD, and the
"Recipient-ID-Symmetric:" header contains the name of the KD
recipient, taken from the RCV subfield of the CSM used to
exchange the KD.
In PEM, the "Key-Info:" header field conveys 4 items, an IK
Use Indicator, a MIC Algorithm Indicator, a DEK, and a MIC.
The IK Use Indicator identifies the algorithm and mode which
the identified IK was used for DEK and MIC encryption for a
particular recipient. The MIC Algorithm Indicator
identifies the MIC computation algorithm used for a
particular recipient. The DEK and MIC are symmetrically
encrypted under a previously identified IK. For use with
ANSI X9.17, instead of an IK Use Indicator, the first
subfield of the "Key-Info:" header field is an X9.17 Use
Indicator, which indicates the use of an ANSI X9.17 key.
Instead of a DEK, the third subfield is the name of the KD,
Backus [Page 3]
draft- ANSI X9.17-Based Key Management July 1994
taken from the IDK1 subfield of the CSM used to exchange the
KD.
The MIC is encrypted under the DEK (KD). This is done for
two main reasons. First, the ANSI X9.17 standard allows for
a 1-layer relationship. In a 1-layer relationship there
would not be a KK to correspond to the PEM interchange key
(IK). Secondly, and more importantly, the ANSI X9.17
standard very closely defines the usage of KKs and maintains
usage counters for them. To use them for any reason other
then to encrypt lower layer keys within CSMs is a violation
of the standard.
4. Example and explanation of a message secured with X9.17 keys
The following is an example of a privacy-enhanced message
using ANSI X9.17 keys:
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F814EDE5960C597
Originator-ID-Symmetric: JON-BACKUS
Recipient-ID-Symmetric: DAVE-BALENSON
Key-Info: DES-KMA,RSA-MD2,KDE0446,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: JOHN-LINN
Key-Info: DES-KMA,RSA-MD2,KDE1830,
E2EF532C65CBCFF79F83A2658132DB47
Recipient-ID-Symmetric: STEVE-KENT
Key-Info: DES-KMA,RSA-MD2,KDE9203,
8DA308493CC4385B96DA720EA394B8A3
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNS
8tEjmF/zxB+bHiMom8Lr9wloXIKjHUlBL820dkeoY7U7tAngie9EEpk6e1n
asDdflkeikck/sap9pel8jj3kKK+3do6720dcBWGGsDLpTpSCnpot3k495z
dxd/H5LMDWnonNvPCxQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----
This message is being sent to three different recipients.
The "Originator-ID-Symmetric:" header field contains an
X9.17 compliant "ORG" subfield value of "JON-BACKUS." The
"Recipient-ID-Symmetric:" header fields contain X9.17
compliant "RCV" subfield values of "DAVE-BALENSON", "JOHN-
LINN", and "STEVE-KENT." The first item of the "Key-Info:"
header fields contain the X9.17 indicator, "DES-KMA." The
third item of the "Key-Info:" header fields contain X9.17
compliant "IDK1" subfield values of "KDE0446", "KDE1830",
and "KDE9203."
Backus [Page 4]
draft- ANSI X9.17-Based Key Management July 1994
4.1 Implications of this example
There is only one "Originator-ID-Symmetric:" header field.
This implies that the originator is known by the same X9.17
"ORG" value for all recipients. If for some reason the
originator of the message is known by different "ORG" values
then they must create separate messages for each group of
recipients that know them by a particular "ORG" value.
Each originator/recipient pair have a different X9.17 key
value. This implies that the PEM application must encrypt
this message three separate times, once for each recipient.
The example only shows the body of the message encrypted for
one of the recipients. The encrypted body would be
different for each recipient.
5. Changes to RFC1421
To allow for ANSI X9.17 keys to be used there requires some
changes to "Part I: Message Encryption and Authentication
Procedures" of "Privacy Enhancement for Internet Electronic
Mail" document RFC1421.
5.1 Section 4.6.2.1.2, Originator-ID-Symmetric Fields
This section needs modified to reflect that if X9.17 keys
are being used then this field will contain the X9.17 "ORG"
subfield value that was used in the CSM exchange.
5.2 Section 4.6.4.1.2, Recipient-ID-Symmetric Field
This section needs modified to reflect that if X9.17 keys
are being used then this field will contain the X9.17 "RCV"
subfield value that was used in the CSM exchange.
5.3 Section 4.6.4.2.1, Symmetric Key Management
This section needs modified to reflect that the first item
of the "Key-Info:" field may convey the presence of ANSI
X9.17 keys instead of the usage of the IK, in which case the
third item would convey the KD name instead of the IK
encrypted DEK.
5.4 Section 9, Descriptive Grammar
The BNF needs expanded to reflect the options of <ORGname>
and <RCVname> for <symmid>, with <ORGname> and <RCVname>
being defined as 16 characters in compliance with ANSI X9.17
naming conventions.
Backus [Page 5]
draft- ANSI X9.17-Based Key Management July 1994
6. Changes to RFC1423
To allow for ANSI X9.17 keys to be used there requires some
changes to "Part III: Algorithms, Modes, and Identifiers" of
"Privacy Enhancement for Internet Electronic Mail" document
RFC1423 [7].
6.1 Section 3.3, DES in KMA mode (DES-KMA) ** NEW **
A new section, 3.3 DES in KMA mode (DES-KMA), needs created
to reflect that in this mode only the MIC is encrypted in
DES Electronic Codebook mode and that the character string
"DES-KMA" within an encapsulated PEM header field indicates
use of this algorithm/mode combination.
6.2 Descriptive Grammar
The BNF needs expanded to reflect the option of "DES-KMA"
for field <ikalgid> and the option of <DEKname> for
<symencdek>, with <DEKname> being defined as 16 characters
in compliance with ANSI X9.17 naming conventions.
NOTES:
[1] ANSI X3.92, Data Encryption Algorithm, 1981.
[2] ANSI X9.17, Financial Institution Key Management
(Wholesale), April 1985.
[3] FIPS 171, Key Management using ANSI X9.17, April 1992.
[4] ANSI X9.23, Financial Institution Encryption of
Wholesale Financial Messages, 1988.
[5] ANSI X9.9, Financial Institution Message Authentication
(Wholesale), 1986.
[6] Linn, J., "Privacy Enhancement of Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC1421, February 1993.
[7] Balenson, D., "Privacy Enhancement of Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC1423, February 1993.
Author's Address
Jonathan M. Backus
15 Catawba Place
Hagerstown, MD 21742-6515
Backus [Page 6]
draft- ANSI X9.17-Based Key Management July 1994
Phone: 301-714-0446
Fax: 301-714-1854
EMail: 76277(_dot_)115(_at_)compuserve(_dot_)com