idnits 2.17.1 draft-ietf-ipsec-inline-isakmp-01.txt: 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 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 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ISAKMP,OAKLEY,, [ISAOAK], [SKIP], ISAOAK], [DOI], [BADESP]), 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.) -- The document date (March 1997) is 9897 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) == Unused Reference: 'AH' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'ESP' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'IPSEC' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'OAKLEY' is defined on line 421, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BADESP' ** Obsolete normative reference: RFC 1826 (ref. 'AH') (Obsoleted by RFC 2402) == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-00 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'DOI') ** Obsolete normative reference: RFC 1827 (ref. 'ESP') (Obsoleted by RFC 2406) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-02 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'ISAOAK') ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-skip is -06, but you're referring to -07. -- Possible downref: Normative reference to a draft: ref. 'SKIP' Summary: 17 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Bill Sommerfeld 3 INTERNET-DRAFT Hewlett Packard 4 draft-ietf-ipsec-inline-isakmp-01.txt March 1997 6 Inline Keying within the ISAKMP Framework. 7 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 This particular Internet Draft is being published in order to focus 30 discussion on protocols for lightweight inline keying in the context 31 of ISAKMP/Oakley. It is intended that this version will raise more 32 questions than it answers; there many ways to do inline keying and 33 the author does not pretend to have all the answers. A future 34 version of this draft might become suitable for submission to the 35 IESG as a standards track protocol. 37 ABSTRACT 39 The current proposal for IP-layer key management [ISAKMP, OAKLEY, 40 ISAOAK] has fairly high overhead. Before a security association can 41 be established, at least one pair of messages need to be exchanged 42 between the communicating peers. For efficiency, this suggests that 43 ISAKMP setup should be infrequent. However, general principles of 44 key management suggest that individual keys should be used as little 45 as practical and changed as frequently as possible. Steve Bellovin 46 has suggested that, ideally, different security associations should 47 be used for each different transport-level connection[BADESP]. 49 This document discusses a way of structuring a protocol to permit 50 this to happen with minimal overhead, both in round-trip delay at 51 connection setup, and in bandwidth once the connection is 52 established. 54 The general concept of inline or in-band keying here was inspired by 55 SKIP[SKIP]. However, SKIP's approach is burdened by the addition of 56 an extra intermediate header of perhaps 20 to 28 bytes to every 57 protected packet, which doubles the bandwidth overhead of protected 58 traffic compared with ESP with fixed keying. In order to minimise 59 the per-packet overhead, an inline keying header should be used only 60 until the desired security association is established, at which point 61 the peers will fall back to pure ESP/AH. 63 IN-BAND SECURITY ASSOCIATION SETUP 65 AH and ESP security associations are identified by a 32-bit 66 identifier known as an SPI, which is assigned by the receiving end of 67 the association. This makes it difficult to create a new security 68 association at the request of a traffic originator without at least 69 one round trip. 71 However, most packets are sent either in response to another packet, 72 or in the expectation that a response will be received. 74 We can exploit this, by having the sender allocate an SPI for return 75 traffic, and include a message informing the recipient of it in the 76 first message. The reponse to this message can also contain a return 77 SPI, so further packets in the conversation can be directed to the 78 appropriate security association for the conversation. 80 There are at least two applications for this protocol. Hosts may 81 wish to use separate SPIs for separate transport-layer connections. 82 Similarly, routers doing tunnel-mode ESP may wish to establish 83 separate SPIs for each active host-pair they tunnel. 85 In the former case, for a typical TCP exchange, the in-band keying 86 headers would piggyback on the SYN and SYN/ACK packets, and would 87 then be absent from subsequent traffic. 89 No explicit acknowledgement of the creation of the new SPI is needed, 90 as use of the reply-SPI by the peer would (implicitly) acknowledge 91 the key change. 93 No explicit retransmission of in-band-keying requests is needed; if 94 the upper-level protocol retransmits before the full SPI pair is 95 created, the inline keying header is included in the retransmission. 97 PACKET PROCESSING 99 Some additional logic needs to be added to an implementation's 100 outbound and inbound policy engines. As this protocol has not yet 101 been implemented, the following is necessarily vague; suggestions on 102 how to improve it are welcomed. 104 When sending a packet, if there isn't a valid outbound SPI we want to 105 use to reach the peer, and we have reason to believe the peer accepts 106 inline keying headers, we look up the inbound SPI we want our peer to 107 use (or create it if it's nonexistant) and insert an in-band keying 108 header in the outbound packet. 110 On the other hand, if there is a valid outbound SPI, we use it. If 111 there isn't a valid inbound SPI for a response, we create the inbound 112 SPI we want to receive replies on and insert an in-band-keying header 113 in the outbound packet, then send it using the outbound SPI. 115 If an inbound packet contains a valid in-band-keying header with a 116 reply SPI in it, we create an outbound SPI with the appropriate TTL, 117 and then process the rest of the packet. 119 PARENT SPI PARAMETERS 121 The parent SPI must have the following parameters specified or 122 negotiated: 123 - a shared secret 124 - the pseudo-random function (prf) to be used for key derivation. 125 - the algorithm to be used for encryption, and any algorithm-specific 126 parameters (other than the key). 127 - the algorithm to be used for message integrity protection, and any 128 algorithm-specific parameters (other than the key). 130 ESTABLISHING THE PARENT SPI. 132 This scheme can only "spawn" new SPIs from old SPIs; therefore, there 133 needs to be a way to establish the "parent" SPI. 135 There are several possible alternatives: 137 One of the ISAKMP exchanges could be used to establish the parent 138 SPI. 140 Another alternative, very similar to SKIP, would be for each system 141 to publish a certificate containing a Diffie-Hellman public key, a 142 "well known" SPI, and the additional parent-SPI parameters listed 143 above. The shared secret actually used in the inline-keying protocol 144 would depend on the source address of the packet. It is not clear 145 whether this variation is of interest and is included only for 146 completeness. 148 ENCODING OPTIONS 150 There are a number of potential ways of encoding this protocol, with 151 different advantages and disadvantages; at this point, it is not 152 clear which way is best. The primary areas of variability include: 154 - how the SPI-creation message is framed 156 - what is contained in the SPI-creation message 158 - how the user payload "along for the ride" is protected. 160 In order to minimize complexity, in the end, there should only be one 161 answer for each of these questions. Several requirements on the 162 encoding exist: 164 1) the SPI-creation message must be optional 165 2) there should be some "cryptographic distance" between the three 166 kinds of keys involved: 167 - the key(s) used to authenticate and/or encrypt the user 168 payload which is along for the ride 169 - the key(s) used to authenticate the SPI-creation message 170 - the key(s) used by the newly-created reply SPI. 171 3) there should be as much commonality in encoding between this 172 protocol and the various sub-protocols of ESP and ISAKMP with similar 173 functionality. 175 4) the inline keying header should be small. 177 FRAMING 179 Three alternatives suggest themselves: 181 - special-case encoding within an ESP transform, perhaps using a bit 182 out of the pad length by mutual agreement between the communicating 183 peers. 185 - a new IP-layer protocol 187 - use of the "IPv6 destination options" IP-layer protocol. 189 Using a new IP-layer protocol seems cleanest, though there has been 190 strong opposition to it from some implementors. The use of the IPv6 191 destination options protocol would limits the size of a single option 192 to no more than 255 octets, which may be a significant constraint. 194 REPLY-SPI-CREATION CONTENTS 196 There are essentially two possibilities for the reply-SPI-creation 197 message: either an encapsulated quick mode message, or a custom 198 message simpler than, but similar to quick mode. 200 Encapsulating ISAKMP/Oakley 202 A simpler, but less efficient, alternative would be to encapsulate 203 various ISAKMP/Oakley quick-mode messages as the reply-SPI-creation 204 message. 206 Custom Format 208 Notation here is derived from the notation used in the Oakley draft. 210 We assume the existance of a shared secret, sSPI between the 211 communicating parties, and a parent SPI corresponding to the shared 212 secret. This can be established in a number of ways, which will be 213 discussed later. 215 Fields: 217 reply-SPI 218 reply-SPI-scope 219 reply-SPI-lifetime 220 reply-SPI-nonce 221 reply-SPI-parameters 222 peer-SPI-nonce 224 spi-creation-fields is a set of fields which tell the receiver how to 225 create an outbound SPI for reponses to the payload of this datagram. 226 This set includes: 228 Reply-SPI is the number of an SPI created by the sender for responses 229 to this packet. 231 Reply-SPI-scope indicates the scope of the reply SPI; exact encoding 232 is TBS and should probably be similar to the way the scope is handled 233 in [DOI]. The scope should be able to select among (at least) four 234 possible scopes: host-range, host, protocol, protocol+port. 236 Reply-SPI-lifetime is the lifetime (exact encoding TBS), of the 237 newly-created SPI. A similar encoding to the one used by [DOI] 238 should be used here. 240 reply-SPI-parameters are other parameters of the newly created SPI, 241 including the algorithm, and any algorithm-specific parameters. An 242 encoding similar to the one used by [DOI] should be used. 244 Peer-spi-nonce is either all zeros, or the peer's reply-SPI-nonce. 246 The key(s) associated with the newly-created SPI are derived from: 248 prf (sSPI, reply-TAG | peer-spi-nonce | reply-spi-nonce | 249 reply-SPI) 251 reply-TAG is a well-known constant, TBD. 253 sSPI is the shared secret associated with the parent SPI. 255 prf(a, b) is a pseudo-random function as in Oakley; the exact 256 function to use is a parameter of the parent SPI. 258 It may be desirable to include other fields from the header in both 259 of the key-derivation hashes. 261 KEYING OF THE USER PAYLOAD 263 If the "parent" algorithm is judged to be sufficently strong, the 264 initial user payload could simply be encrypted using the ESP in the 265 parent SPI. However, the use of inline keying seems to suggest a 266 desire to segregate different communications under different keys. 268 A extension to ESP suggests itself. We can negotiate the addition of 269 a "key generation nonce" to the cleartext part of the ESP header, and 270 then generate the key for encrypting the ciphertext portion of the 271 packet using a keyed hash of the shared secret and the nonce: 273 prf (sSPI, current-packet-nonce | SPI | other) 275 sSPI is the SPI's shared secret; 277 current-packet-nonce is a 128-bit random value generated by the 278 sender (ideally different for each packet). 280 "SPI" is the numeric SPI value. 282 "other" are any additional fields which might make sense to include 283 in the key-generation hash. 285 MISCELLANEOUS ISSUES 287 There are a number of miscellaneous problems which arise as a result 288 of constructing a protocol of this form. None of them seem to be 289 particularly insurmountable. These considerations are based on the 290 author's experience with vaguely similar security protocols. 292 Interaction With MTU Discovery 294 Because insertion of the inline keying header will change the size of 295 the packet, there are likely to be interactions between this protocol 296 and MTU discovery when the first packet triggering the creation of a 297 new SA pair is near maximum size. 299 Several potential solutions come to mind: 301 1) With some cooperation between layers, it may be possible to reduce 302 the amount of data in the outbound packet (this may be possible for 303 TCP; it's almost certainly not possible for other protocols). 305 2) MTU discovery could be deferred, by sending the packet with DF 306 cleared. 308 Neither of these seem really satisfactory; suggestions on how to 309 handle this case are welcomed. 311 SPI expiration and clock skew. 313 This section perhaps belongs as an appendix to the a future version 314 of the Internet DOI specification [DOI]. 316 Inline SPI's expire after a defined time. Since relative timestamps 317 are used in the protocol, clocks synchronized in phase are not 318 assumed; however, some minimal accuracy in frequency is assumed. 320 It is assumed here that SPI timestamps are maintained in absolute 321 form internally and converted to and from relative form only for use 322 over the network. 324 The explicit expiration time of the SPI indicates the time after 325 which the sender should no longer send to that SPI. The recipient 326 should still honor inbound packets to that SPI for an additional 327 grace period of: 328 K1 * MSL + K2 * nominal-lifetime 329 where "MSL" is the maximum lifetime of a packet in the network as in 330 TCP, "K1" is a fudge factor allowing some margin around MSL, and "K2" 331 is a fudge factor allowing for a difference in clock frequency 332 between systems. 334 Proposed default values: 335 MSL: 120 (same as TCP) 336 K1: 2 (same as TCP) 337 K2: 1/32 (allow for ~3% frequency difference) 338 It may be useful for debugging purposes to allow these parameters to 339 be adjusted. 341 With the above constants, a nominal 10-minute SPI would be valid for 342 about 14 minutes; and a nominal 2-hour SPI would be valid for 343 approximately 2 hours and 8 minutes. 345 EXAMPLE 347 The following is a simplified example of the messages involved in 348 setting up a new SPI pair using inline keying. A lot of detail has 349 been omitted to clarify the presentation. 351 Assume per-connection inline keying is in use between two hosts A and 352 B, with a security association X existing from A to B. 354 A wishes to establish a TCP connection to B. Because per-connection 355 keying is in use, A would first create a new inbound SPI "Y", and 356 send: 358 ESP [A-to-B, inline[N1, seq 0, Y], TCP [port 4352 to 21, SYN]] 360 Upon receipt, B creates a new outbound SPI "Y", and a new inbound SPI 361 "Z", and hands off the TCP packet to its TCP. It then responds with: 363 ESP [Y, inline[N2, seq 0, Z], TCP [port 21 to 4352, SYN+ACK]] 365 Upon receipt, A creates a new outbound SPI "Z". 367 Receipt of a packet on spi Y acknowleges receipt of the inline-keying 368 message, so subsequent messages for this connection do not contain an 369 inline keying header, so A responds with: 371 ESP [Z, TCP [port 4352 to 21, ACK, data1]] 373 Similarly, B responds with: 375 ESP [Y, TCP [port 21 to 4352, ACK, data2]] 377 and the conversation would continue like this until the TCP 378 connection closed. 380 SECURITY CONSIDERATIONS 381 This entire document concerns key management for the IP security 382 protocols. 384 This protocol does not provide for Perfect Forward Secrecy by itself, 385 but if used in conjunction with ISAKMP, may provide a reasonable 386 engineering tradeoff between security and performance. 388 As with Oakley's Quick Mode, this protocol can consume the entropy of 389 the shared secret[ISAOAK]. Implementors should take note of this fact 390 and be able to limit the number of inline-keying messages allowed per 391 shared secret. This draft does not proscribe such a limit. 393 REFERENCES 395 [BADESP] Bellovin, S., "Problem Areas for the IP Security 396 Protocols", Proceedings of the Sixth Usenix UNIX security 397 symposium, July 1996 (available from 398 ftp://ftp.research.att.com/dist/smb/badesp.ps) 400 [AH] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 401 RFC1826, August 1995. 403 [DOI] Piper, D., "The Internet IP Security Domain Of 404 Interpretation for ISAKMP", version 1, draft-ietf-ipsec- 405 ipsec-doi-00.txt. 407 [ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 408 RFC1827, August 1995. 410 [IPSEC] Randall Atkinson, "Security Architecture for the Internet 411 Protocol", Internet Draft draft-ietf-ipsec-arch-sec-01.txt, 412 10 November 1996 414 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and Turner, J., 415 "Internet Security Association and Key Management Protocol 416 (ISAKMP)", version 6, draft-ietf-ipsec-isakmp-06.{ps,txt}. 418 [ISAOAK] Harkins, D., Carrel, D., "The resolution of ISAKMP with 419 Oakley", draft-ietf-ipsec-isakmp-oakley-02.txt. 421 [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", version 422 1, draft-ietf-ipsec-oakley-01.txt. 424 [SKIP] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key- 425 Management For Internet Protocols", draft-ietf-ipsec- 426 skip-07.txt. 428 AUTHOR'S ADDRESS: 430 Bill Sommerfeld 431 Hewlett Packard 432 300 Apollo Drive 433 Chelmsford MA 01824 435 Telephone: +1 508 436 4352