Security Working Group D. Frommer
Internet Draft RADGUARD
Expires in six months June 1996
The DES-CBC plus DES-MAC Security Transform
draft-frommer-sec-transform-00.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 working group mailing list (ipsec@tis.com) or the author.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing 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 refer-
ence 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)
Frommer expires in six months [Page i]
DRAFT ESP DES-CBC-DES-MAC June 1996
Abstract
This document describes the use of DES-CBC for confidentiality
plus DES Message Authentication Code (MAC) for integrity, in the
IP Encapsulating Security Payload (ESP).
The use of the DES algorithm for both purposes may serve useful in
environments where hardware acceleration is available.
Frommer expires in six months [Page ii]
DRAFT ESP DES-CBC-DES-MAC June 1996
1. Introduction
The Encapsulating Security Payload (ESP) [RFC-1827] provides confi-
dentiality for IP datagrams by encrypting the payload data to be pro-
tected.
This specification describes the ESP for both confidentiality and
integrity. Confidentiality is based on the Cipher Block Chaining
(CBC) mode of the US Data Encryption Standard (DES) algorithm
[FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. For integrity calculation the
DES MAC (DES-CBC residue) algorithm is used. The MAC value is the last
DES CBC block computed over the data using a different key.
This document assumes that the reader is familiar with the related
document "Security Architecture for the Internet Protocol"
[RFC-1825], that defines the overall security plan for IP, and pro-
vides important background for this specification.
1.1. Keys
There are two DES keys used by this transform, one used for
confidentiality and the other for integrity. The keys are provided by
the key management protocol.
DES keys are secret keys shared between the communicating parties and
are eight octets (64-bits) in length. The keys consist of a 56-bit
quantity stored as a 64-bit quantity, with the least significant bit of
each octet used as a parity bit.
For security reasons, it is required that the two keys be different
[Kaufman95, p 91].
Frommer expires in six months [Page 1]
DRAFT ESP DES-CBC-DES-MAC June 1996
1.2. Initialization Vectors
The CBC mode of DES requires an Initialization Vector (IV) that
is eight octets (64-bits) in length. The IV for confidentiality
purposes, denoted in this document as CIV is contained in each
datagram. Including the CIV in each datagram ensures that decryption
can be performed, even when other datagrams are dropped, or
datagrams are re-ordered in transit. The IV for integrity is not
included in datagrams and implicitly assumed to have a value of zero.
Implementation Notes:
A common technique for the IV is simply a counter, beginning with a
randomly chosen value. This provides an easy method for preventing
repetition, and is sufficiently robust for practical use.
Other implementations 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 rep-
etition during the lifetime of the session key.
1.3. Data Size
The DES algorithm operates on blocks of eight octets (64-bits). This
often requires padding after the end of the unencrypted payload data.
Both input and output result in the same number of octets. This
facilitates in-place encryption and decryption.
On receipt, if the length of the data to be decrypted is not an inte-
gral multiple of eight octets, then an error is indicated, as
described in [RFC-1825].
1.4. Performance
The DES algorithm is designed to perform well using hardware
implementations. Commonly available DES hardware is considerably
faster than software implementations on popular processors. The
use of hardware allows a level of parallelism between the CPU
and the DES hardware, especially important in security gateway
implementations. In addition, the DES calculation of both
integrity and confidentiality may be performed in parallel given
the appropriate hardware.
Frommer expires in six months [Page 2]
DRAFT ESP DES-CBC-DES-MAC June 1996
2. Payload Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Confidentiality Initialization Vector (CIV) | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- |
| | ^ |
~ Payload Data ~ | DES
| | DES MAC
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC |
| | Padding | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Payload Type | V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- ---
| DES Residue |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameters Index (SPI)
4 octets. Identifies the Security Parameters for
this datagram. The value MUST NOT be zero.
Confidentiality Initialization Vector (CIV)
8 octets. This is the initialization vector used
by the DES CBC algorithm for confidentiality purposes.
Payload Data variable.
Prior to encryption and after decryption, this field
begins with the IP Protocol/Payload header specified
in the Payload Type field. Note that in the case of
IP-in-IP encapsulation (Payload Type 4), this will
be another IP header.
Padding variable.
Prior to encryption, it is filled with unspecified
implementation dependent (preferably random) values,
to align the Pad Length and Payload Type fields at
an eight octet boundary.
After decryption, it MUST be ignored.
Frommer expires in six months [Page 3]
DRAFT ESP DES-CBC-DES-MAC June 1996
Pad Length 1 octet. Indicates the size of the Padding field.
It does not include the Pad Length and Payload Type
fields. The value typically ranges from 0 to 7, but
may be up to 255 to permit hiding of the actual data
length.
This field is opaque. That is, the value is set
prior to encryption, and is examined only after
decryption.
Payload Type 1 octet. Indicates the contents of the Payload Data
field, using the IP Protocol/Payload value. Up-to-
date values of the IP Protocol/Payload are specified
in the most recent "Assigned Numbers" [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
(Tunnel-Mode), this field will contain the value 4,
indicating IP-in-IP encapsulation.
DES Residue 8 octets. Filled with the result of the DES MAC
calculation.
Frommer expires in six months [Page 4]
DRAFT ESP DES-CBC-DES-MAC June 1996
3. Algorithm
DES-CBC is used for both confidentiality and integrity calculations.
For confidentiality, the IV (CIV) is supplied in the packet. Each
plaintext block is XOR'd with the previous ciphertext block, and the
DES encryption function is applied to yield the ciphertext for the
current block. This provides for resynchronization when datagrams
are lost.
For integrity, the IV is implicitly assumed to be zero. DES-CBC
using a different key than the one used for confidentiality is
calculated over the ciphertext. The produced last block is used
as the DES MAC.
For more explanation and implementation information for DES, see
[Schneier95]. The use of DES for both integrity and confidentiality is
discussed in [Kaufman95, p 91].
3.1. Transmission
Append zero or more octets of (preferably random) padding to the
plaintext, to make its modulo 8 length equal to 6. For example, if
the plaintext length is 41, 5 octets of padding are added.
Append a Pad Length octet containing the number of padding octets
just added.
Append a Payload Type octet containing the IP Protocol/Payload value
identifying the protocol header that begins the payload.
Provide a Confidentiality Initialization Vector (CIV), as described ear-
lier.
Encrypt the payload with DES in CBC mode, producing a ciphertext of
the same length.
Octets are mapped to DES blocks in network order (most significant
octet first) [RFC-1700]. Octet 0 (modulo 8) of the payload corre-
sponds to bits 1-8 of the 64-bit DES input block, while octet 7 (mod-
ulo 8) corresponds to bits 57-64 of the DES input block.
Add the SPI and IV in front of the Payload Data.
Calculate the 64-bit DES Residue value over the CIV and ciphertext
Payload Data, Padding, Pad Length, and Payload Type. Append it to the
packet tail.
Frommer expires in six months [Page 5]
DRAFT ESP DES-CBC-DES-MAC June 1996
Construct an appropriate IP datagram for the target Destination. The
Total/Payload Length in the encapsulating IP Header reflects the
length of the encrypted data, plus the SPI, CIV, Padding, Pad Length,
Payload Type, and DES Residue.
3.2. Reception
First, the SPI field is examined. This is used as an index into the
local Security Parameter table to find the negotiated parameters and
decryption/integrity keys.
The DES Residue is verified by calculating the DES CBC algorithm
over the CIV and the encrypted part of the payload.
The SPI and CIV fields are removed.
The encrypted part of the payload is decrypted using DES in the CBC
mode. The CIV is used as the initialization vector.
The Payload 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 Payload
Type field.
Frommer expires in six months [Page 6]
DRAFT ESP DES-CBC-DES-MAC June 1996
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 the 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 [Schneier95, p 280].
Despite several potential risks, the level of privacy pro-
vided by use of ESP DES-CBC-DES-MAC in the Internet environment is
far greater than sending the datagram as cleartext.
Acknowledgements
Significant portions of this specification are derived from earlier
work by Phil Karn, Perry Metzger and Bill Simpson.
Frommer expires in six months [Page 7]
DRAFT ESP DES-CBC-DES-MAC June 1996
References
[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.
[FIPS-46-1]
US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS) Publication
46-1, January 1988.
[FIPS-74]
US National Bureau of Standards, "Guidelines for Implement-
ing and Using the Data Encryption Standard", Federal Infor-
mation Processing Standard (FIPS) Publication 74, April
1981.
[FIPS-81]
US National Bureau of Standards, "DES Modes of Operation"
Federal Information Processing Standard (FIPS) Publication
81, December 1980.
[Kaufman95]
Kaufman, C., Perlman, R. and Speciner, M., "Network Security:
Private Communication in a Public World", PTR Prentice Hall,
Englewood Cliffs, New Jersey, 1995. ISBN 0-13-061466-1
[RFC-1446]
Galvin, J., and McCloghrie, K., "Security Protocols for Ver-
sion 2 of the Simple Network Management Protocol (SNMPv2)",
RFC-1446, DDN Network Information Center, April 1993.
[RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
RFC-1700, USC/Information Sciences Institute, October 1994.
[RFC-1800]
Postel, J., "Internet Official Protocol Standards", STD 1,
RFC-1800, USC/Information Sciences Institute, July 1995.
[RFC-1825]
Atkinson, R., "Security Architecture for the Internet Proto-
col", RFC-1825, Naval Research Laboratory, July 1995.
Frommer expires in six months [Page 8]
DRAFT ESP DES-CBC-DES-MAC June 1996
[RFC-1826]
Atkinson, R., "IP Authentication Header", RFC-1826, Naval
Research Laboratory, July 1995.
[RFC-1827]
Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
RFC-1827, Naval Research Laboratory, July 1995.
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7
Frommer expires in six months [Page 9]
DRAFT ESP DES-CBC-DES-MAC June 1996
Author's Address
Questions about this memo can be directed to:
Dan Frommer <dan@radguard.com>
RADGUARD, Ltd.
24 Raoul-Wallenberg St.
Tel Aviv 69719
Israel
Telephone: +972-3-645-5396
Frommer expires in six months [Page 10]