idnits 2.17.1 draft-ietf-ipsec-isakmp-SA-revised-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-23) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-ipsec-isakmp-SA-revised-00', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 87 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. 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. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '2' on line 209 looks like a reference -- Missing reference section? '3' on line 216 looks like a reference -- Missing reference section? '1' on line 204 looks like a reference -- Missing reference section? '4' on line 223 looks like a reference -- Missing reference section? '5' on line 228 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security working group Baiju V. Patel, 3 Internet Draft Michael Jeronimo, 4 Intel Corp. 5 Document: draft-ietf-ipsec-isakmp-SA-revised-00.txt 6 November, 1997 8 Revised SA negotiation mode for ISAKMP/Oakley 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 "working draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 26 munnari.oz.au. 28 A revised version of this draft document will be submitted to the 29 RFC editor as a Proposed Standard for the Internet Community. 30 Discussion and suggestions for improvement are requested. This 31 document will expire before February 1998. Distribution of this 32 draft is unlimited. 34 1. Abstract 36 ISAKMP/OAKLEY [2][3] is the key management protocol defined by IPSEC 37 working to be a framework for authentication, security association 38 negotiation and key management. The protocol defines two phases 39 whereby, in the phase 1, the peers are authenticates, the security 40 association (SA) for ISAKMP/Oakley, and keying material is agreed 41 upon by the peers to secure ISAKMP messages. The phase 2 is used to 42 negotiate security association for security applications (e.g., 43 IPSEC AH and ESP). When perfect forward secrecy is required, phase 2 44 is also used to exchange keying material for the application. 45 However, when perfect forward secrecy is not a requirement, the 46 keying material from the phase 1 is used to generate session keys 47 for the secure communication applications. 49 The proposal in this document is based on the observation that when 50 perfect forward secrecy is not a requirement, if application 52 Patel 1 53 draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97 55 specific SA was negotiated during phase 1, the application can start 56 immediately after phase 1. The phase 2 can be used subsequently for 57 key refresh on per need bases in the future. Therefore, this 58 proposal reduces startup time for communication and improves the 59 efficiency of the protocol. 61 Remark: This document is NOT self-contained, it is intended as an 62 addendum to [2][3]. Thus, it is best read in conjunction with 63 [2][3]. 65 2. Revised modes of ISAKMP/Oakley 67 2.1. 68 Notation 70 SA_App: is an SA negotiation payload with one or more proposals 72 specific to the application (e.g., IPSEC AH or ESP), 74 SA_App_p: is the entire body of the SA_App payload (minus the ISAKMP 76 generic header) -- i.e., the DOI, situation, all proposals, and all 78 transforms included in SA_App. 80 HASH_I = 82 prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | Sap | SA_App_p | IDii) 84 HASH_R = 86 prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | SA_App_p | IDir) 88 Observe that the HASH-I and HASH-R functions in this revised mode 90 include application specific SA's. This a change from the 92 specification in [3]. 94 Unless otherwise specified, all the notations used in this document 96 are same as those in [3]. 98 2.2. 99 Phase 1 authenticated with Signatures 101 Main Mode with signature authentication is described as follows: 103 Initiator Responder 105 ---------- ----------- 107 HDR, SA --> 109 <-- HDR, SA 111 HDR, KE, Ni --> 113 <-- HDR, KE, Nr 115 HDR*, IDii, SA_App [ CERT, ] SIG_I --> 117 <-- HDR*, IDir, [ CERT, ] SIG_R 119 Aggressive mode with signatures in conjunction with ISAKMP is 121 described as follows: 123 Initiator Responder 125 ----------- ----------- 127 HDR, SA, SA_App, KE, Ni, IDii --> 129 Patel and jeronimo 2 130 draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97 132 <-- HDR, SA, SA_App, KE, Nr, 134 IDir, [ CERT, ] SIG_R 136 HDR, [ CERT, ] SIG_I --> 138 2.3. 139 Phase 1 Authenticated With Public Key Encryption 141 When using encryption for authentication, Main Mode is defined as 142 follows. 144 Initiator Responder 145 ----------- ----------- 146 HDR, SA --> 147 <-- HDR, SA 148 HDR, KE, [ HASH(1), ] 149 PubKey_r, 150 PubKey_r --> 151 HDR, KE, PubKey_i, 152 <-- PubKey_i 153 HDR*, SA_App, HASH_I --> 154 <-- HDR*, SA_App, HASH_R 156 Aggressive Mode authenticated with encryption is described as 157 follows: 159 Initiator Responder 160 ----------- ----------- 161 HDR, SA, SA_App, [ HASH(1),] KE, 162 Pubkey_r, 163 Pubkey_r --> 164 HDR, SA, SA_App, KE, 165 PubKey_i, 166 <-- PubKey_r, HASH_R 167 HDR, HASH_I --> 169 Where HASH(1) is a hash (using the negotiated hash function) of 170 the certificate which the initiator is using to encrypt the nonce 171 and identity. 173 2.4. Phase 1 Authenticated With a Pre-Shared Key 175 When doing a pre-shared key authentication, Main Mode is defined 176 as follows: 178 Initiator Responder 179 ---------- ----------- 180 HDR, SA --> 181 <-- HDR, SA 182 HDR, KE, Ni --> 183 <-- HDR, KE, Nr 184 HDR*, SA_App IDii, HASH_I --> 185 <-- HDR*, SA_App, IDir, HASH_R 187 Patel and jeronimo 3 188 draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97 190 Aggressive mode with a pre-shared key is described as follows: 192 Initiator Responder 193 ----------- ----------- 194 HDR, SA, SA_App, KE, Ni, IDii --> 195 <-- HDR, SA, SA_App, KE, Nr, IDir, HASH_R 196 HDR, HASH_I --> 198 3. Security Considerations 200 This draft defines a security protocol. 202 4. References 204 [1]. 205 Bradner, S, "Key words for use in RFCs to Indicate 207 Requirement Levels", RFC 2119, Harvard University, March 1997. 209 [2]. 210 Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 212 "Internet Security Association and Key Management Protocol 214 (ISAKMP)", version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}. 216 [3]. 217 D. Harkins, D. Carrel, "The resolution of ISAKMP with 219 Oakley", Internet Draft, , 221 July 1997 223 [4]. 224 Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing 226 for Message Authentication", RFC 2104, February 1997. 228 [5]. 229 Schneier, B., "Applied Cryptography, Protocols, Algorithms, 231 and Source Code in C", 2nd edition. 233 5. Acknowledgments 235 This draft is largely based on the Dan Harkin's IETF draft on 236 ISAKMP/OAKLEY resolution. 238 6. Author's Addresses 240 Baiju V. Patel 241 Intel Corp 242 2511 NE 25th Ave 243 Hillsboro, OR 97124 244 Phone: 503 264 2422 245 Email: baiju@mailbox.jf.intel.com 247 Michael Jeronimo 248 Intel Corp 249 2511 NE 25th Ave 250 Hillsboro, OR 97124 251 Phone: 503 264 5970 252 Email: jeronim@ccm.jf.intel.com 254 Patel and jeronimo 4 255 draft-ietf-ipsec-isakmp-SA-revised-00.txt 11/21/97 257 Patel and jeronimo 5