[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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

                          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],
   [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of
   pre-shared keys.  This document defines the Pre-Shared Key for the

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",

   [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-

   [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),"

   [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP
   Payload Compression Protocol (IPComp)," draft-ietf-ippcp- protocol-

   [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
   "Internet Security Association and Key Management Protocol (ISAKMP),"

   [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft-

Piper, Harkins                                                  [Page 4]

INTERNET DRAFT                                             April 1, 1998


   [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

   Dan Harkins
   The Industrial Lounge

Piper, Harkins                                                  [Page 5]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/