idnits 2.17.1 draft-simpson-photuris-schemes-05.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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 159 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 140: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 211: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 250: '...e of the modulus MUST be unique, indep...' RFC 2119 keyword, line 303: '... a previous key MUST be discarded. A...' RFC 2119 keyword, line 305: '... MUST be discarded. The Key-Generat...' (12 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 (March 1998) is 9539 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 423, but not defined ** Obsolete undefined reference: RFC 1852 (Obsoleted by RFC 2841) == Unused Reference: 'RFC-1850' is defined on line 775, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DBP96' -- 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-16 ** Downref: Normative reference to an Experimental draft: draft-simpson-photuris (ref. 'RFC-zzzz') Summary: 18 errors (**), 0 flaws (~~), 6 warnings (==), 9 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 March 1998 6 Photuris: Extended Schemes and Attributes 7 draft-simpson-photuris-schemes-05.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 Copyright Notice 37 Copyright (C) Philip Karn and William Allen Simpson (1995-1998). All 38 Rights Reserved. 40 Abstract 42 Photuris is a session-key management protocol. Extensible Exchange- 43 Schemes are provided to enable future implementation changes without 44 affecting the basic protocol. 46 Additional authentication attributes are included for use with the IP 47 Authentication Header (AH). 49 Additional confidentiality attributes are included for use with the 50 IP Encapsulating Security Protocol (ESP). 52 1. Additional Exchange-Schemes 54 The packet format and basic facilities are already defined for Pho- 55 turis [RFC-zzzz]. 57 These optional Exchange-Schemes are specified separately, and no sin- 58 gle implementation is expected to support all of them. 60 This document defines the following values: 62 (3) Implementation Optional. Any modulus (p) with a recommended 63 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 64 the modulus is contained in the Exchange-Scheme Value field in 65 the list of Offered-Schemes. 67 An Exchange-Scheme Size of zero is invalid. 69 Key-Generation-Function "MD5 Hash" | 70 Privacy-Method "Simple Masking" | 71 Validity-Method "MD5-IPMAC Check" | 73 This combination of features requires a modulus with at least 74 64-bits of cryptographic strength. 76 (4) Implementation Optional. Any modulus (p) with a recommended 77 generator (g) of 2. When the Exchange-Scheme Size is non-zero, 78 the modulus is contained in the Exchange-Scheme Value field in 79 the list of Offered-Schemes. 81 When the Exchange-Scheme Size field is zero, includes by refer- 82 ence all of the moduli specified in the list of Offered-Schemes 83 for Scheme #2. 85 Key-Generation-Function "MD5 Hash" | 86 Privacy-Method "DES-CBC over Mask" | 87 Validity-Method "MD5-IPMAC Check" | 89 This combination of features requires a modulus with at least 90 64-bits of cryptographic strength. 92 (5) Implementation Optional. Any modulus (p) with a recommended 93 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 94 the modulus is contained in the Exchange-Scheme Value field in 95 the list of Offered-Schemes. 97 An Exchange-Scheme Size of zero is invalid. 99 Key-Generation-Function "MD5 Hash" | 100 Privacy-Method "Simple Masking" | 101 Validity-Method "MD5-IPMAC Check" | 103 This combination of features requires a modulus with at least 104 64-bits of cryptographic strength. 106 (6) Implementation Optional. Any modulus (p) with a recommended 107 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 108 the modulus is contained in the Exchange-Scheme Value field in 109 the list of Offered-Schemes. 111 When the Exchange-Scheme Size field is zero, includes by refer- 112 ence all of the moduli specified in the list of Offered-Schemes 113 for Scheme #3. 115 Key-Generation-Function "MD5 Hash" | 116 Privacy-Method "DES-CBC over Mask" | 117 Validity-Method "MD5-IPMAC Check" | 119 This combination of features requires a modulus with at least 120 64-bits of cryptographic strength. 122 (7) Implementation Optional. Any modulus (p) with a variable gen- 123 erator (g). When the Exchange-Scheme Size is non-zero, the 124 pair [g,p] is contained in the Exchange-Scheme Value field in 125 the list of Offered-Schemes. Each is encoded in a separate 126 Variable Precision Integer (VPI). The generator VPI is fol- 127 lowed by (concatenated to) the modulus VPI, and the result is 128 nested inside the Exchange-Scheme Value field. 130 An Exchange-Scheme Size of zero is invalid. 132 Key-Generation-Function "MD5 Hash" | 133 Privacy-Method "Simple Masking" | 134 Validity-Method "MD5-IPMAC Check" | 136 This combination of features requires a modulus with at least 137 64-bits of cryptographic strength. 139 When more than one modulus is specified for a given kind of 140 Scheme, the Size of the modulus MUST be unique, independent of 141 the Size of the generator. 143 (8) Implementation Optional. Any modulus (p) with a recommended 144 generator (g) of 2. When the Exchange-Scheme Size is non-zero, 145 the modulus is contained in the Exchange-Scheme Value field in 146 the list of Offered-Schemes. 148 When the Exchange-Scheme Size field is zero, includes by refer- 149 ence all of the moduli specified in the list of Offered-Schemes 150 for Schemes #2 and #4. 152 Key-Generation-Function "SHA1 Hash" | 153 Privacy-Method "DES-EDE3-CBC over Mask" | 154 Validity-Method "SHA1-IPMAC Check" | 156 This combination of features requires a modulus with at least 157 112-bits of cryptographic strength. 159 (10) Implementation Optional. Any modulus (p) with a recommended 160 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 161 the modulus is contained in the Exchange-Scheme Value field in 162 the list of Offered-Schemes. 164 When the Exchange-Scheme Size field is zero, includes by refer- 165 ence all of the moduli specified in the list of Offered-Schemes 166 for Scheme #5. 168 Key-Generation-Function "MD5 Hash" | 169 Privacy-Method "DES-CBC over Mask" | 170 Validity-Method "MD5-IPMAC Check" | 172 This combination of features requires a modulus with at least 173 64-bits of cryptographic strength. 175 (12) Implementation Optional. Any modulus (p) with a recommended 176 generator (g) of 3. When the Exchange-Scheme Size is non-zero, 177 the modulus is contained in the Exchange-Scheme Value field in 178 the list of Offered-Schemes. 180 When the Exchange-Scheme Size field is zero, includes by refer- 181 ence all of the moduli specified in the list of Offered-Schemes 182 for Schemes #3 and #6. 184 Key-Generation-Function "SHA1 Hash" | 185 Privacy-Method "DES-EDE3-CBC over Mask" | 186 Validity-Method "SHA1-IPMAC Check" | 188 This combination of features requires a modulus with at least 189 112-bits of cryptographic strength. 191 (14) Implementation Optional. Any modulus (p) with a variable gen- 192 erator (g). When the Exchange-Scheme Size is non-zero, the 193 pair [g,p] is contained in the Exchange-Scheme Value field in 194 the list of Offered-Schemes. Each is encoded in a separate 195 Variable Precision Integer (VPI). The generator VPI is 196 followed by (concatenated to) the modulus VPI, and the result 197 is nested inside the Exchange-Scheme Value field. 199 When the Exchange-Scheme Size field is zero, includes by refer- 200 ence all of the moduli specified in the list of Offered-Schemes 201 for Scheme #7. 203 Key-Generation-Function "MD5 Hash" | 204 Privacy-Method "DES-CBC over Mask" | 205 Validity-Method "MD5-IPMAC Check" | 207 This combination of features requires a modulus with at least 208 64-bits of cryptographic strength. 210 When more than one modulus is specified for a given kind of 211 Scheme, the Size of the modulus MUST be unique, independent of 212 the Size of the generator. 214 (20) Implementation Optional. Any modulus (p) with a recommended 215 generator (g) of 5. When the Exchange-Scheme Size is non-zero, 216 the modulus is contained in the Exchange-Scheme Value field in 217 the list of Offered-Schemes. 219 When the Exchange-Scheme Size field is zero, includes by refer- 220 ence all of the moduli specified in the list of Offered-Schemes 221 for Schemes #5 and #10. 223 Key-Generation-Function "SHA1 Hash" | 224 Privacy-Method "DES-EDE3-CBC over Mask" | 225 Validity-Method "SHA1-IPMAC Check" | 227 This combination of features requires a modulus with at least 228 112-bits of cryptographic strength. 230 (28) Implementation Optional. Any modulus (p) with a variable gen- 231 erator (g). When the Exchange-Scheme Size is non-zero, the 232 pair [g,p] is contained in the Exchange-Scheme Value field in 233 the list of Offered-Schemes. Each is encoded in a separate 234 Variable Precision Integer (VPI). The generator VPI is fol- 235 lowed by (concatenated to) the modulus VPI, and the result is 236 nested inside the Exchange-Scheme Value field. 238 When the Exchange-Scheme Size field is zero, includes by refer- 239 ence all of the moduli specified in the list of Offered-Schemes 240 for Schemes #7 and #14. 242 Key-Generation-Function "SHA1 Hash" | 243 Privacy-Method "DES-EDE3-CBC over Mask" | 244 Validity-Method "SHA1-IPMAC Check" | 246 This combination of features requires a modulus with at least 247 112-bits of cryptographic strength. 249 When more than one modulus is specified for a given kind of 250 Scheme, the Size of the modulus MUST be unique, independent of 251 the Size of the generator. 253 2. Additional Key-Generation-Function 254 2.1. SHA1 Hash 256 SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating 257 the key(s). The key(s) begin with the most significant bits of the 258 hash. SHA1 is iterated as needed to generate the requisite length of 259 key material. 261 When an individual key does not use all 160-bits of the last hash, 262 any remaining unused (least significant) bits of the last hash are 263 discarded. When combined with other uses of key generation for the 264 same purpose, the next key will begin with a new hash iteration. 266 3. Additional Privacy-Methods 267 3.1. DES-CBC over Mask 269 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- 270 vacy-key material is generated to match the message length, beginning 271 with the next field after the SPI, and including the Padding. The 272 message is masked by XOR with the privacy-key. 274 Then, the Key-Generation-Function is iterated to generate a DES key. 275 The most significant 64-bits (8 bytes) of the generated hash are used 276 for the privacy-key, and the remainder are discarded. Although 277 extremely rare, the 64 weak, semi-weak, and possibly weak keys 278 [Schneier95, pages 280-282] are discarded. The Key-Generation- 279 Function is iterated until a valid key is obtained. 281 The least significant bit of each key byte is ignored (or set to par- 282 ity when the implementation requires). 284 The 64-bit CBC IV is zero. Message encryption begins with the next + 285 field after the SPI, and continues to the end of the data indicated 286 by the UDP Length. 288 3.2. DES-EDE3-CBC over Mask 290 This is "Triple DES" outer-CBC EDE encryption (and DED decryption) 291 with three 56-bit keys [KR96]. 293 As described in [RFC-zzzz] "Privacy-Key Computation", sufficient pri- 294 vacy-key material is generated to match the message length, beginning 295 with the next field after the SPI, and including the Padding. The 296 message is masked by XOR with the privacy-key. 298 Then, the Key-Generation-Function is iterated (at least) three times 299 to generate the three DES keys. The most significant 64-bits (8 300 bytes) of each generated hash are used for each successive privacy- 301 key, and the remainder are discarded. Each key is examined sequen- 302 tially, in the order used for encryption. A key that is identical to 303 a previous key MUST be discarded. Although extremely rare, the 64 304 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] 305 MUST be discarded. The Key-Generation-Function is iterated until a 306 valid key is obtained before generating the next key. 308 In all three keys, the least significant bit of each key byte is 309 ignored (or set to parity when the implementation requires). 311 The 64-bit CBC IV is zero. Message encryption begins with the next + 312 field after the SPI, and continues to the end of the data indicated 313 by the UDP Length. 315 4. Additional Validity-Method 316 4.1. SHA1-IPMAC Check 318 As described in [RFC-zzzz] "Validity Verification", the Verification 319 field value is the SHA1 [FIPS-180-1] hash over the concatenation of 321 SHA1( key, keyfill, data, datafill, key, mdfill ) | 323 where the key is the computed verification-key. 325 The keyfill and datafill use the same pad-with-length technique | 326 defined for mdfill. This padding and length is implicit, and does 327 not appear in the datagram. 329 The resulting Verification field is a 160-bit Variable Precision 330 Integer (22 bytes including Size). When used in calculations, the + 331 Verification data includes both the Size and Value fields. 333 5. Additional Attributes 335 The attribute format and basic facilities are already defined for 336 Photuris [RFC-zzzz]. 338 These optional attributes are specified separately, and no single 339 implementation is expected to support all of them. 341 This document defines the following values: 343 Use Type 344 AEI 6 SHA1-IPMAC | 345 AEI 7 RIPEMD-160-IPMAC | 346 E 8 DES-CBC | 347 E 9 Invert (Decryption/Encryption) | 348 E 10 XOR | 350 A AH Attribute-Choice | 351 E ESP Attribute-Choice | 352 I Identity-Choice | 353 X dependent on list location | 355 5.1. SHA1-IPMAC 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Attribute | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Attribute 6 | 363 Length 0 365 Symmetric Identification + 367 When selected as an Identity-Choice, the immediately following 368 Identification field contains an unstructured Variable Precision 369 Integer. Valid Identifications and symmetric secret-keys are pre- 370 configured by the parties. 372 There is no required format or content for the Identification 373 value. The value may be a number or string of any kind. See 374 [RFC-zzzz] "Use of Identification and Secrets" for details. 376 The symmetric secret-key (as specified) is selected based on the 377 contents of the Identification field. All implementations MUST 378 support at least 62 bytes. The selected symmetric secret-key 379 SHOULD provide at least 80-bits of cryptographic strength. 381 As described in [RFC-zzzz] "Identity Verification", the Verifica- 382 tion field value is the SHA1 [FIPS-180-1] hash over the concatena- 383 tion of: 385 SHA1( key, keyfill, data, datafill, key, mdfill ) | 387 where the key is the computed verification-key. 389 The keyfill and datafill use the same pad-with-length technique | 390 defined for mdfill. This padding and length is implicit, and does 391 not appear in the datagram. 393 The resulting Verification field is a 160-bit Variable Precision 394 Integer (22 bytes including Size). When used in calculations, the + 395 Verification data includes both the Size and Value fields. 397 For both [RFC-zzzz] "Identity Verification" and "Validity Verifi- 398 cation", the verification-key is the SHA1 [FIPS-180-1] hash of the 399 following concatenated values: 401 + the symmetric secret-key, 402 + the computed shared-secret. 404 For [RFC-zzzz] "Session-Key Computation", the symmetric secret-key 405 is used directly as the generation-key. 407 The symmetric secret-key is used in calculations in the same fash- 408 ion as [RFC-zzzz] "MD5-IPMAC Symmetric Identification". 410 Authentication + 412 May be selected as an AH or ESP Attribute-Choice, pursuant to 413 [RFC-1852] et sequitur. The selected Exchange-Scheme SHOULD pro- 414 vide at least 80-bits of cryptographic strength. 416 As described in [RFC-zzzz] "Session-Key Computation", the most 417 significant 384-bits (48 bytes) of the Key-Generation-Function 418 iterations are used for the key. 420 Profile: 422 When negotiated with Photuris, the transform differs slightly 423 from [RFC-1852]. 425 The form of the authenticated message is: 427 SHA1( key, keyfill, datagram, datafill, key, mdfill ) 429 where the key is the SPI session-key. 431 The additional datafill protects against the attack described 432 in [PO96]. The keyfill and datafill use the same pad-with- 433 length technique defined for mdfill. This padding and length 434 is implicit, and does not appear in the datagram. 436 5.2. RIPEMD-160-IPMAC 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Attribute | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Attribute 7 | 444 Length 0 446 Symmetric Identification | 448 When selected as an Identity-Choice, the immediately following | 449 Identification field contains an unstructured Variable Precision | 450 Integer. Valid Identifications and symmetric secret-keys are pre- | 451 configured by the parties. | 453 There is no required format or content for the Identification | 454 value. The value may be a number or string of any kind. See | 455 [RFC-zzzz] "Use of Identification and Secrets" for details. | 457 The symmetric secret-key (as specified) is selected based on the | 458 contents of the Identification field. All implementations MUST | 459 support at least 62 bytes. The selected symmetric secret-key | 460 SHOULD provide at least 80-bits of cryptographic strength. | 462 As described in [RFC-zzzz] "Identity Verification", the Verifica- | 463 tion field value is the RIPEMD-160 [DBP96] hash over the concate- | 464 nation of: | 466 RIPEMD160( key, keyfill, data, datafill, key, mdfill ) | 468 where the key is the computed verification-key. | 470 The keyfill and datafill use the same pad-with-length technique | 471 defined for mdfill. This padding and length is implicit, and does | 472 not appear in the datagram. | 473 The resulting Verification field is a 160-bit Variable Precision | 474 Integer (22 bytes including Size). When used in calculations, the | 475 Verification data includes both the Size and Value fields. | 477 For both [RFC-zzzz] "Identity Verification" and "Validity Verifi- | 478 cation", the verification-key is the RIPEMD-160 [DBP96] hash of | 479 the following concatenated values: | 481 + the symmetric secret-key, | 482 + the computed shared-secret. | 484 For [RFC-zzzz] "Session-Key Computation", the symmetric secret-key | 485 is used directly as the generation-key. | 487 The symmetric secret-key is used in calculations in the same fash- | 488 ion as [RFC-zzzz] "MD5-IPMAC Symmetric Identification". | 490 Authentication | 492 May be selected as an AH or ESP Attribute-Choice. The selected 493 Exchange-Scheme SHOULD provide at least 80-bits of cryptographic 494 strength. 496 As described in [RFC-zzzz] "Session-Key Computation", the most 497 significant 384-bits (48 bytes) of the Key-Generation-Function 498 iterations are used for the key. 500 Profile: 502 When negotiated with Photuris, the form of the authenticated | 503 message is: 505 RIPEMD160( key, keyfill, datagram, datafill, key, mdfill ) | 507 where the key is the SPI session-key. 509 The additional datafill protects against the attack described 510 in [PO96]. The keyfill and datafill use the same pad-with- | 511 length technique defined for mdfill. This padding and length 512 is implicit, and does not appear in the datagram. 514 5.3. DES-CBC 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Attribute | Length | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Attribute 8 522 Length 0 524 May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et 525 sequitur. The selected Exchange-Scheme SHOULD provide at least 526 56-bits of cryptographic strength. 528 As described in [RFC-zzzz] "Session-Key Computation", the most sig- 529 nificant 64-bits (8 bytes) of the Key-Generation iteration are used 530 for the key, and the remainder are 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. 535 The least significant bit of each key byte is ignored (or set to par- 536 ity when the implementation requires). 538 Profile: 540 When negotiated with Photuris, the transform differs slightly from 541 [RFC-1829]. 543 The 32-bit Security Parameters Index (SPI) field is followed by a 544 32-bit Sequence Number (SN). 546 The 64-bit CBC IV is generated from the 32-bit Security Parameters 547 Index (SPI) field followed by (concatenated with) the 32-bit 548 Sequence Number (SN) field. Then, the bit-wise complement of the 549 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits 550 (SPI): 552 (SPI ^ -SN) || SN 554 The Padding values begin with the value 1, and count up to the 555 number of padding bytes. For example, if the plaintext length is 556 41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any addi- 557 tional obscuring padding. 559 The PadLength and PayloadType are not appended. Instead, the Pay- + 560 loadType is indicated by the SPI, as specified by the ESP- + 561 Attributes attribute (#2). 563 After decryption, if the padding bytes are not the correct sequen- 564 tial values, then the payload is discarded, and a "Decryption 565 Failed" error is indicated, as described in [RFC-xxxx]. 567 5.4. Invert (Decryption/Encryption) 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Attribute | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Attribute 9 575 Length 0 577 May be selected as an ESP Attribute-Choice, immediately preceding an | 578 encryption choice. This indicates that the following attribute is | 579 inverted from encryption to decryption (or decryption to encryption) | 580 as the attributes are processed. | 582 For example, the combination 584 "DES-CBC", | 585 "Invert", | 586 "DES-CBC", | 587 "DES-CBC", | 589 indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) | 590 with three keys [KR96] pursuant to [RFC-1851] et sequitur. The 591 selected Exchange-Scheme SHOULD provide at least 112-bits of crypto- 592 graphic strength. 594 As described in [RFC-zzzz] "Session-Key Computation", the Key- 595 Generation-Function is iterated (at least) three times to generate 596 the three independent keys, in the order used for encryption. The 597 most significant 64-bits (8 bytes) of each iteration are used for 598 each successive key, and the remainder are discarded. + 600 Each key is examined sequentially, in the order used for encryption. 601 A key that is identical to any previous key MUST be discarded. Any | 602 weak keys indicated for the algorithm MUST be discarded. The Key- 603 Generation-Function is iterated until a valid key is obtained before 604 generating the next key. 606 Profile: - 608 When negotiated with Photuris, the "DES-EDE3-CBC" transform dif- | 609 fers slightly from [RFC-1851], in the same fashion as "DES-CBC" | 610 (described earlier). 612 5.5. XOR Whitening 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Attribute | Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Attribute 10 | 620 Length 0 622 May be selected as an ESP Attribute-Choice, pursuant to [RFC-yyyy] et 623 sequitur. The combination 625 "XOR", 626 "DES-CBC", | 627 "XOR", 629 indicates "DESX" encryption with three keys [KR96]. The selected 630 Exchange-Scheme SHOULD provide at least 104-bits of cryptographic 631 strength. 633 As described in [RFC-zzzz] "Session-Key Computation", the Key- 634 Generation-Function is iterated (at least) three times to generate 635 the three independent keys, in the order used for encryption. The 636 most significant bytes of each iteration are used for each successive 637 key, and the remainder are discarded. 639 Note that this attribute may appear multiple times in the same ESP 640 attribute list, both before and after an encryption transform. For 641 example, 643 "XOR", 644 "DES-CBC", | 645 "XOR", 646 "Invert", | 647 "DES-CBC", | 648 "XOR", 649 "DES-CBC", | 650 "XOR", 652 would be one possible combination with Triple DES. 654 A. Exchange-Scheme Selection - 656 At first glance, there appear to be a large number of exchange- + 657 schemes. In practice, the selection is simple to automate. + 659 Each scheme indicates a needed strength. This strength is based upon + 660 the functions used in protecting the Photuris Exchanges themselves. + 662 Each keyed attribute also indicates a needed strength. This strength + 663 is based upon its cryptographic functions. + 665 Because the usage of these functions is orthogonal, the same strength + 666 value can select an appropriate scheme that meets the needs of both + 667 features. 669 A.1. Responder 671 The attributes to be offered to the particular Initiator are exam- + 672 ined. For each level of strength specified, a scheme that meets or + 673 exceeds the requirements is offered. + 675 For example, a Responder offering MD5-IPMAC and SHA1-IPMAC might + 676 offer scheme #2 with a 512-bit modulus and a 1024-bit modulus, and + 677 scheme #4 with a zero Size (indicating moduli of #2). 679 A.2. Initiator 681 The strength indicated by the application for the Security Associa- + 682 tion, together with the party privacy policy of the system operator, + 683 is used to select from the offered schemes. The strength indicates + 684 the minimal level to be chosen, while the party privacy policy indi- + 685 cates whether to choose the minimal or maximal level of available + 686 protection. + 688 For example, an application might indicate that it desires 80-bits of + 689 strength. In that case, only the 1024-bit modulus would be appropri- + 690 ate. The party privacy policy of the system operator would indicate + 691 whether to choose scheme #2 with "Simple Masking" or scheme #4 with + 692 "DES-CBC over Mask". + 694 Alternatively, an application might indicate that it desires 64-bits + 695 of strength. The party privacy policy of the system operator would + 696 indicate whether to choose scheme #2 with the 512-bit modulus, or + 697 scheme #4 with the 1024-bit modulus. 699 Security Considerations - 701 Provision for multiple generators does not enhance the security of | 702 the Photuris protocol exchange itself. Rather, it provides an oppor- | 703 tunity for novelty of moduli, by allowing more forms of moduli to be | 704 used. An abundance of moduli inhibits a determined attacker from | 705 pre-calculating moduli exchange values, and discourages dedication of | 706 resources for analysis of any particular modulus. That is, this pro- | 707 tects the community of Photuris users. | 709 In addition to preventing various attacks by protecting verification | 710 fields, the masking of the message plaintext before encryption is 711 intended to obscure the relation of the number of parties and SPIs 712 active between two IP nodes. The privacy mask dependency on the SPI | 713 and SPILT generates a different initial encrypted block for every SPI 714 creation message. 716 This obscurement would be less effective when the SPI and SPILT are | 717 invariant or are not created for a particular exchange direction. 718 The number of parties could be revealed by the number of exchanges 719 with differences in the initial encrypted blocks. 721 Acknowledgements 723 Phil Karn was principally responsible for the design of party privacy 724 protection, and provided much of the design rationale text (now 725 removed to a separate document). 727 William Simpson designed the packet formats, and additional Exchange- 728 Schemes, editing and formatting. All such mistakes are his responsi- 729 bity. 731 Use of encryption for privacy protection is also found in the Sta- 732 tion-To-Station authentication protocol [DOW92]. 734 Bart Preneel and Paul C van Oorschot in [PO96] suggested adding 735 padding between the data and trailing key when hashing for authenti- 736 cation. 738 Niels Provos developed the first implementation with multiple schemes 739 and multiple moduli per scheme (circa July 1997). 741 References 743 [DBP96] Dobbertin, H., Bosselaers, A., and Preneel, B., + 744 "RIPEMD-160: a strengthened version of RIPEMD", Fast + 745 Software Encryption, Third International Workshop, Lec- + 746 ture Notes in Computer Science 1039 (1996), Springer- + 747 Verlag, pages 71-82. + 749 See also corrections at + 750 ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. + 752 [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J 753 Wiener, "Authentication and Authenticated Key Exchanges", 754 Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer 755 Academic Publishers, 1992. 757 [FIPS-180-1] 758 "Secure Hash Standard", National Institute of Standards 759 and Technology, U.S. Department Of Commerce, April 1995. 761 Also known as: 59 Fed Reg 35317 (1994). 763 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: 764 Weighing Security and Performance", Dr. Dobbs Journal, 765 January 1996. 767 [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of 768 two MAC algorithms", Advances in Cryptology -- Eurocrypt 769 '96, Lecture Notes in Computer Science 1070 (May 1996), 770 Springer-Verlag, pages 19-32. 772 [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC 773 Transform", July 1995. 775 [RFC-1850] Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES 776 Transform", September 1995. 778 [RFC-1851] Metzger, P., Simpson, W., "IP Authentication using Keyed 779 SHA", September 1995. 781 [RFC-xxxx] Karn, P., and Simpson, W., "ICMP Security Failures Mes- 782 sages", draft-simpson-icmp-ipsec-fail-02.txt, work in 783 progress. 785 [RFC-yyyy] Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Trans- 786 form", draft-ietf-ipsec-ciph-desx-00.txt, work in 787 progress. 789 [RFC-zzzz] Karn, P., and Simpson, W., "Photuris: Session Key Manage- 790 ment Protocol", draft-simpson-photuris-16.txt, work in 791 progress. 793 Contacts 795 Comments about this document should be discussed on the pho- 796 turis@adk.gr mailing list. 798 Questions about this document can also be directed to: 800 Phil Karn 801 Qualcomm, Inc. 802 6455 Lusk Blvd. 803 San Diego, California 92121-2779 805 karn@qualcomm.com 806 karn@unix.ka9q.ampr.org (preferred) 808 William Allen Simpson 809 DayDreamer 810 Computer Systems Consulting Services 811 1384 Fontaine 812 Madison Heights, Michigan 48071 814 wsimpson@UMich.edu 815 wsimpson@GreenDragon.com (preferred) 817 Full Copyright Statement 819 Copyright (C) Philip Karn and William Allen Simpson (1995-1998). All 820 Rights Reserved. 822 This document and translations of it may be copied and furnished to 823 others, and derivative works that comment on or otherwise explain it 824 or assist in its implementation may be prepared, copied, published 825 and distributed, in whole or in part, without restriction of any 826 kind, provided that the above copyright notice and this paragraph are 827 included on all such copies and derivative works. However, this doc- 828 ument itself may not be modified in any way, except as required to 829 translate it into languages other than English. 831 This document and the information contained herein is provided on an 832 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 833 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 834 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.