idnits 2.17.1 draft-ietf-dime-ikev2-psk-diameter-11.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2011) is 4546 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: 'Responder-Identity' is mentioned on line 463, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-10 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 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 V. Cakulev 3 Internet-Draft Alcatel Lucent 4 Intended status: Standards Track A. Lior 5 Expires: May 17, 2012 Bridgewater Systems 6 S. Mizikovsky 7 Alcatel Lucent 8 November 14, 2011 10 Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter 11 Server Interaction 12 draft-ietf-dime-ikev2-psk-diameter-11.txt 14 Abstract 16 The Internet Key Exchange protocol version 2 (IKEv2) is a component 17 of the IPsec architecture and is used to perform mutual 18 authentication as well as to establish and to maintain IPsec security 19 associations (SAs) between the respective parties. IKEv2 supports 20 several different authentication mechanisms, such as the Extensible 21 Authentication Protocol (EAP), certificates, and shared key. 23 Diameter interworking for Mobile IPv6 between the Home Agent, as a 24 Diameter client, and the Diameter server has been specified. 25 However, that specification focused on the usage of EAP and did not 26 include support for shared key based authentication available with 27 IKEv2. This document specifies the IKEv2 Server to the Diameter 28 server communication when the IKEv2 Peer authenticates using the 29 Internet Key Exchange v2 with Shared Key. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 17, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Application Identifier . . . . . . . . . . . . . . . . . . . . 6 68 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Support for IKEv2 and Shared Keys . . . . . . . . . . . . 7 70 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 8 71 4.2.1. Session-Termination-Request/Answer . . . . . . . . . . 8 72 4.2.2. Abort-Session-Request/Answer . . . . . . . . . . . . . 9 73 5. Command Codes for Diameter IKEv2 with SK . . . . . . . . . . . 10 74 5.1. IKEv2-SK-Request (IKESKR) Command . . . . . . . . . . . . 10 75 5.2. IKEv2-SK-Answer (IKESKA) Command . . . . . . . . . . . . . 11 76 6. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 13 77 6.1. IKEv2-Nonces . . . . . . . . . . . . . . . . . . . . . . . 13 78 6.1.1. Ni . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1.2. Nr . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.2. IKEv2-Identity . . . . . . . . . . . . . . . . . . . . . . 13 81 6.2.1. Initiator-Identity . . . . . . . . . . . . . . . . . . 13 82 6.2.2. Responder-Identity . . . . . . . . . . . . . . . . . . 14 83 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 15 84 8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 17 87 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 17 89 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 18 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 The Internet Key Exchange version 2 (IKEv2) protocol [RFC5996] is 99 used to mutually authenticate two parities and to establish a 100 security association (SA) that can be used to efficiently secure the 101 communication between the IKEv2 Peer and Server, for example, using 102 Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication 103 Header (AH) [RFC4302]. The IKEv2 protocol allows several different 104 mechanisms for authenticating a IKEv2 Peer to be used, such as the 105 Extensible Authentication Protocol, certificates, and shared key. 107 From a service provider perspective, it is important to ensure that a 108 user is authorized to use the services. Therefore, the IKEv2 Server 109 must verify that the IKEv2 Peer is authorized for the requested 110 services possibly with the assistance of the operator's Diameter 111 servers. [RFC5778] defines the home agent as a Diameter client to 112 the Diameter server communication when the mobile node authenticates 113 using the IKEv2 protocol with the Extensible Authentication Protocol 114 (EAP) [RFC3748] or using the Mobile IPv6 Authentication Protocol 115 [RFC4285]. This document specifies the IKEv2 Server to the Diameter 116 server communication when the IKEv2 Peer authenticates using the 117 Internet Key Exchange v2 with Shared Key. 119 Figure 1 depicts the reference architecture for this document. 121 +--------+ 122 |Diameter| 123 |Server | 124 +--------+ 125 ^ 126 Back-End | IKEv2 Server<->HAAA Server 127 Support | Interaction 128 Protocol | (this document) 129 v 130 +---------+ +---------------+ 131 | IKEv2 | Front-End Protocol |IKEv2 Server/ | 132 | Peer |<-------------------->|Diameter Client| 133 +---------+ IKEv2 +---------------+ 135 Figure 1: Architecture Overview 137 An example use case for this architecture is Mobile IPv6 deployment 138 in which the Mobile IPv6 signaling between the Mobile Node and the 139 Home Agent is protected using IPsec. The Mobile node acts as the 140 IKEv2 Peer and the Home Agent acts as an IKEv2 server. In this use 141 case Internet Key Exchange v2 (IKEv2) with shared key based initiator 142 authentication is used for the setup of the IPsec SAs. The HA 143 obtains the shared key using the Diameter application specified in 144 this document. 146 This document does not assume that the IKEv2 Server has the shared 147 key (SK) with the IKEv2 Peer. Instead it assumes that the SK 148 provided to the IKEv2 Peer, as well as the SK delivered to the IKEv2 149 Server by the Diameter Server, are established or derived using the 150 same rules. Furthermore, it assumes that these rules are agreed to 151 by the external protocol on a Peer side providing the key to the 152 IKEv2 Peer, and on the Diameter Server side providing the key to the 153 IKEv2 Server. This document allows for the SK to be obtained for a 154 specific IKEv2 session and exchanged between IKEv2 Server and the 155 Home Authentication, Authorization and Accounting (HAAA) server. The 156 protocol provides IKEv2 attributes to allow the HAAA to compute the 157 SK specific for the session if desired (see Section 10). This is 158 accomplished through the use of a new Diameter application 159 specifically designed for performing IKEv2 authorization decisions. 160 This document focuses on the IKEv2 server, as a Diameter client, 161 communicating to the Diameter server, and specifies the Diameter 162 application needed for this communication. Other protocols 163 leveraging this Diameter application MAY specify their own SK 164 derivation scheme For example see [X.S0047] and [X.S0058]. This 165 document specifies the default procedure for derivation of the SK 166 used in IKEv2 authentication when protocols leveraging this Diameter 167 application do not specify their own derivation procedure. Selection 168 of either default or other SK derivation procedure is done by the 169 external protocol between the Peer side providing the key to the 170 IKEv2 Peer, and the Diameter Server, and is outside the scope of this 171 document. 173 2. Requirements notation 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119]. 179 2.1. Abbreviations 181 AH Authentication Header 183 AVP Attribute Value Pair 185 EAP Extensible Authentication Protocol 187 ESP Encapsulating Security Payload 189 ESP Home Authentication, Authorization and Accounting 191 IKEv2 Internet Key Exchange version 2 193 NAI Network Access Identifier 195 PSK Pre-Shared Key 197 SA Security Association 199 SK Shared Key 201 SPI Security Parameter Index 203 3. Application Identifier 205 This specification defines a new Diameter application and its 206 respective Application Identifier: 208 Diameter IKE SK (IKESK) TBD1 by IANA 210 The IKESK Application Identifier is used when the IKEv2 Peer is to be 211 authenticated and authorized using IKEv2 with SK-based 212 authentication. 214 4. Protocol Description 216 4.1. Support for IKEv2 and Shared Keys 218 When IKEv2 is used with SK-based initiator authentication, the 219 Diameter commands IKEv2-SK-Request/Answer defined in this document 220 are used between IKEv2 server and a Home AAA server (HAAA) to 221 authorize the IKEv2 Peer for the services. Upon receiving the 222 IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the 223 information received in IDi [RFC5996] to identify the IKEv2 Peer and 224 the SPI if available to determine the correct SK for this IKEv2 Peer. 225 If there is no SK found associated with this IKEv2 Peer, the IKEv2 226 Server MUST send an Authorize-Only (Auth-Request-Type set to 227 "Authorize-Only") Diameter IKEv2-SK-Request message to the HAAA to 228 obtain the SK. If the IDi payload extracted from the IKE_AUTH 229 message contains an identity that is meaningful for the Diameter 230 infrastructure, such as a Network Access Identifier (NAI), it SHALL 231 be used by the IKEv2 Server to populate the User-Name AVP in the 232 Diameter message. Otherwise it is out of scope of this document how 233 the IKEv2 server maps the value received in IDi payload to the User- 234 Name AVP and whether the User-Name AVP is included or not in the 235 IKEv2-SK-Request message. The IKEv2 Server SHALL also include in the 236 same Diameter message the IKEv2-Nonces AVP with the initiator and 237 responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange. 238 Finally, the IKEv2 Server SHALL include in the IKEv2-SK-Request 239 message the IKEv2-Identity AVP. Initiator-Identity AVP SHALL be 240 populated with the IDi field extracted from the IKE_AUTH message. If 241 IDr payload was included in the IKE_AUTH message received from the 242 IKEv2 Peer, the IKEv2 Server SHALL also include Responder-Identity 243 AVP populated with the received IDr. 245 The IKEv2 Server sends the IKEv2-SK-Request message to the IKEv2 246 Peer's HAAA. The Diameter message is routed to the correct HAAA as 247 per [RFC3588]. 249 Upon receiving Diameter IKEv2-SK-Request message from the IKEv2 250 Server, the HAAA SHALL use the User-Name AVP (if present) and/or 251 Initiator-Identity AVP to retrieve the associated keying material. 252 When the default SK generation procedure specified in this document 253 is used, the Peer side that provides the SK to the IKEv2 Peer, as 254 well as the Diameter Server, SHALL use the same SK derivation which 255 follows the methodology similar to that specified in Section 3.1 of 256 [RFC5295], specifically: 258 SK = KDF(PSK, key label | "\0" | Ni | Nr | IDi | length) 260 Where: 262 o KDF is the default key derivation function based on HMAC-SHA-256 263 as specified in Section 3.1.2 of [RFC5295]. 265 o Pre-Share Key (PSK) is the key available to the protocol 266 leveraging this Diameter application, e.g., the long term shared 267 secret, or the Extended Master Session Key (EMSK) as the result of 268 prior EAP authentication etc. Selection of this value is left up 269 to the protocol leveraging this Diameter application. 271 o Key label is set to 'sk4ikev2@ietf.org'. 273 o | denotes concatenation 275 o "\0" is a NULL octet (0x00 in hex) 277 o Length is a 2-octet unsigned integer in network byte order of the 278 output key length in octets. 280 When applications using this protocol define their own SK generation 281 algorithm it is strongly RECOMMENDED that the nonces Ni and Nr are 282 used in the computation. It is also RECOMMENDED that IDi be used. 283 IDr SHOULD NOT be used in the SK generation algorithm. Applications 284 that want to use IDr in the computation should take into 285 consideration that the IDr asserted by the IKEv2 peer may not be the 286 same as the IDr returned by the IKEv2 responder. This mismatch will 287 result in different SKs being generated. The HAAA returns the SK to 288 the IKEv2 Server using the Key AVP as specified in 289 [I-D.ietf-dime-local-keytran]. 291 Once the IKEv2 Server receives the SK from the HAAA, the IKEv2 Server 292 verifies the IKE_AUTH message received from the IKEv2 Peer. If the 293 verification of AUTH is successful, the IKEv2 Server sends the IKE 294 message back to the IKEv2 Peer. 296 4.2. Session Management 298 The HAAA may maintain Diameter session state or may be stateless. 299 This is indicated by the presence or absence of the Auth-Session- 300 State AVP included in the Answer message. The IKEv2 Server MUST 301 support the Authorization Session State Machine defined in [RFC3588]. 303 4.2.1. Session-Termination-Request/Answer 305 In the case where HAAA is maintaining session state, when the IKEv2 306 Server terminates the SA it SHALL send a Session-Termination-Request 307 (STR) message [RFC3588] to inform the HAAA that the authorized 308 session has been terminated. 310 The Session-Termination-Answer (STA) message [RFC3588] is sent by the 311 HAAA to acknowledge the notification that the session has been 312 terminated. 314 4.2.2. Abort-Session-Request/Answer 316 The Abort-Session-Request (ASR) message [RFC3588] is sent by the HAAA 317 to the IKEv2 Server to terminate the authorized session. When the 318 IKEv2 Server receives the ASR message, it MUST delete the 319 corresponding IKE_SA and all CHILD_SAs set up through it. 321 The Abort-Session-Answer (ASA) message [RFC3588] is sent by the IKEv2 322 Server in response to an ASR message. 324 5. Command Codes for Diameter IKEv2 with SK 326 This section defines new Command-Code values that MUST be supported 327 by all Diameter implementations conforming to this specification. 329 +------------------+---------+------+-------------+-------------+ 330 | Command-Name | Abbrev. | Code | Reference | Application | 331 +------------------+---------+------+-------------+-------------+ 332 | IKEv2-SK-Request | IKESKR | TBD2 | Section 5.1 | IKESK | 333 | | | | | | 334 | IKEv2-SK-Answer | IKESKA | TBD2 | Section 5.2 | IKESK | 335 +------------------+---------+------+-------------+-------------+ 337 Table 1: Command Codes 339 5.1. IKEv2-SK-Request (IKESKR) Command 341 The IKEv2-SK-Request message, indicated with the Command-Code set to 342 TBD2 and the 'R' bit set in the Command Flags field, is sent from the 343 IKEv2 Server to the HAAA to initiate IKEv2 with SK authorization. In 344 this case, the Application-ID field of the Diameter Header MUST be 345 set to the Diameter IKE SK Application ID (value of TDB1). 347 Message format 349 ::= < Diameter Header: TBD2, REQ, PXY > 350 < Session-Id > 351 { Auth-Application-Id } 352 { Origin-Host } 353 { Origin-Realm } 354 { Destination-Realm } 355 { Auth-Request-Type } 356 [ Destination-Host ] 357 [ NAS-Identifier ] 358 [ NAS-IP-Address ] 359 [ NAS-IPv6-Address ] 360 [ NAS-Port ] 361 [ Origin-State-Id ] 362 [ User-Name ] 363 [ Key-SPI ] 364 { IKEv2-Identity } 365 [ Auth-Session-State ] 366 { IKEv2-Nonces } 367 * [ Proxy-Info ] 368 * [ Route-Record ] 369 ... 370 * [ AVP ] 372 The IKEv2-SK-Request message MUST include a IKEv2-Nonces AVP 373 containing the Ni and Nr nonces exchanged during initial IKEv2 374 exchange. The IKEv2-SK-Request message MAY contain a Key-SPI AVP 375 (Key-SPI AVP is specified in [I-D.ietf-dime-local-keytran]). If 376 included, it contains the Security Parameter Index (SPI) that HAAA 377 SHALL use, in addition to the other parameters (e.g., Initiator- 378 Identity), to identify the appropriate SK. The IKEv2-SK-Request 379 message MUST include IKEv2-Identity AVP. The Initiator-Identity AVP 380 SHALL contain IDi as received in IKE_AUTH message. Responder- 381 Identity AVP SHALL be included in the IKEv2-SK-Request message, if 382 IDr payload was included in the IKE_AUTH message received from the 383 IKEv2 Peer. If included, Responder-Identity AVP contains the 384 received IDr. 386 5.2. IKEv2-SK-Answer (IKESKA) Command 388 The IKEv2-SK-Answer (IKESKA) message, indicated by the Command-Code 389 field set to TBD2 and the 'R' bit cleared in the Command Flags field, 390 is sent by the HAAA to the IKEv2 Server in response to the IKESKR 391 command. In this case, the Application-ID field of the Diameter 392 Header MUST be set to the Diameter IKE SK Application ID (value of 393 TDB1). 395 Message format 397 ::= < Diameter Header: TBD2, PXY > 398 < Session-Id > 399 { Auth-Application-Id } 400 { Auth-Request-Type } 401 { Result-Code } 402 { Origin-Host } 403 { Origin-Realm } 404 [ User-Name ] 405 [ Key ] 406 [ Responder-Identity ] 407 [ Auth-Session-State ] 408 [ Error-Message ] 409 [ Error-Reporting-Host ] 410 * [ Failed-AVP ] 411 [ Origin-State-Id ] 412 * [ Redirect-Host ] 413 [ Redirect-Host-Usage ] 414 [ Redirect-Max-Cache-Time ] 415 * [ Proxy-Info ] 416 * [ Route-Record ] 417 ... 418 * [ AVP ] 420 If the authorization procedure is successful then the IKEv2-SK-Answer 421 message SHALL include the Key AVP as specified in 422 [I-D.ietf-dime-local-keytran]. The value of the Key-Type AVP SHALL 423 be set to IKEv2-SK (TBD3). The Keying-Material AVP SHALL contain the 424 SK. If Key-SPI AVP is received in IKEv2-SK-Request, Key-SPI AVP 425 SHALL be included in Key AVP. The Key-Lifetime AVP may be included 426 and if it is included then the associated key SHALL NOT be used by 427 the receiver of the answer if the lifetime has expired. Finally, 428 Responder-Identity AVP may be included. 430 6. Attribute Value Pair Definitions 432 This section defines new AVPs for the IKEv2 with SK. 434 6.1. IKEv2-Nonces 436 The IKEv2-Nonces AVP (Code TBD4) is of type Grouped and contains the 437 nonces exchanged between the IKEv2 Peer and the IKEv2 Server during 438 IKEv2 initial exchange. The nonces are used for SK generation. 440 IKEv2-Nonces ::= < AVP Header: TBD4> 441 {Ni} 442 {Nr} 443 *[AVP] 445 6.1.1. Ni 447 The Ni AVP (AVP Code TBD5) is of type OctetString and contains the 448 IKEv2 initiator nonce as contained in Nonce Data field. 450 6.1.2. Nr 452 The Nr AVP (AVP Code TBD6) is of type OctetString and contains the 453 IKEv2 responder nonce as contained in Nonce Data field. 455 6.2. IKEv2-Identity 457 The IKEv2-Identity AVP (Code TBD7) is of type Grouped and contains 458 the Initiator and possibly Responder identities as included in 459 IKE_AUTH message sent from the IKEv2 Peer to the IKEv2 Server. 461 IKEv2-Identity ::= < AVP Header: TBD7> 462 {Initiator-Identity} 463 [Responder-Identity] 464 *[AVP] 466 6.2.1. Initiator-Identity 468 The Initiator-Identity AVP (AVP Code TBD8) is of type Grouped and 469 contains the identity type and identification data of the IDi payload 470 of the IKE_AUTH message. 472 Initiator-Identity ::= < AVP Header: TBD8> 473 {ID-Type} 474 {Identification-Data} 476 *[AVP] 478 6.2.1.1. ID-Type 480 The ID-Type AVP (AVP Code TBD9) is of type Enumerated and contains 481 the ID type value of IDi payload of the IKE_AUTH message. 483 6.2.1.2. Identification-Data 485 The Identification-Data AVP (AVP Code TBD10) is of type OctetString 486 and contains the Identification Data field of IDi payload of the 487 IKE_AUTH message. 489 6.2.2. Responder-Identity 491 The Responder-Identity AVP (AVP Code TBD11) is of type Grouped and 492 contains the identity type and identification data of the IDr payload 493 of the IKE_AUTH message. 495 Responder-Identity ::= < AVP Header: TBD8> 496 {ID-Type} 497 {Identification-Data} 498 *[AVP] 500 6.2.2.1. ID-Type 502 The ID-Type AVP (AVP Code TBD9) is of type Enumerated and contains 503 the ID type value of IDr payload of the IKE_AUTH message. 505 6.2.2.2. Identification-Data 507 The Identification-Data AVP (AVP Code TBD10) is of type OctetString 508 and contains the Identification Data field of IDr payload of the 509 IKE_AUTH message. 511 7. AVP Occurrence Tables 513 The following tables present the AVPs defined or used in this 514 document and their occurrences in Diameter messages. Note that AVPs 515 that can only be present within a Grouped AVP are not represented in 516 this table. 518 The table uses the following symbols: 520 0: 522 The AVP MUST NOT be present in the message. 524 0+: 526 Zero or more instances of the AVP MAY be present in the message. 528 0-1: 530 Zero or one instance of the AVP MAY be present in the message. 532 1: 534 One instance of the AVP MUST be present in the message. 536 +-------------------+ 537 | Command-Code | 538 |---------+---------+ 539 AVP Name | IKESKR | IKESKA | 540 -------------------------------|---------+---------+ 541 Key | 0 | 0-1 | 542 Key-SPI | 0-1 | 0 | 543 IKEv2-Nonces | 1 | 0 | 544 IKEv2-Identity | 1 | 0 | 545 Responder-Identity | 0 | 0-1 | 546 +---------+---------+ 548 IKESKR and IKESKA Commands AVP Table 550 8. AVP Flag Rules 552 The following table describes the Diameter AVPs, their AVP Code 553 values, types, and possible flag values. The Diameter base [RFC3588] 554 specifies the AVP Flag rules for AVPs in Section 4.5. 556 +--------------------+ 557 | AVP Flag rules | 558 +----+---+------+----+ 559 AVP Defined | | |SHOULD|MUST| 560 Attribute Name Code in Value Type |MUST|MAY| NOT | NOT| 561 +---------------------------------------------+----+---+------+----+ 562 |Key TBD Note 1 Grouped | M | P | | V | 563 +---------------------------------------------+----+---+------+----+ 564 |Keying-Material TBD Note 1 OctetString| M | P | | V | 565 +---------------------------------------------+----+---+------+----+ 566 |Key-Lifetime TBD Note 1 Integer64 | M | P | | V | 567 +---------------------------------------------+----+---+------+----+ 568 |Key-SPI TBD Note 1 Unsigned32 | M | P | | V | 569 +---------------------------------------------+----+---+------+----+ 570 |Key-Type TBD Note 1 Enumerated | M | P | | V | 571 +---------------------------------------------+----+---+------+----+ 572 |IKEv2-Nonces TBD4 6.1 Grouped | M | P | | V | 573 +---------------------------------------------+----+---+------+----+ 574 |Ni TBD5 6.1.1 OctetString| M | P | | V | 575 +---------------------------------------------+----+---+------+----+ 576 |Nr TBD6 6.1.2 OctetString| M | P | | V | 577 +---------------------------------------------+----+---+------+----+ 578 |IKEv2-Identity TBD7 6.2 Grouped | M | P | | V | 579 +---------------------------------------------+----+---+------+----+ 580 |Initiator-Identity TBD8 6.2.1 Grouped | M | P | | V | 581 +---------------------------------------------+----+---+------+----+ 582 |ID-Type TBD9 6.2.1.1 Enumerated | M | P | | V | 583 +---------------------------------------------+----+---+------+----+ 584 |Identification-Data TBD10 6.2.1.2 OctetString| M | P | | V | 585 +---------------------------------------------+----+---+------+----+ 586 |Responder-Identity TBD11 6.2.2 Grouped | M | P | | V | 587 +---------------------------------------------+----+---+------+----+ 589 AVP Flag Rules Table 591 Note 1: Key, Keying-Material, Key-Type, Key-SPI and Key-Lifetime AVPs 592 are defined in [I-D.ietf-dime-local-keytran]. 594 9. IANA Considerations 596 Upon publication of this memo as an RFC, IANA is requested to assign 597 values as described in the following sections. 599 9.1. Command Codes 601 IANA is requested to allocate a command code value for the following 602 new command from the Command Code namespace defined in [RFC3588]. 604 Command Code | Value 605 ---------------------------------+------ 606 IKEv2-SK-Request/Answer | TBD2 608 9.2. AVP Codes 610 This specification requires IANA to register the following new AVPs 611 from the AVP Code namespace defined in [RFC3588]. 613 o IKEv2-Nonces - TBD4 615 o Ni - TBD5 617 o Nr - TBD6 619 o IKEv2-Identity - TBD7 621 o Initiator-Identity - TBD8 623 o ID-Type - TBD9 625 o Identification-Data - TBD10 627 o Responder-Identity - TBD11 629 The AVPs are defined in Section 6. 631 9.3. AVP Values 633 IANA is requested to create a new value for the Key-Type AVP. The 634 new value TBD3 signifies that IKEv2 SK is being sent. 636 9.4. Application Identifier 638 This specification requires IANA to allocate one new value "Diameter 639 IKE SK" from the Application Identifier namespace defined in 640 [RFC3588]. 642 Application Identifier | Value 643 -------------------------------+------ 644 Diameter IKE SK (IKESK) | TBD1 646 10. Security Considerations 648 The security considerations of the Diameter Base protocol [RFC3588] 649 are applicable to this document (e.g., it is expected that Diameter 650 protocol is used with security mechanism and that Diameter messages 651 are secured). 653 In addition, the assumption is that the IKEv2 Server and the Diameter 654 Server where the SK is generated are in a trusted relationship. 655 Hence, the assumption is that there is an appropriate security 656 mechanism to protect the communication between these servers. For 657 example the IKEv2 Server and the Diameter server would be deployed in 658 the same secure network or would utilize transport layer security as 659 specified in [RFC3588]. 661 The Diameter messages between the IKEv2 Server and the HAAA may be 662 transported via one or more AAA brokers or Diameter agents. In this 663 case, the IKEv2 Server to the Diameter server AAA communication is 664 hop-by-hop protected, hence relies on the security properties of the 665 intermediating AAA inter- connection networks, AAA brokers, and 666 Diameter agents. Furthermore, any agents that process IKEv2-SK- 667 Answer messages can see the contents of the Key AVP. 669 To mitigate the threat of exposing long lived PSK, this specification 670 expects that the HAAA derives and returns the associated SK to the 671 IKEv2 Server. Given that SK derivation is security-critical, for the 672 SK derivation this specification recommends the use of short lived 673 secrets, possibly based on a previous network access authentication, 674 if such secrets are available. To ensure key freshness and to limit 675 the key scope, this specification strongly recommends the use of 676 nonces included in IKEv2-SK-Request. The specifics of key derivation 677 depend on the security characteristics of the system that is 678 leveraging this specification (for example see [X.S0047] and 679 [X.S0058]), therefore this specification does not define how the 680 Diameter server derives required keys for these systems. For systems 681 and protocols that leverage this Diameter application but do not 682 specify the key derivation procedure, this document specifies the 683 default key derivation procedure that preserves expected security 684 characteristics. 686 11. References 688 11.1. Normative References 690 [I-D.ietf-dime-local-keytran] 691 Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute- 692 Value Pairs for Cryptographic Key Transport", 693 draft-ietf-dime-local-keytran-10 (work in progress), 694 May 2011. 696 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 697 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 699 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 700 December 2005. 702 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 703 RFC 4303, December 2005. 705 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 706 "Specification for the Derivation of Root Keys from an 707 Extended Master Session Key (EMSK)", RFC 5295, 708 August 2008. 710 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 711 "Internet Key Exchange Protocol Version 2 (IKEv2)", 712 RFC 5996, September 2010. 714 11.2. Informative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 720 Levkowetz, "Extensible Authentication Protocol (EAP)", 721 RFC 3748, June 2004. 723 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 724 Chowdhury, "Authentication Protocol for Mobile IPv6", 725 RFC 4285, January 2006. 727 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 728 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 729 Agent to Diameter Server Interaction", RFC 5778, 730 February 2010. 732 [X.S0047] 3GPP2: X.S0047, "Mobile IPv6 Enhancements", February 2009. 734 [X.S0058] 3GPP2: X.S0058, "WiMAX-HRPD Interworking: Core Network 735 Aspects", June 2010. 737 Authors' Addresses 739 Violeta Cakulev 740 Alcatel Lucent 741 600 Mountain Ave. 742 3D-517 743 Murray Hill, NJ 07974 744 US 746 Phone: +1 908 582 3207 747 Email: violeta.cakulev@alcatel-lucent.com 749 Avi Lior 750 Bridgewater Systems 751 303 Terry Fox Drive 752 Ottawa, Ontario K2K 3J1 753 Canada 755 Phone: +1 613-591-6655 756 Email: avi@bridgewatersystems.com 758 Semyon Mizikovsky 759 Alcatel Lucent 760 600 Mountain Ave. 761 3C-506 762 Murray Hill, NJ 07974 763 US 765 Phone: +1 908 582 0729 766 Email: Simon.Mizikovsky@alcatel-lucent.com