idnits 2.17.1 draft-carrel-ipsecme-controller-ike-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2125 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-qr-ikev2-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Carrel 3 Internet-Draft B. Weis 4 Intended status: Standards Track Cisco Systems 5 Expires: January 3, 2019 July 2, 2018 7 IPsec Key Exchange using a Controller 8 draft-carrel-ipsecme-controller-ike-00 10 Abstract 12 This document presents a key exchange method allowing devices managed 13 by a controller (e.g., an SDN management station) to create private 14 pair-wise IPsec SAs without IKEv2 or any other direct peer-to-peer 15 session establishment messages. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Generating Initial IPsec SAs . . . . . . . . . . . . . . . . 5 55 4. Rekey of IPsec SAs . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Single IPsec Device Rekey . . . . . . . . . . . . . . . . 7 57 4.2. Simultaneous Rekey of IPsec Devices . . . . . . . . . . . 9 58 5. IPsec Database Generation . . . . . . . . . . . . . . . . . . 12 59 5.1. The Security Policy Database (SPD) . . . . . . . . . . . 12 60 5.2. Security Association Database (SAD) . . . . . . . . . . . 12 61 5.2.1. Generating Keying Material for IPsec SAs . . . . . . 12 62 5.3. Peer Authorization Database (PAD) . . . . . . . . . . . . 14 63 6. Policy distributed by the Controller . . . . . . . . . . . . 14 64 6.1. IPsec policy negotiation . . . . . . . . . . . . . . . . 15 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 10.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Appendix A. Example Controller protocols . . . . . . . . . . . . 18 72 A.1. Example: I2NSF . . . . . . . . . . . . . . . . . . . . . 18 73 A.2. Example: Network Controller . . . . . . . . . . . . . . . 19 74 A.3. Additional controller protocol considerations . . . . . . 19 75 A.3.1. Peer-to-peer distribution of IPsec policy . . . . . . 20 76 A.3.2. Ordering of messages distributed to a controller . . 21 77 Appendix B. Differences between IKEv2 and Controller based 78 methods . . . . . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 81 1. Introduction 83 Network architectures typically have included network devices 84 directly communicating using network control protocols such as 85 routing and signaling protocols. Additionally, secured 86 communications between these network devices are usually accomplished 87 with a key agreement protocol such as IKEv2 [RFC7296], in which the 88 network devices directly authenticate each other and agree upon 89 security policy and keying material to protect communications between 90 themselves. However, controller-based network architectures 91 (sometimes called "Software-Defined Networking") are now being 92 defined [RFC7426] [RFC8192] and implemented. In controller-based 93 network architectures, control protocols --including key exchange 94 protocols -- are not implemented directly between the network 95 devices. Software-Defined Networks utilize the controller based 96 network design while maximizing the scalability that it provides. 98 The result is a significantly different trust model; rather than 99 apply a peer-to-peer trust model, the network applies a device-to- 100 controller trust model. 102 +-------------+ 103 | | 104 | Controller | 105 | | 106 +-+----+-----++ 107 | | | 108 +---------------+ | +--------------+ 109 | Control Plane | 110 | | | 111 | | | 112 +--+--+ +--+--+ +--+--+ 113 | | | | | | 114 | A | | B | | C | 115 | | | | | | 116 +-+-+-+ ++--+-+ +-+-+-+ 117 | | | | | | 118 | +-----------------+ +------------------+ | 119 +-------------------------------------------+ 120 Secured Data Plane 122 Figure 1: Controller-based Secured Communications 124 Figure 1 shows an example controller based network design. Three 125 network devices (labeled A, B, and C) setup a protected control plane 126 connection to a Controller. The Controller distributes policy to the 127 network devices, which enable them to securely communicate between 128 them in the data plane. 130 When a controller participates in a key exchange protocol, it is 131 tempting to give it the task of generating and distributing session 132 keys directly to network devices. However, such a design has several 133 security considerations. Because the controller has all session 134 keys, it can become an active participant or a passive monitor to the 135 secured communications. Also, for scalability reasons controller- 136 distributed session keys tend to be group keys, either a single group 137 key or a set of group keys that devices use to protect communications 138 between them. 140 Many key exchange methods (such as IKEv2) use a Diffie-Hellman (DH) 141 algorithm to derive keys. When combined with an authentication 142 method, the key exchange method allows two network devices to 143 generate private pair-wise keys with each other. This document 144 presents a key exchange method making use of the device-to-controller 145 trust model, where a controller is used to distribute keying material 146 and policy between network devices, also resulting in the devices 147 generating private pair-wise keys with each other. DH public values 148 are provided to controllers from IPsec devices, where the controller 149 relays the DH public values to authorized peers of that IPsec device 150 as defined by a centralized policy. Network devices then create and 151 install private pair-wise IPsec session keys to be used to secure 152 communications with their peers. 154 Controller-based key exchange methods can be used to create a 155 Gateway-to-Gateway VPN [RFC7018] in either a Full-Mesh Topology or 156 Dynamic Full-Mesh Topology. 158 Although IKEv2 is not used in this approach, interfaces between IKEv2 159 and IPsec defined in RFC 7296 are maintained as much as possible. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 2. Overview 171 A controller acts as a proxy relaying policy and keying material 172 between IPsec devices. All algorithms are selected by the 173 controller, for example by a management station. The combination of 174 a Controller and a set of IPsec devices comprises a cooperating group 175 of devices that make up a VPN, where each IPsec device is authorized 176 to communicate with other IPsec devices in the group (either all 177 devices, or a subset depending on policy). 179 DH public values are distributed to the controller from each IPsec 180 device and redistributed from the controller to each IPsec device. 181 Each IPsec device creates and maintains a DH pair, which it uses to 182 communicate with other members of the VPN. This distribution of DH 183 public values (and other related values) is intended to be embedded 184 into an existing network device/controller protocol. In particular, 185 Controller-IKE provides a mechanism for secure key management and 186 only key management. It does not provide policy information or 187 configuration as that is assumed to be provided by the controller. 188 One such protocol is being developed at this time in the IETF I2NSF 189 working group. 191 3. Generating Initial IPsec SAs 193 When an IPsec device begins operation, it generates a DH pair, using 194 an algorithm defined in the IKEv2 Diffie-Hellman Group Transform IDs 195 [IKEV2-IANA]. If the device does not have any active peers it simply 196 distributes its DH public value to the Controller, along with a nonce 197 used during SA creation. Whenever a DH pair is created, a new nonce 198 MUST also be created. Whenever DH public values are transmitted, 199 they are transmitted with the corresponding nonce. Whenever a DH 200 private or DH public value is used, it is used along with the 201 corresponding nonce. However, in the diagrams and descriptions 202 below, the nonces are often left out for simplicity and clarity sake. 204 Upon receiving a peer's DH public value and nonce, the receiver 205 creates IPsec SAs (as described in Section 5.2). For each peer, a 206 pair of IPsec SAs are created combining the IPsec device's own DH 207 private value with the DH public number received from the Controller. 209 +---+ +----------+ +---+I 210 | A | |Controller| | B | 211 +-+-+ +-----+----+ +-+-+ 212 +----------+ | | | 213 |Generate | | | | +----------+ 214 |DH pair a1| | | | |Generate | 215 +----------+ | a1-pub | | |DH pair b1| 216 +----------> | b1-pub | +----------+ 217 | | <----------+ 218 | | | 219 | | a1-pub | 220 | b1-pub +----------> | +-----------+ 221 +-----------+ | <----------+ | |Create SA: | 222 |Create SAs:| | | | | Tx(b1-a1)| 223 | Tx(a1-b1)| | | | | Rx(a1-b1)| 224 | Rx(b1-a1)| | | | +-----------+ 225 +-----------+ | | | 226 | | | 227 | IPsec ESP Tx(a1-b1) | 228 +-----------------------> | 229 | | | 230 | IPsec ESP Tx(b1-a1) | 231 | <-----------------------+ 232 | | | 233 + + + 235 Figure 2: Generation of Initial IPsec SAs between two peers 237 Figure 2 shows IPsec SA generation between a pair of IPsec devices. 238 Two IPsec devices (A and B shown in Figure 1) join the network. Each 239 creates it's own DH pair (labelled "a1" on A and "b1" on B), and 240 distributes the DH public value (labelled a1-pub and b1-pub) to the 241 Controller. The controller forwards the DH public value to all 242 authorized peers, although for simplicity of exposition the figure 243 only shows the two IPsec devices. 245 When each device receives the peer's DH public value, a pair of IPsec 246 SAs are generated: one outbound and one inbound. As shown in the 247 figure, A generates an outbound SA labeled Tx(a1-b1), representing 248 that it has been generated using A's DH pair labeled a1 and B's DH 249 pair labeled b1. B generates the same IPsec SA as an inbound SA, 250 which is labeled Rx(a1-b1). Similarly, A generates an inbound IPsec 251 SA labelled Rx(b1-a1), which is the same IPsec SA on B labelled 252 Tx(b1-a1). 254 This process repeats on both A and B as they discover other IPsec 255 devices with which they are authorized to communicate. 257 4. Rekey of IPsec SAs 259 Any IPsec device may initiate a rekey at any time. Common reasons to 260 perform a rekey include a local time or volume based policy, or may 261 be the result of a cipher counter mode Initialization Vector (IV) 262 counter nearing its final value. The rekey process is performed 263 individually for each remote peer. If rekeying is performed with 264 multiple peers simultaneously, then the decision process and rules 265 described in this rekey are performed independently for each peer. 267 A decision process choosing an outbound IPsec SA is followed when 268 certain events occur, as described in the rules below. The same 269 decision process is followed regardless of whether the device is 270 performing a rekey or responding to a peer's rekey. The decision 271 process is: 273 1. Determine the outbound SAs with the remote peer's most recently 274 distributed DH public value. 276 2. Determine which of those outbound SAs are "live". A "live" 277 outbound SA is one built from a DH value from the local peer for 278 which it has observed inbound traffic using any SA based on the 279 same local DH pair. This proves that the remote peer is prepared 280 to receive traffic protected by that DH pair. 282 3. Choose the "live" outbound SA built from the local peer's most 283 recent DH public value. 285 A rekey operation follows these four basic rules. 287 Rule 1 When an IPsec device needs to perform a rekey with a remote 288 peer, it creates a new pair of IPsec SAs by combining the new DH 289 private value with the peer's DH public values. If the remote 290 peer is also in the midst of a rollover and its DH public value 291 has already been received, then this may result in creating two 292 sets of SAs: one pair with the remote peer's old DH public value, 293 and one pair with the remote peer's new DH public value. 295 Rule 2 When an IPsec device receives a new remote peer's DH public 296 value from the controller it creates and installs a new pair of 297 IPsec SAs by combining the remote peer's new DH public value with 298 its own current local DH private values. If both devices are in 299 the midst of a rollover, this may result in creating two sets of 300 SAs with the remote peer's new DH public value: one with the local 301 old DH private value, and one with the local new DH private value. 302 The outbound SA decision process is performed. 304 Rule 3 The first IPsec packet received by a rekeying IPsec device on 305 an inbound SA using its new DH pair causes it to perform the 306 outbound SA decision process. It may also shorten the lifetime of 307 IPsec SAs using its own old DH pair that are shared with this 308 peer, as they are no longer in use (other than the inbound SA 309 might receive packets in transit). 311 Rule 4 The first IPsec packet received from a remote rekeying IPsec 312 device using the remote peer's new DH pair allows the IPsec device 313 to shorten the lifetime of IPsec SAs shared with this peer using 314 unused remote DH pairs. 316 Two examples follow: a single IPsec device performing a rekey with 317 its peers, and two IPsec devices performing a simultaneous rekey. 318 The same rekey operations described above are exhibited in both 319 cases. 321 4.1. Single IPsec Device Rekey 323 When a single IPsec device begins a rekey, it first generates a new 324 DH pair and generates new IPsec SA pairs for each peer with which it 325 is communicating. It does this by combining the new DH private value 326 with each peer's existing DH public value. Only when the new IPsec 327 SAs have been installed and the device is prepared to receive on 328 those new SAs does it then distributes the new DH public value to the 329 Controller, which forwards it to its authorized peers. It continues 330 to transmit on the old SAs for each peer until it observes that peer 331 begin to transmit on the new SAs. 333 +---+ +----------+ +---+ 334 | A | |Controller| | B | 335 +-+-+ +-----+----+ +-+-+ 336 +----------+ | | | 337 |Generate | | | | 338 |DH pair a2| | | | 339 +----------+ | | | 340 +--------------+ | | | 341 |Rule 1 | | | | 342 | Create SAs | | | | 343 | Tx(a2-b1) | | | | 344 | Rx(b1-a2) | | | | 345 | Use Tx(a1-b1)| | a2-pub | | 346 +--------------+ +----------> | | 347 | | | 348 | IPsec ESP Tx(a1-b1) | 349 +-----------------------> | 350 | IPsec ESP Tx(b1-a1) | 351 | <-----------------------+ 352 | | | 353 | | a2-pub | 354 | +----------> | +--------------+ 355 | | | |Rule 2 | 356 | | | | Create SAs | 357 | | | | Tx(b1-a2) | 358 | | | | Rx(a2-b1) | 359 | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 360 +--------------+ | <-----------------------+ +--------------+ 361 |Rule 3 | | | | 362 | Use Tx(a2-b1)| | | | 363 | Shorten life | | | | 364 | Tx(a1-b1) | | IPsec ESP Tx(a2-b1) | 365 | Rx(b1-a1) | +----------------------> | +--------------+ 366 +--------------+ | | | |Rule 4 | 367 | | | | Shorten life | 368 | | | | Tx(b1-a1) | 369 | | | | Rx(a1-b1) | 370 | | | +--------------+ 371 + + + 373 Figure 3: Single IPsec Device Rekey Protocol Flow 375 In Figure 3, device A is shown as performing a rekey, and it creates 376 a DH pair labelled "a2". The following steps are followed. 378 1. Rule 1 requires creating new IPsec SAs for each peer. In this 379 example, A creates a new outbound IPsec SA to communicate with B 380 labelled Tx(a2-b1), and a new inbound IPsec SA labelled 381 Rx(b1-a2). A continues to transmit on Tx(a1-b1) (generated as 382 shown in Figure 2). 384 2. A distributes the new public value (a2-pub) to the Controller who 385 forwards it to A's authorized peers, which includes B. During 386 this time, both A and B continue to use the initial IPsec SAs 387 setup between them using a1 and b1. 389 3. When B receives a2 from the controller, B follows Rule 2 by 390 creating Tx(b1-a2), Rx(a2-b1). B also follows the outbound SA 391 decision process, which causes it to change its outbound IPsec SA 392 to A to Tx(b1-a2). 394 4. When A receives a packet protected by Rx(b1-a2), it follows Rule 395 3 and performs the outbound SA decision process. This causes it 396 to change its outbound IPsec SA to Use Tx(a2-b1). It also 397 optionally shortens the lifetime of the old IPsec SAs shared with 398 this peer. 400 5. When B receives a packet protected by Tx(a2-b1), it follows Rule 401 4, in which it may shorten the lifetime of the old IPsec SAs 402 shared with this peer using DH pairs that are no longer in use. 404 At the end of the rekey, both A and B retain a single DH pair, and a 405 single set of IPsec SAs between them. 407 4.2. Simultaneous Rekey of IPsec Devices 409 When two or more IPsec device simultaneously begin a rekey, they each 410 follow the rekeying method described in the previous section. Every 411 rekeying IPsec device generates a new DH pair and generates new IPsec 412 SA pairs for each peer with which it is communicating by combining 413 their new DH private value with each peer's existing DH public value. 414 When this completes on a particular IPsec device, it distributes the 415 new DH public value to the Controller, which forwards it to its 416 authorized peers. Each continues to transmit on the existing SAs for 417 each peer until it observes that peer transmitting on the new SAs. 418 During a simultaneous rekey up to four pairs of IPsec SAs may be 419 temporarily created, but the four rules ensure that they converge on 420 a single new set of IPsec SAs. 422 +---+ +----------+ +---+ 423 | A | |Controller| | B | 424 +-+-+ +-----+----+ +-+-+ 425 +---------------------+ | | | +--------------+ 426 |Generate DH pair a2 | | | | |Gen DH pair b2| 427 +---------------------+ | | | +--------------+ 428 +---------------------+ | | | +--------------+ 429 |Rule 1 | | | | |Rule 1 | 430 | Create SAs | | | | | Create SAs | 431 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b2-a1) | 432 | Use Tx(a1-b1) | | a2-pub | | | Rx(a1-b2) | 433 +---------------------+ +----------> | b2-pub | | Use Tx(b1-a1)| 434 | | <----------+ +--------------+ 435 | IPsec ESP Tx(a1-b1) | 436 +-----------------------> | 437 | IPsec ESP Tx(b1-a1) | 438 | <-----------------------+ 439 | | a2-pub | 440 | b2-pub +----------> | +--------------+ 441 +---------------------+ | <----------+ | |Rule 2 | 442 |Rule 2 | | | | | Create SAs | 443 | Create SAs | | | | | Tx(b1-a2) | 444 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a2-b1) | 445 | Tx(a2-b2),Rx(b2-a2)| | | | | Tx(b2-a2) | 446 | Use Tx(a1-b2) | | | | | Rx(a2-b2) | 447 +---------------------+ | IPsec ESP Tx(b1-a2) | | Use Tx(b1-a2)| 448 | <-----------------------+ +--------------+ 449 | IPsec ESP Tx(a1-b2) | 450 +---------------------+ +-----------------------> | +--------------+ 451 |Rule 3 | | | | |Rule 3 | 452 | Use Tx(a2-b2) | | | | | Use Tx(b2-a2)| 453 | Shorten life | | | | | Shorten life | 454 | Tx(a1-b1),Rx(b1-a1)| | | | | Tx(b1-a1) | 455 | Tx(a1-b2),Rx(b2-a1)| | | | | Rx(a1-b1) | 456 +---------------------+ | IPsec ESP Tx(a2-b2) | | Tx(b1-a2) | 457 +----------------------> | | Rx(a2-b1) | 458 | IPsec ESP Tx(b2-a2) | +--------------+ 459 +---------------------+ <-----------------------+ +--------------+ 460 | Rule 4 | | | | |Rule 4 | 461 | Shorten life | | | | | Shorten life | 462 | Tx(a2-b1),Rx(b1-a2)| | | | | Tx(b1-a2) | 463 +---------------------+ | | | | Rx(a2-b1) | 464 + + + +--------------+ 466 Figure 4: Simultaneous IPsec Device Rekey Protocol Flow 468 In Figure 4, device A and device B are both shown as performing a 469 rekey. Their initial state corresponds to the final state shown in 470 Figure 2 (i.e., they are communicating using a single pair of IPsec 471 SAs created from DH pairs "a1" and "b1". 473 1. A and B follow Rule 1, which includes creating new IPsec SAs for 474 each peer. In this example, A creates a new outbound IPsec SA to 475 communicate with B labelled Tx(a2-b1), and a new inbound IPsec SA 476 labelled Rx(b1-a2). B creates a new outbound IPsec SA to 477 communicate with B labelled Tx(a1-b2), and a new inbound IPsec SA 478 labelled Rx(b2-a1). A and B continue to transmit on IPsec SAs 479 previously created from DH pairs "a1" and "b1". 481 2. A distributes the new public value (a2-pub) to the Controller who 482 forwards it to A's authorized peers, which includes B. B also 483 distributes the new public value (b2-pub) to the Controller who 484 forwards it to B's authorized peers, which includes A. 486 3. When A and B receive each other's new peer DH public value from 487 the controller they follows Rule 2. But because now there are 488 four DH values that could be in used between A and B, they must 489 be prepared to use IPsec SAs using each permutation of DH values: 490 a1-b1, a1-b2, a2-b1, a2-b2. Prior to implementing Rule 2, each 491 has already created sets of IPsec SAs matching two of the 492 permutations, so just two more sets must be generated during Rule 493 2. 495 * One pair is created using the IPsec device's old DH pair with 496 the peer's new DH pair. This is necessary, because the peer 497 may transmit on this pair. 499 * One pair is created using the IPsec device's new DH pair with 500 the peer's new DH pair. This is the set of IPsec SAs that 501 will be used at the end of the rekey process. 503 Each peer begins transmitting on an IPsec SA that combines the 504 remote peer's new DH pair and its own old DH pair, which is the 505 most recent "live" SA on which it can transmit. I.e., A begins 506 transmitting on Tx(a1-b2) and B begins transmitting on Tx(b1-a2). 508 4. When A receives a packet protected by Rx(b1-a2), it understands 509 that the remote peer has received its new DH public value. A 510 also understands that because of Rule 2 that B must have created 511 IPsec SAs using a2-b2. This allows A to follow Rule 3 and change 512 its outbound IPsec SA to Use Tx(a2-b2). Similarly, when B 513 receives a packet protected by Rx(a1-b2), B recognizes that it 514 can also begin to transmit using Tx(b2-a2). Note that it also 515 possible that A will receive a packet protected by Rx(b2-a2) or B 516 will receive a packet protected by Rx(a2-b2), and then knows it 517 can transmit on an IPsec SA using both of the new DH pairs. 519 5. Also in Rule 3, Both A and B optionally shorten the lifetime of 520 older IPsec SAs shared with this peer derived from unused DH 521 pairs to be cleaned up. A shortens the lifetime of SAs based on 522 a1. B shortens the lifetime of SAs based on b1. 524 6. When A and B receive a packet protected by the remote peer's 525 latest DH pair, they shortens the lifetime of SAs based on the 526 remote peer's unused DH pair. 528 5. IPsec Database Generation 530 The PAD, SPD, and SAD all need to be setup as defined in the IPsec 531 Security Architecture [RFC4301]. 533 5.1. The Security Policy Database (SPD) 535 The SPD is implemented using methods outside the scope of this 536 document. The SPD describes the type of traffic that will be 537 protected between IPsec devices and the policy (e.g., ciphers) used 538 to create SAs. 540 5.2. Security Association Database (SAD) 542 The SAD is constructed from IPsec policy (e.g., ciphers) obtained 543 (depending on the controller protocol method) either from the 544 controller or distributed by a peer (see Section 6). 546 Keying Material is generated following the method defined in IKEv2, 547 and depends on SPIs, nonces, and the Diffie-Hellman shared secret. 549 The following sections describe how the necessary values are 550 determined. 552 5.2.1. Generating Keying Material for IPsec SAs 554 5.2.1.1. g^ir 556 A DH public value is distributed from the peer. 558 A DH shared secret (g^ir) is computed using the peer's public value, 559 and the device's private value. The DH group to be used must be 560 known by the device. Options include distribution by an SDN 561 controller, or distribution by the peer with the DH public value (see 562 Section 6). 564 5.2.1.2. Nonces 566 Nonces are distributed with a DH public value, and are used only with 567 that value. It is RECOMMENDED that nonces are generated as described 568 in Section 2.10 of [RFC7296]. 570 IKEv2 Key derivation specifies an initiator's nonce (Ni) and a 571 responder's nonce (Nr). While neither peer is truly initiating a 572 session), in order to fit the IKE key material models the roles must 573 be assigned. The initiator is chosen as the peer with the larger 574 nonce and the responder is the peer with the smaller. This does mean 575 that the roles can change for each rekey and for each SA within a 576 rekey. 578 5.2.1.3. SPIs 580 SPI values that are unique to each generation of keying material need 581 to be determined. While each peer could distribute its own inbound 582 SA value, the SPI value would be used by many peers. Although this 583 is not a problem for an SA lookup (lookup can include the source and 584 destination IP addresses), experience has shown that this is sub- 585 optimal for some hardware SA lookup algorithms. Instead, this 586 specification proposes generating values that are unpredictable and 587 indistinguishable from randomly-generated SPI values. 589 SPI values are generated using the IKEv2 prf+ function, where nonces 590 are used as the input to the prf. However, in some circumstances 591 additional values may also need to be added to the prf for peers to 592 ensure that they have implemented the same policy. Appendix A.3.1 593 includes a discussion of when this might be needed. 595 {SPI_i | SPI_r } = prf+(Ni | Nr, "SPI generation") 597 The SPI_i is taken by the device providing Ni, where SPI_r is taken 598 by the other device. 600 Because a device is not choosing its inbound SPI, its SA lookup 601 process needs to be aware that duplicates could occur. In that case, 602 the inbound SA Lookup SHOULD include a source IP addresses in 603 addition to the SPI value (see Section 4.1 of [RFC4301]). 605 5.2.1.4. IPsec key generation 607 As described in previous sections, a DH public value and a nonce are 608 distributed by peers. These are used to generate IPsec keys 609 following the method defined in the IKEv2. SKEYSEED is generated 610 following Section 2.14 of [RFC7296]: 612 SKEYSEED = prf(Ni | Nr, g^ir) 614 KEYMAT can be similarly derived as defined by IKEv2 (Section 2.17 of 615 [RFC7296]), although only SK_d is required to be generated (shown in 616 Section 2.14 of [RFC7296]). 618 SK_d = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 620 KEYMAT = prf+(SK_d, Ni | Nr) 622 However, with the simplification where only SK_d is generated, it can 623 be observed that the derivation of SK_d could be skipped entirely, 624 and an optimized derivation of KEYMAT could be as follows: 626 KEYMAT = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) 628 Note: A single specification for generating KEYMAT will be determined 629 in a future version of this document. 631 5.3. Peer Authorization Database (PAD) 633 The PAD identifies authorized peers. PAD entries are either 634 statically configured, or may be dynamically updated by the 635 controller. 637 The PAD omits authentication data for each peer, because it has 638 delegated authentication and authorization to the controller. 640 The controller protocol MUST be able to describe an identity that a 641 receiver can match against its local PAD database, to ensure that the 642 peer is an authorized peer. 644 6. Policy distributed by the Controller 646 An IPsec device distributes to a controller a DH public value and the 647 associated information and policy needed to create IPsec SAs in a 648 Device Information Message (DIM). The controller then distributes 649 the DIM to all authorized peers of that device. The following data 650 elements MUST be embedded in a DIM message: 652 o DH public number (used for key computation) 654 o Nonce (used for key computation and SPI generation) 656 o Peer identity (used to identify a peer in the PAD) 658 o An Indication whether this is the initial distributed policy. 660 In cases where a single fixed IPsec policy has been pre-distributed, 661 it is not necessary for the peer to send or receive that policy in a 662 DIM. However, in cases where an IPsec device needs to indicate the 663 policy it is willing to use, the following data elements SHOULD be 664 included in a DIM: 666 o A rekey counter, which increases for each unique DIM sent 668 o An IPsec policy or policies 670 Appendix A suggests different ways that this policy may be included 671 in a controller protocol. This document does not define a normative 672 protocol format, because the DIM very likely needs to be integrated 673 into an existing controller protocol rather than be an independent 674 key management protocol. However, the controller protocol MUST 675 provide a strong authentication between the device and the 676 controller, and integrity of the messages MUST be provided. 677 Confidentiality of the messages SHOULD also be provided. It is 678 important that the controller protocol be protected with algorithms 679 that are at least as strong as the algorithms used to protect the 680 IPsec packets. 682 6.1. IPsec policy negotiation 684 In many controller based networks, there is a single IPsec policy 685 used by all devices and there is no need to redistribute or select 686 policy details. However, in some circumstances, there may be a need 687 to have multiple policy options. This could happen when a controller 688 changes the policy and wants to smoothly migrate all devices to the 689 new policy. Or it could happen if a network supports devices with 690 different capabilities. In these cases, devices need to be able to 691 choose the correct policy to use for each other device, and must do 692 this without sending additional messages and without sending 693 individual messages to each peer. When a device supports multiple 694 policies, it MUST include those policies within the DIM. This is 695 done by sending multiple distinct policies, in order of preference, 696 where the first policy is the most preferred. The policy to use is 697 selected by taking the receiver's list of policies (i.e., the list 698 advertised by the device that generates Nr), starting with the first 699 policy, compare against the initiator's (device that generates Ni) 700 list, and choosing the first one found in common. The method 701 conforms to the IKEv2 Cryptographic Algorithm Negotiation described 702 in Section 2.7 of [RFC7296]. (However, see additional discussion 703 when IKEv2 payloads are used in Appendix A.3.1). 705 If there is no match, this indicates a controller configuration 706 error. These devices MUST NOT establish new SAs until a DIM is 707 received that does produce a match. 709 When a device supports more than one DH group, then a unique DH 710 public number MUST be specified for each in order of preference. The 711 selection of which DH group to use follows the same logic as Policy 712 selection, using the receiver's list order until a match is found in 713 the initiator's list. 715 7. Security Considerations 717 This document proposes that a device re-use an ephemeral Diffie- 718 Hellman exponential with multiple peers. There are some known 719 potential vulnerabilities to this approach, which can be mitigated by 720 the device first validating a peer's public value to be a safe public 721 value before combining its own private value with it. The tests 722 which MUST be performed are described in [RFC6989]. See [REUSE] for 723 additional security considerations when reusing ephemeral Diffie- 724 Hellman keys. 726 A controller acts as a "trusted third party", which asserts that a 727 particular Diffie-Hellman public value is associated with a 728 particular entity. A device receiving the public key is not required 729 to validate the assertion. 731 A subverted controller can act as a "man-in-the-middle" between a 732 pair of devices. The easiest attack would be for the attacker to 733 adjust the routing for the desired traffic through a compromised 734 gateway and directly observe the cleartext. It is also possible that 735 a subverted controller could provide a device with a Diffie-Hellman 736 public value that actually belongs to a compromised gateway rather 737 than the intended gateway, but doing so does not seem to be 738 necessary. Nonetheless, the attack of a subverted controller can be 739 mitigated by having a device sign its Diffie-Hellman public value 740 (e.g, as a CMS Signed data object), where the receiver validates the 741 digital signature on the object. However, this adds significant 742 processing cost to a rekey and does not fit the controller-based 743 network architecture model. 745 A subverted IPsec device whose DH pair has been compromised would be 746 vulnerable to all of its IPsec traffic using that DH pair being 747 compromised. Assuming the use of strong DH algorithms (including 748 quantum resistant algorithms as they become available), the 749 compromise would most likely be due to the device itself being 750 compromised. Such a compromised device is also vulnerable to a 751 direct plaintext compromise. 753 PFS is achieved between rekey periods, as DH pairs are required to be 754 generated independently. However, because a device uses the same 755 long-term key to generate session key with multiple peers, there is 756 no PFS between sessions within the same rekey period. To reduce key 757 exposure outside of a rekey period, when a connection is closed each 758 endpoint MUST forget not only the keys used by the connection but 759 also any information that could be used to recompute those keys. 760 Hoever, the DH private key value and the nonce distributed with it 761 may be forgotten only once the last IPsec SA that uses the private 762 key value is removed from the SAD and there is no chance that a new 763 IPsec SA could be setup that requires the private key value. 765 If quantum resistance is considered to be an issue, the controller 766 can distribute a PSK, which could be used to create the SK_d in the 767 manner shown in [I-D.ietf-ipsecme-qr-ikev2]. 769 8. IANA Considerations 771 This memo specifies no IANA actions. 773 9. Acknowledgements 775 Graham Bartlett provided many useful comments and suggestions. 777 10. References 779 10.1. Normative References 781 [IKEV2-IANA] 782 IANA, "Internet Key Exchange Version 2 (IKEv2) 783 Parameters", February 2016, 784 . 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 793 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 794 December 2005, . 796 [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman 797 Tests for the Internet Key Exchange Protocol Version 2 798 (IKEv2)", RFC 6989, DOI 10.17487/RFC6989, July 2013, 799 . 801 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 802 Kivinen, "Internet Key Exchange Protocol Version 2 803 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 804 2014, . 806 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 807 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 808 May 2017, . 810 10.2. Informative References 812 [I-D.ietf-ipsecme-qr-ikev2] 813 Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov, 814 "Postquantum Preshared Keys for IKEv2", draft-ietf- 815 ipsecme-qr-ikev2-04 (work in progress), July 2018. 817 [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 818 Diffie-Hellman Key Agreement Protocols", December 2008, 819 . 822 [RFC7018] Manral, V. and S. Hanna, "Auto-Discovery VPN Problem 823 Statement and Requirements", RFC 7018, 824 DOI 10.17487/RFC7018, September 2013, 825 . 827 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 828 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 829 Defined Networking (SDN): Layers and Architecture 830 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 831 2015, . 833 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 834 and J. Jeong, "Interface to Network Security Functions 835 (I2NSF): Problem Statement and Use Cases", RFC 8192, 836 DOI 10.17487/RFC8192, July 2017, 837 . 839 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 840 Kumar, "Framework for Interface to Network Security 841 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 842 . 844 Appendix A. Example Controller protocols 846 This section contains suggestions of how a Controller protocol might 847 distribute policy for the Controller-based IKE. 849 A.1. Example: I2NSF 851 IPsec devices described in this document could be implemented as an 852 Network Security Function (NSF) in the I2NSF Framework [RFC8329]. An 853 I2NSF Controller or NSF Manager could distribute a DIM as a new type 854 of I2NSF Policy Rule. A YANG configuration data model would need to 855 be defined for this. 857 A.2. Example: Network Controller 859 Site-to-site networks (e.g., an L2VPN or L3VPN) often use a network 860 controller to share networking state between routers. When those 861 routers use IPsec to protect the communications between themselves, 862 this same network controller could distribute DH public number and 863 nonces as well. For example, when a BGP Route Reflector (RR) is used 864 in a network, a new address family (AFI) could distribute the state 865 necessary for a controller-based IPsec key exchange. The BGP session 866 between BGP routers and the Route Reflector (RR) would need to at 867 least be integrity protected from a man in the middle and SHOULD be 868 protected for confidentiality to prevent identity leakage. 870 The controller protocol MUST provide for adequate synchronization of 871 the state. For example, when IPsec devices are synchronized with a 872 key management protocol it is often necessary for the protocol to 873 indicate when a device has rebooted and thinks that it is contacting 874 peers for the first time. This alerts peers to destroy earlier 875 keying state that they may still believe is current. 877 One possible method for distributing a DIM within a controller 878 protocol is to use a set of IKEv2 payloads. For example, when a 879 single set of IPsec policy has been distributed to all IPsec devices 880 by a configuration server then the following minimum required data 881 elements can be distributed using the following IKEv2 payloads. 883 ID, [N(INITIAL_CONTACT),] KE, Ni 885 When initiating a rekey, the IPsec device need only distribute its 886 new DH public number due to Rule 1. Existing peers receiving the new 887 DH public number need not be re-told about the previous DH public 888 number. Any new peer that receives and acts upon a "stale" 889 controller message (containing the old DH public number) will still 890 be able to setup IPsec SAs using the old DH public number, and can 891 use them until the new DH public number is received. 893 A.3. Additional controller protocol considerations 895 If the controller protocol is more complicated, there are some 896 additional considerations. 898 A.3.1. Peer-to-peer distribution of IPsec policy 900 In some cases an IPsec device may have more than one IPsec policy 901 under which it is willing to communicate. This would result in an 902 IPsec device using the decision process described in Section 6.1 to 903 determine which policy to use between itself and that peer. An IKEv2 904 SA payload could be used to distribute the policies, and the decision 905 process could be used to determine which single set of policy is to 906 be used. Note that the same decision process is followed by both 907 peers. It is important that when an SA payload is used, that each 908 proposal within the SA payload MUST contain at most a single 909 transform for each Transform type (e.g., ENCR and (optionally) ESN 910 for combined mode algorithms, ENCR, INTEG, and (optionally) ESN 911 otherwise). This is due to the absence of a direct peer-to-peer 912 reply message, which would alert the sender of which proposal was 913 chosen. 915 1. Determine the Responder (as defined in Section 5.2.1.2). 917 2. Follow the negotiation rules defined in Section 2.7 of IKEv2 918 [RFC7296] (with the restrictions that more than one transform of 919 each type MUST NOT be present, and no error notifications are 920 returned to the peer). Each peer will independently compare each 921 Proposal in the Responder's SA payload to each Proposal in the 922 Initiator's SA payload and choose the first match. 924 3. If there is no match, then this is considered a controller error, 925 and the IPsec devices SHOULD report the error to the controller. 927 Payloads distributed in the controller protocol could be as follows: 929 ID, [N(INITIAL_CONTACT),] SA, KE, Ni 931 where the SA payload contains one or more Proposals, each of this 932 includes a transform indicating the Diffie-Hellman group it is 933 willing to use (D-H Transform), and IPsec transforms that it is 934 willing to use (e.g., ENCR, INTEG, and ESN Transforms). The KE 935 payload includes a DH public number matching the D-H Transform. 937 Because there is no direct peer-to-peer IKE messages, there is a need 938 for peers to reliably know which Proposal in the SA payload was 939 chosen. That is, if they do not reliably follow the same decision 940 process they may end up installing IPsec SAs with incompatible 941 policy. A straightforward method to verify that a peer has chosen 942 the same policy is to include the SA Proposal number (SPN) from the 943 SA payload in the SPI calculation. 945 {SPI_i | SPI_r } = prf+(Ni | Nr, "SPI generation" | SPNi | SPNr) 947 If a device is willing to use more than one DH group, then a single 948 SA payload should be distributed, but the included Proposals may 949 contain different D-H Transforms. A KE payload must be included for 950 each D-H Group that is offered in the SA payload. 952 ID, [N(INITIAL_CONTACT),] [SA,] KE, [KE,] Ni 954 A.3.2. Ordering of messages distributed to a controller 956 A controller protocol may require a method of determining ordering of 957 messages that are distributed, i.e. a Rekey Counter (RC). It is 958 RECOMMENDED that the ordering be defined by a monotonically 959 increasing counter value distributed with the IPsec policy. It is 960 further RECOMMENDED that to ensure ordering after a device reboot 961 that the counter include a "boot count", which increments after each 962 reboot. For example, the counter could be a 64-bit counter where the 963 high order 32 bits are a "boot count", followed by the counter that 964 begins at 1 following the increment of the "boot count". 966 Appendix B. Differences between IKEv2 and Controller based methods 968 Placeholder appendix. 970 Authors' Addresses 972 David Carrel 973 Cisco Systems 974 170 W. Tasman Drive 975 San Jose, California 95134-1706 976 USA 978 Phone: +1-408-525-7852 979 Email: carrel@cisco.com 981 Brian Weis 982 Cisco Systems 983 170 W. Tasman Drive 984 San Jose, California 95134-1706 985 USA 987 Phone: +1-408-526-4796 988 Email: bew@cisco.com