idnits 2.17.1 draft-ietf-ipsec-photuris-ext-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 185: '... Exchange Scheme SHOULD provide at lea...' RFC 2119 keyword, line 248: '... Exchange Scheme SHOULD provide at lea...' RFC 2119 keyword, line 284: '... Exchange Scheme SHOULD provide at lea...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...62 abef f434 ...' == Line 459 has weird spacing: '...y-Count two...' -- 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 1995) is 10383 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: 'RFC-1852' is mentioned on line 191, but not defined ** Obsolete undefined reference: RFC 1852 (Obsoleted by RFC 2841) == Missing Reference: 'RFC-xxxx' is mentioned on line 254, but not defined == Missing Reference: 'RFC-1144' is mentioned on line 440, but not defined == Unused Reference: 'RFC-1825' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC-1850' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'Schneier94' is defined on line 544, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Firefly' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 1850 (Obsoleted by RFC 4750) ** Downref: Normative reference to an Experimental RFC: RFC 1851 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier94' Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Simpson, Editor 2 Internet Draft DayDreamer 3 expires in six months November 1995 5 Photuris Extensions 6 draft-ietf-ipsec-photuris-ext-01.txt 8 Status of this Memo 10 This document is a submission to the IP Security Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the ipsec@ans.net mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 29 Directories on: 31 ftp.is.co.za (Africa) 32 nic.nordu.net (Europe) 33 ds.internic.net (US East Coast) 34 ftp.isi.edu (US West Coast) 35 munnari.oz.au (Pacific Rim) 37 Abstract 39 Photuris is an experimental session-key management protocol intended 40 for use with the IP Security Protocols (AH and ESP). Extensible 41 Exchange Schemes and Attributes are provided to enable future 42 implementation changes without affecting the basic protocol. 44 1. Additional Exchange Schemes 46 The packet format and basic facilities are already defined for 47 Photuris [Firefly]. 49 Up-to-date values for the Exchange Schemes are specified in the most 50 recent "Assigned Numbers" [RFC-1700]. This document defines the 51 following values: 53 (3) Implementation Optional. Modular Exponentiation using a 1024- 54 bit strong prime (p), expressed in hex: 56 58 The recommended generator (g) for this prime is 3. 60 Provides 1024 bits of keying material. The cryptographic 61 strength is currently estimated to be equivalent to 86 bits 62 (pessimistic) through 98 bits (optimistic). Exponent lengths 63 of 196 to 256 bits are recommended. 65 The Identification_Message and Change_Message Privacy-Method is 66 DES-CBC-64. 68 The Change_Message Validity-Method is MD5. 70 (4) Implementation Optional. Modular Exponentiation using a 2048- 71 bit strong prime (p), expressed in hex: 73 75 The recommended generator (g) for this prime is 2. 77 Provides 2048 bits of keying material. The cryptographic 78 strength is currently estimated to be equivalent to ??? bits 79 (pessimistic). Exponent lengths of ??? to 512 bits are 80 recommended. 82 The Identification_Message and Change_Message Privacy-Method is 83 3DES-CBC-64. 85 The Change_Message Validity-Method is MD5. 87 (5) Implementation Optional. Modular Exponentiation using a 1024- 88 bit strong prime (p), expressed in hex: 90 a478 8e21 84b8 d68b fe02 690e 4dbe 485b 91 17a8 0bc5 f21d 680f 1a84 1313 9734 f7f2 92 b0db 4e25 3750 018a ad9e 86d4 9b60 04bb 93 bcf0 51f5 2fcb 66d0 c5fc a63f bfe6 3417 95 3485 bbbf 7642 e9df 9c74 b85b 6855 e942 96 13b8 c2d8 9162 abef f434 2435 0e96 be41 97 edd4 2de9 9a69 6163 8c1d ac59 8bc9 0da0 98 69b5 0c41 4d8e b865 2adc ff4a 270d 567f 100 The recommended generator (g) for this prime is 5. 102 Provides 1024 bits of keying material. The cryptographic 103 strength is currently estimated to be equivalent to 86 bits 104 (pessimistic) through 98 bits (optimistic). Exponent lengths 105 of 196 to 256 bits are recommended. 107 The Identification_Message and Change_Message Privacy-Method is 108 DES-CBC-64. 110 The Change_Message Validity-Method is MD5. 112 This prime modulus was randomly generated by a freely available 113 program written by Phil Karn, verified using the 114 mpz_probab_prime() function Miller-Rabin test in the Gnu Math 115 Package (GMP) version 1.3.2; and also verified with GMP on 116 another platform by Frank A Stevenson. 118 (6) Reserved. 120 (7) Implementation Optional. Elliptic curve: 122 124 The Identification_Message and Change_Message Privacy-Method is 125 3DES-CBC-64. 127 The Change_Message Validity-Method is SHA. 129 (8) Implementation Optional. Modular Exponentiation using a 4096- 130 bit strong prime (p), expressed in hex: 132 134 The recommended generator (g) for this prime is 2. 136 Provides 4096 bits of keying material. The cryptographic 137 strength is currently estimated to be equivalent to ??? bits 138 (pessimistic). Exponent lengths of ??? to 1024 bits are 139 recommended. 141 The Identification_Message and Change_Message Privacy-Method is 142 3DES-CBC-64. 144 The Change_Message Validity-Method is SHA. 146 2. Additional Attributes 148 The basic Attribute formats are already defined for Photuris 149 [Firefly]. 151 Up-to-date values for the Attribute Type are specified in the most 152 recent "Assigned Numbers" [RFC-1700]. This document concerns the 153 following values: 155 A I Type 156 + + 6 SHA 157 + 15 RC5 158 + 20 Triple DES-CBC, 0-bit IV 159 + 21 Triple DES-CBC, 32-bit IV 160 + 22 Triple DES-CBC, 64-bit IV 161 + 26 PKCS 162 + 27 DNS-SIG certificate 163 + 28 PGP certificate 164 + 29 X.509 certificate chain 165 + 32 Sensitivity Label 166 + 33 VJ Header Compression 167 + 34 LZ77 168 + 35 Stac LZS 169 + 36 AH-Sequence 171 A Initiator/Responder Attribute-Choice 172 I Identity-Choice 173 + feature must be supported 174 when algorithm optionally supported 176 2.1. SHA 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type 6 183 Length 0 185 The selected Exchange Scheme SHOULD provide at least 80-bits of 186 cryptographic strength. 188 Attribute-Choice 190 When selected as an Initiator or Responder Attribute-Choice, 191 pursuant to [RFC-1852], SHA is also used as the key generation 192 cryptographic hash for generating the SPI session-key. All 160- 193 bits of the generated hash are used for the key. 195 Identity-Choice 197 When selected as an Identity-Choice, the resulting Verification field 198 is 160-bits (22 octets including Size). 200 The SHA hash is calculated as described in "Identity Verification". 201 The authentication secret-key (as specified) is selected based on the 202 contents of the Identification field. 204 The Identification field contains a variable precision number. Valid 205 Identifications and secret-keys are preconfigured by the parties. 207 There is no required format or content for the Identification value. 208 The value may be a number or string of any kind. 210 Validity-Method 212 When selected as a Validity-Method, the resulting Verification field 213 is 160-bits (22 octets including Size). 215 The hash is calculated as described in "Change Verification". The 216 leading shared-secret is not padded to any particular alignment. 218 2.2. RC5 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type | Length | Version | Word-Size | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Rounds | Key-Size | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Type 15 227 Length 4 229 Version Indicates the most recent version supported. All 230 implementations must support version 16 (0x10). 232 Word-Size The number of bits used by internal calculations. 233 All implementations must support at least 32-bits. 235 Rounds The number of rounds used. All implementations must 236 support at least 12 rounds. 238 Key-Size The number of octets in the session-key. All 239 implementations must support at least 5 octets. 241 When offered as an Attribute, the Version, Word-Size, Rounds, and 242 Key-Size are set to the maximum supported. 244 When chosen as an Attribute, the Version, Word-Size, Rounds, and 245 Key-Size are set to the actual values to be used. 247 Note that the Key-Size might be limited by available Exchange 248 Schemes. The selected Exchange Scheme SHOULD provide at least Key- 249 Size (in bits) of cryptographic strength. 251 Attribute-Choice 253 When selected as an Initiator or Responder Attribute-Choice, 254 pursuant to [RFC-xxxx], MD5 is used as the key generation 255 cryptographic hash for generating the SPI session-key. The most 256 significant Key-Size octets of the generated hash are used for the 257 key. 259 Privacy-Method 261 When selected as a Privacy-Method, MD5 is used as the key generation 262 cryptographic hash for generating the privacy session-key. The most 263 significant Key-Size octets of the generated hash are used for the 264 key. 266 The least-significant bits of the ???-bit Initialization Vector (IV) 267 are set to the least-significant bits of the Type, LifeTime, and SPI 268 fields. Encryption begins with the next field, and continues to the 269 end of the data indicated by the UDP Length. 271 2.3. Triple DES-CBC 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Type 20, 21 or 22 279 Length 0 281 This attribute indicates EDE encryption (and DED decryption) with 282 three 56-bit keys. 284 The selected Exchange Scheme SHOULD provide at least 112-bits of 285 cryptographic strength. 287 Attribute-Choice 289 When selected as an Initiator or Responder Attribute-Choice, 290 pursuant to [RFC-1851], MD5 is used as the key generation 291 cryptographic hash for generating the three SPI session-keys. 293 The first MD5 hash is generated as described in [Firefly]. 295 A second MD5 hash is calculated over the following concatenated 296 values: 298 + the computed shared-secret, 299 + the first 128-bit hash, 300 + the computed shared-secret again. 302 A third MD5 hash is calculated over the following concatenated 303 values: 305 + the computed shared-secret, 306 + the second 128-bit hash, 307 + the computed shared-secret again. 309 In all three keys, the most significant 64-bits of the generated 310 hash are used for the key. The least significant bit of each 311 octet is ignored (or set to parity). 313 Privacy-Method 315 When selected as a Privacy-Method, MD5 is used as the key generation 316 cryptographic hash for generating the privacy session-keys. The 317 three keys are generated as described above. 319 The 64-bit Initialization Vector (IV) is set to the Type, LifeTime, 320 and SPI fields. Encryption begins with the next field, and continues 321 to the end of the data indicated by the UDP Length. 323 2.4. PGP certificate 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Type 28 331 Length 0 333 When selected as a Signature-Choice, the resulting Signature field 334 size is variable. PGP certificates include an identification of the 335 signature algorithm. As a minimum, it is required that all 336 implementations support MD5 with RSA. 338 A Certificate field always follows the Signature field, and contains 339 a PGP certificate. The PGP formats document is distributed with 340 every copy of PGP. If the implementation cannot handle the given 341 certificate, an Error_Message indicates Signature Failure. 343 PGP certificates include version numbers. All implementations must 344 support version 3 (PGP 2.6) certificates. A certificate chain can 345 include certificates with different version numbers. 347 The length of the RSA key is encoded in each certificate. All 348 implementations must support a minimum of 2048-bit keys. 350 2.5. X.509 certificate chain 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Type 29 357 Length 0 359 Future extensions to this attribute may add 360 parameter values. This will be indicated by a non- 361 zero value. 363 When selected as a Signature-Choice, the resulting Signature field 364 size is variable. X.509 certificates include an identification of 365 the signature algorithm. As a minimum, it is required that all 366 implementations support MD5 with RSA. 368 A Certificate field always follows the Signature field, and contains 369 a chain of X.509 certificates [??? reference]. If the implementation 370 cannot handle the given certificate chain, an Error_Message indicates 371 Signature Failure. 373 X.509 certificates include version numbers. All implementations must 374 support X.509.v1 (1988) certificates. A certificate chain can 375 include certificates with different version numbers. 377 The length of the RSA key is encoded in each certificate. All 378 implementations must support a minimum of 512-bit keys. 380 Different certificates in the chain may have different signature 381 algorithms and key lengths. 383 To improve performance, an implementation can cache the public keys 384 for the issuers that frequently sign end-user certificates. These 385 cached public keys can be used to verify the final certificate, and 386 avoid the cost of verifying each certificate in the chain. However, 387 the transmitter should always send the entire chain. 389 2.6. DNS-SIG 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Type 27 397 Length 0 399 2.7. Sensitivity Label 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Type 32 407 Length 0 409 2.8. VJ Header Compression 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | Slots | Flags | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Type 33 417 Length 2 419 Slots indicates the maximum slot identifier. This is one 420 less than the actual number of slots; the slot 421 identifier has values from zero to Slots. 423 There may be implementations that have problems with 424 small numbers. The example in [RFC-1144] will only 425 work with 3 through 254 slots. 427 Flags (0) All compressed TCP packets must set the C bit 428 in every change mask, and must include the slot 429 identifier. 431 (1) The slot identifer may be compressed. This 432 requires an ability for the implementation to 433 indicate all errors in reception to the 434 decompression module. Synchronization after errors 435 depends on waiting for a packet with the slot 436 identifier. See the discussion in [RFC-1144]. 438 When selected as an Initiator or Responder Attribute-Choice, all data 439 encapsulated in ESP [RFC-1827] is first compressed according to 440 [RFC-1144]. 442 Note that this attribute requires ordered delivery. Therefore, this 443 attribute is principly used for single network hops. 445 2.9. LZ77 447 2.10. Stac LZS 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length | History-Count | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Check-Mode | 453 +-+-+-+-+-+-+-+-+ 455 Type 35 457 Length 3 459 History-Count two octets, most significant octet first. Specifies 460 the maximum number of Compression Histories. 462 (0) the implementation expects the peer to reset the 463 Compression History at the beginning of every 464 packet. 466 (1) only one history is maintained. 468 Other valid values range from 2 to 65535. The peer 469 is not required to send as many histories as the 470 implementation indicates that it can receive. 472 Check-Mode indicates support of LCB, CRC or Sequence checking. 474 0 None (default) 475 1 LCB 476 2 CRC 477 4 Sequence Number 479 When offered as an Attribute, the History-Count is set to the maximum 480 histories that can be sent, and the Check-Mode is the XOR of the 481 modes supported. 483 When selected as an Initiator or Responder Attribute-Choice, the 484 History-Count is set to the maximum histories that can be received 485 (less than or equal to the number offered), and the Check-Mode is set 486 to only one of the modes supported. 488 2.11. AH-Sequence 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Type 36 496 Length 0 498 When selected as an Initiator or Responder Attribute-Choice, the 499 previously Reserved field of the Authentication Header (AH) [RFC- 500 1826] contains a 16-bit sequence number. The SPI Owner (receiver) 501 validates this number within an implementation dependent range of 502 expected values. Any AH protected datagram that fails this test is 503 silently discarded. 505 When the range has been exhausted, the SPI Owner (receiver) expires 506 the SPI, despite any remaining SPI LifeTime. On arrival of an AH 507 protected datagram with an expired SPI, an appropriate ICMP Security 508 Failures message is generated (Type 40 Code 0), and the datagram is 509 discarded. 511 Security Considerations 513 Security issues are the primary topic of this memo. 515 Acknowledgements 517 Robert W Baldwin of RSA provided text for RC5 and X.509 Certificates. 519 References 521 [Firefly] 522 "Photuris" is the latin name for the firefly. "Firefly" is 523 in turn the name for the USA National Security 524 Administration's (classified) key exchange protocol for the 525 STU-III secure telephone. Informed speculation has it that 526 Firefly is based on very similar design principles. 528 [RFC-1700] 529 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 530 RFC-1700, USC/Information Sciences Institute, October 1994. 532 [RFC-1825] 533 Atkinson, R., "Security Architecture for the Internet 534 Protocol", RFC-1825, Naval Research Laboratory, July 1995. 536 [RFC-1826] 538 [RFC-1827] 540 [RFC-1850] 542 [RFC-1851] 544 [Schneier94] 545 Schneier, B., "Applied Cryptography", John Wiley & Sons, New 546 York, NY, 1994. ISBN 0-471-59756-2. 548 Author's Address 550 Questions about this memo can also be directed to: 552 William Allen Simpson 553 Daydreamer 554 Computer Systems Consulting Services 555 1384 Fontaine 556 Madison Heights, Michigan 48071 558 Bill.Simpson@um.cc.umich.edu 559 bsimpson@MorningStar.com 560 Table of Contents 562 1. Additional Exchange Schemes ........................... 1 564 2. Additional Attributes ................................. 3 565 2.1 SHA ............................................. 3 566 2.2 RC5 ............................................. 4 567 2.3 Triple DES-CBC .................................. 6 568 2.4 PGP certificate ................................. 7 569 2.5 X.509 certificate chain ......................... 7 570 2.6 DNS-SIG ......................................... 8 571 2.7 Sensitivity Label ............................... 9 572 2.8 VJ Header Compression ........................... 9 573 2.9 LZ77 ............................................ 10 574 2.10 Stac LZS ........................................ 10 575 2.11 AH-Sequence ..................................... 11 577 SECURITY CONSIDERATIONS ...................................... 12 579 ACKNOWLEDGEMENTS ............................................. 12 581 REFERENCES ................................................... 12 583 AUTHOR'S ADDRESS ............................................. 12