view Side-By-Side changes
Network Working Group P Metzger
Internet Draft P Karn
W A Simpson
expires in six months January March 1995
The ESP DES-CBC Transform
draft-ietf-ipsec-esp-des-cbc-00.txt
draft-ietf-ipsec-esp-des-cbc-03.txt |
Status of this Memo
This document is a submission to the IP Security Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipsec@ans.net mailing list.
Distribution of this memo is unlimited.
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 not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``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:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Abstract
This document describes the DES-CBC security transform for the IP |
Encapsulating Security Payload (ESP).
Troublemakers
Metzger, Karn & Simpson expires in six months [Page 1] i]
DRAFT ESP DES-CBC January March 1995
1. Introduction
The Encapsulating Security Payload (ESP) [1] [A-ESP] provides
confidentiality and integrity by encrypting the data to be protected.
This specification describes the ESP use of the Cipher Block Chaining
(CBC) mode of the US Data Encryption Standard (DES) algorithm. DES
is described is several US Government publications [2, 3, 4, 5].
A algorithm [FIPS-
46, FIPS-46-1, FIPS-74, FIPS-81].
All implementations that claim conformance or compliance with the
Encapsulating Security Payload specification MUST implement this
DES-CBC transform.
Implementors should consult the most recent book also provides information version of the IAB
Standards [RFC-1610] for further guidance on DES [6]. At least one
hardware implementation the status of DES-CBC can encrypt or decrypt at about 1
Gbps [6, p. 231].
Conformance with ESP requires this
document.
This document assumes that the reader is familiar with the related
document "Security Architecture for the Internet Protocol" [A-SA],
which defines the overall security plan for IP, and provides
important background for this Security Transform MUST be
implemented. specification.
1.1. Keys
The secret DES key shared between the communicating parties is 64
bits long. eight |
octets in length. This key consists of a 56-bit quantity used by the
DES
algorithm, and 8 parity bits arranged such that one parity bit algorithm. The 56-bit key is stored as a 64-bit (eight octet)
quantity, with the least significant bit of each octet. octet used as a
parity bit.
1.2. Initialization Vector
This mode of DES requires an Initialization Vector (IV) that is 8 eight |
octets in length.
Each datagram contains its own DES IV. Including the IV in each datagram
ensures that decryption of each received datagram can be performed,
even when other datagrams are dropped, or datagrams are re-ordered in
transit.
The method for selection of the IV values is implementation
dependent.
Note: A common technique is simply a counter, beginning with a
Metzger, Karn & Simpson expires in six months [Page 1]
DRAFT ESP DES-CBC March 1995
randomly chosen value. Other implementations also exhibit
unpredictability, usually through a pseudo-random number
generator. Care should be taken that the periodicity of the
number generator is long enough to prevent repetition during the
lifetime of the session key.
Troublemakers expires in six months [Page 1]
DRAFT ESP DES-CBC January 1995
1.3. Data Size
The DES algorithm operates on blocks of 8 eight octets. This often |
requires padding after the end of the unencrypted payload data.
Both input and output result in the same number of octets, which
facilitates in-place encryption and decryption.
On receipt, if the length of the data to be decrypted is not an
integral multiple of 8 octets, then an error is indicated. The
datagram is discarded, and an appropriate ICMP message is returned.
The failure SHOULD be recorded in the system or audit log, including |
the cleartext values for the SAID, Security Parameters Index (SPI),
date/time, Source, Destination, and other identifying information.
1.4. Performance
At the time of writing, at least one hardware implementation can
encrypt or decrypt at about 1 Gbps [Schneier94, p. 231].
Metzger, Karn & Simpson expires in six months [Page 2]
DRAFT ESP DES-CBC March 1995
2. Payload Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association Identifier (SAID) Parameters Index (SPI) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initialization Vector (IV) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Payload Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding | Pad Length | Data Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Association Identifier (SAID) Parameters Index (SPI) |
A 32-bit value identifying the Security Association Parameters for this
datagram. If no Security Association has been established, the The value of this field is MUST NOT be zero.
Initialization Vector
The size of this field is variable, though for any given Security
Association SPI it
has a particular known size. Its position and size
is are constant
for all DES-CBC datagrams of the same SAID SPI and IP Destination.
Troublemakers expires in six months [Page 2]
DRAFT ESP DES-CBC January 1995
This field is considered to be transparent, though most users will
not be able to make sense of its contents.
The field may size MUST be longer or shorter than the 64-bits used by DES,
in multiples a multiple of 32-bits. This allows alignment of the Encrypted
Data for in-place decryption.
All conformant implementations MUST correctly process a 64-bit
field size. Octets are sent in
network order.
When the size is negotiated to 32-bits, a 64-bit value is formed from the 32-bit
value followed by (concatentated with) the inverse bit-wise complement of
the 32-bits
is appended to form a 64-bit 32-bit value.
When the This field size is negotiated to 96-bits or greater, most common, as it aligns
the Payload Data for both 32-bit and 64-bit processing.
All conformant implementations MUST also correctly process a 64-
bit field size. This provides strict compatibility with existing
hardware implementations.
It is the intent that the value not repeat during the alignment lifetime
of the encryption session key. Even when a full 64-bit value within this IV is
used, the session key SHOULD be changed at least as frequently
as 2**32 datagrams.
This field is negotiated by a variable
parameter. Unused octets are filled with unspecified
implementation dependent values. considered to be transparent, though most users will
not be able to make sense of its contents.
Metzger, Karn & Simpson expires in six months [Page 3]
DRAFT ESP DES-CBC March 1995
Payload Data
The size of this field is variable. This field is opaque.
Prior to encryption and after decryption, the contents of this
field begins with an entire IP datagram (IP-Mode), (Tunnel-Mode), or an another
IP
Payload Protocol/Payload header (Transport-Mode).
Padding
The size of this field is variable. This field is opaque.
Prior to encryption, it is filled with unspecified implementation
dependent (preferably random) values.
After decryption, it MUST be ignored.
Pad Length
This field indicates the size of the Padding field. It does not
include the Pad Length and Data Type fields. The value typically
ranges from 0 to 7, but may be up to 255 to permit hiding of that the
actual data length.
This field is opaque. That is, the value is set prior to
encryption, and is examined only after decryption.
Data Type
This field indicates the contents of the Payload Data field, using
Troublemakers expires in six months [Page 3]
DRAFT ESP DES-CBC January 1995
the IP Protocol/Payload value. Up-to-date values of the IP
Protocol/Payload are specified in the most recent "Assigned
Numbers" RFC [7]. [RFC-1700].
This field is opaque. That is, the value is set prior to
encryption, and is examined only after decryption.
For example, when encrypting an entire IP datagram (IP-Mode), (Tunnel-
Mode), this field will contain the value 4, which indicates
IP-in-IP encapsulation.
Security Considerations
Users need
3. Algorithm
In DES-CBC, the base DES encryption function is applied to understand that the quality XOR of
each plaintext block with the security provided by
this specification depends completely on the strength of whichever
encryption algorithm that has been implemented, previous ciphertext block to yield the correctness of
that algorithm's implementation,
ciphertext for the security of current block. In formalized notation,
Metzger, Karn & Simpson expires in six months [Page 4]
DRAFT ESP DES-CBC March 1995
DES-CBC: C[n] = E[k](P[n] XOR C[n-1])
P[n] = C[n-1] XOR D[k](C[n])
E[k](X) indicates the DES encryption function with key management
mechanism and its implementation, the strength of k performed
upon block X.
D[k](X) indicates the DES decryption function with key [8], and k upon
block X.
P[n] indicates plaintext block n.
C[n] indicates ciphertext block n.
A XOR B indicates the correctness bitwise exclusive-or of the ESP blocks A and IP implementations in all B.
For more explanation and implementation information for DES, see
[Schneier94].
3.1. Encryption
Append zero or more octets of (preferably random) padding to the
participating systems.
It is known that DES is an algorithm approaching the end of
plaintext, to make its
useful lifetime. As of modulo 8 length equal to 6. For example, if
the writing plaintext length is 41, 5 octets of this document, Biham and
Shamir [9] have padding are added.
Append a Pad Length octet containing the number of padding octets
just added.
Append a Data Type octet containing the IP Protocol/Payload value
which identifies the protocol header that begins the payload.
Provide an Initialization Vector (IV) of the size indicated by the
SPI.
Encrypt the payload with DES in CBC mode, producing a ciphertext of
the same length.
Octets are mapped to DES blocks in network order. Octet 0 (modulo 8)
of the payload corresponds to bits 1-8 of the 64-bit DES input block,
while octet 7 (modulo 8) corresponds to bits 57-64 of the DES input
block.
Contruct a new IP datagram for the target Destination, with the
indicated SPI, IV, and payload.
The Total/Payload Length in the IP Header reflects the length of the
Metzger, Karn & Simpson expires in six months [Page 5]
DRAFT ESP DES-CBC March 1995
encrypted data, plus the SPI, IV, padding, pad length, and data type
octets.
3.2. Decryption
First, the SPI field is removed and examined. This is used as an |
index into the local Security Parameter table to find the negotiated |
parameters and decryption key.
The negotiated form of the IV determines the size of the IV field.
These octets are removed, and an appropriate 64-bit IV value is
constructed.
The encrypted part of the payload is decrypted using DES in the CBC
mode.
The Data Type is removed and examined. If it is unrecognized, the
payload is discarded with an appropriate ICMP message.
The Pad Length is removed and examined. The specified number of pad
octets are removed from the end of the decrypted payload, and the IP
Total/Payload Length is adjusted accordingly.
The IP Header(s) and the remaining portion of the decrypted payload
are passed to the protocol receive routine specified by the Data Type
field.
Security Considerations
Users need to understand that the quality of the security provided by
this specification depends completely on the strength of the DES
algorithm, the correctness of that algorithm's implementation, the
security of the key management mechanism and its implementation, the
strength of the key [CN94], and upon the correctness of the
implementations in all of the participating nodes.
Among other considerations, applications may wish to take care not to
select weak keys, although the odds of picking one at random are low
[Schneier94, p 233].
At the time of writing of this document, [BS93] demonstrated a *
differential cryptanalysis based chosen-plaintext attack requiring
2^47 plaintext-ciphertext pairs, and Mitsuru Matsui [10] has [Matsui94] demonstrated a linear
cryptanalysis based known-plaintext attack requiring only 2^43
Metzger, Karn & Simpson expires in six months [Page 6]
DRAFT ESP DES-CBC March 1995
plaintext-ciphertext pairs. Although these attacks are not
considered practical, they must be taken into account.
More disturbingly, Wiener [11] [Weiner94] has shown the design of a DES cracking
machine costing $1 Million that can crack one key every 3.5 hours.
This is an extremely practical attack, attack. The Unicity distance for DES
is only a couple of blocks, and it changing the session key frequently
will not mitigate the brute force attack.
It is suggested that DES is not a good encryption algorithm for the
protection of even moderate value information in the face of such
equipment. Triple DES is probably a better choice for such purposes.
Acknowledgements
The original
Some of the text of this specification was derived from work by Ran |
Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.
The use of DES for confidentiality is closely modeled on the work
done for SNMPv2 [12].
Troublemakers DES for confidentiality is closely modeled on the work
done for SNMPv2 [RFC-1446].
Steve Bellovin, Steve Deering, Charles Lynn, and Dave Mihelcic
provided useful critiques of earlier versions of this draft.
References
[A-SA] Randall Atkinson, "Security Architecture for the Internet
Protocol", work in progress.
[A-ESP] Randall Atkinson, "IP Encapsulating Security Protocol
(ESP)", work in progress.
[BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of
the Data Encryption Standard", Berlin: Springer-Verlag,
1993.
[CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
253-280, July 1994.
[FIPS-46]
US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
46, January 1977.
Metzger, Karn & Simpson expires in six months [Page 4] 7]
DRAFT ESP DES-CBC January March 1995
References
[1] Randall Atkinson, Perry Metzger, William Simpson,
"Encapsulating Security Protocol (ESP)", work in progress.
[2]
[FIPS-46-1]
US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication 46,
46-1, January 1977.
[3] 1988.
[FIPS-74]
US National Bureau of Standards, "Data "Guidelines for
Implementing and Using the Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication 46-
1, January 1988.
[4]
74, April 1981.
[FIPS-81]
US National Bureau of Standards, "DES Modes of Operation"
Federal Information Processing Standard (FIPS) Publication
81, December 1980.
[5] US National Bureau of Standards, "Guidelines for Implementing
[Matsui94]
Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
Springer-Verlag, 1994.
[RFC-1446]
Galvin, J., and Using McCloghrie, K., "Security Protocols for
Version 2 of the Data Encryption Standard", Federal Simple Network Management Protocol
(SNMPv2)", RFC-1446, DDN Network Information
Processing Standard (FIPS) Publication 74, Center, April 1981.
[6] Schneier, B., "Applied Cryptography", John Wiley & Sons, New
York, NY,
1993.
[RFC-1610]
Postel, J., "Internet Official Protocol Standards", STD 1,
RFC 1610, USC/Information Sciences Institute, July 1994. ISBN 0-471-59756-2
[7]
[RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[8] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-
280, July 1994.
[9] Biham, E., and Shamir, A., "Differential Cryptanalysis of the
Data Encryption Standard", Berlin: Springer-Verlag, 1993.
[10] Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
Advances in cryptology -- Eurocrypt '93 Proceedings, Berlin:
Springer-Verlag,
[Schneier94]
Schneier, B., "Applied Cryptography", John Wiley & Sons, New
York, NY, 1994.
[11] ISBN 0-471-59756-2
[Weiner94]
Wiener, M.J., "Efficient DES Key Search", School of Computer
Science, Carleton University, Ottawa, Canada, TR-244, May
1994. Presented at the Rump Session of Crypto '93.
[12] Galvin, J., and McCloghrie, K., "Security Protocols for Version
2 of the Simple Network Management Protocol (SNMPv2)", RFC-
1446, DDN Network Information Center, April 1993.
Troublemakers
Metzger, Karn & Simpson expires in six months [Page 5] 8]
DRAFT ESP DES-CBC January March 1995
Author's Address
Questions about this memo can also be directed to:
Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington,
DC 20375-5320
USA
Telephone: (DSN) 354-8590
Fax: (DSN) 354-7942
<atkinson@itd.nrl.navy.mil>
Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY 10033
perry@piermont.com
Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779
karn@unix.ka9q.ampr.org
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Troublemakers
Metzger, Karn & Simpson expires in six months [Page 6] 9]
DRAFT ESP DES-CBC January March 1995
Table of Contents
1. Introduction .......................................... 1
1.1 Keys ............................................ 1
1.2 Initialization Vector ........................... 1
1.3 Data Size ....................................... 2
1.4 Performance ..................................... 2
2. Payload Format ........................................ 2 3
3. Algorithm ............................................. 4
3.1 Encryption ...................................... 5
3.2 Decryption ...................................... 6
SECURITY CONSIDERATIONS ...................................... 4 6
ACKNOWLEDGEMENTS ............................................. 4 7
REFERENCES ................................................... 5 7
AUTHOR'S ADDRESS ............................................. 5 8
----