Security Working Group J. Hughes
INTERNET DRAFT Network Systems Corp.
February 1996
Expires in six months
Combined DES-CBC, MD5 and Replay Prevention Security Transform
<draft-ietf-ipsec-esp-des-md5-00.txt>
Status of this Memo
This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed
to the working group mailing list (ipsec@ans.net) or to the author.
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 draft documents 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 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).
Distribution of this memo is unlimited.
Abstract
This draft describes a combination of privacy, authentication,
integrity and optional replay prevention into a single packet format.
This draft extends rfc1829.
Discussion
This draft allows a combination of MD5 and DES-CBC. The goal is to
ensure that the packet is authentic, can not be modified in transit,
or replayed.
Replay is optional. The inclusion of the replay field is negotiated
as a part of the key exchange.
Hughes FORMFEED[Page 1]
RFC DRAFT February 1987
The combinations of trasformations are summarized below.
DES-CBC MD5 Replay
RFC1829(ESP) Yes No No
RFC1828(AH) No Yes No
This Draft Yes Yes No
This Draft Yes Yes Yes
Packet Format
The only difference from rfc1829 is s the inclusion of a MD5 residual
and an optional replay field.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initialization Vector (IV) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- ---
| | ^ ^
~ Payload Data ~ | |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Padding (0-7 bytes) | MD5 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Payload Type | | DES-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBC
| | | |
+ Replay Prevention Field (optional) + | |
| | v |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- |
| | |
+ MD5 Residual + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Replay Prevention
Replay prevention field is a 64 bit value that is used to make sure
that a previous packet can not be sent again and be decrypted
correctly and inserted into the stream again.
Hughes FORMFEED[Page 2]
RFC DRAFT February 1987
The format of the replay field is two 32 bit fields. The first 32
bits is a session specific nonce. This value will be constant for the
entire time that this key is in use. If both directions use the same
encryption key, each directions shall use a different nonce.
For example, the nonce can be the time of day that this session was
established.
This field is negotiated as a part of the key exchange.
The second 32 bits is a simple binary up counter.
The replay prevention is provided by making sure that the nonce is
correct and that the counter is going up.
The key must not be used for a period of time that allows the counter
to wrap, that is, to transmit more than 2^32 packets using a single
key. (Rfc1829 recommends changing the keys at least this often.)
Note: It is possible to use the "incrementing IV" method
discussed in rfc1829, but there are 2 problems. First, the
"incrementing IV" method discussed in rfc1829 does not cover
sending a packet which is recorded in one direction in the other
direction (if both directions are using the same key).
Second, the "incrementing IV" method described in rfc1829 is not
checked for integrity. Changes in the IV will show through in
the first block of the plaintext and may or may not be detected
by the host once the packets are decrypted.
MD5 Residual
The MD5 residual is a 128 bit MD5 (rfc1321) of the payload, padding,
pad length, payload type and optional replay field. Note that the
length of the area that the MD5 covers is a multiple of 64 bits.
Note: This MD5 is not keyed nor includes any header nor other
information than is specified here.
Security Considerations
The claims of privacy, integrity, authentication, and optional replay
prevention are made in this draft.
Privacy is provided by DES-CBC. (This could actually be performed by
any 64 bit block algorithm in CBC mode.) See the discussion of DES-
CBC in rfc1829.
Hughes FORMFEED[Page 3]
RFC DRAFT February 1987
Integrity is provided by the combination of DES and MD5. Since the
MD5 residual is under the DES transformation, the packet can not be
changed in a reliable way that will not be detected by MD5.
Authentication is provided since only the source and destination know
the DES key. Since the MD5 is under the DES transformation, it can
not be checked until after the packet is decrypted. If the MD5 is
correct, it proves that it must have been encrypted by the source,
since only the source knows the key. (If an evesdropper knows the
keys, all bets are off anyway..)
Replay prevention is provided by the combination of a constantly
increasing count with a nonce, and the replay field is covered by MD5
and MD5 is transformed by DES.
Author's Address:
James P. Hughes
Network Systems Corporation
Brooklyn Park, MN
Hughes FORMFEED[Page 4]
