idnits 2.17.1 draft-ietf-dime-erp-17.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 (March 11, 2013) is 4026 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: 'ERP-Realm' is mentioned on line 297, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bournelle 3 Internet-Draft L. Morand 4 Intended status: Standards Track Orange Labs 5 Expires: September 12, 2013 S. Decugis 6 INSIDE Secure 7 Q. Wu 8 Huawei 9 G. Zorn 10 Network Zen 11 March 11, 2013 13 Diameter Support for the EAP Re-authentication Protocol (ERP) 14 draft-ietf-dime-erp-17.txt 16 Abstract 18 The EAP Re-authentication Protocol (ERP) defines extensions to the 19 Extensible Authentication Protocol (EAP) to support efficient re- 20 authentication between the peer and an EAP Re-authentication (ER) 21 server through a compatible authenticator. This document specifies 22 Diameter support for ERP. It defines a new Diameter ERP application 23 to transport ERP messages between an ER authenticator and the ER 24 server, and a set of new AVPs that can be used to transport the 25 cryptographic material needed by the re-authentication server. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Bootstrapping the ER Server . . . . . . . . . . . . . . . . . 6 67 5.1. Bootstrapping During the Initial EAP authentication . . . 6 68 5.2. Bootstrapping During the First Re-authentication . . . . . 8 69 6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 10 70 7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12 73 8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12 74 8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 12 76 8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 12 77 8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13 78 8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13 79 9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 10.1. Diameter Application Identifier . . . . . . . . . . . . . 13 83 10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.3. New Permanent Failures Result-Code AVP Values . . . . . . 14 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol 95 (ERP). It consists of the following steps: 97 Bootstrapping 99 A root key for re-authentication is derived from the Extended 100 Master Session Key (EMSK) created during EAP authentication 101 [RFC5295]. This root key is transported from the EAP server to 102 the ER server. 104 Re-authentication 106 A one-round-trip exchange between the peer and the ER server, 107 resulting in mutual authentication. To support the EAP 108 reauthentication functionality, ERP defines two new EAP codes - 109 EAP-Initiate and EAP-Finish. 111 This document defines how Diameter transports the ERP messages during 112 the re-authentication process. For this purpose, we define a new 113 Application Identifier for ERP, and re-use the Diameter EAP commands 114 (DER/DEA). 116 This document also discusses the distribution of the root key during 117 bootstrapping, in conjunction with either the initial EAP 118 authentication (implicit bootstrapping) or the first ERP exchange 119 (explicit bootstrapping). Security considerations for this key 120 distribution are detailed in Section 7.4 of Salowey, et 121 al. [RFC5295]. 123 2. Terminology 125 This document uses terminology defined in Aboba, et al. [RFC3748], 126 Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et 127 al. [RFC4072]. 129 Following RFC 5295, the term "domain" herein refers to a key 130 management domain unless otherwise qualified. Similarly, the terms 131 "home domain", and "local domain" have the same meaning here as in 132 RFC 6696. 134 The re-authentication Domain-Specific Root Key (rDSRK) is a re- 135 authentication Root Key (rRK, [RFC6696]) derived from the DSRK 136 instead of the EMSK. 138 "Root key" (RK) or "bootstrapping material" refers to the rRK or 139 rDSRK derived from an EMSK, depending on whether the ER server is 140 located in the home or a foreign domain. 142 We use the notation "ERP/DER" and "ERP/DEA" in this document to refer 143 to Diameter-EAP-Request and Diameter-EAP-Answer commands with the 144 Application Id set to (Section 10.1); the 145 same commands are denoted "EAP/DER" and "EAP/DEA" when the 146 Application Id in the message is set to 147 [RFC4072]. 149 2.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Assumptions 157 This document assumes the existence of at most one logical ER server 158 entity in a given domain. If several physical servers are deployed 159 for robustness, a replication mechanism must be deployed to 160 synchronize the ERP state (e.g., root keys) between these servers. 161 Any such replication mechanism is outside the scope of this document. 162 If multiple ER servers are deployed in the domain, we assume that 163 they can be used interchangeably. If multiple ER servers are 164 deployed across multiple domains, we assume that only one ER server, 165 topologically close to the peer, is involved in ERP, distance being 166 measured in terms of Diameter hops. 168 This document also assumes the existence of at most one EAP server 169 entity in the home domain. In case of multiple physical home EAP 170 servers, if the ER server wants to reach the same home EAP server, 171 the ER server SHOULD cache the Destination-Host AVP corresponding to 172 the home EAP server it requests. 174 In general, it is assumed that key management domain names and 175 Diameter realm names are identical for any given domain/realm. 177 4. Protocol Overview 179 The following figure illustrates the components involved in ERP and 180 their interactions. 182 Diameter +--------+ 183 +-------------+ ERP +-----------+ (*) | Home | 184 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 185 +-------------+ +-----------+ | server | 186 +--------+ 187 (*) Diameter EAP application, explicit bootstrapping scenario only. 189 Figure 1: Diameter ERP Overview. 191 The ER server is located either in the home domain (same as EAP 192 server) or in the local domain (same as authenticator, when it 193 differs from the home domain). 195 When the peer initiates an ERP exchange, the authenticator creates a 196 Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of 197 the message is set to that of the Diameter ERP application 198 Section 10.1 in the message. The generation of the ERP/DER message 199 is detailed in Section 6. 201 If there is an ER server in the same domain as the authenticator 202 (i.e., the local domain), Diameter routing MUST be configured so that 203 this ERP/DER message reaches that server, even if the Destination- 204 Realm is not the same as local domain. 206 If there is no local ER server, the message is routed according to 207 its Destination-Realm AVP content, extracted from the realm component 208 of the keyName-NAI attribute. As specified in RFC 6696, this realm 209 is the home domain of the peer in the case of bootstrapping exchange 210 ('B' flag is set in ERP message) or the domain of the bootstrapped ER 211 server otherwise. . 213 If no ER server is available in the home domain either, the ERP/DER 214 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER 215 MUST be generated as specified in RFC 6733 and returned to the 216 authenticator. The authenticator MAY cache this information (with 217 limited duration) to avoid further attempts to execute ERP with this 218 realm. It MAY also fallback to full EAP authentication to 219 authenticate the peer. 221 When an ER server receives the ERP/DER message, it searches its local 222 database for a valid, unexpired root key matching the keyName part of 223 the User-Name AVP. If such key is found, the ER server processes the 224 ERP message as described in RFC 6696, then creates the ERP/DEA answer 225 as described in Section 6. The rMSK is included in this answer. 227 Finally, the authenticator extracts the rMSK from the ERP/DEA as 228 described in RFC 6696, and forwards the content of the EAP-Payload 229 AVP, the EAP-Finish/Re-Auth message, to the peer. 231 The ER server may or may not possess the root key in its local 232 database. If the EAP-Initiate/Re-Auth message has its 'B' flag set 233 (Bootstrapping exchange) and the ER server possesses the root key, 234 the ER server SHOULD respond directly to the peer that initiated the 235 ERP exchange. Otherwise, the ER server SHOULD act as a proxy and 236 forward the message to the home EAP server after changing its 237 Application Id to Diameter EAP and adding the ERP-RK-Request AVP to 238 request the root key. See Section 5 for more detail on this process. 240 5. Bootstrapping the ER Server 242 The bootstrapping process involves the home EAP server and the ER 243 server, but also impacts the peer and the authenticator. In ERP, the 244 peer must derive the same keying material as the ER server. To 245 achieve this, it must learn the domain name of the ER server. How 246 this information is acquired is outside the scope of this 247 specification, but the authenticator might be configured to advertize 248 this domain name, especially in the case of re-authentication after a 249 handover. 251 The bootstrapping of an ER server with a given root key happens 252 either during the initial EAP authentication of the peer when the 253 EMSK -- from which the root key is derived -- is created, during the 254 first re-authentication, or sometime between those events. We only 255 consider the first two possibilities in this specification, in the 256 following sub-sections. 258 5.1. Bootstrapping During the Initial EAP authentication 260 Bootstrapping the ER server during the initial EAP authentication 261 (also known as implicit bootstrapping) offers the advantage that the 262 server is immediately available for re-authentication of the peer, 263 thus minimizing the re-authentication delay. On the other hand, it 264 is possible that only a small number of peers will use re- 265 authentication in the local domain. Deriving and caching key 266 material for all the peers (for example, for the peers that do not 267 support ERP) is a waste of resources and should be avoided. 269 To achieve implicit bootstrapping, the ER server acts as a Diameter 270 EAP Proxy , and Diameter routing MUST be configured so that Diameter 271 EAP application messages are routed through this proxy. The figure 272 bellow illustrates this mechanism. 274 ER server & 275 Authenticator EAP Proxy Home EAP server 276 ============= =========== =============== 277 -------------------------> 278 Diameter EAP/DER 279 (EAP-Response) 280 -------------------------> 281 Diameter EAP/DER 282 (EAP-Response) 283 (ERP-RK-Request) 285 <==================================================> 286 Multi-round Diameter EAP exchanges, unmodified 288 <------------------------- 289 Diameter EAP/DEA 290 (EAP-Success) 291 (MSK) 292 (Key AVP (rRK)) 293 <------------------------- 294 Diameter EAP/DEA 295 (EAP-Success) 296 (MSK) 297 [ERP-Realm] 299 Figure 2: ERP Bootstrapping During Full EAP Authentication 301 The authenticator creates the first DER of the full EAP 302 authentication and sends it to the ER server. The ER server proxies 303 the first DER of the full EAP authentication and adds the ERP-RK- 304 Request AVP inside, then forwards the request to the home EAP server. 306 If the home Diameter server does not support the Diameter ERP 307 extensions, it simply ignores the ERP-RK-Request AVP and continues as 308 specified in RFC 4072 [RFC4072]. If the server supports the ERP 309 extensions, it saves the value of the ERP-Realm AVP found inside the 310 ERP-RK-Request AVP, and continues with the EAP authentication. When 311 the authentication completes, if it is successful and the EAP method 312 has generated an EMSK, the server MUST derive the rRK as specified in 313 RFC 6696, using the saved ERP realm name. It then includes the rRK 314 inside a Key AVP (Section 8.3) with the Key-Type AVP set to rRK, 315 before sending the DEA as usual. 317 When the ER server proxies a Diameter-EAP-Answer message with a 318 Session-Id corresponding to a message to which it added an ERP-RK- 319 Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine 320 the message and save and remove any Key AVP (Section 8.3) with Key- 321 Type AVP set to rRK. If the message does not contain such Key AVP, 322 the ER server may cache the information that ERP is not possible for 323 this session to avoid possible subsequent attempts. In any case, the 324 information stored in ER server concerning a session should not have 325 a lifetime greater than the EMSK for this session. 327 If the ER server is successfully bootstrapped, it should also add the 328 ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the 329 EAP/DEA message. This ERP-Realm information can be used by the 330 authenticator to notify the peer that ER server is bootstrapped, and 331 for which domain. How this information can be transmitted to the 332 peer is outside the scope of this document. This information needs 333 to be sent to the peer if both implicit and explicit bootstrapping 334 mechanisms are possible, because the ERP message and the root key 335 used for protecting this message are different in bootstrapping 336 exchanges and non-bootstrapping exchanges. 338 5.2. Bootstrapping During the First Re-authentication 340 Bootstrapping the ER server during the first re-authentication (also 341 known as explicit bootstrapping) is only needed when there is no ER 342 server in the local domain and there is an ER server in the home 343 domain. It is less resource-intensive, since the EMSK generated 344 during initial EAP authentication is reused to derive root keys. On 345 the other hand, the first re-authentication requires a one-round-trip 346 exchange with the home EAP server, since the EMSK is generated during 347 the initial EAP authentication and never leaves the home EAP server, 348 which is less efficient than implicit bootstrapping. 350 The EAP-Initiate/Re-auth message is sent to the home ER server. The 351 home ER server receives the ERP/DER message containing the EAP- 352 Initiate/Re-Auth message with the 'B' flag set. It creates the new 353 EAP/DER message using the received DRP/DER message and performs the 354 following processing: 356 Set the Application Id in the header of the message to [RFC4072] 359 Extract the ERP-RK-Request AVP from the ERP/DER message, which 360 contains the name of the domain where the ER server is located and 361 add it to the newly created ERP/DER message. 363 Then the newly created EAP/DER is sent and routed to the home 364 Diameter EAP application server. 366 If the home Diameter EAP server does not support ERP extensions, EAP 367 packets with an unknown ERP-specific code (EAP-Initiate) will not be 368 understood. In such a case, the home Diameter EAP server MUST send 369 an EAP/DEA with a Result-Code indicating a Permanent Failure (for 370 example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or 371 DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and 372 contain a copy of the EAP-Payload AVP. Otherwise, it processes the 373 DSRK request as described in RFC 6696. In particular, it includes 374 the Domain- Name TLV attribute with the content from the ERP-Realm 375 AVP. The server creates the EAP/DEA reply message [RFC4072] 376 including an instance of the Key AVP (Section 8.3) with Key-Type AVP 377 set to rRK and an instance of the Domain-Name TLV attribute with the 378 content from the ERP-Realm AVP. 380 The ER server receives this EAP/DEA and proxies it as follows, in 381 addition to standard proxy operations: 383 Set the Application Id back to Diameter ERP Application Id 384 (Section 10.1) 386 Extract and cache the content of the Key AVP with Key-Type set to 387 rRK, as described in Section 5.1). 389 The ERP/DEA message is then forwarded to the authenticator, that can 390 use the rMSK as described in RFC 6696. 392 The figure below captures this proxy behavior: 394 Authenticator ER server Home Diameter server 395 ============= ========= ==================== 396 -----------------------> 397 Diameter ERP/DER 398 (EAP-Initiate) 399 ------------------------> 400 Diameter EAP/DER 401 (EAP-Response) 402 (ERP-RK-Request) 404 <------------------------ 405 Diameter EAP/DEA 406 (EAP-Success) 407 (Key AVP (rRK)) 408 (Key AVP (rMSK)) 409 <---------------------- 410 Diameter ERP/DEA 411 (EAP-Finish) 412 (Key AVP (rMSK)) 414 Figure 3: ERP Explicit Bootstrapping Message Flow 416 6. Re-Authentication 418 This section describes in detail a re-authentication exchange with an 419 ER server that was previously bootstrapped. The following figure 420 summarizes the re-authentication exchange. 422 ER server 423 Peer Authenticator (bootstrapped) 424 ==== ============= ====================== 425 [ <------------------------ ] 426 [optional EAP-Initiate/Re-auth-start,] 427 [ possibly with ERP domain name ] 429 -----------------------> 430 EAP-Initiate/Re-auth 431 ===============================> 432 Diameter ERP, cmd code DER 433 User-Name: Keyname-NAI 434 EAP-Payload: EAP-Initiate/Re-auth 436 <=============================== 437 Diameter ERP, cmd code DEA 438 EAP-Payload: EAP-Finish/Re-auth 439 Key AVP: rMSK 440 <---------------------- 441 EAP-Finish/Re-auth 443 Figure 4: Diameter ERP Re-authentication Exchange 445 The peer sends an EAP-Initiate/Re-auth message to the ER server via 446 the authenticator. Alternatively, the authenticator may send an EAP- 447 Initiate/Re-auth-Start message to the peer to trigger the mechanism. 448 In this case, the peer responds with an EAP-Initiate/Re-auth message. 450 If the authenticator does not support ERP (pure Diameter EAP 451 [RFC4072] support), it discards the EAP packets with an unknown ERP- 452 specific code (EAP-Initiate). The peer should fallback to full EAP 453 authentication in this case. 455 When the authenticator receives an EAP-Initiate/Re-auth message from 456 the peer, the message is processed as described in RFC 6696 with 457 regard to the EAP state machine. It creates a Diameter ERP/DER 458 message following the general process of Diameter EAP [RFC4072], with 459 the following differences: 461 The Application Id in the header is set to (code 462 TBD1). 464 The value in Auth-Application-Id AVP is also set to . 467 The keyName-NAI attribute from the ERP message is used to create 468 the content of the User-Name and Destination-Realm AVPs. 470 The Auth-Request-Type AVP content is set to the appropriate value. 472 The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message. 474 Then this ERP/DER message is sent as described in Section 4. 476 The ER server receives and processes this request as described in 477 Section 4. It then creates an ERP/DEA message following the general 478 process described in Eronen, et al. [RFC4072], with the following 479 differences: 481 The Application Id in the header is set to (code 482 TBD1). 484 The value of the Auth-Application-Id AVP is also set to . 487 The EAP-Payload AVP contains the EAP-Finish/Re-auth message. 489 If authentication is successful, an instance of the Key AVP 490 containing the Re-authentication Master Session Key (rMSK) derived 491 by ERP is included. 493 When the authenticator receives this ERP/DEA answer, it processes it 494 as described in the Diameter EAP Application specification [RFC4072] 495 and RFC 6696: the content of the EAP-Payload AVP is forwarded to the 496 peer, and the contents of the Keying-Material AVP [RFC6734] is used 497 as a shared secret for a secure association protocol specific to the 498 lower-layer in use. 500 7. Application Id 502 We define a new Diameter application in this document, Diameter ERP 503 Application, with an Application Id value of TBD1. Diameter nodes 504 conforming to this specification in the role of ER server MUST 505 advertise support by including an Auth-Application-Id AVP with a 506 value of Diameter ERP in the Capabilities-Exchange-Request and 507 Capabilities-Exchange-Answer commands [RFC6733]. 509 The primary use of the Diameter ERP Application Id is to ensure 510 proper routing of the messages, and that the nodes that advertise the 511 support for this application do understand the new AVPs defined in 512 Section 8, although these AVP have the 'M' flag cleared. 514 8. AVPs 516 The following sub-sections discuss the AVPs used by the Diameter ERP 517 application. 519 8.1. ERP-RK-Request AVP 521 The ERP-RK-Request AVP (AVP Code TBD2) is of type grouped AVP. This 522 AVP is used by the ER server to indicate its willingness to act as ER 523 server for a particular session. 525 This AVP has the M and V bits cleared. 527 ERP-RK-Request ::= < AVP Header: TBD2 > 528 { ERP-Realm } 529 * [ AVP ] 531 Figure 5: ERP-RK-Request ABNF 533 8.2. ERP-Realm AVP 535 The ERP-Realm AVP (AVP Code TBD3) is of type DiameterIdentity. It 536 contains the name of the realm in which the ER server is located. 538 This AVP has the M and V bits cleared. 540 8.3. Key AVP 542 The Key AVP [RFC6734] is of type "Grouped" and is used to carry the 543 rRK or rMSK and associated attributes. The usage of the Key AVP and 544 its constituent AVPs in this application is specified in the 545 following sub-sections. 547 8.3.1. Key-Type AVP 549 The value of the Key-Type AVP MUST be set to 1 for rRK or 2 for rMSK. 551 8.3.2. Keying-Material AVP 553 The Keying-Material AVP contains the rRK sent by the home EAP server 554 to the ER server, in answer to a request containing an ERP-RK-Request 555 AVP, or the rMSK sent by the ER server to the authenticator. How 556 this material is derived and used is specified in RFC 6696. 558 8.3.3. Key-Name AVP 560 This AVP contains the EMSKname which identifies the keying material. 561 The derivation of this name is specified in RFC 6696. 563 8.3.4. Key-Lifetime AVP 565 The Key-Lifetime AVP contains the lifetime of the keying material in 566 seconds. It MUST NOT be greater than the remaining lifetime of the 567 EMSK from which the material was derived. 569 9. Result-Code AVP Values 571 This section defines new Result-Code [RFC6733] values that MUST be 572 supported by all Diameter implementations that conform to this 573 specification. 575 9.1. Permanent Failures 577 Errors that fall within the Permanent Failures category are used to 578 inform the peer that the request failed and SHOULD NOT be attempted 579 again. 581 DIAMETER_ERROR_EAP_CODE_UNKNOWN (TBD4) 583 This error code is used by the Diameter server to inform the 584 peer that the received EAP-PAYLOAD AVP contains an EAP packet 585 with an unknown EAP code. 587 10. IANA Considerations 589 This document requires IANA registration of the following new 590 elements in the Authentication, Authorization, and Accounting (AAA) 591 Parameters registries [AAAPARAMS]. 593 10.1. Diameter Application Identifier 595 This specification requires IANA to allocate a new value "Diameter 596 ERP" (code: TBD1) in the "Application IDs" registry using the 597 "Specification Required" policy [RFC5226]; see Section 11.3 of RFC 598 3588 [RFC3588] for further details. 600 10.2. New AVPs 602 This specification requires IANA to allocate new values from the "AVP 603 Codes" registry according to the policy specified in Section 11.1 of 604 Fajardo, et al. [RFC6733] for the following AVPs: 606 ERP-RK-Request (code: TBD2) 608 ERP-Realm (code: TBD3) 610 These AVPs are defined in Section 8. 612 10.3. New Permanent Failures Result-Code AVP Values 614 This specification requires IANA to allocate a new value from the 615 "Result-Code AVP Values (code 268) - Permanent Failure" registry 616 according to the policy specified in Section 11.3.2 of Fajardo, et 617 al. [RFC6733] for the following Result-Code: 619 DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4) 621 This result-code value is defined in Section 9. 623 11. Security Considerations 625 The security considerations from the following documents apply here: 627 o Eronen, et al. [RFC4072] 629 o Salowey, et al. [RFC5295] 631 o Cao, et al. [RFC6696] 633 o Fajardo, et al. [RFC6733] 635 o Zorn, et al. [RFC6734] 637 Because this application involves the transmission of sensitive data, 638 including cryptographic keys, it MUST be protected using Transport 639 Layer Security (TLS) [RFC5246], Datagram Transport Layer Security 640 (DTLS) [RFC6347] or IP Encapsulating Security Payload (ESP) 641 [RFC4303]. If TLS or DTLS is used, the bulk encryption algorithm 642 negotiated MUST be non-null. If ESP is used, the encryption 643 algorithm MUST be non-null. 645 12. Contributors 647 Hannes Tschofenig wrote the initial draft of this document. 649 Lakshminath Dondeti contributed to the early versions of the 650 document. 652 13. Acknowledgements 654 Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem 655 Dodge, Vincent Roca, Stephen Farrell, Sean Turner, Pete Resnick, Russ 656 Housley, Martin Stiemerling and Jouni Korhonen provided useful 657 reviews. 659 Vidya Narayanan reviewed a rough draft version of the document and 660 found some errors. 662 Many thanks to these people! 664 14. References 666 14.1. Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 672 H. Levkowetz, "Extensible Authentication Protocol 673 (EAP)", RFC 3748, June 2004. 675 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter 676 Extensible Authentication Protocol (EAP) Application", 677 RFC 4072, August 2005. 679 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 680 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 681 May 2008. 683 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. 684 Nakhjiri, "Specification for the Derivation of Root Keys 685 from an Extended Master Session Key (EMSK)", RFC 5295, 686 August 2008. 688 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP 689 Extensions for the EAP Re-authentication Protocol 690 (ERP)", RFC 6696, July 2012. 692 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 693 "Diameter Base Protocol", RFC 6733, October 2012. 695 [RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute- 696 Value Pairs for Cryptographic Key Transport", RFC 6734, 697 October 2012. 699 14.2. Informative References 701 [AAAPARAMS] Internet Assigned Numbers Authority, "Authentication, 702 Authorization, and Accounting (AAA) Parameters", 703 http://www.iana.org/assignments/aaa-parameters/. 705 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 706 Arkko, "Diameter Base Protocol", RFC 3588, 707 September 2003. 709 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 710 RFC 4303, December 2005. 712 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 713 Security (TLS) Protocol Version 1.2", RFC 5246, 714 August 2008. 716 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 717 Security Version 1.2", RFC 6347, January 2012. 719 Authors' Addresses 721 Julien Bournelle 722 Orange Labs 723 38-40 rue du general Leclerc 724 Issy-Les-Moulineaux 92794 725 France 727 EMail: julien.bournelle@orange-ftgroup.com 729 Lionel Morand 730 Orange Labs 731 38-40 rue du general Leclerc 732 Issy-Les-Moulineaux 92794 733 France 735 EMail: lionel.morand@orange.com 736 Sebastien Decugis 737 INSIDE Secure 738 41 Parc Club du Golf 739 Aix-en-Provence 13856 740 France 742 Phone: +33 (0)4 42 39 63 00 743 EMail: sdecugis@freediameter.net 745 Qin Wu 746 Huawei Technologies Co., Ltd 747 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 748 Nanjing 210001 749 China 751 EMail: sunseawq@huawei.com 753 Glen Zorn 754 Network Zen 755 227/358 Thanon Sanphawut 756 Bang Na, Bangkok 10260 757 Thailand 759 EMail: glenzorn@gmail.com