[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-internet-key-00.txt
Network Working Group Derrell Piper, The Electric Loft
INTERNET-DRAFT Dan Harkins, The Industrial Lounge
draft-ieft-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 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),
munnari.oz.au (Australia), ds.internic.net (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]