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