idnits 2.17.1 draft-mamros-pskeyext-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-19) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == It seems as if not all pages are separated by form feeds - found 3 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 13 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC-2104], [Pip97], [Hark97], [SHA], [RFC-2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 105: '... SHOULD, SHOULD NOT, RECOMMEN...' RFC 2119 keyword, line 114: '...as a zero octet, MUST NOT be included ...' RFC 2119 keyword, line 118: '... MUST be converted to their l...' RFC 2119 keyword, line 124: '... The ID Type field MUST be ID_KEY_ID, as defined in [Pip97]....' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1997) is 9652 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 section? 'Hark97' on line 176 looks like a reference -- Missing reference section? 'RFC-2119' on line 186 looks like a reference -- Missing reference section? 'SHA' on line 189 looks like a reference -- Missing reference section? 'Pip97' on line 179 looks like a reference -- Missing reference section? 'RFC-2104' on line 182 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Mamros 2 Expires May 1997 New Oak Communications 3 Internet Draft November 1997 5 Pre-Shared Key Extensions for ISAKMP/Oakley 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 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as ``work 19 in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. This draft will 28 expire six months from date of issue. 30 1. Abstract 32 The application of IP Security for remote access over the 33 Internet requires that it support ''traditional'' authentication 34 paradigms. This document describes how a traditional 35 username and passphrase-style mechanism can be integrated into 36 the existing pre-shared key authentication mechanism in 37 ISAKMP/Oakley. 39 2. Introduction 41 ISAKMP/Oakley [Hark97] provides several authentication 42 methods. Of these, only the pre-shared key authentication 43 method can be made to work in the absence of a public key 44 infrastructure. While it is expected that usage of public 45 key mechanisms will increase substantially in the near 46 future, many sites which want to use IP Security as a tunnelling 47 mechanism for remote access over the Internet may not be 48 able or willing to convert their existing systems to use 49 public key technology right away. Thus, these sites will 50 need to use pre-shared key authentication in one form or 51 another. 53 ISAKMP/Oakley provides both Main Mode and Aggressive Mode 54 as the two basic methods for establishing an authenticated 55 key exchange. However, Main Mode using pre-shared key 56 authentication is restricted to using only the IP addresses 57 of the initiator and responder as the means to select a key. 58 Remote access solutions require user-based keying, which 59 means that Aggressive Mode is the only viable method which 60 can be used with pre-shared keys. 62 The major drawback to Aggressive Mode is that, unlike Main 63 Mode, one cannot protect the identities of the initiator and 64 responder; these must be transmitted in the clear. Another 65 element which must be transmitted in the clear is the 66 responder's hash, designated as HASH_R in [Hark97]. When 67 pre-shared key authentication is being used, HASH_R is 68 derived from a combination of the pre-shared key and the 69 nonces, ISAKMP cookies, and publicly-exchanged Diffie-Hellman 70 values of both the initiator and responder, plus the 71 responder's identity. The only "secret" element among those 72 used to calculate HASH_R is the pre-shared key itself; all 73 of the other elements are transmitted in the clear in the 74 first two messages of Aggressive Mode. The security of 75 HASH_R is thus entirely dependent on the security of the 76 pre-shared key itself, which in turn relies on the effective 77 key length. 79 The "traditional" method of using a username for 80 identification, and a passphrase for authentication, is 81 still in common use at many sites. Such sites may be 82 tempted to map the username/passphrase directly to the 83 ISAKMP/Oakley pre-shared authentication mechanism, with 84 the username being used for the initiator's identity 85 (designated as IDii in [Hark97]) and the passphrase being 86 employed as the pre-shared key. However, the lack of 87 identity protection in Aggressive Mode, coupled with a 88 relatively small search space for text-based passphrases, 89 makes this approach vulnerable to brute-force searches of 90 the passphrase via analysis of HASH_R. 92 This document defines an alternate approach through which 93 usernames and passphrases may be used in conjunction with 94 pre-shared key authentication, while providing somewhat 95 better protection for the identity and also expanding the 96 brute-force key space. The method described here employs 97 an additional algorithm for deriving the values used for 98 IDii and the pre-shared key; these values are then used 99 as-is in the standard algorithms defined in [Hark97] for 100 deriving keys and hash values. 102 3. Terms and Definitions 104 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, 105 SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when 106 they appear in this document, are to be interpreted as 107 described in [RFC-2119]. 109 4.1. Derivation of Initiator Identity (IDii) 111 The initiator identity (IDii) is derived by performing a 112 SHA-1 [SHA] hash calculation over the username. Any 113 characters used to terminate or delimit the username string, 114 such as a zero octet, MUST NOT be included in the hash 115 calculation. If the environment in which the username is 116 defined considers usernames to be case-insensitive, any 117 uppercase alphabetical characters (A-Z) in the username 118 MUST be converted to their lowercase equivalents (a-z) 119 before performing the hash calculation. 121 The initiator places the SHA-1 hash in the Identification 122 Data field of the Identification Payload designated as IDii 123 in its initial message to the responder in Aggressive Mode. 124 The ID Type field MUST be ID_KEY_ID, as defined in [Pip97]. 125 The responder stores a table of SHA-1 hashes mapped to their 126 respective usernames and their corresponsing passphrases. 128 4.2. Derivation of the Pre-Shared Key 130 The pre-shared key is derived by using the HMAC algorithm 131 [RFC-2104] in conjunction with the SHA-1 hash algorithm, 132 with the passphrase used as the key and the plaintext 133 username as the "message". In the notation of [Hark97], 135 pre-shared-key = prf(passphrase, username) 137 where the pseudo-random function is HMAC-SHA-1. 139 As with the IDii derivation described above, terminating 140 and delimiting characters (such as zero octets) MUST NOT 141 be included in the calculation. If usernames are case- 142 insensitive, uppercase alphabetical characters MUST be 143 converted to lowercase before applying this algorithm. 144 However, mixed-case passphrases MUST be supported, and the 145 case of all alphabetic characters in the passphrase MUST be 146 preserved in the calculation. The resulting 160-bit hash 147 value MUST be used in its entirety as the pre-shared key. 149 5. Security Considerations 151 The methods described in this document do not purport to 152 be a solution for all of the problems which face any system 153 relying on username/passphrase authentication for security. 154 A weak passphrase can compromise the security of any such 155 system. Also, physical and logical security of the 156 username/passphrase database is crucially important. 158 The method for deriving IDii does provide some level of 159 identity obfuscation, but it falls short of full identity 160 protection as provided by Main Mode. One can compare 161 the value of IDii with the values used in previous exchanges 162 to determine whether or not the same user initiated a prior 163 exchange. We rely on the collision and reversability 164 resistance and properties of SHA-1 to protect the original 165 username. 167 The algorithm for deriving the pre-shared key is stronger 168 than using the passphrase as-is for the key only if the 169 plaintext username is not revealed to an attacker. Security 170 administrators may wish to consider the use of different 171 usernames for remote access under this scheme than those 172 which are used for other systems such as electronic mail. 174 6. References 176 [Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with 177 Oakley", draft-ietf-ipsec-isakmp-oakley-05.txt. 179 [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation 180 for ISAKMP", draft-ietf-ipsec-ipsec-doi-06.txt. 182 [RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., 183 "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, 184 February 1997. 186 [RFC-2119] Bradner, S., "Key Words for use in RFCs to indicate 187 Requirement Levels", RFC 2119, March 1997. 189 [SHA] NIST, FIPS PUB 180-1, Secure Hash Standard, April 1995. 190 http://csrc.nist.gov/fips/fip180-1.txt (ascii) 191 http://csrc.nist.gov/fips/fip180-1.ps (postscript) 193 7. Author's Address 195 Shawn Mamros 196 New Oak Communications, Inc. 197 125 Nagog Park +1 978 266 1011 198 Acton, Massachusetts, 01720 smamros@newoak.com