idnits 2.17.1 draft-mahesh-karp-rkmp-06.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 22, 2018) is 2104 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: 'N' is mentioned on line 350, but not defined == Missing Reference: 'KEi' is mentioned on line 350, but not defined == Missing Reference: 'KEr' is mentioned on line 352, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft 4 Intended status: Standards Track B. Weis 5 Expires: January 23, 2019 Cisco Systems 6 K. Patel 7 Arrcus 8 D. Zhang 9 Huawei 10 S. Hartman 11 Painless Security 12 U. Chunduri 13 A. Tian 14 Ericsson Inc. 15 J. Touch 16 USC/ISI 17 July 22, 2018 19 Negotiation for Keying Pairwise Routing Protocols in IKEv2 20 draft-mahesh-karp-rkmp-06 22 Abstract 24 This document describes a mechanism to secure the routing protocols 25 which use unicast to transport their signaling messages. Most of 26 such routing protocols are TCP-based (e.g., BGP and LDP), and the TCP 27 Authentication Option (TCP-AO) is primarily employed for securing the 28 signaling messages of these routing protocols. There are also two 29 exceptions: BFD which is over UDP or MPLS, and RSVP-TE which is over 30 IP (but employs an integrated approach to protecting the signaling 31 messages instead of using IPsec). The proposed mechanism secures 32 pairwise TCP-based Routing Protocol (RP) associations, BFD 33 associations and RSVP-TE associations using the IKEv2 Key Management 34 Protocol (KMP) integrated with TCP-AO, BFD, and RSVP-TE respectively. 35 Included are extensions to IKEv2 and its Security Associations to 36 enable its key negotiation to support TCP-AO, BFD, and RSVP-TE. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on January 23, 2019. 61 Copyright Notice 63 Copyright (c) 2018 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 4 80 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 81 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2.1. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . 6 84 3.1. IKE_SA_INIT . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.2. IKE_AUTH . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.3. CREATE_CHILD_SA . . . . . . . . . . . . . . . . . . . . . 7 87 3.4. INFORMATIONAL . . . . . . . . . . . . . . . . . . . . . . 8 88 4. Operation Details . . . . . . . . . . . . . . . . . . . . . . 9 89 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 4.2. Initial Key Specific Data Exchange . . . . . . . . . . . 10 91 4.3. Key Selection, Rollover and Protocol Interaction . . . . 10 92 5. Key Management Database . . . . . . . . . . . . . . . . . . . 10 93 6. Header and Payload Formats . . . . . . . . . . . . . . . . . 11 94 6.1. Header and Payload Formats for TCP-AO . . . . . . . . . . 11 95 6.1.1. Security Association Payload for TCP-AO . . . . . . . 11 96 6.1.1.1. Transforms Substructures for TCP-AO . . . . . . . 11 97 6.1.1.2. Example Proposal Exchange . . . . . . . . . . . . 12 98 6.1.2. Derivation of TCP-AO Keying Material . . . . . . . . 13 99 6.2. Security Association Payload for BFD . . . . . . . . . . 13 100 6.2.1. Transforms Substructures for BFD Authentication . . . 14 101 6.3. Security Association Payload for RSVP-TE . . . . . . . . 15 102 6.3.1. Transforms Substructures for RSVP-TE Authentication . 15 103 6.4. Notify and Delete Payloads . . . . . . . . . . . . . . . 16 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 10.2. Informative References . . . . . . . . . . . . . . . . . 18 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 Existing routing protocols using unicast pairwise communication model 115 (e.g., BGP, LDP, RSVP-TE, and BFD) have cryptographic authentication 116 mechanisms that use a key shared between the network devices (devices 117 for short) on the both sides of the model to protect routing message 118 exchanges between endpoints. The unicast key management for these 119 protocols today is limited to statically configured master keys in 120 individual network devices. This document defines a mechanism to 121 secure such pairwise Routing Protocol (RP) associations using IKEv2 122 [RFC7296], allowing network devices to automatically exchange keying 123 material related information between the network devices. To benefit 124 the discussion, it is implied that the routing protocols mentioned in 125 the remainder of this memo use unicast pair-wise communication model, 126 unless otherwise mentioned. 128 This memo assumes that network devices need to be provisioned with 129 some credentials for a one-to-one authentication protocol. Any 130 method for a pairwise security protocol specified for use with IKEv2 131 is applicable. 133 When two network devices running a routing protocol have not yet 134 established a secure association, the two endpoints need to select a 135 KMP solution that meets their mutual requirements and use that KMP 136 solution to establish the required security before sending out any 137 routing protocol packets. The KMP solution typically enables the 138 network devices to perform mutual authentication using their 139 provisioned credentials and to agree upon certain keying material as 140 the result of an successful authentication. The keying material then 141 can be applied to secure the routing protocol. 143 1.1. Terminologies 145 This section lists the key terminologies used throughout the memo. 147 Network Device: In this memo, a router or any other type of device 148 participating in routing protocols is referred to as a network 149 device. 151 Key Management Database (KDMB): A KDMB is a conceptual database which 152 locates in the middle of a key management protocol and a routing 153 protocol to provide the long-term key management service. Therefore, 154 the RP and the KMP need not to cooperate directly. 156 1.2. Acronyms and Abbreviations 158 The following acronyms and abbreviations are used throughout this 159 memo. 161 IKEv2 Internet Key Exchange Protocol Version 2 163 RP Routing Protocol 165 SA Security Association 167 KMP Key Management Protocol 169 2. Overview 171 As illustrated in Figure 1, this work makes use the state machine of 172 IKEv2. Assume a network device and its peer device are in State 1. 173 That is, the device has not authenticated its peer device and does 174 not have the keys to secure the routing protocol packets which it 175 would like to exchange with the peer. Before sending any routing 176 protocol packets, the two devices need to perform a IKE_SA_INIT 177 exchange. If the IKE_SA_INIT exchange succeeds, both network devices 178 are transferred to State 2 where they have agreed upon certain keying 179 material but have decided how to use the material to derive keys to 180 secure routing protocols. To achieve this objective, the two network 181 devices perform an IKE_AUTH exchange, in which both endpoints try to 182 authenticate each other and generate security associations for the 183 routing protocol they intend to support. If the IKE_AUTH exchange 184 succeeds, the network devices transfer their state to State 3 where 185 both endpoints are authenticated and keys for securing the routing 186 protocols are generated. If the endpoints intend to generate new SAs 187 for routing protocols by using the keying material already generated, 188 they can just perform an CREATE_CHILD_SA exchange. A discussion in 189 more details can be found in Section 4. 191 ----------------------- 192 =======> | Not Authenticated |========== 193 || | No RP Keys | || 194 || ----------------------- IKE_SA_INIT exchange 195 || State 1 || 196 || || 197 INFORMATIONAL VV 198 || -------------------------- 199 || | Privacy Keys Exchanged | 200 || | No RP Keys | 201 || -------------------------- 202 || || State 2 203 || || 204 || |-------------------- IKE_AUTH exchange 205 =========| Authenticated | <============ 206 | RP Keys Derived | ==== 207 -------------------- || 208 State 3 ^^ || 209 || CREATE_CHILD_SA 210 || || 211 =============== 213 Figure 1: State Diagram 215 2.1. Types of Keys 217 Three types of keys mentioned the discussion of this memo are listed 218 as follows: 220 o PSK (Pre-Shared Key) : a PSK is a pair-wise unique key, which can 221 be used for securing the routing protocol exchanges or be used for 222 authenticating a network device by a KMP. These keys are 223 configured by some mechanism such as manual configuration or a 224 management application outside of the scope of KMP. 226 o Protocol master key: A protocol master key is a key exported by a 227 KMP for use by a routing protocol. This is the key that is shared 228 in the KMDB between the routing protocol and KMP. A routing 229 protocol may use a protocol master key directly or derive traffic 230 keys from it. 232 o Traffic key: A traffic key is the key actually used to protect the 233 integrity of the routing messages exchanged in a routing protocol. 234 In existing cryptographic authentication mechanisms for routing 235 protocols, the traffic key can be the same as or derived from the 236 protocol master key. If there is no KMP provided, a traffic key 237 can be the same as or derived from a pre-shared key. 239 3. Protocol Exchanges 241 The KARP analysis in BGP, LDP, PCEP, and MSDP indicates that all of 242 these routing protocols need a dedicated key management 243 protocol[RFC6952] to confidentially exchange keying material between 244 endpoints. There is no need to define an entirely new protocol for 245 this purpose, when existing mature protocol exchanges and methods 246 have been vetted. This draft makes use of the IKEv2 protocol 247 exchanges, state machine, and policy definitions to define a 248 dedicated key management protocol. 250 The notations contained in the IKEv2 message are defined as follows. 252 +----------+------------------------------+ 253 | Notation | Payload | 254 +----------+------------------------------+ 255 | AUTH | Authentication | 256 | CERT | Certificate | 257 | CERTREQ | Certificate Request | 258 | D | Delete | 259 | HDR | IKEv2 Header (not a payload) | 260 | IDi | Identification - Initiator | 261 | IDr | Identification - Responder | 262 | KE | Key Exchange | 263 | Ni, Nr | Nonce | 264 | N | Notify | 265 | SA | Security Association | 266 | SK | Encrypted and Authenticated | 267 | TSi | Traffic Selector - Initiator | 268 | TSr | Traffic Selector - Responder | 269 +----------+------------------------------+ 271 Acronyms Used in Protocol Exchange 273 3.1. IKE_SA_INIT 275 A network device desiring to negotiate a key and other associated 276 parameters for a pair-wise routing protocol to a peer initiates an 277 IKE_SA_INIT exchange defined in IKEv2 [RFC7296]. The IKE_SA_INIT 278 exchange is a two-message exchange that allows the network devices to 279 negotiate cryptographic algorithms, exchange nonce information, and 280 do a Diffie-Hellman (DH) [DH] exchange, for their routing protocols, 281 after which protocols on these network devices can communicate 282 privately. Note that at the end of a IKE_SA_INIT exchange the 283 endpoints on the both sides have not authenticated each other yet. 284 For the details of this exchange, refer to IKE_SA_INIT in IKEv2 285 [RFC7296]. 287 Peer (Initiator) Peer (Responder) 288 -------------------- ------------------ 289 HDR, SAi1, KEi, Ni --> 290 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 292 IKE_SA_INIT 294 Up to this step, this work introduces no change to IKEv2. 296 3.2. IKE_AUTH 298 Next, the network devices perform an IKE_AUTH exchange defined in 299 IKEv2 [RFC7296]. The SA payloads contain the security policies for a 300 key and the associated parameters (as defined in Header and Payload 301 Formats (Section 6)), and the TS payloads contains traffic selectors 302 as defined in IKEv2 [RFC7296]. For the details of the exchange 303 please refer to IKE_AUTH in IKEv2 [RFC7296]. 305 Peer (Initiator) Peer (Responder) 306 -------------------- ------------------ 307 HDR, SK {IDi, [CERT,] [CERTREQ,] 308 [IDr,] AUTH, SAi2, TSi, TSr} --> 309 <-- HDR, SK {IDr, [CERT,] AUTH, 310 SAr2, TSi, TSr} 312 IKE_AUTH 314 In the IKE_AUTH exchange, the Initiator proposes one or more sets of 315 policies for the key used for securing a routing protocol in the 316 SAi2. The SA payload indicates that the supported policies 317 associated with the key are being proposed. The Responder returns 318 the one policy contained in SAr2 that it accepts. Based on this 319 policy, appropriate keying material is derived from the existing 320 shared keying material. At the successful conclusion of the IKE_AUTH 321 exchange, the initiator and responder have agreed upon a single set 322 of policy and keying material for a particular routing protocol. 324 3.3. CREATE_CHILD_SA 326 The network devices may then destroy the state associated with the 327 IKEv2 SA, continuing to use the RP policy and keying material, or 328 they may choose to retain them for further usages. Note that this 329 policy differs from IKEv2/IPsec, where the deletion of the IKEv2 SA 330 necessitates the deletion of the IPsec SAs. If both the network 331 devices choose to retain them, they may use the IKEv2 SA to 332 subsequently agree upon replacement policy for the same RP, or agree 333 upon the policy and keying material for another routing protocol. 335 Either case will require the use of the IKEv2 CREATE_CHILD_SA 336 exchange as defined in IKEv2 [RFC7296]. 338 A CREATE_CHILD_SA exchange therefore can be triggered in order to 340 1. Rekey an antique RP master key and establish a new equivalent 341 one, 343 2. Generate needed keying material for a newly executed routing 344 protocol based on an existing SA, or 346 3. Rekey an IKEv2 SA and establish a new equivalent IKEv2 SA. 348 Peer (Initiator) Peer (Responder) 349 -------------------- ------------------ 350 HDR, SK {[N], SA, Ni, [KEi], 351 [TSi, TSr]} --> 352 <-- HDR, SK {SA, Nr, [KEr], 353 [TSi, TSr]} 355 CREATE_CHILD_SA 357 A CREATE_CHILD_SA exchange MAY be initiated by either end of the SA 358 after the initial exchanges are completed. All messages in a 359 CREATE_CHILD_SA exchange are cryptographically protected using the 360 cryptographic algorithms and keys negotiated in the initial exchange. 362 For details on the exchange, refer to the CREATE_CHILD_SA exchange as 363 defined in IKEv2 [RFC7296]. 365 3.4. INFORMATIONAL 367 The IKEv2 INFORMATIONAL exchange is also useful for deleting specific 368 IKEv2 SAs or sending status information. The Notify (N) and Delete 369 (D) payloads are as those defined by IKEv2 [IKEV2-PARAMS]. For 370 example, if the Responder refused to accept one of Proposals sent by 371 the Initiator, it would return an INFORMATIONAL exchange of type 372 NO_PROPOSAL_CHOSEN instead of the response to CREATE_CHILD_SA. 374 Peer (Initiator) Peer (Responder) 375 ------------------- ------------------ 376 HDR, SK {[N,] [D,] ... } --> 377 <-- HDR, SK {[N,] [D,] ... } 379 INFORMATIONAL 381 4. Operation Details 383 4.1. General 385 IKEv2 is used to dynamically derive keying material information 386 between the two network devices trying to establish or maintain a 387 routing protocol neighbor adjacency. Typically network devices 388 running the routing protocols establish neighbor adjacencies at the 389 routing protocol level. These routing protocols may run different 390 security algorithms that provide transport level security for the 391 protocol neighbor adjacencies. Depending on the security algorithm 392 used, the routing protocols are configured with security algorithm 393 specific keys that are either long term keys or short term session 394 keys. These keys are specific to the security algorithms used to 395 enforce transport level security for the routing protocols. 397 A routing protocol causes IKEv2 to execute when it needs keying 398 material to establish neighbor adjacency. This can be as a result of 399 the routing protocol neighbor being configured, neighbor changed or 400 updated, a local rekey policy decision, or some other event dictated 401 by the implementation. The keying material would allow the network 402 devices to then independently generate the same key and establish an 403 IKEv2 session between them. This is typically done by the Initiator 404 (IKEv2 speaker) initiating an IKEv2 IKE_SA_INIT exchange mentioned in 405 the section 2.1 towards its IKEv2 peer. As part of IKEv2_INIT 406 exchange, IKEv2 will send a message to the peer's IKEv2 port. The 407 format of the message is explained in Section 6. The procedure to 408 exchange key information is explained in Section 6. Once the keying 409 material information is successfully exchanged by both of the IKEv2 410 speakers, the IKEv2 neighbor adjacency may be torn down or kept 411 around as explained in Section 6. 413 The master key data received from IKEv2 peers is stored in the 414 separate Key Management Database known as KMDB. KMDB follows the 415 guidelines in Database of Long Lived Symmetric Cryptographic Keys 416 [RFC7210], and each entry consists of Key specific information, 417 Security algorithm to which the Key is applicable to, Routing 418 Protocol Clients of interest, and the announcing KMP Peer. KMDB is 419 also used to notify the routing protocols about the key updates. 420 Typically keying material information is exchanged whenever a routing 421 protocol is about to create a new neighbor adjacency. This is 422 considered as an Initial Key exchange mode. Keying material 423 information is also exchanged to refresh existing key data on an 424 already existing neighbor adjacency. This is considered as Key 425 rollover exchange mode. The following sections describes their 426 detail behavior. 428 4.2. Initial Key Specific Data Exchange 430 Routing protocols informs IKEv2 of its new neighbor adjacency. It 431 does so by creating a local entry in KMDB which consists of a 432 Security algorithm, Key specific information, routing protocol client 433 and the routing protocol neighbor. Upon a successful creation of 434 such an entry IKEv2 initiates KMP peering with the neighbor and 435 starts an initial IKE_SA_INIT exchange explained in Section 3.1 436 followed by the RP_AUTH exchanged explained in Section 3.2. Once the 437 key related information is successfully exchanged, KMDB may invoke 438 the routing protocol client to provide key specific information 439 updates if any. 441 4.3. Key Selection, Rollover and Protocol Interaction 443 A routing protocol may need to perform the key selection and rollover 444 in cooperation with KMDB. Such a procedure is described in Section 3 445 of Database of Long-Lived Symmetric Cryptographic Keys [RFC7210]. 446 Details of how RP interact with KMDB and deals with multiple keys 447 during rollover are also described in that section. When a routing 448 protocol uses TCP-AO to secure its message exchanges, conditions 449 could be a little more complex. Typically, a TCP-AO implementation 450 has its own key tables. TCP-AO may only carry out key management 451 operations on the key tables if the key information maintained in 452 KDMB needs not to be updated. In 453 [I-D.chunduri-karp-using-ikev2-with-tcp-ao], a Gatekeeper (GK) 454 mechanism is provided to orchestrate the key management operations on 455 the TCP-AO key tables and KMDB. 457 5. Key Management Database 459 Protocol interaction between KMP and its client routing protocols is 460 typically done using KMDB. Routing protocols may be able to update 461 KMDB by performing key selection and rollover operations. During a 462 key selection, if there is no appropriate key found in the conceptual 463 database, as a part of the KMDB update, IKEv2 is initiated to connect 464 with its appropriate IKEv2 peer so as to generate a new key. When a 465 key needs to be revoked, it is also the responsibility of IKEv2 to 466 inform its peer to guarantee the synchronization of the databases on 467 the both sides. In addition, when a key is obsoleted for some 468 reasons when it is being used by a client routing protocol, the 469 routing protocol may need to be informed of this update. For the 470 routing protocols which using TCP-AO to secure their message 471 exchanges, a Gatekeeper mechanism is provided to trigger the update 472 of keys and manage the key revocation 473 [I-D.chunduri-karp-using-ikev2-with-tcp-ao]. 475 6. Header and Payload Formats 477 The protocol defined in this memo uses IKEv2 payload definitions. 478 However, new security policy definitions are described to support 479 security transforms and policy defined by routing protocol documents. 481 6.1. Header and Payload Formats for TCP-AO 483 6.1.1. Security Association Payload for TCP-AO 485 The TCP Authentication Option (TCP-AO) [RFC5925] is primarily 486 intended for BGP and other TCP-based routing protocols. In order for 487 IKEv2 to negotiate TCP-AO policy, a new Security Protocol Identifier 488 needs to be defined in the IANA registry for "IKEv2 Security Protocol 489 Identifiers" Magic Numbers' for ISAKMP Protocol [IKEV2-PROTOCOL-IDS]. 490 This memo proposes adding a new Protocol Identifier to the table, 491 with a Protocol Name of "TCP_AO" and a value of 6. 493 The Security Association (SA) payload contains a list of Proposals, 494 which describe one or more sets of policies that a network device is 495 willing to use to protect a routing protocol. In the Initiator's 496 message, the SAi2 payload contains a list of Proposal payloads (as 497 defined in the next sections), each of which contains a single set of 498 policy that can be applied to the packets described in the Traffic 499 Selector (TS) payloads in the same exchange. Each set of policy is 500 given a particular "Proposal Number" uniquely identifying this set of 501 policy. 503 The responder includes a single Proposal payload in it's SA policy, 504 which denotes the choice it has made amongst the initiator's list of 505 Proposals. Any attributes of a selected transform MUST be returned 506 unmodified as explained in IKEv2 [RFC7296] section 3.3.6. The 507 initiator of an exchange MUST check that the accepted offer is 508 consistent with one of its proposals, and if not MUST terminate the 509 exchange. 511 6.1.1.1. Transforms Substructures for TCP-AO 513 Each Proposal has a list of Transform (T) substructures, each of 514 which describe a particular set of cryptographic policy choices. A 515 TCP-AO proposal uses the INTEG transform to negotiate the MKT Message 516 Authentication Code (MAC) algorithm. Cryptographic Algorithms for 517 TCP-AO [RFC5926] describes HMAC-SHA-1-96, AES-128-CMAC-96, which map 518 to the existing INTEG transform IDs of AUTH_HMAC_SHA1_96 and 519 AUTH_AES_CMAC_96 respectively. The use of each INTEG algorithm 520 implies the use of a specific KDF (deriving session keys from a 521 master key), and so the choice of a particular INTEG transform ID 522 also specifies the required KDF transform. This will be true for 523 every transform ID used with TCP-AO, as required in RFC 5926 (see 524 Section 3.2 where the "KDF_Alg" is a fixed element of a MAC algorithm 525 definition for TCP-AO). 527 A TCP-AO proposal also requires a new type of transform, which 528 describes whether TCP options are to be protected by the integrity 529 algorithm. This memo proposes adding a new Transform Type in the 530 IANA registry for "Transform Type Values" [IKEV2-TRANSFORM-TYPES] 532 +-------+---------------------------------+ 533 |Number | Name | 534 +-------+---------------------------------+ 535 | 0 |Options Not Integrity Protected | 536 | 1 |Options Integrity Protected | 537 +-------+--------------------------------- 539 Figure 2: Transform Type 6 - TCP Authentication Option Transform IDs 541 The TCP-AO KeyID is sent in the SPI field of an IKEv2 proposal. A 542 KeyID for TCP-AO has the same purpose as an IPsec SPI value, so it is 543 natural to place it in this portion of the proposal. If the KeyID 544 values in a responder's Proposal does not mach the KeyID values 545 initiator's Proposal, then they have chosen to use different KeyID 546 values to represent the same master key and associated proposal 547 policy. This is consistent with how IPsec uses the SPI value, and 548 the semantic of initiator and responder using different SendIDs is 549 supported by RFC 5925. 551 The following table shows the Transforms that can be negotiated for a 552 TCP-AO protocol. 554 Protocol Mandatory Types Optional Types 555 --------------------------------------------------- 556 TCP-AO INTEG, TCP D-H 558 Figure 3: Mandatory and Optional Transforms for TCP-AO 560 6.1.1.2. Example Proposal Exchange 562 Figure 4 shows an example of IKEv2 SA Payload including a single 563 Proposal sent in the first message of an IKE_AUTH or CREATE_CHILD_SA 564 exchange. It indicates a willingness to use either of the two MAC 565 algorithms defined in RFC 5926, and is willing to either protect TCP 566 options or not. The SPI value represents the new SendID it is 567 associating with the TCP-AO Master Key Tuple (MKT) policy being 568 negotiated. 570 SA Payload 571 | 572 +--- Proposal #1 ( Proto ID = TCP-AO(T6), SPI size = 1, 573 | 4 transforms, SPI = 0x01 ) 574 | 575 +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 576 +-- Transform INTEG ( Name = AUTH_AES_CMAC_96 ) 577 +-- Transform TCP ( Name = PROTECT_OPTIONS ) 578 +-- Transform TCP ( Name = NO_PROTECT_OPTIONS ) 580 Figure 4: Example Initiator SA Payload for TCP-AO 582 The responder will record the SPI value to be the RecvID of the MKT. 583 It chooses its own SendID value, one of each Transform type, and 584 returns this policy in the response message. For example, if the 585 responder chose HMAC-SHA-1-96 and chose to protect the TCP options, 586 the corresponding SA payload would be: 588 SA Payload 589 | 590 +--- Proposal #1 ( Proto ID = TCP-AO(6), SPI size = 1, 591 | 2 transforms, SPI = 0x11 ) 592 | 593 +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) 594 +-- Transform TCP ( Name = PROTECT_OPTIONS ) 596 Figure 5: Example Responder SA Payload for TCP-AO 598 In this example, the Proposal responder chose to use a different SPI 599 value (0x11) as its SendID. This is possible because Section 2.2 of 600 [RFC5925] declares that "KeyID values MAY be the same in both 601 directions of a connection, but do not have to be and there is no 602 special meaning when they are." 604 6.1.2. Derivation of TCP-AO Keying Material 606 Each TCP-AO MAC algorithm specification in Section 3.2 of Crypto for 607 TCP-AO [RFC5926] defines the Key_Length as a number of bits 608 needed as keying material for the MAC algorithm. 610 6.2. Security Association Payload for BFD 612 In order for IKEv2 to negotiate BFD authentication policy, a new 613 Security Protocol Identifier needs to be defined in the IANA registry 614 for "IKEv2 Security Protocol Identifiers" Magic Numbers' for ISAKMP 615 Protocol [IKEV2-PROTOCOL-IDS]. This memo proposes adding a new 616 Protocol Identifier to the table, with a Protocol Name of "BFD" and a 617 value of 7. 619 6.2.1. Transforms Substructures for BFD Authentication 621 The base BFD specification [RFC5880] defines five authentication 622 mechanisms: Password, Keyed MD5, Meticulous Keyed MD5, Keyed SHA1, 623 and Meticulous Keyed SHA1. Because Password does not use keys, the 624 support of this mechanism is out of the scope of this work. In the 625 other four mechanisms, Keyed MD5 and Meticulous Keyed MD5 use MD5 as 626 the Message Authentication Code (MAC) algorithm, while Keyed SHA1 and 627 Meticulous Keyed SHA1 use SHA1. In 628 [I-D.ietf-bfd-generic-crypto-auth], a generic authentication 629 mechanism and a generic meticulous authentication mechanism which can 630 support various MAC algorithms is proposed. 632 Therefore, a BFD proposal also requires a new type of transform to 633 identify the type of BFD authentication. This memo proposes adding a 634 new Transform Type in the IANA registry for "Transform Type 635 Values"[IKEV2-TRANSFORM-TYPES] 637 +-------+---------------------------------+ 638 |Number | Name | 639 +-------+---------------------------------+ 640 | 0 |Base Authentication | 641 | 1 |Base Meticulous Authentication | 642 | 2 |Generic Authentication | 643 | 3 |Generic Meticulous Authentication| 644 +-------+---------------------------------+ 646 Figure 6: Transform Type 7 - BFD Authentication Option Transform IDs 648 Base Authentication in Figure 6 indicates the keyed (MD5 or SHA-1) 649 authentication mechanism defined in the base BFD specification 650 [RFC5880]. Base Meticulous Authentication indicates the meticulous 651 keyed (MD5 or SHA-1) authentication mechanism defined in the base BFD 652 specification. Generic Authentication and Generic Meticulous 653 Authentication indicate the generic keyed authentication and the 654 generic keyed meticulous authentication mechanisms defined in 655 [I-D.ietf-bfd-generic-crypto-auth] respectively. 657 A BFD proposal uses INTEG transforms to negotiate Message 658 Authentication Code (MAC) algorithms. In the base BFD [RFC5880], 659 keyed MD5 and keyed SHA-1 are adopted. The two algorithms can be 660 identified using existing INTEG transform IDs of AUTH_HMAC_MD5_96 and 661 AUTH_HMAC_SHA1_96 respectively. In [I-D.ietf-bfd-hmac-sha], it is 662 specified that a BFD using the authentication mechanisms defined in 663 [I-D.ietf-bfd-generic-crypto-auth] MUST support HMAC-SHA-256 which 664 can be identified using existing INTEG transform IDs of 665 AUTH_HMAC_SHA2_256_128 [RFC4868]. 667 The BFD KeyID is sent in the SPI field of an IKEv2 proposal. Note 668 that according to [RFC5880], the length of KeyID is 8 bits. 670 Because in BFD the transport key is the same as the protocol master 671 key, no KDF needs to be negotiated. 673 The following figure shows the Transforms that can be negotiated for 674 a BFD implementation. 676 Protocol Mandatory Types Optional Types 677 --------------------------------------------------- 678 BFD BFD, INTEG D-H 680 Figure 7: Mandatory and Optional Transforms for BFD 682 6.3. Security Association Payload for RSVP-TE 684 In order for IKEv2 to negotiate RSVP-TE authentication policy, a new 685 Security Protocol Identifier needs to be defined in the IANA registry 686 for "IKEv2 Security Protocol Identifiers" Magic Numbers' for ISAKMP 687 Protocol [IKEV2-PROTOCOL-IDS]. This memo proposes adding a new 688 Protocol Identifier to the table, with a Protocol Name of "RSVP-TE" 689 and a value of 8. 691 6.3.1. Transforms Substructures for RSVP-TE Authentication 693 In the authentication mechanism for RSVP-TE [RFC2747], only HMAC-MD5 694 is mandated. Therefore, no INTG transform needs to be included in a 695 RSVP-TE proposal. 697 A RSVP-TE proposal requires a new type of transform, which indicates 698 whether the integrity handshake (which is used to collect the latest 699 sequence number associated with a key ID) is permitted. This memo 700 proposes adding a new Transform Type in the IANA registry for 701 "Transform Type Values" [IKEV2-TRANSFORM-TYPES] 703 +-------+---------------------------------+ 704 |Number | Name | 705 +-------+---------------------------------+ 706 | 0 |Not Allowed | 707 | 1 |Allowed | 708 +-------+---------------------------------+ 710 Figure 8: Transform Type 8 - RSVP-TE Transform IDs 712 The RSVP-TE KeyID is sent in the SPI field of an IKEv2 proposal. 714 The following figure shows the Transforms that can be negotiated for 715 a RSVP-TE implementation. 717 Protocol Mandatory Types Optional Types 718 --------------------------------------------------- 719 RSVP-TE RSVP-TE, D-H 721 Figure 9: Mandatory and Optional Transforms for BFD 723 6.4. Notify and Delete Payloads 725 A Notify Payload (IKEv2 [RFC7296] Section 3.10) or Delete Payload 726 (IKEv2 [RFC7296] Section 3.11) contains a Protocol ID field. The 727 Protocol ID is set to TCP_AO (6) when a notify message is relevant to 728 the TCP-AO KeyID value contained in the SPI field. Similarly, the 729 Protocol ID is set to BFD (7) when a notify message is relevant to 730 the BFD KeyID value contained in the SPI field, and the Protocol ID 731 is set to RSVP-TE (8) when a notify message is relevant to the RSVP- 732 TE KeyID value contained in the SPI field. 734 7. IANA Considerations 736 In order for IKEv2 to negotiate TCP-AO authentication policies, a new 737 Security Protocol Identifier needs to be defined in the IANA registry 738 for "IKEv2 Security Protocol Identifiers" Magic Numbers' for ISAKMP 739 Protocol [IKEV2-PROTOCOL-IDS]. IANA is requested to add a new 740 Protocol Identifier to the table, with a Protocol Name of "TCP-AO" 741 and a value of 6. A TCP-AO proposal also requires a new type of 742 transform, which describes whether TCP options are to be protected by 743 the integrity algorithm. This memo proposes adding a new Transform 744 Type 6 for this transform in the IANA registry for "Transform Type 745 Values". 747 In order for IKEv2 to negotiate BFD authentication policies, a new 748 Security Protocol Identifier needs to be defined in the IANA registry 749 for "IKEv2 Security Protocol Identifiers" Magic Numbers' for ISAKMP 750 Protocol [IKEV2-PROTOCOL-IDS]. IANA is requested to add a new 751 Protocol Identifier to the table, with a Protocol Name of "BFD" and a 752 value of 7. A BFD proposal also requires a new type of transform, 753 which identifies the type of BFD authentication mechanism. This memo 754 proposes adding a new Transform Type 7 in the IANA registry for 755 "Transform Type Values". 757 In order for IKEv2 to negotiate RSVP-TE authentication policies, a 758 new Security Protocol Identifier needs to be defined in the IANA 759 registry for "IKEv2 Security Protocol Identifiers" Magic Numbers' for 760 ISAKMP Protocol [IKEV2-PROTOCOL-IDS]. IANA is requested to add a new 761 Protocol Identifier to the table, with a Protocol Name of "RSVP-TE" 762 and a value of 8. A RSVP-TE proposal requires a new type of 763 transform, which indicates whether the integrity handshake (which is 764 used to collect the latest sequence number associated with a key ID) 765 is permitted. This memo proposes adding a new Transform Type 8 in 766 the IANA registry for "Transform Type Values". 768 8. Security Considerations 770 TBD 772 9. Acknowledgements 774 During the development of TCP-AO, Gregory Lebovitz noted that a 775 protocol based on an IKEv2 exchange would be a good automated key 776 management method for deriving a TCP-AO master key. 778 10. References 780 10.1. Normative References 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, 784 DOI 10.17487/RFC2119, March 1997, 785 . 787 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 788 Authentication", RFC 2747, DOI 10.17487/RFC2747, January 789 2000, . 791 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 792 384, and HMAC-SHA-512 with IPsec", RFC 4868, 793 DOI 10.17487/RFC4868, May 2007, 794 . 796 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 797 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 798 . 800 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 801 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 802 June 2010, . 804 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 805 for the TCP Authentication Option (TCP-AO)", RFC 5926, 806 DOI 10.17487/RFC5926, June 2010, 807 . 809 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 810 Kivinen, "Internet Key Exchange Protocol Version 2 811 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 812 2014, . 814 10.2. Informative References 816 [DH] Diffie, W. and M. Hellman, "New Directions in 817 Cryptography", IEEE Transactions on Information 818 Theory, V.IT-22 n. 6, June 1977. 820 [I-D.chunduri-karp-using-ikev2-with-tcp-ao] 821 Chunduri, U., Tian, A., and J. Touch, "A framework for RPs 822 to use IKEv2 KMP", draft-chunduri-karp-using-ikev2-with- 823 tcp-ao-06 (work in progress), February 2014. 825 [I-D.ietf-bfd-generic-crypto-auth] 826 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 827 "BFD Generic Cryptographic Authentication", draft-ietf- 828 bfd-generic-crypto-auth-06 (work in progress), April 2014. 830 [I-D.ietf-bfd-hmac-sha] 831 Zhang, D., Bhatia, M., Manral, V., and M. Jethanandani, 832 "Authenticating BFD using HMAC-SHA-2 procedures", draft- 833 ietf-bfd-hmac-sha-05 (work in progress), July 2014. 835 [IKEV2-PARAMS] 836 "Internet Key Exchange Version 2 (IKEv2) Parameters", 837 . 840 [IKEV2-PROTOCOL-IDS] 841 "'Magic Numbers' for ISAKMP Protocol", 842 . 845 [IKEV2-TRANSFORM-TYPES] 846 "'Magic Numbers' for ISAKMP Protocol", 847 . 850 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 851 BGP, LDP, PCEP, and MSDP Issues According to the Keying 852 and Authentication for Routing Protocols (KARP) Design 853 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 854 . 856 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 857 "Database of Long-Lived Symmetric Cryptographic Keys", 858 RFC 7210, DOI 10.17487/RFC7210, April 2014, 859 . 861 Authors' Addresses 863 Mahesh Jethanandani 864 California 865 USA 867 Email: mjethanandani@gmail.com 869 Brian Weis 870 Cisco Systems 871 170 W. Tasman Drive 872 San Jose, California 95134 873 USA 875 Phone: +1 (408) 526-4796 876 Email: bew@cisco.com 878 Keyur Patel 879 Arrcus 880 California 881 USA 883 Email: keyur@arrcus.com 885 Dacheng Zhang 886 Huawei 887 Beijing 888 China 890 Email: zhangdacheng@huawei.com 892 Sam Hartman 893 Painless Security 895 Email: hartmans@painless-security.com 896 Uma Chunduri 897 Ericsson Inc. 898 300 Holger Way 899 San Jose, California 95134 900 USA 902 Email: uma.chunduri@ericsson.com 904 Albert Tian 905 Ericsson Inc. 906 300 Holger Way 907 San Jose, California 95134 908 USA 910 Email: albert.tian@ericsson.com 912 Joe Touch 913 USC/ISI 914 4676 Admiralty Way 915 Marina del Rey, California 90292-6695 916 USA 918 Email: touch@isi.edu