idnits 2.17.1 draft-simpson-photuris-schemes-02.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 6 months document validity. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 88 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 219: '... a previous key MUST be discarded. A...' RFC 2119 keyword, line 221: '... MUST be discarded. The Key-Generat...' RFC 2119 keyword, line 293: '... tions MUST support at least 62 byte...' RFC 2119 keyword, line 294: '... key SHOULD provide at least 80-bits...' RFC 2119 keyword, line 328: '... [RFC-1852] et sequitur. The selected Exchange Scheme SHOULD provide...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1997) is 9781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Qualcomm' is mentioned on line 1, but not defined == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'RFC-1852' is mentioned on line 338, but not defined ** Obsolete undefined reference: RFC 1852 (Obsoleted by RFC 2841) == Unused Reference: 'RFC-1850' is defined on line 559, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DOW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'KR96' -- Possible downref: Non-RFC (?) normative reference: ref. 'PO96' ** Obsolete normative reference: RFC 1850 (Obsoleted by RFC 4750) ** Downref: Normative reference to an Experimental RFC: RFC 1851 ** Downref: Normative reference to an Experimental draft: draft-simpson-icmp-ipsec-fail (ref. 'RFC-xxxx') -- No information found for draft-ietf-ipsec-ciph-desx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC-yyyy' == Outdated reference: A later version (-18) exists of draft-simpson-photuris-13 ** Downref: Normative reference to an Experimental draft: draft-simpson-photuris (ref. 'RFC-zzzz') Summary: 17 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Karn [Qualcomm] 2 Internet Draft W A Simpson [DayDreamer] 3 expires in six months July 1997 5 Photuris: Extended Schemes and Attributes | 6 draft-simpson-photuris-schemes-02.txt | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Europe) 27 ds.internic.net (US East Coast) 28 ftp.isi.edu (US West Coast) 29 munnari.oz.au (Pacific Rim) 31 Distribution of this memo is unlimited. 33 Abstract 35 Photuris is a session-key management protocol. Extensible Exchange 36 Schemes are provided to enable future implementation changes without 37 affecting the basic protocol. | 39 Additional authentication attributes are included for use with the | 40 IP Authentication Header (AH). 42 Additional confidentiality attributes are included for use with the | 43 IP Encapsulating Security Protocol (ESP). 45 1. Additional Exchange Schemes - 47 The packet format and basic facilities are already defined for Pho- 48 turis [RFC-zzzz]. 50 These optional exchange schemes are specified separately, and no sin- 51 gle implementation is expected to support all of them. 53 This document defines the following values: 55 (3) Implementation Optional. Any modulus (p) with a recommended 56 generator (g) of 3. The modulus is contained in the Exchange 57 Scheme Value field in the list of Offered-Schemes. 59 The Key-Generation function is "MD5 Hash". | 61 The Privacy-Method is "Simple Masking". 63 The Validity-Method is "MD5-KMpKp Check". | 65 (4) Implementation Optional. Any modulus (p) with a recommended 66 generator (g) of 2. The modulus is contained in the Exchange 67 Scheme Value field in the list of Offered-Schemes. 69 The Key-Generation function is "MD5 Hash". | 71 The Privacy-Method is "DES-CBC over Mask". | 73 The Validity-Method is "MD5-KMpKp Check". 75 (5) Implementation Optional. Any modulus (p) with a recommended 76 generator (g) of 5. The modulus is contained in the Exchange 77 Scheme Value field in the list of Offered-Schemes. 79 The Key-Generation function is "MD5 Hash". | 81 The Privacy-Method is "Simple Masking". 83 The Validity-Method is "MD5-KMpKp Check". | 85 (6) Implementation Optional. Any modulus (p) with a recommended 86 generator (g) of 3. The modulus is contained in the Exchange 87 Scheme Value field in the list of Offered-Schemes. 89 The Key-Generation function is "MD5 Hash". | 91 The Privacy-Method is "DES-CBC over Mask". | 92 The Validity-Method is "MD5-KMpKp Check". 94 (7) Implementation Optional. Any modulus (p) with a variable gen- 95 erator (g). Each is encoded in a separate Variable Precision 96 Number. The generator VPN is followed by (concatenated to) the 97 modulus VPN, and the pair are contained in the Exchange Scheme 98 Value field in the list of Offered-Schemes. 100 The Key-Generation function is "MD5 Hash". | 102 The Privacy-Method is "Simple Masking". 104 The Validity-Method is "MD5-KMpKp Check". | 106 (8) Implementation Optional. Any modulus (p) with a recommended 107 generator (g) of 2. The modulus is contained in the Exchange 108 Scheme Value field in the list of Offered-Schemes. 110 The Key-Generation function is "SHA1 Hash". | 112 The Privacy-Method is "DES-EDE3-CBC over Mask". 114 The Validity-Method is "SHA1-KMpKp Check". | 116 (10) Implementation Optional. Any modulus (p) with a recommended 117 generator (g) of 5. The modulus is contained in the Exchange 118 Scheme Value field in the list of Offered-Schemes. 120 The Key-Generation function is "MD5 Hash". | 122 The Privacy-Method is "DES-CBC over Mask". | 124 The Validity-Method is "MD5-KMpKp Check". 126 (12) Implementation Optional. Any modulus (p) with a recommended 127 generator (g) of 3. The modulus is contained in the Exchange 128 Scheme Value field in the list of Offered-Schemes. 130 The Key-Generation function is "SHA1 Hash". | 132 The Privacy-Method is "DES-EDE3-CBC over Mask". 134 The Validity-Method is "SHA1-KMpKp Check". | 136 (14) Implementation Optional. Any modulus (p) with a variable gen- 137 erator (g). Each is encoded in a separate Variable Precision 138 Number. The generator VPN is followed by (concatenated to) the 139 modulus VPN, and the pair are contained in the Exchange Scheme 140 Value field in the list of Offered-Schemes. 142 The Key-Generation function is "MD5 Hash". | 144 The Privacy-Method is "DES-CBC over Mask". | 146 The Validity-Method is "MD5-KMpKp Check". 148 (20) Implementation Optional. Any modulus (p) with a recommended 149 generator (g) of 5. The modulus is contained in the Exchange 150 Scheme Value field in the list of Offered-Schemes. 152 The Key-Generation function is "SHA1 Hash". | 154 The Privacy-Method is "DES-EDE3-CBC over Mask". 156 The Validity-Method is "SHA1-KMpKp Check". | 158 (28) Implementation Optional. Any modulus (p) with a variable gen- 159 erator (g). Each is encoded in a separate Variable Precision 160 Number. The generator VPN is followed by (concatenated to) the 161 modulus VPN, and the pair are contained in the Exchange Scheme 162 Value field in the list of Offered-Schemes. 164 The Key-Generation function is "SHA1 Hash". | 166 The Privacy-Method is "DES-EDE3-CBC over Mask". 168 The Validity-Method is "SHA1-KMpKp Check". | 170 2. Key-Generation 171 2.1. SHA1 Hash 173 SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating + 174 the key(s). The key(s) begin with the most significant bits of the + 175 hash. SHA1 is iterated as needed to generate the requisite length of + 176 key material. + 178 When an individual key does not use all 128-bits of the last hash, + 179 any remaining unused (least significant) bits of the last hash are + 180 discarded. When combined with other uses of key generation for the + 181 same purpose, the next key will begin with a new hash iteration. + 183 3. Privacy Methods 184 3.1. DES-CBC over Mask 186 As described in [RFC-zzzz] "Privacy Masking", sufficient privacy-key | 187 material is generated to match the message length, beginning with the | 188 next field after the SPI, and including the Padding. The message is | 189 masked by XOR with the privacy-key. | 191 Then, the Key-Generation function is iterated to generate a DES key. | 192 The most significant 64-bits (8 bytes) of the generated hash are used | 193 for the privacy-key, and the remainder are discarded. Although 194 extremely rare, the 64 weak, semi-weak, and possibly weak keys | 195 [Schneier95, pages 280-282] are discarded. The Key-Generation func- | 196 tion is iterated until a valid key is obtained. 198 The least significant bit of each key byte is ignored (or set to par- | 199 ity when the implementation requires). 201 Message encryption begins with the next field after the SPI, and con- 202 tinues to the end of the data indicated by the UDP Length. 204 3.2. DES-EDE3-CBC over Mask 206 This is "Triple DES" outer-CBC EDE encryption (and DED decryption) | 207 with three 56-bit keys [KR96]. 209 As described in [RFC-zzzz] "Privacy Masking", sufficient privacy-key | 210 material is generated to match the message length, beginning with the | 211 next field after the SPI, and including the Padding. The message is | 212 masked by XOR with the privacy-key. | 214 Then, the Key-Generation function is iterated (at least) three times | 215 to generate the three DES keys. The most significant 64-bits (8 | 216 bytes) of each generated hash are used for each successive privacy- | 217 key, and the remainder are discarded. Each key is examined sequen- | 218 tially, in the order used for encryption. A key that is identical to | 219 a previous key MUST be discarded. Although extremely rare, the 64 | 220 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] | 221 MUST be discarded. The Key-Generation function is iterated until a | 222 valid key is obtained before generating the next key. | 224 In all three keys, the least significant bit of each key byte is | 225 ignored (or set to parity when the implementation requires). 227 Message encryption begins with the next field after the SPI, and con- - 228 tinues to the end of the data indicated by the UDP Length. 230 4. Validity Methods 231 4.1. SHA1-KMpKp Check 233 As described in [RFC-zzzz] "Validity Verification", the SHA1 234 [FIPS-180-1] hash is calculated over the concatenation of 236 SHA1( key, data, datafill, key, sha1fill ) 238 where the key is the computed shared-secret. 240 The leading key is not padded to any particular alignment. 242 The datafill uses the same pad-with-length technique defined for 243 sha1fill. This padding and length is implicit, and does not appear | 244 in the datagram. The datafill length includes only the leading key | 245 and data. 247 The resulting Verification field is a 160-bit Variable Precision Num- 248 ber (22 bytes including Size). | 250 5. Additional Attributes 252 The attribute format and basic facilities are already defined for 253 Photuris [RFC-zzzz]. 255 These optional attributes are specified separately, and no single 256 implementation is expected to support all of them. 258 This document defines the following values: 260 Use Type 261 I 4 SHA1-KMpKp Symmetric Identification 262 X 6 SHA1-KpMpKp Authentication 263 E 8 DES-CBC Encryption 264 E 9 DES Decryption 265 E 11 XOR 267 A AH-only Attribute-Choice 268 E ESP-only Attribute-Choice 269 I Identity-Choice 270 X dependent on list location 272 5.1. SHA1-KMpKp Symmetric Identification 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Type 4 280 Length 0 282 When selected as an Identity-Choice, the immediately following Iden- 283 tification field contains an unstructured Variable Precision Number. 284 Valid Identifications and symmetric secret-keys are preconfigured by 285 the parties. 287 There is no required format or content for the Identification value. 288 The value may be a number or string of any kind. See [RFC-zzzz] "Use 289 of Identification and Secrets" for details. 291 The authentication symmetric secret-key (as specified) is selected 292 based on the contents of the Identification field. All implementa- 293 tions MUST support at least 62 bytes. The selected symmetric secret- 294 key SHOULD provide at least 80-bits of cryptographic strength. 296 As described in [RFC-zzzz] "Identity Verification", the SHA1 297 [FIPS-180-1] hash is calculated over the concatenation of: 299 SHA1( key, data, datafill, key, sha1fill ) 301 where the key is the computed shared-secret. 303 The leading key is not padded to any particular alignment. 305 The datafill uses the same pad-with-length technique defined for 306 sha1fill. This padding and length is implicit, and does not appear 307 in the datagram. The datafill length includes only the leading key 308 and data. 310 The resulting Verification field is a 160-bit Variable Precision Num- 311 ber (22 bytes including Size). 313 For identity verification and session-key calculation, the authenti- 314 cation symmetric secret-key is also used as the calculation secret- 315 key. 317 5.2. SHA1-KpMpKp Authentication 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type 6 325 Length 0 327 May be selected as an AH or ESP Attribute-Choice, pursuant to 328 [RFC-1852] et sequitur. The selected Exchange Scheme SHOULD provide 329 at least 80-bits of cryptographic strength. 331 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 332 nificant 480-bits (60 bytes) of the Key-Generation iterations are 333 used for the key. 335 Profile: 337 When negotiated with Photuris, the transform differs slightly from 338 [RFC-1852]. 340 The form of the authenticated message is: 342 SHA1( key, keyfill, datagram, datafill, key, sha1fill ) 344 where the key is the SPI session-key. 346 The additional datafill protects against the attack described in 347 [PO96]. This is also filled to the next 512-bit boundary, using 348 the same pad-with-length technique defined for SHA1. This padding 349 and length is implicit, and does not appear in the datagram. The 350 datafill length includes only the leading key and data. 352 5.3. DES-CBC Encryption 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Type 8 360 Length 0 362 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et 363 sequitur. The selected Exchange Scheme SHOULD provide at least 364 56-bits of cryptographic strength. 366 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 367 nificant 64-bits (8 bytes) of the Key-Generation iteration are used 368 for the key, and the remainder are discarded. Although extremely 369 rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, 370 pages 280-282] MUST be discarded. The Key-Generation function is 371 iterated until a valid key is obtained. 373 The least significant bit of each key byte is ignored (or set to par- 374 ity when the implementation requires). 376 Profile: 378 When negotiated with Photuris, the transform differs slightly from 379 [RFC-1829]. 381 The 32-bit Security Parameters Index (SPI) field is followed by a 382 32-bit Sequence Number (SN). 384 The 64-bit CBC IV is generated from the 32-bit Security Parameters 385 Index (SPI) field followed by (concatenated with) the 32-bit 386 Sequence Number (SN) field. Then, the bit-wise complement of the 387 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 388 (SPI): 390 (SPI ^ -SN) || SN 392 The padding values begin with the value 1, and count up to the 393 number of padding bytes (zero relative). For example, if the 394 plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and 395 the following PadLength is 5. 397 After decryption, if the padding bytes are not the correct values 398 for the PadLength, then the payload is discarded, and a 399 "Decryption Failed" error is indicated, as described in [RFC- 400 xxxx]. 402 5.4. DES Decryption 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Type 9 410 Length 0 412 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1851] et 413 sequitur. The combination 415 "DES-CBC Encryption", 416 "DES Decryption", 417 "DES-CBC Encryption", 419 indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) 420 with three keys [KR96]. The selected Exchange Scheme SHOULD provide 421 at least 112-bits of cryptographic strength. 423 As described in [RFC-zzzz] "Session-Key Computation", the Key- 424 Generation function is iterated (at least) three times to generate 425 the three independent keys, in the order used for encryption. The 426 most significant 64-bits (8 bytes) of each Key-Generation iteration 427 are used for each successive key, and the remainder are discarded. 428 Each key is examined sequentially, in the order used for encryption. 429 A key that is identical to a previous key MUST be discarded. 430 Although extremely rare, the 64 weak, semi-weak, and possibly weak 431 keys [Schneier95, pages 280-282] MUST be discarded. The Key- 432 Generation function is iterated until a valid key is obtained before 433 generating the next key. 435 In all three keys, the least significant bit of each key byte is 436 ignored (or set to parity when the implementation requires). 438 Profile: 440 When negotiated with Photuris, the transform differs slightly from 441 [RFC-1851]. 443 The 32-bit Security Parameters Index (SPI) field is followed by a 444 32-bit Sequence Number (SN). 446 The 64-bit CBC IV is generated from the 32-bit Security Parameters 447 Index (SPI) field followed by (concatenated with) the 32-bit 448 Sequence Number (SN) field. Then, the bit-wise complement of the 449 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 450 (SPI): 452 (SPI ^ -SN) || SN 454 The padding values begin with the value 1, and count up to the 455 number of padding bytes (zero relative). For example, if the 456 plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and 457 the following PadLength is 5. 459 After decryption, if the padding bytes are not the correct values 460 for the PadLength, then the payload is discarded, and a "Decryp- 461 tion Failed" error is indicated, as described in [RFC-xxxx]. 463 5.5. XOR Whitening 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Type 11 471 Length 0 473 May be selected as an ESP Attribute-Choice, pursuant to [RFC-yyyy] et 474 sequitur. The combination 476 "XOR", 477 "DES-CBC Encryption", 478 "XOR", 480 indicates "DESX" encryption with three keys [KR96]. The selected 481 Exchange Scheme SHOULD provide at least 104-bits of cryptographic 482 strength. 484 As described in [RFC-zzzz] "Session-Key Computation", the Key- 485 Generation function is iterated (at least) three times to generate 486 the three independent keys, in the order used for encryption. The 487 most significant 64-bits (8 bytes) of each Key-Generation iteration 488 are used for each successive key, and the remainder are discarded. 490 Note that this attribute may appear multiple times in the same ESP 491 attribute list, both before and after an encryption transform. For 492 example, 494 "XOR", 495 "DES-CBC Encryption", 496 "XOR", 497 "DES Decryption", 498 "XOR", 499 "DES-CBC Encryption", 500 "XOR", 502 would be one possible combination with Triple DES. 504 Security Considerations | 506 The "whitening" of the plaintext before DES encryption is intended to 507 obscure the relation of the number of parties and SPIs active between 508 two IP nodes. The combination of a randomized secret mask with the | 509 CBC IV generates a different initial encrypted block for every SPI 510 creation message. 512 This obscurement is less effective when the SPI and SPILT are invari- | 513 ant or are not created for a particular exchange direction. The num- | 514 ber of parties could be revealed by the number of exchanges with dif- 515 ferences in the initial encrypted blocks. 517 Acknowledgements 519 Phil Karn was principally responsible for the design of party privacy 520 protection, and provided much of the design rationale text (now | 521 removed to a separate document). 523 William Simpson designed the packet formats, and additional exchange 524 schemes, editing and formatting. All such mistakes are his responsi- 525 bity. 527 Use of encryption for privacy protection is also found in the Sta- | 528 tion-To-Station authentication protocol [DOW92]. 530 Bart Preneel and Paul C van Oorschot in [PO96] suggested adding 531 padding between the data and trailing key when hashing for authenti- 532 cation. 534 References 536 [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, 537 "Authentication and Authenticated Key Exchanges", Designs, 538 Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Pub- 539 lishers, 1992. 541 [FIPS-180-1] 542 "Secure Hash Standard", National Institute of Standards and 543 Technology, U.S. Department Of Commerce, April 1995. 545 Also known as: 59 Fed Reg 35317 (1994). 547 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing 548 Security and Performance", Dr. Dobbs Journal, January 1996. 550 [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of 551 two MAC algorithms", Advances in Cryptology -- Eurocrypt 552 '96, Lecture Notes in Computer Science 1070 (May 1996), 553 Springer-Verlag, pages 19-32. - 555 [RFC-1829] 556 Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Trans- | 557 form", July 1995. | 559 [RFC-1850] | 560 Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES + 561 Transform", September 1995. + 563 [RFC-1851] + 564 Metzger, P., Simpson, W., "IP Authentication using Keyed + 565 SHA", September 1995. + 567 [RFC-xxxx] + 568 Karn, P., and Simpson, W., "ICMP Security Failures Mes- + 569 sages", draft-simpson-icmp-ipsec-fail-02.txt, work in + 570 progress. + 572 [RFC-yyyy] + 573 Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform", + 574 draft-ietf-ipsec-ciph-desx-00.txt, work in progress. + 576 [RFC-zzzz] + 577 Karn, P., and Simpson, W., "Photuris: Session Key Management 578 Protocol", draft-simpson-photuris-13.txt, work in progress. + 580 Contacts 582 Comments about this document should be discussed on the pho- 583 turis@majordomo.soscorp.com mailing list. 585 Questions about this document can also be directed to: 587 Phil Karn 588 Qualcomm, Inc. 589 6455 Lusk Blvd. 590 San Diego, California 92121-2779 592 karn@qualcomm.com 593 karn@unix.ka9q.ampr.org (preferred) 595 William Allen Simpson 596 DayDreamer 597 Computer Systems Consulting Services 598 1384 Fontaine 599 Madison Heights, Michigan 48071 601 wsimpson@UMich.edu 602 wsimpson@GreenDragon.com (preferred) 603 bsimpson@MorningStar.com