Security Working Group IPsec Working Group INTERNET-DRAFT J. Hughes, Editor April 1996 Expires in Six months Combined DES-CBC, HMAC 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@tis.com) or to the editor. 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 and optionally, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. Hughes [Page 1] INTERNET DRAFT April 1996 Discussion This draft allows a combination of MD5 and DES-CBC. In addition to privacy, the goal of this transform is to ensure that the packet is authentic, can not be modified in transit, or replayed. The valid combinations of this transformation are summarized below. Name Description -------- -------------- esp-DES-IV32 Privacy Tunnel (32 IV) esp-DES-IV64 Privacy Tunnel (64 IV) esp-DES-HMAC-RP DES, HMAC, Replay (Mandatary transform) The combinations of transformations are negotiated at key establishment time such as described in ISA/KMP [Maughan96] and Oakley [Orman96]. To conform with this RFC, of the 3 transforms documented in this RFC, only esp-DES-HMAC-RP shall be implemented. Packet Format There are 3 slightly different packet formats. Format with 32 bit IV (esp-DES-IV32) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Hughes [Page 2] INTERNET DRAFT April 1996 Format with a 64 bit IV: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 64 bit IV + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | ^ ~ Payload Data ~ | | | DES + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | Padding (0-7 bytes) | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Pad Length | Payload Type | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Format with DES, HMAC and replay (esp-DES-HMAC-RP) (This is the Mandatary transform) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Replay Prevention Field | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | | ^ HMAC ~ Payload Data ~ | | | | DES | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CBC | | | Padding (0-7 bytes) | | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | | ~ HMAC Residual ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Parameters Index This field is negotiated at key setup and shall not be 0 [RFC-1825] Hughes [Page 3] INTERNET DRAFT April 1996 Initialization Vector IV for the first block is either formed from the replay field or from a 32 or 64 bit IV field. The section on replay describes the calculation of the IV when the replay field is present. If a 64 bit IV is used, the entire 64 bits are the IV. If a 32 bit IV is used, the 32 bit IV and its compliment are then concatenated to form the 64 bit IV and that is them XORed by the IV key. Replay Prevention Replay Prevention is an unsigned 32 bit up counter starting at a value of 1. The replay field is also used to create the IV for the first block of ciphertext. This is accomplished by concatenating the SPI and the replay field and XORing this against 64 bits of IV key material (see section on keys). The resulting 64 bits are the IV. 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. If more than 2^32 packets are transmitted, the counter will alias back to the initial value. Counter wrapping shall be considered a replay attack. At the receiving point, the replay value is assured to be increasing. The implementation may accept of out of order packets. The number of packets wiling to accept out of order is an implementation detail. If a "out of order window" is supported, the implementation shall ensure that any and all packets accepted out of order are guaranteed not to have arrived before. That is, the implementation will accept any packet at most once. An example may allow the most recent 32 packets to be allowed to arrive out of order. That is, these 32 packets can arrive in any sequence relative to each other except that these packets are guaranteed to arrive only once. Other window sizes are optional, both larger and smaller. Appendix A has actual code that implement a 32 packet replay window Hughes [Page 4] INTERNET DRAFT April 1996 and a test routine to show how it works. Payload The payload contains data that is described by the payload type field. This is a byte length field that can end on any boundary within a word. Padding Shall contains the number of pad bytes to fill the space between the end of the payload and the "pad length" field so that the "payload type" field ends on a double word boundary. Padding bytes man be initialized with random data. More than the minimum bytes necessary to achieve a double word boundary may inserted provided that the total number of bytes added are less than 255. Pad Length Shall contain an unsigned number of bytes of padding. A value of 0 means there was no padding and that the byte immediately preceding the Pad Length field is the last byte of the payload. Payload Type Describes what the payload is. The values are described in: ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers Hughes [Page 5] INTERNET DRAFT April 1996 HMAC Residual The HMAC residual is a 128 bit residue described in [Krawczyk96]. This covers the SPI, replay, payload, padding, pad length, payload type. HMAC is a keyed algorithm and shall use the HMAC key as described in the section on keys. Key Material The key material for the transform is provided by key management protocol. These bits will be hashed down so that the quality of the bits do not need to have 100% entropy. There are 4 keys. The key management key "K", the "DES Key", the "IV key" and the "HMAC key". The key provided by the key management layer is K. All the other keys are derived from that key. Let MD5(x|y) describes taking the residual x concatenated with y. Let Truncate(x,n) takes the first n bits from x and discards the rest. DES Key = Truncate(MD5( DPad | K ),64) IV Key = Truncate(MD5( IPad | K ),64) HMAC Key = MD5( HPad | K ) where each _Pad is 512 bit string. DPad = 0x5C repeated 64 times. IPad = 0xAC repeated 64 times. HPad = 0x53 repeated 64 times. The 16 byte intermediate residuals can be precalculated from these constants. This method will work with key material from the key server of any size, caveat emptor. Hughes [Page 6] INTERNET DRAFT April 1996 Security Considerations The claims of privacy, integrity, authentication, and optional replay prevention are made in this draft. I will not try to diagram all the security considerations. A good text is [Schneier95]. Privacy is provided by DES-CBC [Schneier95]. Integrity is provided by HMAC [Krawczyk96]. Authentication is provided since only the source and destination know the HMAC key. If the HMAC is correct, it proves that it must have been added by the source, since only the source knows the HMAC key. Replay prevention is provided by the combination of a constantly increasing count, the SPI and the HMAC key. The integrity of the replay field is provided by the HMAC. There are active attacks to esp-DES-IV32 and esp-DES-IV64 which can (in certain circumstances) compromise the confidentiality of messages encrypted under the DES privacy transform, when no message integrity protection is in use [Bellovin96]. The ESP-DES-HMAC-RP transform described in this draft is immune to this active attack. (AH [RFC-1826], in some modes, can also provide immunity to this attack [Bellovin96].) References [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Protocols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, July, 1996. [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: Keyed-MD5 for Message Authentication", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- hmac-md5-00.txt, March, 1996 [Maughan96] Maughan, D., Schertler, M. Internet Security Association and Key Management Protocol (ISAKMP) http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- isakmp-04.txt, February, 1996 Hughes [Page 7] INTERNET DRAFT April 1996 [Orman96] Orman, H., "The Oakley Key Determination Protocol", http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- oakley-00.txt, February, 1996. [RFC-1825] Atkinson, R, "Security Architecture for the Internet Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-1826] Atkinson, R, "IP Authentication Header", ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. [Schneier95] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 Acknowledgements This document is the result of significant work by several major contributors. They include (in alphabetical order): Robert W. Baldwin RSA Labs. Kevin Kingdon RSA Labs Hugo Krawczyk IBM Corporation Perry Metzger Piermont Information Services Bill Simpson Computer Systems Consulting Services David A Wagner University of California at Berkeley Hughes [Page 8] INTERNET DRAFT April 1996 In addition, the contributions of the entire IPSEC Working Group are acknowledged. The IPsec working group can be contacted through the chairs: Ran Atkinson Cisco Systems Paul Lambert Oracle Corporation Editor's Address James P. Hughes Network Systems Corporation Hughes [Page 9] INTERNET DRAFT April 1996 Appendix A This is a routine that implements a 32 packet window. This is intended on being an implementation sample. #include #include typedef unsigned long u_long; enum { ReplayWindowSize = 32 }; u_long bitmap = 0; /* session state - must be 32 bits */ u_long lastSeq = 0; /* session state */ /* Returns 0 if packet disallowed, 1 if packet permitted */ int ChkReplayWindow(u_long seq); int ChkReplayWindow(u_long seq) { u_long diff; if (seq == 0) return 0; /* first == 0 or wrapped */ if (seq > lastSeq) { /* new larger sequence number */ diff = seq - lastSeq; if (diff < ReplayWindowSize) { /* In window */ bitmap <<= diff; while (diff > 1) bitmap &= ~(1 << --diff); bitmap |= 1; /* set bit for this packet */ } else bitmap = 1; /* This packet has a "way larger" */ lastSeq = seq; return 1; /* larger is good */ } diff = lastSeq - seq; if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ if (bitmap & (1 << diff)) return 0; /* this packet already seen */ bitmap |= (1 << diff); /* mark as seen */ return 1; /* out of order but good */ } Hughes [Page 10] INTERNET DRAFT April 1996 char string_buffer[512]; #define STRING_BUFFER_SIZE sizeof(string_buffer) int main() { int result; u_long last, current, bits; printf("Input initial state (bits in hex, last msgnum):0); if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); sscanf(string_buffer, "%lx %lu", &bits, &last); if (last != 0) bits |= 1; bitmap = bits; lastSeq = last; printf("bits:%08lx last:%lu0, bitmap, lastSeq); printf("Input value to test (current):0); while (1) { if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; sscanf(string_buffer, "%lu", ¤t); result = ChkReplayWindow(current); printf("%-3s", result ? "OK" : "BAD"); printf(" bits:%08lx last:%lu0, bitmap, lastSeq); } return 0; } Hughes [Page 11] INTERNET DRAFT April 1996 Appendix B, Sample Packet Format This appendix contains sample packets for use by implementors checking the their implementations. This is not intended to be a complete test, but it intended to be a single data point. The keys used in this example are: DES Key = 12345678 9abcdef0 IV Key = 87654321 0fedcba9 HMAC Key = 01020304 05060708 090a0b0c 0d0e0f10 Sample packet format in mode esp-DES-IV64 (Privacy Tunnel (64 IV)) Offset Field Data encoded packet 00 SPI 00000100 04 IV 45454545 08 a6a6a6a6 0c data 11111111 2a7440e8 10 22222222 182aaace 14 33333333 5709748b 18 44444444 2b73fd63 1c 00000000 4da53aea 1c Pad 00000604 d2b2c83b Sample packet format in mode esp-DES-HMAC-RP (DES, HMAC, Replay (Mandatary transform). Offset Field Data encoded packet 00 SPI 00000100 04 Replay 00000001 08 data 11111111 885da058 0c 22222222 c548a6f4 10 33333333 f1576af7 14 44444444 eadcc0f0 18 00000000 7d7ad17a 1c Pad 00000604 9284ed5a 20 HMAC d6e8a3f2 24 bfebd36e 28 aa0cf05f 2c ac278b32 Hughes [Page 12]