Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-simpson-photuris-schemes-01.txt < prev next >

Wrap

Text File | 1997-05-28 | 16.7 KB | 497 lines

Network Working Group P Karn (Qualcomm) Internet Draft W A Simpson (DayDreamer) expires in six months May 1997 Photuris: Extended Schemes and Privacy Protection draft-simpson-photuris-schemes-01.txt Status of this Memo 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) Distribution of this memo is unlimited. Abstract Photuris is a session-key management protocol. 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 May 1997 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 tunnel IP Source has been dynamically allocated, it provides no useful information to an eavesdropper. This leaves the identifying information that the parties send during the Photuris [RFC-zzzz] 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 names in certificates or by checking sig- natures 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 with the Clogging Defense, the 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 function is used to Karn & Simpson expires in six months [Page 1] DRAFT Photuris Schemes May 1997 create a special privacy session-key. This function is calculated over the following concatenated values: + the computed shared-secret, + the Initiator Cookie, + the Responder Cookie, + the SPI Owner Exchange-Value, + the SPI User 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 function, these keying-bits are generated by duplicating the trailing shared-secret, and recalculating the func- tion. That is, the first iteration will have one trailing copy of the shared-secret, the second iteration will have two trailing copies of the shared-secret, and so forth. If decryption failure is detected, the users are notified, and a Ver- ification_Failure message is sent, without adding any Security Asso- ciations. Otherwise, the usual verification procedures occur. Implementation Notes: This is distinct 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 Exchange-Value data 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. Karn & Simpson expires in six months [Page 2] DRAFT Photuris Schemes May 1997 2. Additional Exchange Schemes The packet format and basic facilities are already defined for Pho- turis [RFC-zzzz]. These optional exchange schemes are specified separately, and no sin- gle implementation is expected to support all of them. 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 Privacy-Method is "not protected". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "not protected". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-KDpKp". (7) Implementation Optional. Any modulus (p) with a variable gen- erator (g). Each is encoded in a separate Variable Precision Number. The generator VPN is followed by (concatenated to) the modulus VPN, and the pair are contained in the Exchange Scheme Value field in the list of Offered-Schemes. Karn & Simpson expires in six months [Page 3] DRAFT Photuris Schemes May 1997 The Privacy-Method is "not protected". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "DES-EDE3-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-KDpKp". (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 Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "DES-EDE3-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-KDpKp". (14) Implementation Optional. Any modulus (p) with a variable gen- erator (g). Each is encoded in a separate Variable Precision Number. The generator VPN is followed by (concatenated to) the modulus VPN, and the pair are contained in the Exchange Scheme Value field in the list of Offered-Schemes. The Privacy-Method is "DES-CBC with secret IV". The "SPI Messages" Validity-Method is "MD5-KDpKp". (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 Privacy-Method is "DES-EDE3-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-KDpKp". (28) Implementation Optional. Any modulus (p) with a variable gen- erator (g). Each is encoded in a separate Variable Precision Karn & Simpson expires in six months [Page 4] DRAFT Photuris Schemes May 1997 Number. The generator VPN is followed by (concatenated to) the modulus VPN, and the pair are contained in the Exchange Scheme Value field in the list of Offered-Schemes. The Privacy-Method is "DES-EDE3-CBC with secret IV". The "SPI Messages" Validity-Method is "SHA1-KDpKp". 3. Privacy Methods 3.1. DES-CBC with secret IV MD5 [RFC-1321] is used as the key generation function 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). Although extremely rare, weak, semi-weak, and possibly weak keys are discarded. Another iteration of the key generation function is used. 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. DES-EDE3-CBC with secret IV This "Triple DES" method indicates outer-CBC EDE encryption (and DED decryption) with three 56-bit keys [KR96]. MD5 [RFC-1321] is used as the key generation function for generating the three privacy session-keys, as described in "Party Privacy Pro- tection". The most significant 64-bits of the first generated hash are used for the first session-key. The least significant 64-bits of the first generated hash are used for the second session-key. The most significant 64-bits of the second generated hash are used for the third session-key. In all three keys, the least significant bit of each key octet is ignored (or set to parity when the implementa- tion requires). Weak, semi-weak, and possibly weak keys are not discarded. They are extremely rare, and masked by the other keys. Karn & Simpson expires in six months [Page 5] DRAFT Photuris Schemes May 1997 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-KDpKp As described in [RFC-zzzz] "Validity Verification", the SHA1 [FIPS-180-1] hash is calculated over the concatenation of SHA1( key, data, datafill, key, sha1fill ) where the key is the computed shared-secret. 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). 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. 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 Karn & Simpson expires in six months [Page 6] DRAFT Photuris Schemes May 1997 initial encrypted block for every SPI creation message. This obscurement is not effective when the SPI is invariant or is 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. William Simpson designed the packet formats, and additional exchange schemes, editing and formatting. All such mistakes are his responsi- bity. Use of privacy protection is also found in the Station-To-Station authentication protocol [DOW92]. 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, and 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). [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, "On the security of two MAC algorithms", Advances in Cryptology -- Eurocrypt '96, Lecture Notes in Computer Science 1070 (May 1996), Springer-Verlag, pages 19-32. [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, Karn & Simpson expires in six months [Page 7] DRAFT Photuris Schemes May 1997 MIT Laboratory for Computer Science, April 1992. [RFC-zzzz] Karn, P., Simpson, W., "Photuris: Session Key Management Protocol", work in progress. Contacts Comments about this document should be discussed on the photuris@majordomo.soscorp.com mailing list. Questions about this document 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 (preferred) 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 8]