Internet DRAFT - draft-ietf-ipsec-des-md5
draft-ietf-ipsec-des-md5
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 04:13:47 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 30 Apr 1996 22:00:00 GMT
ETag: "2f5407-4c4c-31868d60"
Accept-Ranges: bytes
Content-Length: 19532
Connection: close
Content-Type: text/plain
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
<draft-ietf-ipsec-des-md5-01.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@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
<baldwin@rsa.com>
RSA Labs.
Kevin Kingdon
<kevin@rsa.com>
RSA Labs
Hugo Krawczyk
<hugo@watson.ibm.com>
IBM Corporation
Perry Metzger
<perry@piermont.com>
Piermont Information Services
Bill Simpson
<bill.simpson@um.cc.umich.edu>
Computer Systems Consulting Services
David A Wagner
<daw@cs.berkeley.edu>
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
<rja@cisco.com>
Cisco Systems
Paul Lambert
<PALAMBER@us.oracle.com>
Oracle Corporation
Editor's Address
James P. Hughes
<hughes@network.com>
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 <stdio.h>
#include <stdlib.h>
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]
