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 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]