idnits 2.17.00 (12 Aug 2021) /tmp/idnits27429/draft-ietf-dime-erp-16.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 (December 11, 2012) is 3448 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 287, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: June 14, 2013 S. Decugis 6 INSIDE Secure 7 Q. Wu 8 Huawei 9 G. Zorn 10 Network Zen 11 December 11, 2012 13 Diameter Support for the EAP Re-authentication Protocol (ERP) 14 draft-ietf-dime-erp-16.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 June 14, 2013. 44 Copyright Notice 46 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 14 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 15 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 Salowey, et al. [RFC5295]. 122 2. Terminology 124 This document uses terminology defined in Aboba, et al. [RFC3748], 125 Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et 126 al. [RFC4072]. 128 The re-athentication Domain-Specific Root Key (rDSRK) is a re- 129 authentication Root Key (rRK, [RFC6696]) derived from the DSRK 130 instead of the EMSK. 132 "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK 133 derived from an EMSK, depending on the location of the ER server in 134 home or foreign domain. 136 We use the notation "ERP/DER" and "ERP/DEA" in this document to refer 137 to Diameter-EAP-Request and Diameter-EAP-Answer commands with the 138 Application Id set to Section 10.1; the 139 same commands are denoted "EAP/DER" and "EAP/DEA" when the 140 Application Id in the message is set to 141 [RFC4072]. 143 2.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Assumptions 151 This document assumes the existence of at most one logical ER server 152 entity in a domain. If several physical servers are deployed for 153 robustness, a replication mechanism must be deployed to synchronize 154 the ERP state (e.g., root keys) between these servers. Any such 155 replication mechanism is outside the scope of this document. If 156 multiple ER servers are deployed in the domain, we assume that they 157 can be used interchangeably. If multiple ER servers are deployed 158 across the domains, we assume only one ER server that is near the 159 peer is involved in ERP. 161 This document also assumes the existence of at most one EAP server 162 entity in the home domain. In case of multiple physical home EAP 163 servers in the same domain, if the ER server wants to reach the same 164 home EAP server, the ER server may cache the Destination-Host AVP 165 corresponding to the home EAP server it requests. 167 4. Protocol Overview 169 The following figure illustrates the components involved in ERP and 170 their interactions. 172 Diameter +--------+ 173 +-------------+ ERP +-----------+ (*) | Home | 174 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 175 +-------------+ +-----------+ | server | 176 +--------+ 177 (*) Diameter EAP application, explicit bootstrapping scenario only. 179 Figure 1: Diameter ERP Overview. 181 The ER server is located either in the home domain (same as EAP 182 server) or in the visited domain (same as authenticator, when it 183 differs from the home domain). 185 When the peer initiates an ERP exchange, the authenticator creates a 186 Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of 187 the message is set to that of the Diameter ERP application 188 Section 10.1 in the message. The generation of the ERP/DER message 189 is detailed in Section 6. 191 If there is an ER server in the same domain as the authenticator 192 (i.e., the local domain), Diameter routing MUST be configured so that 193 this ERP/DER message reaches that server, even if the Destination- 194 Realm is not the same as local domain. 196 If there is no local ER server, the message is routed according to 197 its Destination-Realm AVP content, extracted from the realm component 198 of the keyName-NAI attribute. As specified in RFC 6696, this realm 199 is the home domain of the peer in the case of bootstrapping exchange 200 ('B' flag is set in ERP message) or the domain of the bootstrapped ER 201 server otherwise . 203 If no ER server is available in the home domain either, the ERP/DER 204 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER 205 MUST be generated as specified in [RFC6733] and returned to the 206 authenticator. The authenticator MAY cache this information (with 207 limited duration) to avoid further attempts to execute ERP with this 208 realm. It MAY also fallback to full EAP authentication to 209 authenticate the peer. 211 When an ER server receives the ERP/DER message, it searches its local 212 database for a valid, unexpired root key matching the keyName part of 213 the User-Name AVP. If such key is found, the ER server processes the 214 ERP message as described in RFC 6696, then creates the ERP/DEA answer 215 as described in Section 6. The rMSK is included in this answer. 217 Finally, the authenticator extracts the rMSK from the ERP/DEA as 218 described in RFC 6696, and forwards the content of the EAP-Payload 219 AVP, the EAP-Finish/Re-Auth message, to the peer. 221 The ER server may or may not possess the root key in its local 222 database. If the EAP-Initiate/Re-Auth message has its 'B' flag set 223 (Bootstrapping exchange) and the ER server possesses the root key, 224 the ER server SHOULD respond directly to the peer that initiated the 225 ERP exchange. Otherwise, the ER server SHOULD act as a proxy and 226 forward the message to the home EAP server after changing its 227 Application Id to Diameter EAP and adding the ERP-RK-Request AVP to 228 request the root key. See Section 5 for more detail on this process. 230 5. Bootstrapping the ER Server 232 The bootstrapping process involves the home EAP server and the ER 233 server, but also impacts the peer and the authenticator. In ERP, the 234 peer must derive the same keying material as the ER server. To 235 achieve this, it must learn the domain name of the ER server. How 236 this information is acquired is outside the scope of this 237 specification, but the authenticator might be configured to advertize 238 this domain name, especially in the case of re-authentication after a 239 handover. 241 The bootstrapping of an ER server with a given root key happens 242 either during the initial EAP authentication of the peer when the 243 EMSK -- from which the root key is derived -- is created, during the 244 first re-authentication, or sometime between those events. We only 245 consider the first two possibilities in this specification, in the 246 following sub-sections. 248 5.1. Bootstrapping During the Initial EAP authentication 250 Bootstrapping the ER server during the initial EAP authentication 251 (also known as implicit bootstrapping) offers the advantage that the 252 server is immediately available for re-authentication of the peer, 253 thus minimizing the re-authentication delay. On the other hand, it 254 is possible that only a small number of peers will use re- 255 authentication in the visited domain. Deriving and caching key 256 material for all the peers (for example, for the peers that do not 257 support ERP) is a waste of resources and should be avoided. 259 To achieve implicit bootstrapping, the ER server acts as a Diameter 260 EAP Proxy , and Diameter routing MUST be configured so that Diameter 261 EAP application messages are routed through this proxy. The figure 262 bellow illustrates this mechanism. 264 ER server & 265 Authenticator EAP Proxy Home EAP server 266 ============= =========== =============== 267 -------------------------> 268 Diameter EAP/DER 269 (EAP-Response) 270 -------------------------> 271 Diameter EAP/DER 272 (EAP-Response) 273 (ERP-RK-Request) 275 <==================================================> 276 Multi-round Diameter EAP exchanges, unmodified 278 <------------------------- 279 Diameter EAP/DEA 280 (EAP-Success) 281 (MSK) 282 (Key AVP (rRK)) 283 <------------------------- 284 Diameter EAP/DEA 285 (EAP-Success) 286 (MSK) 287 [ERP-Realm] 289 Figure 2: ERP Bootstrapping During Full EAP Authentication 291 The authenticator creates the first DER of the full EAP 292 authentication and sends it to the ER server. The ER server proxies 293 the first DER of the full EAP authentication and adds the ERP-RK- 294 Request AVP inside, then forwards the request to the home EAP server. 296 If the home Diameter server does not support the Diameter ERP 297 extensions, it simply ignores the ERP-RK-Request AVP and continues as 298 specified in RFC 4072 [RFC4072]. If the server supports the ERP 299 extensions, it saves the value of the ERP-Realm AVP found inside the 300 ERP-RK-Request AVP, and continues with the EAP authentication. When 301 the authentication completes, if it is successful and the EAP method 302 has generated an EMSK, the server MUST derive the rRK as specified in 303 RFC 6696, using the saved domain name. It then includes the rRK 304 inside a Key AVP (Section 8.3) with the Key-Type AVP set to rRK, 305 before sending the DEA as usual. 307 When the ER server proxies a Diameter-EAP-Answer message with a 308 Session-Id corresponding to a message to which it added an ERP-RK- 309 Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine 310 the message and save and remove any Key AVP (Section 8.3) with Key- 311 Type AVP set to rRK. If the message does not contain such Key AVP, 312 the ER server may cache the information that ERP is not possible for 313 this session to avoid possible subsequent attempts. In any case, the 314 information stored in ER server concerning a session should not have 315 a lifetime greater than the EMSK for this session. 317 If the ER server is successfully bootstrapped, it should also add the 318 ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the 319 EAP/DEA message. This ERP-Realm information can be used by the 320 authenticator to notify the peer that ER server is bootstrapped, and 321 for which domain. How this information can be transmitted to the 322 peer is outside the scope of this document. This information needs 323 to be sent to the peer if both implicit and explicit bootstrapping 324 mechanisms are possible, because the ERP message and the root key 325 used for protecting this message are different in bootstrapping 326 exchanges and non-bootstrapping exchanges. 328 5.2. Bootstrapping During the First Re-authentication 330 Bootstrapping the ER server during the first re-authentication (also 331 known as explicit bootstrapping) is only needed when there is no 332 local ER server in the visited domain and there is an ER server in 333 the home domain. It is less resource-intensive, since the EMSK 334 generated during initial EAP authentication is reused to derive root 335 keys. On the other hand, the first re-authentication requires a one- 336 round-trip exchange with the home EAP server, since the EMSK is 337 generated during the initial EAP authentication and never leaves the 338 home EAP server, which is less efficient than implicit bootstrapping. 340 The EAP-Initiate/Re-auth message is sent to the home ER server. The 341 home ER server receives the ERP/DER message containing the EAP- 342 Initiate/Re-Auth message with the 'B' flag set. It creates the new 343 EAP/DER message using the received DRP/DER message and performs the 344 following processing: 346 Set the Application Id in the header of the message to [RFC4072] 349 Extract the ERP-RK-Request AVP from the ERP/DER message, which 350 contains the name of the domain where the ER server is located and 351 add it to the newly created ERP/DER message. 353 Then the newly created EAP/DER is sent and routed to the home 354 Diameter EAP application server. 356 If the home Diameter EAP server does not support ERP extensions, EAP 357 packets with an unknown ERP-specific code (EAP-Initiate) will not be 358 understood. In such a case, the home Diameter EAP server MUST send 359 an EAP/DEA with a Result-Code indicating a Permanent Failure (for 360 example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or 361 DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and 362 contain a copy of the EAP-Payload AVP. Otherwise, it processes the 363 DSRK request as described in RFC 6696. In particular, it includes 364 the Domain- Name TLV attribute with the content from the ERP-Realm 365 AVP. The server creates the EAP/DEA reply message [RFC4072] 366 including an instance of the Key AVP (Section 8.3) with Key-Type AVP 367 set to rRK and an instance of the Domain-Name TLV attribute with the 368 content from the ERP-Realm AVP. 370 The ER server receives this EAP/DEA and proxies it as follows, in 371 addition to standard proxy operations: 373 Set the Application Id back to Diameter ERP Application Id 374 (Section 10.1) 376 Extract and cache the content of the Key AVP with Key-Type set to 377 rRK, as described in Section 5.1). 379 The ERP/DEA message is then forwarded to the authenticator, that can 380 use the rMSK as described in RFC 6696. 382 The figure below captures this proxy behavior: 384 Authenticator ER server Home Diameter server 385 ============= ========= ==================== 386 -----------------------> 387 Diameter ERP/DER 388 (EAP-Initiate) 389 ------------------------> 390 Diameter EAP/DER 391 (EAP-Response) 392 (ERP-RK-Request) 394 <------------------------ 395 Diameter EAP/DEA 396 (EAP-Success) 397 (Key AVP (rRK)) 398 (Key AVP (rMSK)) 399 <---------------------- 400 Diameter ERP/DEA 401 (EAP-Finish) 402 (Key AVP (rMSK)) 404 Figure 3: ERP Explicit Bootstrapping Message Flow 406 6. Re-Authentication 408 This section describes in detail a re-authentication exchange with an 409 ER server that was previously bootstrapped. The following figure 410 summarizes the re-authentication exchange. 412 ER server 413 Peer Authenticator (bootstrapped) 414 ==== ============= ====================== 415 [ <------------------------ ] 416 [optional EAP-Initiate/Re-auth-start,] 417 [ possibly with ERP domain name ] 419 -----------------------> 420 EAP-Initiate/Re-auth 421 ===============================> 422 Diameter ERP, cmd code DER 423 User-Name: Keyname-NAI 424 EAP-Payload: EAP-Initiate/Re-auth 426 <=============================== 427 Diameter ERP, cmd code DEA 428 EAP-Payload: EAP-Finish/Re-auth 429 Key AVP: rMSK 430 <---------------------- 431 EAP-Finish/Re-auth 433 Figure 4: Diameter ERP Re-authentication Exchange 435 The peer sends an EAP-Initiate/Re-auth message to the ER server via 436 the authenticator. Alternatively, the authenticator may send an EAP- 437 Initiate/Re-auth-Start message to the peer to trigger the mechanism. 438 In this case, the peer responds with an EAP-Initiate/Re-auth message. 440 If the authenticator does not support ERP (pure Diameter EAP 441 [RFC4072] support), it discards the EAP packets with an unknown ERP- 442 specific code (EAP-Initiate). The peer should fallback to full EAP 443 authentication in this case. 445 When the authenticator receives an EAP-Initiate/Re-auth message from 446 the peer, the message is processed as described in RFC 6696 with 447 regard to the EAP state machine. It creates a Diameter ERP/DER 448 message following the general process of Diameter EAP [RFC4072], with 449 the following differences: 451 The Application Id in the header is set to (code 452 TBD1). 454 The value in Auth-Application-Id AVP is also set to . 457 The keyName-NAI attribute from the ERP message is used to create 458 the content of the User-Name and Destination-Realm AVPs. 460 The Auth-Request-Type AVP content is set to the appropriate value. 462 The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message. 464 Then this ERP/DER message is sent as described in Section 4. 466 The ER server receives and processes this request as described in 467 Section 4. It then creates an ERP/DEA message following the general 468 process described in Eronen, et al. [RFC4072], with the following 469 differences: 471 The Application Id in the header is set to (code 472 TBD1). 474 The value of the Auth-Application-Id AVP is also set to . 477 The EAP-Payload AVP contains the EAP-Finish/Re-auth message. 479 If authentication is successful, an instance of the Key AVP 480 containing the Re-authentication Master Session Key (rMSK) derived 481 by ERP is included. 483 When the authenticator receives this ERP/DEA answer, it processes it 484 as described in the Diameter EAP Application specification [RFC4072] 485 and RFC 6696: the content of the EAP-Payload AVP is forwarded to the 486 peer, and the contents of the Keying-Material AVP [RFC6734] is used 487 as a shared secret for a secure association protocol specific to the 488 lower-layer in use. 490 7. Application Id 492 We define a new Diameter application in this document, Diameter ERP 493 Application, with an Application Id value of TBD1. Diameter nodes 494 conforming to this specification in the role of ER server MUST 495 advertise support by including an Auth-Application-Id AVP with a 496 value of Diameter ERP in the Capabilities-Exchange-Request and 497 Capabilities-Exchange-Answer commands [RFC6733]. 499 The primary use of the Diameter ERP Application Id is to ensure 500 proper routing of the messages, and that the nodes that advertise the 501 support for this application do understand the new AVPs defined in 502 Section 8, although these AVP have the 'M' flag cleared. 504 8. AVPs 506 The following sub-sections discuss the AVPs used by the Diameter ERP 507 application. 509 8.1. ERP-RK-Request AVP 511 The ERP-RK-Request AVP (AVP Code TBD2) is of type grouped AVP. This 512 AVP is used by the ER server to indicate its willingness to act as ER 513 server for a particular session. 515 This AVP has the M and V bits cleared. 517 ERP-RK-Request ::= < AVP Header: TBD2 > 518 { ERP-Realm } 519 * [ AVP ] 521 Figure 5: ERP-RK-Request ABNF 523 8.2. ERP-Realm AVP 525 The ERP-Realm AVP (AVP Code TBD3) is of type DiameterIdentity. It 526 contains the name of the realm in which the ER server is located. 528 This AVP has the M and V bits cleared. 530 8.3. Key AVP 532 The Key AVP [RFC6734] is of type "Grouped" and is used to carry the 533 rRK or rMSK and associated attributes. The usage of the Key AVP and 534 its constituent AVPs in this application is specified in the 535 following sub-sections. 537 8.3.1. Key-Type AVP 539 The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. 541 8.3.2. Keying-Material AVP 543 The Keying-Material AVP contains the rRK sent by the home EAP server 544 to the ER server, in answer to a request containing an ERP-RK-Request 545 AVP, or the rMSK sent by the ER server to the authenticator. How 546 this material is derived and used is specified in RFC 6696. 548 8.3.3. Key-Name AVP 550 This AVP contains the EMSKname which identifies the keying material. 551 The derivation of this name is specified in RFC 6696. 553 8.3.4. Key-Lifetime AVP 555 The Key-Lifetime AVP contains the lifetime of the keying material in 556 seconds. It MUST NOT be greater than the remaining lifetime of the 557 EMSK from which the material was derived. 559 9. Result-Code AVP Values 561 This section defines new Result-Code [RFC6733] values that MUST be 562 supported by all Diameter implementations that conform to this 563 specification. 565 9.1. Permanent Failures 567 Errors that fall within the Permanent Failures category are used to 568 inform the peer that the request failed and SHOULD NOT be attempted 569 again. 571 DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4) 573 This error code is used by the Diameter server to inform the 574 peer that the received EAP-PAYLOAD AVP contains an EAP packet 575 with an unknown EAP code. 577 10. IANA Considerations 579 This document requires IANA registration of the following new 580 elements in the Authentication, Authorization, and Accounting (AAA) 581 Parameters registries [AAAPARAMS]. 583 10.1. Diameter Application Identifier 585 This specification requires IANA to allocate a new value "Diameter 586 ERP" (code: TBD1) in the "Application IDs" registry using the 587 "Specification Required" policy [RFC5226]; see Section 11.3 of RFC 588 3588 [RFC3588] for further details. 590 10.2. New AVPs 592 This specification requires IANA to allocate new values from the "AVP 593 Codes" registry according to the policy specified in Section 11.1 of 594 Fajardo, et al. [RFC6733] for the following AVPs: 596 ERP-RK-Request (code: TBD2) 598 ERP-Realm (code: TBD3) 600 These AVPs are defined in Section 8. 602 10.3. New Permanent Failures Result-Code AVP Values 604 This specification requires IANA to allocate a new value from the 605 "Result-Code AVP Values (code 268) - Permanent Failure" registry 606 according to the policy specified in Section 11.3.2 of Fajardo, et 607 al. [RFC6733] for the following Result-Code: 609 DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4) 611 This result-code value is defined in Section 9. 613 11. Security Considerations 615 The security considerations from the following documents apply here: 617 o Eronen, et al. [RFC4072] 619 o Cao, et al. [RFC6696] 621 o Fajardo, et al. [RFC6733] 623 o Zorn, et al. [RFC6734] 625 12. Contributors 627 Hannes Tschofenig wrote the initial draft of this document. 629 Lakshminath Dondeti contributed to the early versions of the 630 document. 632 13. Acknowledgements 634 Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem 635 Dodge, Vincent Roca and Jouni Korhonen provided useful reviews. 637 Vidya Narayanan reviewed a rough draft version of the document and 638 found some errors. 640 Many thanks to these people! 642 14. References 643 14.1. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 649 H. Levkowetz, "Extensible Authentication Protocol 650 (EAP)", RFC 3748, June 2004. 652 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter 653 Extensible Authentication Protocol (EAP) Application", 654 RFC 4072, August 2005. 656 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 657 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 658 May 2008. 660 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. 661 Nakhjiri, "Specification for the Derivation of Root Keys 662 from an Extended Master Session Key (EMSK)", RFC 5295, 663 August 2008. 665 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP 666 Extensions for the EAP Re-authentication Protocol 667 (ERP)", RFC 6696, July 2012. 669 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 670 "Diameter Base Protocol", RFC 6733, October 2012. 672 [RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute- 673 Value Pairs for Cryptographic Key Transport", RFC 6734, 674 October 2012. 676 14.2. Informative References 678 [AAAPARAMS] Internet Assigned Numbers Authority, "Authentication, 679 Authorization, and Accounting (AAA) Parameters", 680 http://www.iana.org/assignments/aaa-parameters/. 682 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 683 Arkko, "Diameter Base Protocol", RFC 3588, 684 September 2003. 686 Authors' Addresses 688 Julien Bournelle 689 Orange Labs 690 38-40 rue du general Leclerc 691 Issy-Les-Moulineaux 92794 692 France 694 EMail: julien.bournelle@orange-ftgroup.com 696 Lionel Morand 697 Orange Labs 698 38-40 rue du general Leclerc 699 Issy-Les-Moulineaux 92794 700 France 702 EMail: lionel.morand@orange-ftgroup.com 704 Sebastien Decugis 705 INSIDE Secure 706 41 Parc Club du Golf 707 Aix-en-Provence 13856 708 France 710 Phone: +33 (0)4 42 39 63 00 711 EMail: sdecugis@freediameter.net 713 Qin Wu 714 Huawei Technologies Co., Ltd 715 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 716 Nanjing 210001 717 China 719 EMail: sunseawq@huawei.com 721 Glen Zorn 722 Network Zen 723 227/358 Thanon Sanphawut 724 Bang Na, Bangkok 10260 725 Thailand 727 EMail: glenzorn@gmail.com