idnits 2.17.1 draft-caronni-esp-stream-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '...s of up to and including 128 bits MUST...' RFC 2119 keyword, line 162: '...rk order). The value MUST NOT be zero....' RFC 2119 keyword, line 183: '...ield size is 32 bits. Applications MAY...' RFC 2119 keyword, line 196: '...le, the receiver MUST be able to accep...' RFC 2119 keyword, line 200: '...The sender MUST count all bytes encryp...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9416 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC1827' on line 72 looks like a reference -- Missing reference section? 'RFC1825' on line 85 looks like a reference -- Missing reference section? 'Schn96' on line 123 looks like a reference -- Missing reference section? 'RFC1700' on line 178 looks like a reference -- Missing reference section? 'RFC1810' on line 245 looks like a reference -- Missing reference section? 'RFC1750' on line 350 looks like a reference -- Missing reference section? 'Roos95' on line 358 looks like a reference -- Missing reference section? 'Roos95a' on line 363 looks like a reference -- Missing reference section? 'Roos95b' on line 363 looks like a reference -- Missing reference section? 'Bell96' on line 372 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES JAN 1999 INTERNET DRAFT 2 Network Working Group G. Caronni 3 INTERNET DRAFT M. Waldvogel 4 TIK, ETHZ, Switzerland 5 Category: Informational July 1998 7 The ESP Stream Transform 8 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Distribution of this document is unlimited. 32 Abstract 33 -------- 34 This document describes a security transform providing privacy and 35 optional replay protection through Encapsulating Secure Payload (ESP). 36 The transform defines how to use ESP in conjunction with byte-oriented 37 stream ciphers, such as RC4 or SEAL. These stream ciphers offer strong 38 encryption with comparatively low computational demands, and are thus 39 favorable for multimedia bulk data or environments where the computing 40 power needed per packet should be low. 42 Table of Contents 43 ----------------- 44 1. Introduction 45 1.1. Conventions 46 1.2. Cipher Overview 47 2. Payload Format 48 2.1. Stream Offset 49 2.2. Replay Protection Using the Stream Offset 50 2.3. Authentication Issues 51 3. Encryption 52 4. Decryption 53 5. Security Considerations 54 6. Implementation Details 55 6.1. Summary of Limits 56 6.2. Technical Notes 57 7. Acknowledgements 58 8. References 59 9. Author Addresses 61 1. Introduction 62 ---------------- 63 The mechanisms presented in this document provide confidentiality and 64 optional replay protection for IP datagrams, using the Encapsulating 65 Security Payload (ESP) [RFC1827] format. Although ESP may also provide 66 data integrity and authenticity, 'esp-stream' only offers encryption. 68 This document assumes that the reader is familiar with the related docu- 69 ment "Security Architecture for the Internet Protocol" [RFC1825], which 70 defines the overall security plan for IP and provides important back- 71 ground. Additionally, familiarity with "IP Encapsulating Security Pay- 72 load (ESP)" [RFC1827] is required, as some of the mechanisms employed 73 here are described in greater depth in that document. 75 1.1. Conventions 76 ----------------- 77 There are a few conventions we followed in this document that the reader 78 should be aware of: 80 a) Whenever it is said that something is ``LIMITED'', the appropriate 81 maximum and minimum values plus a set of recommended values are given 82 in section 6.1. 84 b) The meanings of capitalized ``MUST'', ``MUST NOT'', ``SHOULD'', and 85 ``MAY'' apply as declared in [RFC1825]. 87 c) Variables and constants in pseudo code are in ALL CAPITALS, to 88 clearly distinguish actual code symbols from the description of the 89 action. 91 1.2. Cipher Overview 92 --------------------- 93 Fast algorithms, such as RC4 (devised by Ron Rivest) or SEAL (by Phil 94 Rogaway and Don Coppersmith) are very efficient and easily understand- 95 able symmetric additive stream ciphers with a large internal state. The 96 efficiency with which they operate make them ideal candidates for 97 encrypting/decrypting high-throughput, low-latency data streams in 98 software with relatively low CPU usage or just whenever low CPU overhead 99 for security is needed. Such data streams are very common in modern 100 multi-media applications who transmit video data and/or high quality 101 audio data. RC4 has been used (together with SKIP prototypes) to encrypt 102 interactive video connections over IP. Resulting quality was adequate 103 and acceptable. 105 For all stream ciphers, key lengths of up to and including 128 bits MUST 106 be supported by the implementation, although any particular key may be 107 shorter. Longer keys are strongly recommended. 109 RC4 allows for key sizes of up to 256 bytes. The key is used to permute 110 the values of 0 to 255 in an array of 256 entries, thus creating the 111 internal state for the pseudo random generator, whose output is used as 112 a one time pad for encryption/decryption. The initial state after keying 113 can thus be one out of 256! states, being equivalent to about 1676 bits 114 key state. 116 SEAL supports position-dependent key setup, expects 160 bits of key 117 material and allows initializing at any 32 bit offset into the stream. 118 SEAL may in certain environments be even faster than RC4. Key setup in 119 SEAL is much more expensive, as SHA is employed to generate the internal 120 state. 122 For more details about RC4, SEAL, and about using other stream ciphers, 123 refer to [Schn96]. Please note that SEAL is being patented by IBM, and 124 RC4, although interoperable code is available, is a proprietary algo- 125 rithm of RSA Data Security Inc. RC4 is trademarked by RSA DSI, anybody 126 contemplating its use should contact them. 128 2. Payload Format 129 ------------------ 130 The following diagram describes the basic format of IP packets contain- 131 ing the 'esp-stream' header and data. The selection of the actual stream 132 cipher and the key to be used has to take place on a upper layer. 134 |<---- Plain ---->|<---- Encrypted ---->| 135 +-----------+-----------------+------------+----------------+------+ 136 | IP Header | IP Ext. Headers | ESP Header | Encrypted Data | Type | 137 +-----------+-----------------+------------+----------------+------+ 139 A more detailed diagram of the format of the particular ESP Header 140 (labelled ``E'' in the left column shown in diagram below) to be used 141 with stream ciphers and the data following it (Data labelled ``D'', Type 142 labelled ``T'') is given below, together with a short description of 143 every field. 145 |1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8| 146 - +---------------+---------------+---------------+---------------+ 147 E | Security Parameters Index (SPI) | 148 E +---------------------------------------------------------------+ 149 E | Stream Offset | 150 - +---------------------------------------------------------------+ 151 D | | 152 D : Encrypted Payload Data (arbitrary number of bytes) : 153 D | | 154 D | +---------------+---------------+ 155 T | | Payload Type | 156 - +-------------------------------+---------------+ 158 Notes 159 ----- 160 Security Parameters Index (SPI) 161 A 32-bit value identifying the Security Parameters for this 162 datagram (network order). The value MUST NOT be zero. 164 Stream Offset (32 bits, optionally 64 bits) 165 Indicates the number of data bytes already encrypted under the 166 current key for this cipher before this packet was encrypted. This 167 value is stored in network order (most significant octet first) 168 [RFC1700]. For details, see section 2.1. 170 Encrypted Payload Data (arbitrary number of bytes) 171 Encapsulated IP or other protocol data, encrypted. No padding is 172 required. 174 Payload Type (8 bits) 175 Contains the encrypted type of the next protocol header in the 176 encrypted payload data. Up-to-date values of the IP 177 Protocol/Payload are specified in the most recent "Assigned 178 Numbers" [RFC1700]. This value is encrypted together with the pay- 179 load, and may only be examined after decryption. 181 2.1. Stream Offset 182 ------------------- 183 The recommended Stream Offset field size is 32 bits. Applications MAY 184 however choose to implement a 64 bit Stream Offset field. It is the task 185 of the upper layer (e.g. the key management protocol) to decide which of 186 the two solutions is being used for a given connection. See also section 187 6.2. 189 Current stream ciphers were not designed for integration in IP. There- 190 fore, provisions for detecting and handling out of order delivery, 191 duplicate or missing packets must be taken additionally. The Stream 192 Offset field is used at the receiving end to prepare the ciphers inter- 193 nal state such that decrypting is possible even in case of abovemen- 194 tioned events. 196 To make this possible, the receiver MUST be able to accept packets with 197 Stream Offset being a LIMITED number of bytes ahead or before the 198 previously received Stream Offset. 200 The sender MUST count all bytes encrypted before the first byte in this 201 packet is encrypted and send this value as this packet's Stream Offset. 202 The counter MUST be initialized with zero when the encryption key is 203 used the first time. It MUST be reset to zero if and only if the 204 encrypting key changes. It MUST NOT be reset at any other time. Espe- 205 cially, it MUST NOT be allowed to wrap around to zero, the encryption 206 key MUST be changed instead. It is most important (see security con- 207 siderations in section 5), that no encrypting key is used with the same 208 Stream Offset twice. Thus, after the encrypting key has been changed, 209 the probability for its reuse MUST be as small as practically feasible. 210 Ideally, an old encryption key SHOULD NOT be reused ever. 212 The sender MAY encrypt a LIMITED number of dummy bytes between packets, 213 although this is discouraged, because it would use more cache space at 214 the receiver. 216 2.2. Replay Protection Using the Stream Offset 217 ----------------------------------------------- 218 Since the sender creates Stream Offsets so that for any two packets 219 encrypted with the same key their ranges [Stream Offset .. (Stream 220 Offset + Encrypted Bytes in Packet - 1)] are free of intersections, the 221 receiver may optionally check this range independence to protect against 222 replay attacks. The receiving end may independently decide whether 223 replay protection is to be performed or not, it is not mandatory that 224 the sender be involved in this decision. Doing replay protection on the 225 receiving side is strongly recommended. 227 To achieve Replay Protection, the receiver has to remember the ``holes'' 228 in the Stream where incoming packets may still be accepted. For each 229 currently employed key, a LIMITED list of valid Stream Offset ranges has 230 to be stored. They cover the range starting from the end of the 231 `highest' received packet up to the maximum offset, and ranges where 232 packets have not yet been delivered (e.g. were lost in transit or will 233 be delivered out of order). In section 4 we will give pseudo code that 234 implements replay protection for the receiving end, at the same time 235 allowing for reception of out of order packets. 237 2.3. Authentication Issues 238 --------------------------- 239 Authentication is not included into the 'esp-stream' transform, mainly 240 because of the following points: 242 a) The main reason to employ stream ciphers such as RC4 or SEAL is the 243 remarkable speed of these algorithms. MD5 software speeds are ade- 244 quate for commonly deployed LAN and WAN links, but reportedly are too 245 slow for newer link technologies [RFC1810]. If faster implementations 246 emerge, their use is strongly recommended, as encryption without 247 authentication offers only a very limited amount of security. 249 b) Authentication may be chosen as an orthogonal transform in addition 250 to this transform, so users have the ability to choose the authenti- 251 cation that best fits necessities in speed and security at runtime. 253 3. Encryption 254 -------------- 255 Procedural description of the encryption process: 257 Encrypt packet: 258 Prepare sufficient space before and after the payload; 259 Append a Payload Type byte describing the type of encapsulated data; 260 Store the SPI in the SPI field; 261 Get the current internal state associated with this security association; 262 Store the number of data bytes already encrypted with the current key 263 into the Stream Offset field; 264 Encrypt the payload and the Payload Type byte, updating the internal state; 265 Generate outer headers such as AH or IP; 266 Send packet; 268 4. Decryption 269 -------------- 270 Pseudo code to allow efficient handling of out of order packet reception 271 and packet loss including replay protection is given below. To remember 272 the range of Stream Offsets already used by the received packets, a set 273 of 3-tuples for each packet key is stored. It contains start of used 274 range, end of used range (=start+length, effectively being start of next 275 expected packet), and cipher internal state associated with the Stream 276 Offset of the packet that would immediately follow. 278 If no protection against replay attacks is required, the following 279 pseudo code may be simplified. We strongly recommend using replay pro- 280 tection, as the additional cost is low and the benefits are large. 282 FORWARD_SEEK_LIMIT and STATE_CACHE_ENTRIES are defined in section 6.1, 283 DATA_SIZE includes the actual Payload size and the one byte Payload Type 284 field. 286 Key initialization (input: KEY): 287 Set INTERNAL_STATE to the result of prepare_key(KEY); 288 Store tuple (0, 0, INTERNAL_STATE); 289 Return; 291 Decrypt packet (input: ESP_HEADER, ESP_DATA, DATA_LENGTH): 292 Process all outer headers; 293 Set START to Stream Offset found in ESP_HEADER; 294 Set END to START + DATA_LENGTH; 295 If intersection between [START..END] and any stored range { 296 Drop packet and return; // Replay, garbage, or duplicate packet 297 } 298 Set PREDECESSOR to tuple with biggest end <= START; 299 If no PREDECESSOR was found { 300 Drop packet and return; // Packet too old 301 } 302 If START minus PREDECESSOR.END is greater than FORWARD_SEEK_LIMIT { 303 Drop packet and return; // Too far out in ``future'' key stream 304 } 305 If START equals PREDECESSOR.END { 306 Set WORK to PREDECESSOR; 307 } else { 308 // Seek forward to a new IV 309 Duplicate of PREDECESSOR.IV, call it TEMP_IV; 310 Run rc4 on PREDECESSOR.END-START dummy bytes 311 with TEMP_IV, updating it; 312 Store new tuple WORK = (START, START, TEMP_IV); 313 } 314 // We have a tuple just preceding ours, 315 // extend it by our newly received range 316 decrypt with WORK.IV, updating the IV; 317 Set WORK.END to END; 318 If there is a tuple NEIGHBOR whose start == END { 319 // join the two ranges into one 320 Set NEIGHBOR.START to WORK.START; 321 Delete WORK; 322 } 323 If more than STATE_CACHE_ENTRIES tuples are stored { 324 // delete the first (oldest) hole. 325 Set START of the first remaining tuple to 0; 326 } 327 Get Payload Type; 328 If Payload Type is valid { 329 Process packet according to payload type and return; 330 } else { 331 Drop the packet and return; 332 } 334 It is suggested that a new tuple (with extended range) is only stored if 335 the incoming packet is correctly authenticated. Alternatively, if no 336 authentication is required, it may also be stored if the packet decrypts 337 correctly (i.e. passes some integrity tests, such as a valid TCP or UDP 338 checksum in inner headers). This is to prevent denial of service attacks 339 involving excessive seeking in the key stream. In the case a packet 340 fails the verification the packet MUST be dropped. 342 5. Security Considerations 343 --------------------------- 344 One goal of this document is to allow different implementors of the 345 stream cipher RC4 to interoperate securely. Some of the security con- 346 siderations discussed here hold true for other ciphers. 348 Do NOT re-use key material. Do not use previous keys to generate new 349 keys, but use a reliable and well-initialized random number generator to 350 generate new keys. See [RFC1750] for additional information. If you do 351 re-use key material, the security of a stream cipher is instantly lost. 353 Remove all information belonging to old keys whenever they become 354 invalid, including information held in caches, especially the ``hole'' 355 cache. The key management protocol in the upper layer has to decide when 356 a key becomes invalid. 358 As pointed out in [Roos95], there are classes of weak keys (especially 359 those whose first two bytes are two's complements of each other), which 360 SHOULD be avoided in RC4. 362 Since the first few bytes generated after the initial setup of the RC4 363 are those easiest cryptanalized and broken (see [Roos95a, Roos95b]), we 364 recommend that the sender SHOULD encrypt a LIMITED number of dummy bytes 365 (updating the internal state and the Stream Offset accordingly) before 366 starting to send packets. Receivers must be prepared to accept a first 367 packet with a Stream Offset that is equal to a LIMITED number of bytes 368 above zero. 370 We strongly recommend using authentication if your security requirements 371 are high and you want to protect against active attacks, such as those 372 described in [Bell96]. This paper also gives a good overview over the 373 risks and open security problems that need to be taken into considera- 374 tion. 376 6. Implementation Details 377 -------------------------- 378 6.1. Summary of Limits 379 ----------------------- 380 In the following table we show up to three values or ranges for every 381 variable: the minimum supported number (what each implementation MUST 382 support), some recommended values (what implementations SHOULD use), and 383 a maximum that MUST NOT be exceeded. The column ``Who'' indicates 384 whether the sender (S) or the recipient (R) or both need to support 385 these limits. Values are given in bytes, except where otherwise noted. 387 Name Who Minimum Recommended Maximum 388 (MUST) (SHOULD) 389 Key length (bits) SR 128 128 .. 2048 2048 390 Initial forward seek S 0 16 .. 1024 64K 391 Initial forward seek R 64K 392 Forward seek per packet R 32K .. 200K 512K 393 Backward history R 16K .. 100K 394 State cache entries per key R 4 .. 16 396 Notes 397 ----- 398 Key length 399 indicates the number of bits that an implementation must support, 400 although the use of shorter keys may be required in certain cir- 401 cumstances. 403 Initial forward seek 404 indicates the number of bytes the sender should seek forward before 405 encrypting the first packet. The receiver must accept a packet 406 encrypted with a new key with Stream Offsets going up to the value 407 of ``initial forward seek''. Be aware that the first packet 408 encrypted with the new key can get lost, so that senders can not 409 exploit the full limit on ``initial forward seek'' that receivers 410 have. 412 Forward seek per packet 413 indicates the amount of bytes that the receivers allows the Stream 414 Offset of two succeeding packets to be apart, thus restricting the 415 amount of forward or backward seeking that may be performed. Oth- 416 erwise, a denial of service attack could be easily mounted by forc- 417 ing the receiver to do exhaustive seeking in the cipher key stream. 419 Backward history 420 indicates the amount of past bytes for which the receiver should be 421 able to reconstruct the internal state of any ``hole'' (needed for 422 out of order delivery). 424 State cache entries per key 425 is the recommended number of previous internal states a receiver 426 should keep. Under normal circumstances this is enough to provide 427 good coverage of swapped and delayed packets. 429 6.2. Technical Notes 430 --------------------- 431 To prevent getting a blocked channel whenever packets are received out 432 of order, receivers SHOULD maintain multiple internal states for the 433 stream cipher, and handle these conditions gracefully. 435 It is also suggested, that the stream cipher is rekeyed frequently 436 (after short amounts of elapsed time) so that connections can easily 437 recover after excessive blocks of data have been lost. Otherwise the 438 limit on forward seeking at the receiving end might block the connec- 439 tion. 441 Seeking forward by n bytes in the cipher keystream is identical to 442 encrypting that many dummy bytes. Forward seeks may be optimized by 443 creating a dedicated procedure which only implements the relevant parts 444 of the algorithm. Sophisticated solutions may want to add the capability 445 for backward seeking in algorithms where this is possible (such as RC4), 446 and can then use the nearest stored state to seek to the needed posi- 447 tion. When algorithms (such as SEAL) are used, where the current posi- 448 tion in the stream can be set, use of this functionality is strongly 449 encouraged. 451 A Stream Offset field with a size of 32 bits wraps around about once 452 every 15 minutes for e. g. multimedia traffic of about 40 Mbit/sec as it 453 was observed during a distance learning project with several high- 454 quality audio/video streams at ETHZ. In view of these figures, and with 455 the increase in throughput that may be expected in the future, it seems 456 thus reasonable to optionally allow the use of a 64 bit Stream Offset 457 field. Larger Stream Offset fields do not make sense, given the short 458 life time of bulk data keying material. 460 Various other ciphers could be used together with this draft, even block 461 ciphers such as DES in CFB or OFB mode, where the Stream Offset would be 462 used as an initialisation vector. The key management solution that wants 463 to employ stream ciphers needs to specify e.g. the following data: 464 Traffic Encryption 465 Algorithm Number Algorithm Name Key Size Stream Offset Size 466 7 RC4 128 64 bit 467 8 RC4 40 32 bit 468 9 SEAL 128 32 bit 469 This is an example only, relevant information may be found in the 470 specifications for key management solutions. 472 7. Acknowledgements 473 -------------------- 474 We express our gratitude to Ron Rivest for pointing out legal aspects 475 relating to our original `alleged RC4' draft, and, nevertheless, for 476 devising such a simple and elegant cipher such as RC4. 478 In no particular order we would also like to thank the following people 479 for various important contributions, source code, comments and all other 480 kinds of involvement: Ran Atkinson, Christian Schneider, Michael Hauber, 481 Ashar Aziz, Tom Markson, Martin Patterson, Josef Reveane, Rich Skrenta, 482 Roy Schneider, Derek Palma, Terry Davis, and the authors of the RFCs 483 1826, 1828 and 1851 (see References below), from which many ideas were 484 used. 486 8. References 487 -------------- 489 Bell96 S. Bellovin, "Problem Areas for the IP Security Protocols", sub- 490 mitted to the Sixth USENIX Unix Security Conference, draft 491 available from ftp://ftp.research.att.com/dist/smb/badesp.ps. 493 RFC1700 J. Reynolds, J. Postel, "ASSIGNED NUMBERS", 10/20/1994, RFC 494 1700. 496 RFC1750 D. Eastlake, S. Crocker, J. Schiller, "Randomness Recommenda- 497 tions for Security", 12/29/1994, RFC 1750. 499 RFC1810 J. Touch, "Report on MD5 Performance", 06/21/1995, RFC 1810. 501 RFC1825 R. Atkinson, "Security Architecture for the Internet Protocol", 502 08/09/1995, RFC 1825. 504 RFC1826 R. Atkinson, "IP Authentication Header", 08/09/1995, RFC 1826. 506 RFC1827 R. Atkinson, "IP Encapsulating Security Payload (ESP)", 507 08/09/1995, RFC 1827. 509 RFC1828 P. Metzger, W. Simpson, "IP Authentication using Keyed MD5", 510 08/09/1995, RFC 1828. 512 RFC1851 P. Metzger, P. Karn, W. Simpson, "The ESP Triple DES-CBC 513 Transform", 10/02/1995, RFC 1851. 515 Roos95a A. Roos , "Weak Keys in RC4", Posted to 516 the Cypherpunks mailing list on Sep 22, 1995, see 517 http://turing.vironix.co.za/public/andrewr/WeakKeys1.htm 519 Roos95b A. Roos , "Weak Keys in RC4", Posted to 520 the Cypherpunks mailing list on Sep 29, 1995, see 521 http://turing.vironix.co.za/public/andrewr/WeakKeys2.htm 523 Schn96 B. Schneier, "Applied Cryptography: Protcols, Algorithms, and 524 Source Code in C (second edition)", John Wiley & Sons, New York, 525 1996. 527 9. Author addresses 528 -------------------- 529 Questions and comments about this memo can be directed to: 531 Germano Caronni (formerly with:) 532 Computer Engineering and Networks Laboratory 533 Swiss Federal Institute of Technology (ETH) 534 ETH Zentrum 535 CH-8092 Zurich 537 gec@acm.org 539 Marcel Waldvogel 540 Computer Engineering and Networks Laboratory 541 Swiss Federal Institute of Technology (ETH) 542 ETH Zentrum 543 CH-8092 Zurich 545 waldvogel@tik.ee.ethz.ch 546 INTERNET DRAFT EXPIRES JAN 1999 INTERNET DRAFT