idnits 2.17.1 draft-simpson-photuris-schemes-04.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 57 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 145: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 224: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 266: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 318: '... a previous key MUST be discarded. A...' RFC 2119 keyword, line 320: '... 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 (November 1997) is 9656 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 2, but not defined == Missing Reference: 'DayDreamer' is mentioned on line 3, but not defined == Missing Reference: 'RFC-1852' is mentioned on line 439, but not defined ** Obsolete undefined reference: RFC 1852 (Obsoleted by RFC 2841) == Unused Reference: 'RFC-1850' is defined on line 665, 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-17 ** 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. -------------------------------------------------------------------------------- 2 Network Working Group P Karn [Qualcomm] 3 Internet Draft W A Simpson [DayDreamer] 4 expires in six months November 1997 6 Photuris: Extended Schemes and Attributes 7 draft-simpson-photuris-schemes-04.txt | 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) | 28 ftp.nis.garr.it (Southern Europe) | 29 ds.internic.net (Eastern USA) | 30 ftp.isi.edu (Western USA) | 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Abstract 37 Photuris is a session-key management protocol. Extensible Exchange- 38 Schemes are provided to enable future implementation changes without 39 affecting the basic protocol. 41 Additional authentication attributes are included for use with the IP 42 Authentication Header (AH). 44 Additional confidentiality attributes are included for use with the 45 IP Encapsulating Security Protocol (ESP). 47 1. Additional Exchange-Schemes 49 The packet format and basic facilities are already defined for Pho- 50 turis [RFC-zzzz]. 52 These optional Exchange-Schemes are specified separately, and no sin- 53 gle implementation is expected to support all of them. 55 This document defines the following values: 57 (3) Implementation Optional. Any modulus (p) with a recommended 58 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 59 the modulus is contained in the Exchange-Scheme Value field in 60 the list of Offered-Schemes. 62 An Exchange-Scheme Size of zero is invalid. 64 The Key-Generation-Function is "MD5 Hash". 66 The Privacy-Method is "Simple Masking". 68 The Validity-Method is "MD5-IPMAC Check". | 70 This combination of features requires a modulus with at least 71 64-bits of cryptographic strength. 73 (4) Implementation Optional. Any modulus (p) with a recommended 74 generator (g) of 2. When the Exchange-Scheme Size is non-zero, 75 the modulus is contained in the Exchange-Scheme Value field in 76 the list of Offered-Schemes. 78 When the Exchange-Scheme Size field is zero, includes by refer- 79 ence all of the moduli specified in the list of Offered-Schemes 80 for Scheme #2. 82 The Key-Generation-Function is "MD5 Hash". 84 The Privacy-Method is "DES-CBC over Mask". 86 The Validity-Method is "MD5-IPMAC Check". | 88 This combination of features requires a modulus with at least 89 64-bits of cryptographic strength. 91 (5) Implementation Optional. Any modulus (p) with a recommended 92 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 93 the modulus is contained in the Exchange-Scheme Value field in 94 the list of Offered-Schemes. 96 An Exchange-Scheme Size of zero is invalid. 98 The Key-Generation-Function is "MD5 Hash". 100 The Privacy-Method is "Simple Masking". 102 The Validity-Method is "MD5-IPMAC Check". | 104 This combination of features requires a modulus with at least 105 64-bits of cryptographic strength. 107 (6) Implementation Optional. Any modulus (p) with a recommended 108 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 109 the modulus is contained in the Exchange-Scheme Value field in 110 the list of Offered-Schemes. 112 When the Exchange-Scheme Size field is zero, includes by refer- 113 ence all of the moduli specified in the list of Offered-Schemes 114 for Scheme #3. 116 The Key-Generation-Function is "MD5 Hash". 118 The Privacy-Method is "DES-CBC over Mask". 120 The Validity-Method is "MD5-IPMAC Check". | 122 This combination of features requires a modulus with at least 123 64-bits of cryptographic strength. 125 (7) Implementation Optional. Any modulus (p) with a variable gen- 126 erator (g). When the Exchange-Scheme Size is non-zero, the 127 pair [g,p] is contained in the Exchange-Scheme Value field in 128 the list of Offered-Schemes. Each is encoded in a separate | 129 Variable Precision Integer (VPI). The generator VPI is fol- | 130 lowed by (concatenated to) the modulus VPI, and the result is 131 nested inside the Exchange-Scheme Value field. 133 An Exchange-Scheme Size of zero is invalid. 135 The Key-Generation-Function is "MD5 Hash". 137 The Privacy-Method is "Simple Masking". 139 The Validity-Method is "MD5-IPMAC Check". | 141 This combination of features requires a modulus with at least 142 64-bits of cryptographic strength. 144 When more than one modulus is specified for a given kind of 145 Scheme, the Size of the modulus MUST be unique, independent of 146 the Size of the generator. 148 (8) Implementation Optional. Any modulus (p) with a recommended 149 generator (g) of 2. When the Exchange-Scheme Size is non-zero, 150 the modulus is contained in the Exchange-Scheme Value field in 151 the list of Offered-Schemes. 153 When the Exchange-Scheme Size field is zero, includes by refer- 154 ence all of the moduli specified in the list of Offered-Schemes 155 for Schemes #2 and #4. 157 The Key-Generation-Function is "SHA1 Hash". 159 The Privacy-Method is "DES-EDE3-CBC over Mask". 161 The Validity-Method is "SHA1-IPMAC Check". | 163 This combination of features requires a modulus with at least 164 112-bits of cryptographic strength. 166 (10) Implementation Optional. Any modulus (p) with a recommended 167 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 168 the modulus is contained in the Exchange-Scheme Value field in 169 the list of Offered-Schemes. 171 When the Exchange-Scheme Size field is zero, includes by refer- 172 ence all of the moduli specified in the list of Offered-Schemes 173 for Scheme #5. 175 The Key-Generation-Function is "MD5 Hash". 177 The Privacy-Method is "DES-CBC over Mask". 179 The Validity-Method is "MD5-IPMAC Check". | 181 This combination of features requires a modulus with at least 182 64-bits of cryptographic strength. 184 (12) Implementation Optional. Any modulus (p) with a recommended 185 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 186 the modulus is contained in the Exchange-Scheme Value field in 187 the list of Offered-Schemes. 189 When the Exchange-Scheme Size field is zero, includes by refer- 190 ence all of the moduli specified in the list of Offered-Schemes 191 for Schemes #3 and #6. 193 The Key-Generation-Function is "SHA1 Hash". 195 The Privacy-Method is "DES-EDE3-CBC over Mask". 197 The Validity-Method is "SHA1-IPMAC Check". | 199 This combination of features requires a modulus with at least 200 112-bits of cryptographic strength. 202 (14) Implementation Optional. Any modulus (p) with a variable gen- 203 erator (g). When the Exchange-Scheme Size is non-zero, the 204 pair [g,p] is contained in the Exchange-Scheme Value field in 205 the list of Offered-Schemes. Each is encoded in a separate | 206 Variable Precision Integer (VPI). The generator VPI is fol- | 207 lowed by (concatenated to) the modulus VPI, and the result is 208 nested inside the Exchange-Scheme Value field. 210 When the Exchange-Scheme Size field is zero, includes by refer- 211 ence all of the moduli specified in the list of Offered-Schemes 212 for Scheme #7. 214 The Key-Generation-Function is "MD5 Hash". 216 The Privacy-Method is "DES-CBC over Mask". 218 The Validity-Method is "MD5-IPMAC Check". | 220 This combination of features requires a modulus with at least 221 64-bits of cryptographic strength. 223 When more than one modulus is specified for a given kind of 224 Scheme, the Size of the modulus MUST be unique, independent of 225 the Size of the generator. 227 (20) Implementation Optional. Any modulus (p) with a recommended 228 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 229 the modulus is contained in the Exchange-Scheme Value field in 230 the list of Offered-Schemes. 232 When the Exchange-Scheme Size field is zero, includes by refer- 233 ence all of the moduli specified in the list of Offered-Schemes 234 for Schemes #5 and #10. 236 The Key-Generation-Function is "SHA1 Hash". 238 The Privacy-Method is "DES-EDE3-CBC over Mask". 240 The Validity-Method is "SHA1-IPMAC Check". | 241 This combination of features requires a modulus with at least 242 112-bits of cryptographic strength. 244 (28) Implementation Optional. Any modulus (p) with a variable gen- 245 erator (g). When the Exchange-Scheme Size is non-zero, the 246 pair [g,p] is contained in the Exchange-Scheme Value field in 247 the list of Offered-Schemes. Each is encoded in a separate | 248 Variable Precision Integer (VPI). The generator VPI is fol- | 249 lowed by (concatenated to) the modulus VPI, and the result is 250 nested inside the Exchange-Scheme Value field. 252 When the Exchange-Scheme Size field is zero, includes by refer- 253 ence all of the moduli specified in the list of Offered-Schemes 254 for Schemes #7 and #14. 256 The Key-Generation-Function is "SHA1 Hash". 258 The Privacy-Method is "DES-EDE3-CBC over Mask". 260 The Validity-Method is "SHA1-IPMAC Check". | 262 This combination of features requires a modulus with at least 263 112-bits of cryptographic strength. 265 When more than one modulus is specified for a given kind of 266 Scheme, the Size of the modulus MUST be unique, independent of 267 the Size of the generator. 269 2. Additional Key-Generation-Function 270 2.1. SHA1 Hash 272 SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating 273 the key(s). The key(s) begin with the most significant bits of the 274 hash. SHA1 is iterated as needed to generate the requisite length of 275 key material. 277 When an individual key does not use all 160-bits of the last hash, 278 any remaining unused (least significant) bits of the last hash are 279 discarded. When combined with other uses of key generation for the 280 same purpose, the next key will begin with a new hash iteration. 282 3. Additional Privacy-Methods 283 3.1. DES-CBC over Mask 285 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- 286 vacy-key material is generated to match the message length, beginning 287 with the next field after the SPI, and including the Padding. The 288 message is masked by XOR with the privacy-key. 290 Then, the Key-Generation-Function is iterated to generate a DES key. 291 The most significant 64-bits (8 bytes) of the generated hash are used 292 for the privacy-key, and the remainder are discarded. Although 293 extremely rare, the 64 weak, semi-weak, and possibly weak keys 294 [Schneier95, pages 280-282] are discarded. The Key-Generation- 295 Function is iterated until a valid key is obtained. 297 The least significant bit of each key byte is ignored (or set to par- 298 ity when the implementation requires). 300 Message encryption begins with the next field after the SPI, and con- 301 tinues to the end of the data indicated by the UDP Length. 303 3.2. DES-EDE3-CBC over Mask 305 This is "Triple DES" outer-CBC EDE encryption (and DED decryption) 306 with three 56-bit keys [KR96]. 308 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- 309 vacy-key material is generated to match the message length, beginning 310 with the next field after the SPI, and including the Padding. The 311 message is masked by XOR with the privacy-key. 313 Then, the Key-Generation-Function is iterated (at least) three times 314 to generate the three DES keys. The most significant 64-bits (8 315 bytes) of each generated hash are used for each successive privacy- 316 key, and the remainder are discarded. Each key is examined sequen- 317 tially, in the order used for encryption. A key that is identical to 318 a previous key MUST be discarded. Although extremely rare, the 64 319 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] 320 MUST be discarded. The Key-Generation-Function is iterated until a 321 valid key is obtained before generating the next key. 323 In all three keys, the least significant bit of each key byte is 324 ignored (or set to parity when the implementation requires). 326 Message encryption begins with the next field after the SPI, and con- 327 tinues to the end of the data indicated by the UDP Length. 329 4. Additional Validity-Method 330 4.1. SHA1-IPMAC Check 332 As described in [RFC-zzzz] "Validity Verification", the Verification | 333 field value is the SHA1 [FIPS-180-1] hash over the concatenation of 335 SHA1( key, keyfill, data, datafill, key, sha1fill ) | 337 where the key is the computed verification-key. | 339 The keyfill and datafill use the same pad-with-length technique | 340 defined for sha1fill. This padding and length is implicit, and does 341 not appear in the datagram. - 343 The resulting Verification field is a 160-bit Variable Precision | 344 Integer (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-IPMAC Symmetric Identification | 358 X 6 SHA1-IPMAC 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-IPMAC 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 Integer. | 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 symmetric secret-key (as specified) is selected based on the con- | 388 tents of the Identification field. All implementations MUST support 389 at least 62 bytes. The selected symmetric secret-key SHOULD provide 390 at least 80-bits of cryptographic strength. 392 As described in [RFC-zzzz] "Identity Verification", the Verification | 393 field value is the SHA1 [FIPS-180-1] hash over the concatenation of: 395 SHA1( key, keyfill, data, datafill, key, sha1fill ) | 397 where the key is the computed verification-key. | 399 The keyfill and datafill use the same pad-with-length technique | 400 defined for sha1fill. This padding and length is implicit, and does 401 not appear in the datagram. - 403 The resulting Verification field is a 160-bit Variable Precision | 404 Integer (22 bytes including Size). 406 For both [RFC-zzzz] "Identity Verification" and "Validity Verifica- | 407 tion", the verification-key is the SHA1 [FIPS-180-1] hash of the fol- | 408 lowing concatenated values: | 410 + the symmetric secret-key, | 411 + the computed shared-secret. | 413 For [RFC-zzzz] "Session-Key Computation", the symmetric secret-key is | 414 used directly as the generation-key. | 415 The symmetric secret-key is used in calculations in the same fashion | 416 as [RFC-zzzz] "MD5-IPMAC Symmetric Identification". 418 5.2. SHA1-IPMAC Authentication 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Attribute | Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Attribute 6 426 Length 0 428 May be selected as an AH or ESP Attribute-Choice, pursuant to 429 [RFC-1852] et sequitur. The selected Exchange-Scheme SHOULD provide 430 at least 80-bits of cryptographic strength. 432 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 433 nificant 384-bits (48 bytes) of the Key-Generation-Function itera- 434 tions are used for the key. 436 Profile: 438 When negotiated with Photuris, the transform differs slightly from 439 [RFC-1852]. 441 The form of the authenticated message is: 443 SHA1( key, keyfill, datagram, datafill, key, sha1fill ) 445 where the key is the SPI session-key. 447 The additional datafill protects against the attack described in 448 [PO96]. This is also filled to the next 512-bit boundary, using 449 the same pad-with-length technique defined for SHA1. This padding 450 and length is implicit, and does not appear in the datagram. - 452 5.3. DES-CBC Encryption 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Attribute | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Attribute 8 460 Length 0 462 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et 463 sequitur. The selected Exchange-Scheme SHOULD provide at least 464 56-bits of cryptographic strength. 466 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 467 nificant 64-bits (8 bytes) of the Key-Generation iteration are used 468 for the key, and the remainder are discarded. Although extremely 469 rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, 470 pages 280-282] MUST be discarded. The Key-Generation-Function is 471 iterated until a valid key is obtained. 473 The least significant bit of each key byte is ignored (or set to par- 474 ity when the implementation requires). 476 Profile: 478 When negotiated with Photuris, the transform differs slightly from 479 [RFC-1829]. 481 The 32-bit Security Parameters Index (SPI) field is followed by a 482 32-bit Sequence Number (SN). 484 The 64-bit CBC IV is generated from the 32-bit Security Parameters 485 Index (SPI) field followed by (concatenated with) the 32-bit 486 Sequence Number (SN) field. Then, the bit-wise complement of the 487 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 488 (SPI): 490 (SPI ^ -SN) || SN 492 The Padding values begin with the value 1, and count up to the | 493 number of padding bytes. For example, if the plaintext length is 494 41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any addi- | 495 tional obscuring padding. | 497 The PadLength and PayloadType are not appended. 499 After decryption, if the padding bytes are not the correct sequen- | 500 tial values, then the payload is discarded, and a "Decryption 501 Failed" error is indicated, as described in [RFC-xxxx]. 503 5.4. DES Decryption 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Attribute | Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Attribute 9 511 Length 0 513 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1851] et 514 sequitur. The combination 516 "DES-CBC Encryption", 517 "DES Decryption", 518 "DES-CBC Encryption", 520 indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) 521 with three keys [KR96]. The selected Exchange-Scheme SHOULD provide 522 at least 112-bits of cryptographic strength. 524 As described in [RFC-zzzz] "Session-Key Computation", the Key- 525 Generation-Function is iterated (at least) three times to generate 526 the three independent keys, in the order used for encryption. The 527 most significant 64-bits (8 bytes) of each iteration are used for 528 each successive key, and the remainder are discarded. Each key is 529 examined sequentially, in the order used for encryption. A key that 530 is identical to a previous key MUST be discarded. Although extremely 531 rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, 532 pages 280-282] MUST be discarded. The Key-Generation-Function is 533 iterated until a valid key is obtained before generating the next 534 key. 536 In all three keys, the least significant bit of each key byte is 537 ignored (or set to parity when the implementation requires). 539 Profile: 541 When negotiated with Photuris, the transform differs slightly from 542 [RFC-1851]. 544 The 32-bit Security Parameters Index (SPI) field is followed by a 545 32-bit Sequence Number (SN). 547 The 64-bit CBC IV is generated from the 32-bit Security Parameters 548 Index (SPI) field followed by (concatenated with) the 32-bit 549 Sequence Number (SN) field. Then, the bit-wise complement of the 550 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 551 (SPI): 553 (SPI ^ -SN) || SN 555 The Padding values begin with the value 1, and count up to the | 556 number of padding bytes. For example, if the plaintext length is 557 41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any addi- | 558 tional obscuring padding. | 560 The PadLength and PayloadType are not appended. 562 After decryption, if the padding bytes are not the correct sequen- | 563 tial values, then the payload is discarded, and a "Decryption 564 Failed" error is indicated, as described in [RFC-xxxx]. 566 5.5. XOR Whitening 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Attribute | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Attribute 11 574 Length 0 576 May be selected as an ESP Attribute-Choice, pursuant to [RFC-yyyy] et 577 sequitur. The combination 579 "XOR", 580 "DES-CBC Encryption", 581 "XOR", 583 indicates "DESX" encryption with three keys [KR96]. The selected 584 Exchange-Scheme SHOULD provide at least 104-bits of cryptographic 585 strength. 587 As described in [RFC-zzzz] "Session-Key Computation", the Key- 588 Generation-Function is iterated (at least) three times to generate 589 the three independent keys, in the order used for encryption. The | 590 most significant bytes of each iteration are used for each successive 591 key, and the remainder are discarded. 593 Note that this attribute may appear multiple times in the same ESP 594 attribute list, both before and after an encryption transform. For 595 example, 597 "XOR", 598 "DES-CBC Encryption", 599 "XOR", 600 "DES Decryption", 601 "XOR", 602 "DES-CBC Encryption", 603 "XOR", 605 would be one possible combination with Triple DES. 607 Security Considerations 609 The "whitening" of the plaintext before DES encryption is intended to 610 obscure the relation of the number of parties and SPIs active between 611 two IP nodes. The combination of a randomized secret mask with the 612 CBC IV generates a different initial encrypted block for every SPI 613 creation message. 615 This obscurement is less effective when the SPI and SPILT are invari- 616 ant or are not created for a particular exchange direction. The num- 617 ber of parties could be revealed by the number of exchanges with dif- 618 ferences in the initial encrypted blocks. 620 Acknowledgements 622 Phil Karn was principally responsible for the design of party privacy 623 protection, and provided much of the design rationale text (now 624 removed to a separate document). 626 William Simpson designed the packet formats, and additional Exchange- 627 Schemes, editing and formatting. All such mistakes are his responsi- 628 bity. 630 Use of encryption for privacy protection is also found in the Sta- 631 tion-To-Station authentication protocol [DOW92]. 633 Bart Preneel and Paul C van Oorschot in [PO96] suggested adding 634 padding between the data and trailing key when hashing for authenti- 635 cation. 637 Niels Provos developed the first implementation with multiple schemes 638 and multiple moduli per scheme (circa July 1997). 640 References 642 [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J 643 Wiener, "Authentication and Authenticated Key Exchanges", 644 Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer 645 Academic Publishers, 1992. 647 [FIPS-180-1] 648 "Secure Hash Standard", National Institute of Standards 649 and Technology, U.S. Department Of Commerce, April 1995. 651 Also known as: 59 Fed Reg 35317 (1994). 653 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: 654 Weighing Security and Performance", Dr. Dobbs Journal, 655 January 1996. 657 [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of 658 two MAC algorithms", Advances in Cryptology -- Eurocrypt 659 '96, Lecture Notes in Computer Science 1070 (May 1996), 660 Springer-Verlag, pages 19-32. 662 [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC 663 Transform", July 1995. 665 [RFC-1850] Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES 666 Transform", September 1995. 668 [RFC-1851] Metzger, P., Simpson, W., "IP Authentication using Keyed 669 SHA", September 1995. 671 [RFC-xxxx] Karn, P., and Simpson, W., "ICMP Security Failures Mes- 672 sages", draft-simpson-icmp-ipsec-fail-02.txt, work in 673 progress. 675 [RFC-yyyy] Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Trans- 676 form", draft-ietf-ipsec-ciph-desx-00.txt, work in 677 progress. 679 [RFC-zzzz] Karn, P., and Simpson, W., "Photuris: Session Key Manage- 680 ment Protocol", draft-simpson-photuris-17.txt, work in | 681 progress. 683 Contacts 685 Comments about this document should be discussed on the 686 photuris@adk.gr mailing list. 688 Questions about this document can also be directed to: 690 Phil Karn 691 Qualcomm, Inc. 692 6455 Lusk Blvd. 693 San Diego, California 92121-2779 695 karn@qualcomm.com 696 karn@unix.ka9q.ampr.org (preferred) 698 William Allen Simpson 699 DayDreamer 700 Computer Systems Consulting Services 701 1384 Fontaine 702 Madison Heights, Michigan 48071 704 wsimpson@UMich.edu 705 wsimpson@GreenDragon.com (preferred)