idnits 2.17.1 draft-ietf-ipsec-internet-key-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPCOMP], [ESPNULL], [HMACSHA], [ESP3D], [DESMAC], [ESPCAST], [ARCH], [HMACMD5], [ESPCBC], [DES], [ESPBLOW], [AH], [DOI], [ISAKMP], [OAKLEY], [IKE], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1, 1998) is 9521 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'AH' is mentioned on line 39, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-04 == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-04 -- Possible downref: Normative reference to a draft: ref. 'ESPBLOW' -- Possible downref: Normative reference to a draft: ref. 'ESPCAST' == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-ciph-cbc-02 -- Possible downref: Normative reference to a draft: ref. 'ESP3D' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ciph-des-expiv is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. 'DESMAC' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'DOI') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-hmac-md5-96 is -02, but you're referring to -03. -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-hmac-sha196 is -02, but you're referring to -03. == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') -- No information found for draft-ietf-ippcp- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPCOMP' ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. (However, the state information for draft-ietf-ippcp- is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Derrell Piper, The Electric Loft 2 INTERNET-DRAFT Dan Harkins, The Industrial Lounge 3 draft-ietf-ipsec-internet-key-00.txt April 1, 1998 5 The Pre-Shared Key for the Internet Protocol 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and working groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check 21 the "1id-abstracts.txt" listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 23 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 24 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 25 (US West Coast). 27 0. Table Of Contents 28 1. Abstract 29 2. Discussion 30 3. Terms and Definitions 31 4. Pre-Shared Key Definition 32 5. Security Considerations 33 6. Acknowledgments 34 7. References 36 1. Abstract 38 Recent efforts from the IPsec Working Group of the IETF in securing 39 the Internet ([AH], [ARCH], [ESP], [ESPBLOW], [ESPCAST], [ESPCBC], 40 [ESPNULL], [ESP3D], [DES], [DESMAC], [HMACMD5], [HMACSHA], [IKE], 41 [DOI], [IPCOMP], [ISAKMP], and [OAKLEY]) imply the continued use of 42 pre-shared keys. This document defines the Pre-Shared Key for the 43 Internet. 45 2. Discussion 47 Pre-shared keys are normally used for interoperability purposes. The 48 basic idea is that two parties sharing a common secret can 49 communicate securely. This idea has been used since cryptography 50 first sprung onto the scene. For a complete history of cryptography, 51 see Wired magazine. 53 An additional motivation is that pre-shared keys are, for the most 54 part, unencumbered technology. (It's speculated that RSA Data 55 Security, Inc. has made various claims relating to use of pre-shared 56 keys, but these claims have not yet been tested in court). 58 In order to validate security implementations it is necessary to 59 agree on a pre-shared key in an out-of-band fashion. Such a 60 technique is inherently problematic: the two parties must communicate 61 and agree upon a key using a medium which is, itself, probably 62 insecure. By standardizing on a Pre-Shared Key for the Internet, 63 such communication is precluded. 65 Additionally, the technique of pre-communication apriori to 66 subsequent communication has obvious scaling problems. By 67 standardizing on a cannonical Pre-Shared Key for the Internet, pre- 68 shared keys now scale. 70 Previous, non-standard attempts at agreeing on a pre-shared key were 71 deficient in their use of standard English. For example, the ANX 72 sponsored IPSec bakeoffs rather confusingly used both 73 "whatcertificatereally" as well as the more accepted key, "gwock". 74 By standardizing on Pidgin, the Pre-Shared Key for the Internet now 75 sounds, like, most cool. 77 In addition, one use of pre-shared key technology which has been 78 discussed at length is that of secure multicast. By standardizing on 79 a single pre-shared key, the need for a key distribution protocol is 80 obviated. Of course the use of pre-shard keys for encrypting 81 multicast traffic does not address issues such as content 82 watermarking, threat models, or source authentication of multicast 83 traffic (please see the Security Considerations below) and may 84 therefore be unsatisfactory for some people. 86 3. Terms and Definitions 88 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 89 "MAY" that appear in this document are to be interpreted as described 90 in [Bra97]. 92 4. Pre-Shared Key Definition 93 All security implementations that include support for pre-shared keys 94 MUST be capable of supporting the Pre-Shared Key for the Internet. 96 The pre-shared key for the Internet is 14 octets in length. It is 97 represented in ASCII as "mekmitasdigoat" without the accompanying 98 quotation marks. In hexadecimal it is represented as: 99 0x6d656b6d697461736469676f6174. There MUST NOT be any additional 100 termination characters (such as a terminating NULL). 102 When used with [IKE], the pre-shared key for the Internet MUST be 103 used directly for authentication of the Phase 1 exchange ([IKE], 104 Section 5.4). 106 When used with [ARCH], the manual key for the Internet may need to be 107 expanded depending on the actual algorithmic requirements of the 108 corresponding security association. Expansion of the key is 109 performed by successive concatenation until the required length has 110 been met or exceeded, but never both. 112 Other used of pre-shared keys which require greater than 14 octets 113 MUST expand the Pre-Shared Key for the Internet in the manner 114 described above for use with [ARCH]. Other uses which require less 115 than 14 octets MUST truncate the key to the required length. Other 116 uses which require exactly 14 octets or have no limit to the length 117 of a pre-shared key MUST use the Pre-Shared Key for the Internet in 118 the manner described above for use with [IKE]. 120 5. Security Consideration 122 The use of pre-shared keys has known security implications. When used 123 for authentication, the presentation of a shared secret is proof of 124 identity. When used for datagram authentication, the pre-shared key 125 authenticates the content and source of the datagram. Using the 126 Pre-Shared Key for the Internet will, in effect, allow you to 127 authenticate everyone. One drawback is that this will negate the 128 effects of all related security protocols. 130 6. Acknowledgments 132 The authors would like to thank Roy Pereira, Steve Sneddon, William 133 Dixon, Rob Adams, Perry Metzger, Bronislav Kavsan, and Ran Atkinson 134 for their encouragement in writing this draft. 136 10. References 138 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 139 Requirement Levels", RFC-2119, March 1997. 141 [ARCH] Kent, S., Atkinson, R., "Security Architecture for the 142 Internet Protocol," draft-ietf-ipsec-arch-sec-04.txt. 144 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 145 (ESP)," draft-ietf-ipsec-esp-v2-04.txt. 147 [ESPBLOW] Adams, R., "The ESP Blowfish-CBC Algorithm Using an 148 Explicit IV", draft-ietf-ipsec-ciph-blowfish-cbc-00.txt 150 [ESPCAST] Pereira, R., G. Carter, "The ESP CAST128-CBC Algorithm", 151 draft-ietf-ipsec-ciph-cast128-cbc-00.txt 153 [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher 154 Algorithms," draft-ietf-ipsec-ciph-cbc-02.txt. 156 [ESPNULL] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its 157 Use With IPsec," draft-ietf-ipsec-ciph-null-00.txt. 159 [ESP3D] Pereira, R., R. Thayer, "The ESP 3DES-CBC Algorithm Using an 160 Explicit IV", draft-ietf-ipsec-ciph-3des-expiv-00.txt 162 [DES] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm 163 With Explicit IV," draft-ietf-ipsec-ciph-des-expiv-02.txt. 165 [DESMAC] Bitan, S., "The Use of DES-MAC within ESP and AH," draft- 166 bitan-auth-des-mac-00.txt. 168 [DOI] Piper, D., "The Internet IP Security Domain of Interpretation 169 for ISAKMP," draft-ietf-ipsec-ipsec-doi-08.txt. 171 [HMACMD5] Madson, C., Glenn, R., "The Use of HMAC-MD5 within ESP and 172 AH," draft-ietf-ipsec-auth-hmac-md5-96-03.txt. 174 [HMACSHA] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 175 and AH," draft-ietf-ipsec-auth-hmac-sha196-03.txt. 177 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)," 178 draft-ietf-ipsec-isakmp-oakley-06.txt. 180 [IPCOMP] Shacham, A., Monsour, R., Pereira, R., Thomas, M., "IP 181 Payload Compression Protocol (IPComp)," draft-ietf-ippcp- protocol- 182 05.txt. 184 [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., 185 "Internet Security Association and Key Management Protocol (ISAKMP)," 186 draft-ietf-ipsec-isakmp-09.{ps,txt}. 188 [OAKLEY] H. K. Orman, "The OAKLEY Key Determination Protocol," draft- 189 ietf-ipsec-oakley-02.txt. 191 [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems 192 Interconnection - The Directory: Models", CCITT/ITU Recommendation 193 X.501, 1993. 195 [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems 196 Interconnection - The Directory: Authentication Framework", 197 CCITT/ITU Recommendation X.509, 1993. 199 Authors' Addresses: 201 Derrell Piper 202 The Electric Loft 203 41 6th Ave 204 Santa Cruz, CA 95060 205 hobbit@yoyodyne.com 207 Dan Harkins 208 The Industrial Lounge 209 anvil@lounge.org