idnits 2.17.1 draft-simpson-photuris-schemes-03.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-23) 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 93 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 142: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 220: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 263: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 315: '... a previous key MUST be discarded. A...' RFC 2119 keyword, line 317: '... MUST be discarded. The Key-Generat...' (9 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 9779 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 434, but not defined ** Obsolete undefined reference: RFC 1852 (Obsoleted by RFC 2841) == Unused Reference: 'RFC-1850' is defined on line 658, 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-03.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 IP 40 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. When the Exchange-Scheme Size is non-zero, | 57 the modulus is contained in the Exchange-Scheme Value field in 58 the list of Offered-Schemes. 60 An Exchange-Scheme Size of zero is invalid. | 62 The Key-Generation-Function is "MD5 Hash". 64 The Privacy-Method is "Simple Masking". 66 The Validity-Method is "MD5-KMpKp Check". 68 This combination of features requires a modulus with at least + 69 64-bits of cryptographic strength. 71 (4) Implementation Optional. Any modulus (p) with a recommended 72 generator (g) of 2. When the Exchange-Scheme Size is non-zero, | 73 the modulus is contained in the Exchange-Scheme Value field in 74 the list of Offered-Schemes. 76 When the Exchange-Scheme Size field is zero, includes by refer- | 77 ence all of the moduli specified in the list of Offered-Schemes | 78 for Scheme #2. | 80 The Key-Generation-Function is "MD5 Hash". 82 The Privacy-Method is "DES-CBC over Mask". 84 The Validity-Method is "MD5-KMpKp Check". 86 This combination of features requires a modulus with at least + 87 64-bits of cryptographic strength. 89 (5) Implementation Optional. Any modulus (p) with a recommended 90 generator (g) of 5. When the Exchange-Scheme Size is non-zero, | 91 the modulus is contained in the Exchange-Scheme Value field in 92 the list of Offered-Schemes. 94 An Exchange-Scheme Size of zero is invalid. | 96 The Key-Generation-Function is "MD5 Hash". 98 The Privacy-Method is "Simple Masking". 100 The Validity-Method is "MD5-KMpKp Check". 102 This combination of features requires a modulus with at least + 103 64-bits of cryptographic strength. 105 (6) Implementation Optional. Any modulus (p) with a recommended 106 generator (g) of 3. When the Exchange-Scheme Size is non-zero, | 107 the modulus is contained in the Exchange-Scheme Value field in 108 the list of Offered-Schemes. 110 When the Exchange-Scheme Size field is zero, includes by refer- | 111 ence all of the moduli specified in the list of Offered-Schemes | 112 for Scheme #3. | 114 The Key-Generation-Function is "MD5 Hash". 116 The Privacy-Method is "DES-CBC over Mask". 118 The Validity-Method is "MD5-KMpKp Check". 120 This combination of features requires a modulus with at least + 121 64-bits of cryptographic strength. 123 (7) Implementation Optional. Any modulus (p) with a variable gen- 124 erator (g). When the Exchange-Scheme Size is non-zero, the | 125 pair [g,p] is contained in the Exchange-Scheme Value field in 126 the list of Offered-Schemes. Each is encoded in a separate + 127 Variable Precision Number (VPN). The generator VPN is followed + 128 by (concatenated to) the modulus VPN, and the result is nested + 129 inside the Exchange-Scheme Value field. + 131 An Exchange-Scheme Size of zero is invalid. 133 The Key-Generation-Function is "MD5 Hash". | 135 The Privacy-Method is "Simple Masking". 137 The Validity-Method is "MD5-KMpKp Check". 139 This combination of features requires a modulus with at least + 140 64-bits of cryptographic strength. + 141 When more than one modulus is specified for a given kind of + 142 Scheme, the Size of the modulus MUST be unique, independent of + 143 the Size of the generator. 145 (8) Implementation Optional. Any modulus (p) with a recommended 146 generator (g) of 2. When the Exchange-Scheme Size is non-zero, | 147 the modulus is contained in the Exchange-Scheme Value field in 148 the list of Offered-Schemes. 150 When the Exchange-Scheme Size field is zero, includes by refer- | 151 ence all of the moduli specified in the list of Offered-Schemes | 152 for Schemes #2 and #4. | 154 The Key-Generation-Function is "SHA1 Hash". 156 The Privacy-Method is "DES-EDE3-CBC over Mask". 158 The Validity-Method is "SHA1-KMpKp Check". 160 This combination of features requires a modulus with at least + 161 112-bits of cryptographic strength. 163 (10) Implementation Optional. Any modulus (p) with a recommended 164 generator (g) of 5. When the Exchange-Scheme Size is non-zero, | 165 the modulus is contained in the Exchange-Scheme Value field in 166 the list of Offered-Schemes. 168 When the Exchange-Scheme Size field is zero, includes by refer- | 169 ence all of the moduli specified in the list of Offered-Schemes | 170 for Scheme #5. | 172 The Key-Generation-Function is "MD5 Hash". 174 The Privacy-Method is "DES-CBC over Mask". 176 The Validity-Method is "MD5-KMpKp Check". 178 This combination of features requires a modulus with at least + 179 64-bits of cryptographic strength. 181 (12) Implementation Optional. Any modulus (p) with a recommended 182 generator (g) of 3. When the Exchange-Scheme Size is non-zero, | 183 the modulus is contained in the Exchange-Scheme Value field in 184 the list of Offered-Schemes. 186 When the Exchange-Scheme Size field is zero, includes by refer- | 187 ence all of the moduli specified in the list of Offered-Schemes | 188 for Schemes #3 and #6. | 189 The Key-Generation-Function is "SHA1 Hash". 191 The Privacy-Method is "DES-EDE3-CBC over Mask". 193 The Validity-Method is "SHA1-KMpKp Check". 195 This combination of features requires a modulus with at least + 196 112-bits of cryptographic strength. 198 (14) Implementation Optional. Any modulus (p) with a variable gen- 199 erator (g). When the Exchange-Scheme Size is non-zero, the | 200 pair [g,p] is contained in the Exchange-Scheme Value field in 201 the list of Offered-Schemes. Each is encoded in a separate + 202 Variable Precision Number (VPN). The generator VPN is followed + 203 by (concatenated to) the modulus VPN, and the result is nested + 204 inside the Exchange-Scheme Value field. + 206 When the Exchange-Scheme Size field is zero, includes by refer- + 207 ence all of the moduli specified in the list of Offered-Schemes + 208 for Scheme #7. 210 The Key-Generation-Function is "MD5 Hash". | 212 The Privacy-Method is "DES-CBC over Mask". 214 The Validity-Method is "MD5-KMpKp Check". 216 This combination of features requires a modulus with at least + 217 64-bits of cryptographic strength. + 219 When more than one modulus is specified for a given kind of + 220 Scheme, the Size of the modulus MUST be unique, independent of + 221 the Size of the generator. 223 (20) Implementation Optional. Any modulus (p) with a recommended 224 generator (g) of 5. When the Exchange-Scheme Size is non-zero, | 225 the modulus is contained in the Exchange-Scheme Value field in 226 the list of Offered-Schemes. 228 When the Exchange-Scheme Size field is zero, includes by refer- | 229 ence all of the moduli specified in the list of Offered-Schemes | 230 for Schemes #5 and #10. | 232 The Key-Generation-Function is "SHA1 Hash". 234 The Privacy-Method is "DES-EDE3-CBC over Mask". 236 The Validity-Method is "SHA1-KMpKp Check". 238 This combination of features requires a modulus with at least + 239 112-bits of cryptographic strength. 241 (28) Implementation Optional. Any modulus (p) with a variable gen- 242 erator (g). When the Exchange-Scheme Size is non-zero, the | 243 pair [g,p] is contained in the Exchange-Scheme Value field in 244 the list of Offered-Schemes. Each is encoded in a separate + 245 Variable Precision Number (VPN). The generator VPN is followed + 246 by (concatenated to) the modulus VPN, and the result is nested + 247 inside the Exchange-Scheme Value field. + 249 When the Exchange-Scheme Size field is zero, includes by refer- + 250 ence all of the moduli specified in the list of Offered-Schemes + 251 for Schemes #7 and #14. 253 The Key-Generation-Function is "SHA1 Hash". | 255 The Privacy-Method is "DES-EDE3-CBC over Mask". 257 The Validity-Method is "SHA1-KMpKp Check". 259 This combination of features requires a modulus with at least + 260 112-bits of cryptographic strength. + 262 When more than one modulus is specified for a given kind of + 263 Scheme, the Size of the modulus MUST be unique, independent of + 264 the Size of the generator. 266 2. Additional Key-Generation-Function 267 2.1. SHA1 Hash 269 SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating 270 the key(s). The key(s) begin with the most significant bits of the 271 hash. SHA1 is iterated as needed to generate the requisite length of 272 key material. 274 When an individual key does not use all 160-bits of the last hash, | 275 any remaining unused (least significant) bits of the last hash are 276 discarded. When combined with other uses of key generation for the 277 same purpose, the next key will begin with a new hash iteration. 279 3. Additional Privacy-Methods 280 3.1. DES-CBC over Mask 282 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- | 283 vacy-key material is generated to match the message length, beginning 284 with the next field after the SPI, and including the Padding. The 285 message is masked by XOR with the privacy-key. 287 Then, the Key-Generation-Function is iterated to generate a DES key. | 288 The most significant 64-bits (8 bytes) of the generated hash are used 289 for the privacy-key, and the remainder are discarded. Although 290 extremely rare, the 64 weak, semi-weak, and possibly weak keys 291 [Schneier95, pages 280-282] are discarded. The Key-Generation- | 292 Function is iterated until a valid key is obtained. 294 The least significant bit of each key byte is ignored (or set to par- 295 ity when the implementation requires). 297 Message encryption begins with the next field after the SPI, and con- 298 tinues to the end of the data indicated by the UDP Length. 300 3.2. DES-EDE3-CBC over Mask 302 This is "Triple DES" outer-CBC EDE encryption (and DED decryption) 303 with three 56-bit keys [KR96]. 305 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- | 306 vacy-key material is generated to match the message length, beginning 307 with the next field after the SPI, and including the Padding. The 308 message is masked by XOR with the privacy-key. 310 Then, the Key-Generation-Function is iterated (at least) three times | 311 to generate the three DES keys. The most significant 64-bits (8 312 bytes) of each generated hash are used for each successive privacy- 313 key, and the remainder are discarded. Each key is examined sequen- 314 tially, in the order used for encryption. A key that is identical to 315 a previous key MUST be discarded. Although extremely rare, the 64 316 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] 317 MUST be discarded. The Key-Generation-Function is iterated until a | 318 valid key is obtained before generating the next key. 320 In all three keys, the least significant bit of each key byte is 321 ignored (or set to parity when the implementation requires). 323 Message encryption begins with the next field after the SPI, and con- 324 tinues to the end of the data indicated by the UDP Length. 326 4. Additional Validity-Method 327 4.1. SHA1-KMpKp Check 329 As described in [RFC-zzzz] "Validity Verification", the SHA1 330 [FIPS-180-1] hash is calculated over the concatenation of 332 SHA1( key, data, datafill, key, sha1fill ) 334 where the key is the computed shared-secret. 336 The leading key is not padded to any particular alignment. 338 The datafill uses the same pad-with-length technique defined for 339 sha1fill. This padding and length is implicit, and does not appear 340 in the datagram. The datafill length includes only the leading key 341 and data. 343 The resulting Verification field is a 160-bit Variable Precision Num- 344 ber (22 bytes including Size). 346 5. Additional Attributes 348 The attribute format and basic facilities are already defined for 349 Photuris [RFC-zzzz]. 351 These optional attributes are specified separately, and no single 352 implementation is expected to support all of them. 354 This document defines the following values: 356 Use Type 357 I 4 SHA1-KMpKp Symmetric Identification 358 X 6 SHA1-KpMpKp Authentication 359 E 8 DES-CBC Encryption 360 E 9 DES Decryption 361 E 11 XOR 363 A AH-only Attribute-Choice 364 E ESP-only Attribute-Choice 365 I Identity-Choice 366 X dependent on list location 368 5.1. SHA1-KMpKp Symmetric Identification 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Attribute | Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Attribute 4 376 Length 0 378 When selected as an Identity-Choice, the immediately following Iden- 379 tification field contains an unstructured Variable Precision Number. 380 Valid Identifications and symmetric secret-keys are preconfigured by 381 the parties. 383 There is no required format or content for the Identification value. 384 The value may be a number or string of any kind. See [RFC-zzzz] "Use 385 of Identification and Secrets" for details. 387 The authentication symmetric secret-key (as specified) is selected 388 based on the contents of the Identification field. All implementa- 389 tions MUST support at least 62 bytes. The selected symmetric secret- 390 key SHOULD provide at least 80-bits of cryptographic strength. 392 As described in [RFC-zzzz] "Identity Verification", the SHA1 393 [FIPS-180-1] hash is calculated over the concatenation of: 395 SHA1( key, data, datafill, key, sha1fill ) 397 where the key is the computed shared-secret. 399 The leading key is not padded to any particular alignment. 401 The datafill uses the same pad-with-length technique defined for 402 sha1fill. This padding and length is implicit, and does not appear 403 in the datagram. The datafill length includes only the leading key 404 and data. 406 The resulting Verification field is a 160-bit Variable Precision Num- 407 ber (22 bytes including Size). 409 For both identity verification and session-key calculation, the 410 authentication symmetric secret-key is used as the calculation 411 secret-key. 413 5.2. SHA1-KpMpKp Authentication 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Attribute | Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Attribute 6 421 Length 0 423 May be selected as an AH or ESP Attribute-Choice, pursuant to 424 [RFC-1852] et sequitur. The selected Exchange-Scheme SHOULD provide | 425 at least 80-bits of cryptographic strength. 427 As described in [RFC-zzzz] "Session-Key Computation", the most sig- | 428 nificant 384-bits (48 bytes) of the Key-Generation-Function itera- | 429 tions are used for the key. 431 Profile: 433 When negotiated with Photuris, the transform differs slightly from 434 [RFC-1852]. 436 The form of the authenticated message is: 438 SHA1( key, keyfill, datagram, datafill, key, sha1fill ) 440 where the key is the SPI session-key. 442 The additional datafill protects against the attack described in 443 [PO96]. This is also filled to the next 512-bit boundary, using 444 the same pad-with-length technique defined for SHA1. This padding 445 and length is implicit, and does not appear in the datagram. The 446 datafill length includes only the leading key and data. 448 5.3. DES-CBC Encryption 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Attribute | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Attribute 8 456 Length 0 458 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et 459 sequitur. The selected Exchange-Scheme SHOULD provide at least | 460 56-bits of cryptographic strength. 462 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 463 nificant 64-bits (8 bytes) of the Key-Generation iteration are used 464 for the key, and the remainder are discarded. Although extremely 465 rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, 466 pages 280-282] MUST be discarded. The Key-Generation-Function is | 467 iterated until a valid key is obtained. 469 The least significant bit of each key byte is ignored (or set to par- 470 ity when the implementation requires). 472 Profile: 474 When negotiated with Photuris, the transform differs slightly from 475 [RFC-1829]. 477 The 32-bit Security Parameters Index (SPI) field is followed by a 478 32-bit Sequence Number (SN). 480 The 64-bit CBC IV is generated from the 32-bit Security Parameters 481 Index (SPI) field followed by (concatenated with) the 32-bit 482 Sequence Number (SN) field. Then, the bit-wise complement of the 483 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 484 (SPI): 486 (SPI ^ -SN) || SN 488 The padding values begin with the value 1, and count up to the 489 number of padding bytes (zero relative). For example, if the 490 plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and 491 the following PadLength is 5. 493 After decryption, if the padding bytes are not the correct values 494 for the PadLength, then the payload is discarded, and a 495 "Decryption Failed" error is indicated, as described in [RFC- 496 xxxx]. 498 5.4. DES Decryption 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Attribute | Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Attribute 9 506 Length 0 508 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1851] et 509 sequitur. The combination 511 "DES-CBC Encryption", 512 "DES Decryption", 513 "DES-CBC Encryption", 515 indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) 516 with three keys [KR96]. The selected Exchange-Scheme SHOULD provide | 517 at least 112-bits of cryptographic strength. 519 As described in [RFC-zzzz] "Session-Key Computation", the Key- | 520 Generation-Function is iterated (at least) three times to generate 521 the three independent keys, in the order used for encryption. The | 522 most significant 64-bits (8 bytes) of each iteration are used for 523 each successive key, and the remainder are discarded. Each key is 524 examined sequentially, in the order used for encryption. A key that 525 is identical to a previous key MUST be discarded. Although extremely 526 rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, 527 pages 280-282] MUST be discarded. The Key-Generation-Function is | 528 iterated until a valid key is obtained before generating the next 529 key. 531 In all three keys, the least significant bit of each key byte is 532 ignored (or set to parity when the implementation requires). 534 Profile: 536 When negotiated with Photuris, the transform differs slightly from 537 [RFC-1851]. 539 The 32-bit Security Parameters Index (SPI) field is followed by a 540 32-bit Sequence Number (SN). 542 The 64-bit CBC IV is generated from the 32-bit Security Parameters 543 Index (SPI) field followed by (concatenated with) the 32-bit 544 Sequence Number (SN) field. Then, the bit-wise complement of the 545 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 546 (SPI): 548 (SPI ^ -SN) || SN 550 The padding values begin with the value 1, and count up to the 551 number of padding bytes (zero relative). For example, if the 552 plaintext length is 41, the padding values are 1, 2, 3, 4, 5, and 553 the following PadLength is 5. 555 After decryption, if the padding bytes are not the correct values 556 for the PadLength, then the payload is discarded, and a "Decryp- 557 tion Failed" error is indicated, as described in [RFC-xxxx]. 559 5.5. XOR Whitening 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Attribute | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Attribute 11 567 Length 0 569 May be selected as an ESP Attribute-Choice, pursuant to [RFC-yyyy] et 570 sequitur. The combination 572 "XOR", 573 "DES-CBC Encryption", 574 "XOR", 576 indicates "DESX" encryption with three keys [KR96]. The selected | 577 Exchange-Scheme SHOULD provide at least 104-bits of cryptographic 578 strength. 580 As described in [RFC-zzzz] "Session-Key Computation", the Key- | 581 Generation-Function is iterated (at least) three times to generate 582 the three independent keys, in the order used for encryption. The | 583 most significant 64-bits (8 bytes) of each iteration are used for 584 each successive key, and the remainder are discarded. 586 Note that this attribute may appear multiple times in the same ESP - 587 attribute list, both before and after an encryption transform. For 588 example, 590 "XOR", 591 "DES-CBC Encryption", 592 "XOR", 593 "DES Decryption", 594 "XOR", 595 "DES-CBC Encryption", 596 "XOR", 598 would be one possible combination with Triple DES. 600 Security Considerations 602 The "whitening" of the plaintext before DES encryption is intended to 603 obscure the relation of the number of parties and SPIs active between 604 two IP nodes. The combination of a randomized secret mask with the 605 CBC IV generates a different initial encrypted block for every SPI 606 creation message. 608 This obscurement is less effective when the SPI and SPILT are invari- 609 ant or are not created for a particular exchange direction. The num- 610 ber of parties could be revealed by the number of exchanges with dif- 611 ferences in the initial encrypted blocks. 613 Acknowledgements 615 Phil Karn was principally responsible for the design of party privacy 616 protection, and provided much of the design rationale text (now 617 removed to a separate document). 619 William Simpson designed the packet formats, and additional Exchange- | 620 Schemes, editing and formatting. All such mistakes are his responsi- 621 bity. 623 Use of encryption for privacy protection is also found in the Sta- 624 tion-To-Station authentication protocol [DOW92]. 626 Bart Preneel and Paul C van Oorschot in [PO96] suggested adding 627 padding between the data and trailing key when hashing for authenti- 628 cation. 630 Niels Provos developed the first implementation with multiple schemes + 631 and multiple moduli per scheme (circa July 1997). 633 References 635 [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, 636 "Authentication and Authenticated Key Exchanges", Designs, 637 Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Pub- 638 lishers, 1992. 640 [FIPS-180-1] 641 "Secure Hash Standard", National Institute of Standards and 642 Technology, U.S. Department Of Commerce, April 1995. 644 Also known as: 59 Fed Reg 35317 (1994). 646 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing 647 Security and Performance", Dr. Dobbs Journal, January 1996. 649 [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of 650 two MAC algorithms", Advances in Cryptology -- Eurocrypt 651 '96, Lecture Notes in Computer Science 1070 (May 1996), 652 Springer-Verlag, pages 19-32. 654 [RFC-1829] 655 Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Trans- 656 form", July 1995. 658 [RFC-1850] 659 Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES 660 Transform", September 1995. 662 [RFC-1851] 663 Metzger, P., Simpson, W., "IP Authentication using Keyed 664 SHA", September 1995. 666 [RFC-xxxx] 667 Karn, P., and Simpson, W., "ICMP Security Failures Mes- 668 sages", draft-simpson-icmp-ipsec-fail-02.txt, work in 669 progress. 671 [RFC-yyyy] 672 Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform", 673 draft-ietf-ipsec-ciph-desx-00.txt, work in progress. 675 [RFC-zzzz] 676 Karn, P., and Simpson, W., "Photuris: Session Key Management 677 Protocol", draft-simpson-photuris-13.txt, work in progress. 679 Contacts 681 Comments about this document should be discussed on the 682 photuris@majordomo.soscorp.com mailing list. 684 Questions about this document can also be directed to: 686 Phil Karn 687 Qualcomm, Inc. 688 6455 Lusk Blvd. 689 San Diego, California 92121-2779 691 karn@qualcomm.com 692 karn@unix.ka9q.ampr.org (preferred) 694 William Allen Simpson 695 DayDreamer 696 Computer Systems Consulting Services 697 1384 Fontaine 698 Madison Heights, Michigan 48071 700 wsimpson@UMich.edu 701 wsimpson@GreenDragon.com (preferred) 702 bsimpson@MorningStar.com