Network Working Group Derrell Piper, The Electric Loft INTERNET-DRAFT Dan Harkins, The Industrial Lounge draft-ietf-ipsec-internet-key-00.txt April 1, 1998 The Pre-Shared Key for the Internet Protocol <draft-ietf-ipsec-internet-key-00.txt> Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working 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 inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 0. Table Of Contents 1. Abstract 2. Discussion 3. Terms and Definitions 4. Pre-Shared Key Definition 5. Security Considerations 6. Acknowledgments 7. References 1. Abstract Recent efforts from the IPsec Working Group of the IETF in securing the Internet ([AH], [ARCH], [ESP], [ESPBLOW], [ESPCAST], [ESPCBC], [ESPNULL], [ESP3D], [DES], [DESMAC], [HMACMD5], [HMACSHA], [IKE], [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of pre-shared keys. This document defines the Pre-Shared Key for the Internet. Piper, Harkins [Page 1]
INTERNET DRAFT April 1, 1998 2. Discussion Pre-shared keys are normally used for interoperability purposes. The basic idea is that two parties sharing a common secret can communicate securely. This idea has been used since cryptography first sprung onto the scene. For a complete history of cryptography, see Wired magazine. An additional motivation is that pre-shared keys are, for the most part, unencumbered technology. (It's speculated that RSA Data Security, Inc. has made various claims relating to use of pre-shared keys, but these claims have not yet been tested in court). In order to validate security implementations it is necessary to agree on a pre-shared key in an out-of-band fashion. Such a technique is inherently problematic: the two parties must communicate and agree upon a key using a medium which is, itself, probably insecure. By standardizing on a Pre-Shared Key for the Internet, such communication is precluded. Additionally, the technique of pre-communication apriori to subsequent communication has obvious scaling problems. By standardizing on a cannonical Pre-Shared Key for the Internet, pre- shared keys now scale. Previous, non-standard attempts at agreeing on a pre-shared key were deficient in their use of standard English. For example, the ANX sponsored IPSec bakeoffs rather confusingly used both "whatcertificatereally" as well as the more accepted key, "gwock". By standardizing on Pidgin, the Pre-Shared Key for the Internet now sounds, like, most cool. In addition, one use of pre-shared key technology which has been discussed at length is that of secure multicast. By standardizing on a single pre-shared key, the need for a key distribution protocol is obviated. Of course the use of pre-shard keys for encrypting multicast traffic does not address issues such as content watermarking, threat models, or source authentication of multicast traffic (please see the Security Considerations below) and may therefore be unsatisfactory for some people. 3. Terms and Definitions Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Bra97]. 4. Pre-Shared Key Definition Piper, Harkins [Page 2]
INTERNET DRAFT April 1, 1998 All security implementations that include support for pre-shared keys MUST be capable of supporting the Pre-Shared Key for the Internet. The pre-shared key for the Internet is 14 octets in length. It is represented in ASCII as "mekmitasdigoat" without the accompanying quotation marks. In hexadecimal it is represented as: 0x6d656b6d697461736469676f6174. There MUST NOT be any additional termination characters (such as a terminating NULL). When used with [IKE], the pre-shared key for the Internet MUST be used directly for authentication of the Phase 1 exchange ([IKE], Section 5.4). When used with [ARCH], the manual key for the Internet may need to be expanded depending on the actual algorithmic requirements of the corresponding security association. Expansion of the key is performed by successive concatenation until the required length has been met or exceeded, but never both. Other used of pre-shared keys which require greater than 14 octets MUST expand the Pre-Shared Key for the Internet in the manner described above for use with [ARCH]. Other uses which require less than 14 octets MUST truncate the key to the required length. Other uses which require exactly 14 octets or have no limit to the length of a pre-shared key MUST use the Pre-Shared Key for the Internet in the manner described above for use with [IKE]. 5. Security Consideration The use of pre-shared keys has known security implications. When used for authentication, the presentation of a shared secret is proof of identity. When used for datagram authentication, the pre-shared key authenticates the content and source of the datagram. Using the Pre-Shared Key for the Internet will, in effect, allow you to authenticate everyone. One drawback is that this will negate the effects of all related security protocols. 6. Acknowledgments The authors would like to thank Roy Pereira, Steve Sneddon, William Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, and Ran Atkinson for their encouragement in writing this draft. 10. References [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC-2119, March 1997. Piper, Harkins [Page 3]
INTERNET DRAFT April 1, 1998 [ARCH] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt. [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)," draft-ietf-ipsec-esp-v2-04.txt. [ESPBLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an Explicit IV", draft-ietf-ipsec-ciph-blowfish-cbc-00.txt [ESPCAST] Pereira, R., G. Carter, "The ESP CAST128-CBC Algorithm", draft-ietf-ipsec-ciph-cast128-cbc-00.txt [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt. [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt. [ESP3D] Pereira, R., R. Thayer, "The ESP 3DES-CBC Algorithm Using an Explicit IV", draft-ietf-ipsec-ciph-3des-expiv-00.txt [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- bitan-auth-des-mac-00.txt. [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt. [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt. [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt. [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," draft-ietf-ipsec-isakmp-oakley-06.txt. [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP Payload Compression Protocol (IPComp)," draft-ietf-ippcp- protocol- 05.txt. [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)," draft-ietf-ipsec-isakmp-09.{ps,txt}. [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- Piper, Harkins [Page 4]
INTERNET DRAFT April 1, 1998 ietf-ipsec-oakley-02.txt. [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems Interconnection - The Directory: Models", CCITT/ITU Recommendation X.501, 1993. [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT/ITU Recommendation X.509, 1993. Authors' Addresses: Derrell Piper The Electric Loft 41 6th Ave Santa Cruz, CA 95060 hobbit@yoyodyne.com Dan Harkins The Industrial Lounge anvil@lounge.org Piper, Harkins [Page 5]
