Network Working Group P Karn Internet Draft Qualcomm W A Simpson DayDreamer expires in six months April 1996 Photuris Schemes and Privacy Protection draft-simpson-photuris-schemes-00.txt Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as refer- ence material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract Photuris is an experimental session-key management protocol intended for use with the IP Security Protocols (AH and ESP). Extensible Exchange Schemes are provided to enable future implementation changes without affecting the basic protocol. An important improvement in security is provided by protecting exchanges with encryption. Karn & Simpson expires in six months [Page i] DRAFT Photuris Schemes April 1996 1. Party Privacy Protection Although each IP datagram carries a cleartext IP Destination, the ultimate destination can be hidden by "laundering" it through an encrypted tunnel. The IP Source could be hidden in the same manner. If the IP Source has been dynamically allocated, it provides no use- ful information to an eavesdropper. This leaves the identifying information that the parties send during the Photuris [Firefly] Identification Exchange. One would often like to deny this information to an eavesdropper, especially when this would reveal the location of a mobile user. The identification can be easily protected by encrypting the Identi- fication Exchange with the shared-secret just established. This keeps a passive eavesdropper from learning the identities of the par- ties, either directly from the certificates or by checking signatures against a known database of public keys. The scheme is not foolproof. By posing as the Responder, an active attacker could trick the Initiator into revealing its identity. However, this active attack is considerably more difficult than pas- sive vacuum-cleaner monitoring. As in the Clogging Defense, this attack requires appropriating a physical link, or subverting Internet routing. Unless the attacker can steal the private/secret key belonging to the Responder, the Initiator will discover the deception when verifying the Identification Exchange. Nota Bene: It is not possible for an Initiator to similarly trick the Respon- der. The Responder will verify the Initiator Identification before returning its own identity. This facility is distinct from party anonymity, where one of the parties refuses to identify itself to the other. Mutual party identification is fundamental to the security of this protocol. 1.1. Identification Exchange Identification Exchange messages are encrypted and decrypted using the Privacy-Method indicated by the current Scheme-Choice (see "Addi- tional Exchange Schemes"). The Privacy-Method specified key generation cryptographic hash is Karn & Simpson expires in six months [Page 1] DRAFT Photuris Schemes April 1996 used to create a special privacy session-key. This hash is calcu- lated over the following concatenated values: + the computed shared-secret, + the Initiator Cookie, + the Responder Cookie, + the SPI Owner (receiver) Exchange-Value, + the SPI User (sender) Exchange-Value, + the computed shared-secret again. Since the order of the Exchange-Value fields is different in each direction, the resulting privacy session-key will usually be differ- ent in each direction. When a larger number of keying-bits are needed than are available from the specified cryptographic hash, these keying-bits are gener- ated by duplicating the trailing shared-secret, and recalculating the hash. That is, the first hash will have one trailing copy of the shared-secret, the second hash will have two trailing copies of the shared-secret, and so forth. Implementation Notes: This is separate from any encryption method specified for Security Associations. The fields protected, the length of the Padding (if any), and other details are dependent on the Privacy-Method. See the "Pri- vacy Methods". The hash of the Exchange-Value includes both the Size and Value fields. 1.2. SPI Messages SPI Messages are encrypted and decrypted in the same fashion speci- fied for Identification Exchange messages. 2. Additional Exchange Schemes The packet format and basic facilities are already defined for Pho- turis [Firefly]. These optional exchange schemes are specified separately, and no sin- gle implementation is expected to support all of them. Karn & Simpson expires in six months [Page 2] DRAFT Photuris Schemes April 1996 Up-to-date values for the Exchange Schemes will be specified in the most recent "Assigned Numbers" [RFC-1700]. This document defines the following values: (3) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "not protected". The "SPI Messages" Validity-Method is "MD5-DP". (4) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-DP". (5) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "not protected". The "SPI Messages" Validity-Method is "MD5-DP". (6) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-DP". (7) Implementation Optional. Any modulus (p) with a variable gen- erator (g). The generator has the same number of significant bits as the modulus. The modulus is followed by (concatenated to) the generator, and the variable number of significant bits are contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method Karn & Simpson expires in six months [Page 3] DRAFT Photuris Schemes April 1996 is "not protected". The "SPI Messages" Validity-Method is "MD5-DP". (8) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "Triple DES-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-DP". (10) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-DP". (12) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "Triple DES-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-DP". (14) Implementation Optional. Any modulus (p) with a variable gen- erator (g). The generator has the same number of significant bits as the modulus. The modulus is followed by (concatenated to) the generator, and the variable number of significant bits are contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-DP". (20) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. The modulus is contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method Karn & Simpson expires in six months [Page 4] DRAFT Photuris Schemes April 1996 is "Triple DES-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-DP". (28) Implementation Optional. Any modulus (p) with a variable gen- erator (g). The generator has the same number of significant bits as the modulus. The modulus is followed by (concatenated to) the generator, and the variable number of significant bits are contained in the Exchange Scheme Value field in the list of Offered-Schemes. The "Identification Exchange" and "SPI Messages" Privacy-Method is "Triple DES-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-DP". 3. Privacy Methods 3.1. DES-CBC with secret IV MD5 [RFC-1321] is used as the key generation cryptographic hash for generating the privacy session-key, as described in "Party Privacy Protection". The most significant 64-bits of the generated hash are used for the key. The least significant bit of each key octet is ignored (or set to parity when the implementation requires). The least significant 64-bits of the generated hash are used for the Initialization Vector (IV). For each message, this is logically XOR'd with the concatenated message Type, LifeTime, and SPI fields, and then used for the message IV. Message encryption begins with the next field after the SPI, and con- tinues to the end of the data indicated by the UDP Length. 3.2. Triple DES-CBC with secret IV This method indicates outer-CBC EDE encryption (and DED decryption) with three 56-bit keys [KR96]. MD5 [RFC-1321] is used as the key generation cryptographic hash for generating the three privacy session-keys, as described in "Party Privacy Protection". The most significant 64-bits of the first gen- erated hash are used for the first session-key. The least signifi- cant 64-bits of the first generated hash are used for the second ses- sion-key. The most significant 64-bits of the second generated hash are used for the third session-key. In all three keys, the least Karn & Simpson expires in six months [Page 5] DRAFT Photuris Schemes April 1996 significant bit of each key octet is ignored (or set to parity when the implementation requires). The least significant 64-bits of the generated hash are used for the Initialization Vector (IV). For each message, this is logically XOR'd with the concatenated message Type, LifeTime, and SPI fields, and then used for the message IV. Message encryption begins with the next field after the SPI, and con- tinues to the end of the data indicated by the UDP Length. 4. Validity Methods 4.1. SHA1-DP As described in [Firefly] "Validity Verification", the SHA1 [FIPS-180-1] hash is calculated over the concatenation of SHA1( key, data, datafill, key, sha1fill ) The leading key is not padded to any particular alignment. The datafill uses the same pad-with-length technique defined for sha1fill. The length includes the leading key and data. The resulting Verification field is a 160-bit variable precision num- ber (22 octets including Size). Karn & Simpson expires in six months [Page 6] DRAFT Photuris Schemes April 1996 A. Example Bootstrap Moduli During the initial bootstrap of the implementation, there may not be sufficient time to generate a new modulus before a security associa- tion is needed. These moduli are verified examples that may be used during this bootstrap period. (1024-5) A 1024-bit strong prime (p), expressed in hex: a478 8e21 84b8 d68b fe02 690e 4dbe 485b 17a8 0bc5 f21d 680f 1a84 1313 9734 f7f2 b0db 4e25 3750 018a ad9e 86d4 9b60 04bb bcf0 51f5 2fcb 66d0 c5fc a63f bfe6 3417 3485 bbbf 7642 e9df 9c74 b85b 6855 e942 13b8 c2d8 9162 abef f434 2435 0e96 be41 edd4 2de9 9a69 6163 8c1d ac59 8bc9 0da0 69b5 0c41 4d8e b865 2adc ff4a 270d 567f The recommended generator (g) for this prime is 5. This prime modulus was randomly generated by a freely available program written by Phil Karn, verified using the mpz_probab_prime() function Miller-Rabin test in the Gnu Math Package (GMP) version 1.3.2; and also verified with GMP on another platform by Frank A Stevenson. Currently estimated to provide 80 (pessimistic) through 98 (optimistic) bit-equivalents of cryptographic strength. Expo- nent lengths of 160 to 256 bits (or more) are recommended. Security Considerations In addition to the obvious usage, party privacy protection provides a significant improvement in cryptographic strength for the Photuris message exchanges. Hiding the Identification and Verification fields prevents an attacker from direct verification of forgery attacks on the authenti- cation function. Also, hiding the Verification fields inhibits cryptanalysis of ses- sion-key generation by reducing the number of known fields used in the generation. Karn & Simpson expires in six months [Page 7] DRAFT Photuris Schemes April 1996 Hiding attribute choices inhibits traffic cryptanalysis when multiple transform algorithms are implemented. The "whitening" of the DES IV is intended to obscure the relation of the number of parties and SPIs active between two IP nodes. The com- bination of a randomized secret IV with the SPI generates a different initial encrypted block for every SPI creation message. This obscurement is not effective when the SPI is invariant or not created for a particular exchange direction. The number of parties will be revealed by the number of exchanges with differences in the initial encrypted blocks. Acknowledgements Phil Karn was principally responsible for the design of party privacy protection, and provided much of the design rationale text. Use of privacy protection is also found in the Station-To-Station authenti- cation protocol [DOW92]. William Simpson designed the packet formats, and additional exchange schemes, editing and formatting. All such mistakes are his responsi- bity. Bart Preneel and Paul C van Oorschot in [PO96] suggested adding padding between the data and trailing key when hashing for authenti- cation. References [DOW92] Whitfield Diffie, Paul C van Oorshot, Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Pub- lishers, 1992. [FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995. Also known as: 59 Fed Reg 35317 (1994). [Firefly] Karn, P., Simpson, W., "The Photuris Session Key Management Protocol", work in progress. Karn & Simpson expires in six months [Page 8] DRAFT Photuris Schemes April 1996 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing Security and Performance", Dr. Dobbs Journal, January 1996. [PO96] Bart Preneel, and Paul C van Oorshot, "...Two MACs", work in progress. [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, MIT Laboratory for Computer Science, April 1992. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994. Contacts Comments should be submitted to the photuris@majordomo.soscorp.com mailing list. Questions about this memo can also be directed to: Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779 karn@qualcomm.com karn@unix.ka9q.ampr.org (prefered) William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 wsimpson@UMich.edu wsimpson@GreenDragon.com (preferred) bsimpson@MorningStar.com Karn & Simpson expires in six months [Page 9]