idnits 2.17.00 (12 Aug 2021) /tmp/idnits26954/draft-ietf-dime-erp-14.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 (October 22, 2012) is 3498 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 285, but not defined == Outdated reference: draft-ietf-dime-local-keytran has been published as RFC 6734 == Outdated reference: draft-ietf-dime-rfc3588bis has been published as RFC 6733 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 1 error (**), 0 flaws (~~), 4 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: April 25, 2013 S. Decugis 6 INSIDE Secure 7 Q. Wu 8 Huawei 9 G. Zorn 10 Network Zen 11 October 22, 2012 13 Diameter Support for the EAP Re-authentication Protocol (ERP) 14 draft-ietf-dime-erp-14.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 April 25, 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 12.1. Diameter Application Identifier . . . . . . . . . . . . . 14 85 12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14 87 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 14. Normative References . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol 93 (ERP). It consists of the following steps: 95 Bootstrapping 97 A root key for re-authentication is derived from the Extended 98 Master Session Key (EMSK) created during EAP authentication 99 [RFC5295]. This root key is transported from the EAP server to 100 the ER server. 102 Re-authentication 104 A one-round-trip exchange between the peer and the ER server, 105 resulting in mutual authentication. To support the EAP 106 reauthentication functionality, ERP defines two new EAP codes - 107 EAP-Initiate and EAP-Finish. 109 This document defines how Diameter transports the ERP messages during 110 the re-authentication process. For this purpose, we define a new 111 Application Identifier for ERP, and re-use the Diameter EAP commands 112 (DER/DEA). 114 This document also discusses the distribution of the root key during 115 bootstrapping, in conjunction with either the initial EAP 116 authentication (implicit bootstrapping) or the first ERP exchange 117 (explicit bootstrapping). Security considerations for this key 118 distribution are detailed in Salowey, et al. [RFC5295]. 120 2. Terminology 122 This document uses terminology defined in Aboba, et al. [RFC3748], 123 Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, Hiller 124 & Zorn [RFC4072]. 126 The re-athentication Domain-Specific Root Key (rDSRK) is a re- 127 authentication Root Key (rRK, [RFC6696]) derived from the DSRK 128 instead of the EMSK. 130 "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK 131 derived from an EMSK, depending on the location of the ER server in 132 home or foreign domain. 134 We use the notation "ERP/DER" and "ERP/DEA" in this document to refer 135 to Diameter-EAP-Request and Diameter-EAP-Answer commands with the 136 Application Id set to Section 12.1; the 137 same commands are denoted "EAP/DER" and "EAP/DEA" when the 138 Application Id in the message is set to 139 [RFC4072]. 141 2.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Assumptions 149 This document assumes the existence of at most one logical ER server 150 entity in a domain. If several physical servers are deployed for 151 robustness, a replication mechanism must be deployed to synchronize 152 the ERP state (e.g., root keys) between these servers. This 153 replication mechanism is out of the scope of this document. If 154 multiple ER servers are deployed in the domain, we assume that they 155 can be used interchangeably. If multiple ER servers are deployed 156 across the domains, we assume only one ER server that is near to the 157 peer is getting involved in the ERP. 159 Also this document assumes the existence of at most one EAP server 160 entity in the home domain. In case of multiple physical home EAP 161 servers in the same domain, if the ER server wants to reach the same 162 home EAP server, the ER server may cache the Destination-Host AVP 163 corresponding to the home EAP server it requests. 165 4. Protocol Overview 167 The following figure shows the components involved in ERP, and their 168 interactions. 170 Diameter +--------+ 171 +-------------+ ERP +-----------+ (*) | Home | 172 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 173 +-------------+ +-----------+ | server | 174 +--------+ 175 (*) Diameter EAP application, explicit bootstrapping scenario only. 177 Figure 1: Diameter ERP Overview. 179 The ER server is located either in the home domain (same as EAP 180 server) or in the visited domain (same as authenticator, when it 181 differs from the home domain). 183 When the peer initiates an ERP exchange, the authenticator creates a 184 Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of 185 the message is set to that of the Diameter ERP application 186 Section 12.1 in the message. The generation of the ERP/DER message 187 is detailed in Section 6. 189 If there is an ER server in the same domain as the authenticator 190 (i.e., the local domain), Diameter routing MUST be configured so that 191 this ERP/DER message reaches that server, even if the Destination- 192 Realm is not the same as local domain. 194 If there is no local ER server, the message is routed according to 195 its Destination-Realm AVP content, extracted from the realm component 196 of the keyName-NAI attribute. As specified in RFC 6696, this realm 197 is the home domain of the peer in the case of bootstrapping exchange 198 ('B' flag is set in ERP message) or the domain of the bootstrapped ER 199 server otherwise . 201 If no ER server is available in the home domain either, the ERP/DER 202 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER 203 MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and 204 returned to the authenticator. The authenticator MAY cache this 205 information (with limited duration) to avoid further attempts to 206 execute ERP with this realm. It MAY also fallback to full EAP 207 authentication to authenticate the peer. 209 When an ER server receives the ERP/DER message, it searches its local 210 database for a valid, unexpired root key matching the keyName part of 211 the User-Name AVP. If such key is found, the ER server processes the 212 ERP message as described in RFC 6696, then creates the ERP/DEA answer 213 as described in Section 6. The rMSK is included in this answer. 215 Finally, the authenticator extracts the rMSK from the ERP/DEA as 216 described in RFC 6696, and forwards the content of the EAP-Payload 217 AVP, the EAP-Finish/Re-Auth message, to the peer. 219 The ER server may or may not possess the root key in its local 220 database. If the EAP-Initiate/Re-Auth message has its 'B' flag set 221 (Bootstrapping exchange) and the ER server possesses the root key, 222 the ER server SHOULD respond directly to the peer that initiated the 223 ERP exchange. Otherwise, the ER server SHOULD act as a proxy and 224 forward the message to the home EAP server after changing its 225 Application Id to Diameter EAP and adding the ERP-RK-Request AVP to 226 request the root key. See Section 5 for more detail on this process. 228 5. Bootstrapping the ER Server 230 The bootstrapping process involves the home EAP server and the ER 231 server, but also impacts the peer and the authenticator. In ERP, the 232 peer must derive the same keying material as the ER server. To 233 achieve this, it must learn the domain name of the ER server. How 234 this information is acquired is outside the scope of this 235 specification, but the authenticator might be configured to advertize 236 this domain name, especially in the case of re-authentication after a 237 handover. 239 The bootstrapping of an ER server with a given root key happens 240 either during the initial EAP authentication of the peer when the 241 EMSK -- from which the root key is derived -- is created, during the 242 first re-authentication, or sometime between those events. We only 243 consider the first two possibilities in this specification, in the 244 following sub-sections. 246 5.1. Bootstrapping During the Initial EAP authentication 248 Bootstrapping the ER server during the initial EAP authentication 249 (also known as implicit bootstrapping) offers the advantage that the 250 server is immediately available for re-authentication of the peer, 251 thus minimizing the re-authentication delay. On the other hand, it 252 is possible that only a small number of peers will use re- 253 authentication in the visited domain. Deriving and caching key 254 material for all the peers (for example, for the peers that do not 255 support ERP) is a waste of resources and should be avoided. 257 To achieve implicit bootstrapping, the ER server acts as a Diameter 258 EAP Proxy , and Diameter routing MUST be configured so that Diameter 259 EAP application messages are routed through this proxy. The figure 260 bellow illustrates this mechanism. 262 ER server & 263 Authenticator EAP Proxy Home EAP server 264 ============= =========== =============== 265 -------------------------> 266 Diameter EAP/DER 267 (EAP-Response) 268 -------------------------> 269 Diameter EAP/DER 270 (EAP-Response) 271 (ERP-RK-Request) 273 <==================================================> 274 Multi-round Diameter EAP exchanges, unmodified 276 <------------------------- 277 Diameter EAP/DEA 278 (EAP-Success) 279 (MSK) 280 (Key AVP (rRK)) 281 <------------------------- 282 Diameter EAP/DEA 283 (EAP-Success) 284 (MSK) 285 [ERP-Realm] 287 Figure 2: ERP Bootstrapping During Full EAP Authentication 289 The authenticator creates the first DER of the full EAP 290 authentication and sends it to the ER server. The ER server proxies 291 the first DER of the full EAP authentication and adds the ERP-RK- 292 Request AVP inside, then forwards the request to the home EAP server. 294 If the home Diameter server does not support the Diameter ERP 295 extensions, it simply ignores the ERP-RK-Request AVP and continues as 296 specified in RFC 4072 [RFC4072]. If the server supports the ERP 297 extensions, it saves the value of the ERP-Realm AVP found inside the 298 ERP-RK-Request AVP, and continues with the EAP authentication. When 299 the authentication completes, if it is successful and the EAP method 300 has generated an EMSK, the server MUST derive the rRK as specified in 301 RFC 6696, using the saved domain name. It then includes the rRK 302 inside a Key AVP (Section 8.3) with the Key-Type AVP set to rRK, 303 before sending the DEA as usual. 305 When the ER server proxies a Diameter-EAP-Answer message with a 306 Session-Id corresponding to a message to which it added an ERP-RK- 307 Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine 308 the message and save and remove any Key AVP (Section 8.3) with Key- 309 Type AVP set to rRK. If the message does not contain such Key AVP, 310 the ER server may cache the information that ERP is not possible for 311 this session to avoid possible subsequent attempts. In any case, the 312 information stored in ER server concerning a session should not have 313 a lifetime greater than the EMSK for this session. 315 If the ER server is successfully bootstrapped, it should also add the 316 ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the 317 EAP/DEA message. This ERP-Realm information can be used by the 318 authenticator to notify the peer that ER server is bootstrapped, and 319 for which domain. How this information can be transmitted to the 320 peer is outside the scope of this document. This information needs 321 to be sent to the peer if both implicit and explicit bootstrapping 322 mechanisms are possible, because the ERP message and the root key 323 used for protecting this message are different in bootstrapping 324 exchanges and non-bootstrapping exchanges. 326 5.2. Bootstrapping During the First Re-authentication 328 Bootstrapping the ER server during the first re-authentication (also 329 known as explicit bootstrapping) is only needed when there is no 330 local ER server in the visited domain and there is an ER server in 331 the home domain. It is less resource-intensive, since the EMSK 332 generated during initial EAP authentication is reused to derive root 333 keys. On the other hand, the first re-authentication requires a one- 334 round-trip exchange with the home EAP server, since the EMSK is 335 generated during the initial EAP authentication and never leaves the 336 home EAP server, which is less efficient than the implicit 337 bootstrapping scenario. 339 The EAP-Initiate/Re-auth message is sent to the home ER server. The 340 home ER server receives the ERP/DER message containing the EAP- 341 Initiate/Re-Auth message with the 'B' flag set. It creates the new 342 EAP/DER message using the received DRP/DER message and performs the 343 following processing: 345 Set the Application Id in the header of the message to [RFC4072] 348 Extract the ERP-RK-Request AVP from the ERP/DER message, which 349 contains the name of the domain where the ER server is located and 350 add it to the newly created ERP/DER message. 352 Then the newly created EAP/DER is sent and routed to the home 353 Diameter EAP application server. 355 If the home Diameter EAP server does not support ERP extensions, EAP 356 packets with an unknown ERP-specific code (EAP-Initiate) will not be 357 understood. In such a case, the home Diameter EAP server MUST send 358 an EAP/DEA with a Result-Code indicating a Permanent Failure (for 359 example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or 360 DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and 361 contain a copy of the EAP-Payload AVP. Otherwise, it processes the 362 DSRK request as described in RFC 6696. In particular, it includes 363 the Domain- Name TLV attribute with the content from the ERP-Realm 364 AVP. The server creates the EAP/DEA reply message [RFC4072] 365 including an instance of the Key AVP (Section 8.3) with Key-Type AVP 366 set to rRK and an instance of the Domain-Name TLV attribute with the 367 content from the ERP-Realm AVP. 369 The ER server receives this EAP/DEA and proxies it as follows, in 370 addition to standard proxy operations: 372 Set the Application Id back to Diameter ERP Application Id 373 (Section 12.1 ) 375 Extract and cache the content of the Key AVP with Key-Type set to 376 rRK, as described in the implicit scenario (Section 5.1). 378 The ERP/DEA message is then forwarded to the authenticator, that can 379 use the rMSK as described in RFC 6696. 381 The figure below captures this proxy behavior: 383 Authenticator ER server Home Diameter server 384 ============= ========= ==================== 385 -----------------------> 386 Diameter ERP/DER 387 (EAP-Initiate) 388 ------------------------> 389 Diameter EAP/DER 390 (EAP-Response) 391 (ERP-RK-Request) 393 <------------------------ 394 Diameter EAP/DEA 395 (EAP-Success) 396 (Key AVP (rRK)) 397 (Key AVP (rMSK)) 398 <---------------------- 399 Diameter ERP/DEA 400 (EAP-Finish) 401 (Key AVP (rMSK)) 403 Figure 3: ERP Explicit Bootstrapping Message Flow 405 6. Re-Authentication 407 This section describes in detail a re-authentication exchange with an 408 ER server that was previously bootstrapped. The following figure 409 summarizes the re-authentication exchange. 411 ER server 412 Peer Authenticator (bootstrapped) 413 ==== ============= ====================== 414 [ <------------------------ ] 415 [optional EAP-Initiate/Re-auth-start,] 416 [ possibly with ERP domain name ] 418 -----------------------> 419 EAP-Initiate/Re-auth 420 ===============================> 421 Diameter ERP, cmd code DER 422 User-Name: Keyname-NAI 423 EAP-Payload: EAP-Initiate/Re-auth 425 <=============================== 426 Diameter ERP, cmd code DEA 427 EAP-Payload: EAP-Finish/Re-auth 428 Key AVP: rMSK 429 <---------------------- 430 EAP-Finish/Re-auth 432 Figure 4: Diameter ERP Re-authentication Exchange 434 The peer sends an EAP-Initiate/Re-auth message to the ER server via 435 the authenticator. Alternatively, the authenticator may send an EAP- 436 Initiate/Re-auth-Start message to the peer to trigger the mechanism. 437 In this case, the peer responds with an EAP-Initiate/Re-auth message. 439 If the authenticator does not support ERP (pure Diameter EAP 440 [RFC4072] support), it discards the EAP packets with an unknown ERP- 441 specific code (EAP-Initiate). The peer should fallback to full EAP 442 authentication in this case. 444 When the authenticator receives an EAP-Initiate/Re-auth message from 445 the peer, the message is processed as described in RFC 6696 with 446 regard to the EAP state machine. It creates a Diameter ERP/DER 447 message following the general process of Diameter EAP [RFC4072], with 448 the following differences: 450 The Application Id in the header is set to (code 451 TBD1 ). 453 The value in Auth-Application-Id AVP is also set to . 456 The keyName-NAI attribute from the ERP message is used to create 457 the content of the User-Name and Destination-Realm AVPs. 459 The Auth-Request-Type AVP content is set to the appropriate value. 461 The EAP-Payload AVP contains the EAP-Initiate/Re-Auth meassge. 463 Then this ERP/DER message is sent as described in Section 4. 465 The ER server receives and processes this request as described in 466 Section 4. It then creates an ERP/DEA message following the general 467 process described in RFC4072 [RFC4072], with the following 468 differences: 470 The Application Id in the header is set to (code 471 TBD1). 473 The value of the Auth-Application-Id AVP is also set to . 476 The EAP-Payload AVP contains the EAP-Finish/Re-auth message. 478 If authentication is successful, an instance of the Key AVP 479 containing the Re-authentication Master Session Key (rMSK) derived 480 by ERP is included. 482 When the authenticator receives this ERP/DEA answer, it processes it 483 as described in the Diameter EAP Application specification [RFC4072] 484 and RFC 6696: the content of the EAP-Payload AVP is forwarded to the 485 peer, and the contents of the Keying-Material AVP 486 [I-D.ietf-dime-local-keytran] is used as a shared secret for a secure 487 association protocol specific to the lower-layer in use. 489 7. Application Id 491 We define a new Diameter application in this document, Diameter ERP 492 Application, with an Application Id value of TBD1. Diameter nodes 493 conforming to this specification in the role of ER server MUST 494 advertise support by including an Auth-Application-Id AVP with a 495 value of Diameter ERP in the Capabilities-Exchange-Request and 496 Capabilities-Exchange-Answer commands [I-D.ietf-dime-rfc3588bis]. 498 The primary use of the Diameter ERP Application Id is to ensure 499 proper routing of the messages, and that the nodes that advertise the 500 support for this application do understand the new AVPs defined in 501 Section 8, although these AVP have the 'M' flag cleared. 503 8. AVPs 505 The following sub-sections discuss the AVPs used by the Diameter ERP 506 application. 508 8.1. ERP-RK-Request AVP 510 The ERP-RK-Request AVP (AVP Code TBD2) is of type grouped AVP. This 511 AVP is used by the ER server to indicate its willingness to act as ER 512 server for a particular session. 514 This AVP has the M and V bits cleared. 516 ERP-RK-Request ::= < AVP Header: TBD2 > 517 { ERP-Realm } 518 * [ AVP ] 520 Figure 5: ERP-RK-Request ABNF 522 8.2. ERP-Realm AVP 524 The ERP-Realm AVP (AVP Code TBD3) is of type DiameterIdentity. It 525 contains the name of the realm in which the ER server is located. 527 This AVP has the M and V bits cleared. 529 8.3. Key AVP 531 The Key AVP [I-D.ietf-dime-local-keytran] is of type "Grouped" and is 532 used to carry the rRK or rMSK and associated attributes. The usage 533 of the Key AVP and its constituent AVPs in this application is 534 specified in the following sub-sections. 536 8.3.1. Key-Type AVP 538 The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. 540 8.3.2. Keying-Material AVP 542 The Keying-Material AVP contains the rRK sent by the home EAP server 543 to the ER server, in answer to a request containing an ERP-RK-Request 544 AVP, or the rMSK sent by the ER server to the authenticator. How 545 this material is derived and used is specified in RFC 6696. 547 8.3.3. Key-Name AVP 549 This AVP contains the EMSKname which identifies the keying material. 550 The derivation of this name is specified in RFC 6696. 552 8.3.4. Key-Lifetime AVP 554 The Key-Lifetime AVP contains the lifetime of the keying material in 555 seconds. It MUST NOT be greater than the remaining lifetime of the 556 EMSK from which the material was derived. 558 9. Result-Code AVP Values 560 This section defines new Result-Code [I-D.ietf-dime-rfc3588bis] 561 values that MUST be supported by all Diameter implementations that 562 conform to this specification. 564 9.1. Permanent Failures 566 Errors that fall within the Permanent Failures category are used to 567 inform the peer that the request failed and SHOULD NOT be attempted 568 again. 570 DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4) 572 This error code is used by the Diameter server to inform the 573 peer that the received EAP-PAYLOAD AVP contains an EAP packet 574 with an unknown EAP code. 576 10. Contributors 578 Hannes Tschofenig wrote the initial draft of this document. 580 Lakshminath Dondeti contributed to the early versions of the 581 document. 583 11. Acknowledgements 585 Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies and Jouni 586 Korhonen provided useful reviews. 588 Vidya Narayanan reviewed a rough draft version of the document and 589 found some errors. 591 Many thanks to these people! 593 12. IANA Considerations 595 This document requires IANA registration of the following new 596 elements in the Authentication, Authorization, and Accounting (AAA) 597 Parameters [1] registries. 599 12.1. Diameter Application Identifier 601 This specification requires IANA to allocate a new value "Diameter 602 ERP" in the "Application IDs" registry using the policy specified in 603 Section 11.3 of RFC 3588 [RFC3588]. 605 12.2. New AVPs 607 This specification requires IANA to allocate new values from the "AVP 608 Codes" registry according to the policy specified in Section 11.1 of 609 Fajardo, et al. [I-D.ietf-dime-rfc3588bis] for the following AVPs: 611 ERP-RK-Request 613 ERP-Realm 615 These AVPs are defined in Section 8. 617 12.3. New Permanent Failures Result-Code AVP Values 619 This specification requires IANA to allocate a new value from the 620 "Result-Code AVP Values (code 268) - Permanent Failure" registry 621 according to the policy specified in Section 11.3.2 of Fajardo, et 622 al. [I-D.ietf-dime-rfc3588bis] for the following Result-Code: 624 DIAMETER_ERROR_EAP_CODE_UNKNOWN TBD4 626 This result-code value is defined in Section 9. 628 13. Security Considerations 630 The security considerations from the following documents apply here: 632 o Fajardo, et al. [I-D.ietf-dime-rfc3588bis] 634 o RFC 4072 [RFC4072] 636 o RFC 6696 [RFC6696] 638 o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran] 640 14. Normative References 642 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 643 "Diameter Attribute-Value Pairs for 644 Cryptographic Key Transport", 645 draft-ietf-dime-local-keytran-14 (work 646 in progress), August 2011. 648 [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., 649 and G. Zorn, "Diameter Base Protocol", 650 draft-ietf-dime-rfc3588bis-34 (work in 651 progress), June 2012. 653 [RFC2119] Bradner, S., "Key words for use in 654 RFCs to Indicate Requirement Levels", 655 BCP 14, RFC 2119, March 1997. 657 [RFC3588] Calhoun, P., Loughney, J., Guttman, 658 E., Zorn, G., and J. Arkko, "Diameter 659 Base Protocol", RFC 3588, 660 September 2003. 662 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 663 Carlson, J., and H. Levkowetz, 664 "Extensible Authentication Protocol 665 (EAP)", RFC 3748, June 2004. 667 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, 668 "Diameter Extensible Authentication 669 Protocol (EAP) Application", RFC 4072, 670 August 2005. 672 [RFC5295] Salowey, J., Dondeti, L., Narayanan, 673 V., and M. Nakhjiri, "Specification 674 for the Derivation of Root Keys from 675 an Extended Master Session Key 676 (EMSK)", RFC 5295, August 2008. 678 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and 679 G. Zorn, "EAP Extensions for the EAP 680 Re-authentication Protocol (ERP)", 681 RFC 6696, July 2012. 683 [1] 685 Authors' Addresses 687 Julien Bournelle 688 Orange Labs 689 38-40 rue du general Leclerc 690 Issy-Les-Moulineaux 92794 691 France 693 EMail: julien.bournelle@orange-ftgroup.com 695 Lionel Morand 696 Orange Labs 697 38-40 rue du general Leclerc 698 Issy-Les-Moulineaux 92794 699 France 701 EMail: lionel.morand@orange-ftgroup.com 703 Sebastien Decugis 704 INSIDE Secure 705 41 Parc Club du Golf 706 Aix-en-Provence 13856 707 France 709 Phone: +33 (0)4 42 39 63 00 710 EMail: sdecugis@freediameter.net 712 Qin Wu 713 Huawei Technologies Co., Ltd 714 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 715 Nanjing 210001 716 China 718 EMail: sunseawq@huawei.com 720 Glen Zorn 721 Network Zen 722 227/358 Thanon Sanphawut 723 Bang Na, Bangkok 10260 724 Thailand 726 EMail: glenzorn@gmail.com