idnits 2.17.00 (12 Aug 2021) /tmp/idnits27745/draft-ietf-dime-erp-10.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 (June 3, 2012) is 3639 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 281, 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) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 2 errors (**), 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: December 5, 2012 S. Decugis 6 INSIDE Secure 7 Q. Wu 8 Huawei 9 G. Zorn 10 Network Zen 11 June 3, 2012 13 Diameter Support for the EAP Re-authentication Protocol (ERP) 14 draft-ietf-dime-erp-10.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 December 5, 2012. 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 . . . . . 7 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 RFC5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP). 93 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 RFC 5295 [RFC5295]. 120 2. Terminology 122 This document uses terminology defined in RFC3748 [RFC3748], RFC5295 123 [RFC5295], RFC5296 [RFC5296], and RFC4072 [RFC4072]. 125 "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK 126 derived from an EMSK, depending on the location of the ER server in 127 home or foreign domain. 129 We use the notation "ERP/DER" and "ERP/DEA" in this document to refer 130 to Diameter-EAP-Request and Diameter-EAP-Answer commands with the 131 Application Id set to Section 12.1; the 132 same commands are denoted "EAP/DER" and "EAP/DEA" when the 133 Application Id in the message is set to 134 [RFC4072]. 136 2.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Assumptions 144 This document assumes the existence of at most one logical ER server 145 entity in a domain. If several physical servers are deployed for 146 robustness, a replication mechanism must be deployed to synchronize 147 the ERP states (root keys) between these servers. This replication 148 mechanism is out of the scope of this document. If multiple ER 149 servers are deployed in the domain, we assume that they can be used 150 interchangeably. If multiple ER servers are deployed across the 151 domains, we assume only one ER server that is near to the peer is 152 getting involved in the ERP. 154 Also this document assumes the existence of at most one EAP server 155 entity in the home domain. In case of multiple physical home EAP 156 servers in the same domain, if the ER server wants to reach the same 157 home EAP server, the ER server may cache the Destination-Host AVP 158 corresponding to the home EAP server it requests. 160 4. Protocol Overview 162 The following figure shows the components involved in ERP, and their 163 interactions. 165 Diameter +--------+ 166 +-------------+ ERP +-----------+ (*) | Home | 167 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 168 +-------------+ +-----------+ | server | 169 +--------+ 170 (*) Diameter EAP application, explicit bootstrapping scenario only. 172 Figure 1: Diameter ERP Overview. 174 The ER server is located either in the home domain (same as EAP 175 server) or in the visited domain (same as authenticator, when it 176 differs from the home domain). 178 When the peer initiates an ERP exchange, the authenticator creates a 179 Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of 180 the message is set to that of the Diameter ERP application 181 Section 12.1 in the message. The generation of the ERP/DER message 182 is detailed in Section 6. 184 If there is an ER server in the same domain as the authenticator 185 (i.e., the local domain), Diameter routing MUST be configured so that 186 this ERP/DER message reaches that server, even if the Destination- 187 Realm is not the same as local domain. 189 If there is no local ER server, the message is routed according to 190 its Destination-Realm AVP content, extracted from the realm component 191 of the keyName-NAI attribute. As specified in RFC5296 [RFC5296], 192 this realm is the home domain of the peer in the case of 193 bootstrapping exchange ('B' flag is set in ERP message) or the domain 194 of the bootstrapped ER server otherwise . 196 If no ER server is available in the home domain either, the ERP/DER 197 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER 198 MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and 199 returned to the authenticator. The authenticator MAY cache this 200 information (with limited duration) to avoid further attempts to 201 execute ERP with this realm. It MAY also fallback to full EAP 202 authentication to authenticate the peer. 204 When an ER server receives the ERP/DER message, it searches its local 205 database for a valid, unexpired root key matching the keyName part of 206 the User-Name AVP. If such key is found, the ER server processes the 207 ERP message as described in [RFC5296] then creates the ERP/DEA answer 208 as described in Section 6. The rMSK is included in this answer. 210 Finally, the authenticator extracts the rMSK from the ERP/DEA as 211 described in RFC5296 [RFC5296], and forwards the content of the EAP- 212 Payload AVP, the EAP-Finish/Re-Auth message, to the peer. 214 The ER server may or may not possess the root key in its local 215 database. If the EAP-Initiate/Re-Auth message has its 'B' flag set 216 (Bootstrapping exchange) and the ER server possesses the root key, 217 the ER server SHOULD respond directly to the peer that initiated the 218 ERP exchange. Otherwise, the ER server SHOULD act as a proxy and 219 forward the message to the home EAP server after changing its 220 Application Id to Diameter EAP and adding the ERP-RK-Request AVP to 221 request the root key. See Section 5 for more detail on this process. 223 5. Bootstrapping the ER Server 225 The bootstrapping process involves the home EAP server and the ER 226 server, but also impacts the peer and the authenticator. In ERP, the 227 peer must derive the same keying material as the ER server. To 228 achieve this, it must learn the domain name of the ER server. How 229 this information is acquired is outside the scope of this 230 specification, but the authenticator might be configured to advertize 231 this domain name, especially in the case of re-authentication after a 232 handover. 234 The bootstrapping of an ER server with a given root key happens 235 either during the initial EAP authentication of the peer when the 236 EMSK -- from which the root key is derived -- is created, during the 237 first re-authentication, or sometime between those events. We only 238 consider the first two possibilities in this specification, in the 239 following sub-sections. 241 5.1. Bootstrapping During the Initial EAP authentication 243 Bootstrapping the ER server during the initial EAP authentication 244 (also known as implicit bootstrapping) offers the advantage that the 245 server is immediately available for re-authentication of the peer, 246 thus minimizing the re-authentication delay. On the other hand, it 247 is possible that only a small number of peers will use re- 248 authentication in the visited domain. Deriving and caching key 249 material for all the peers (for example, for the peers that do not 250 support ERP) is a waste of resources and should be avoided. 252 To achieve implicit bootstrapping, the ER server acts as a Diameter 253 EAP Proxy , and Diameter routing MUST be configured so that Diameter 254 EAP application messages are routed through this proxy. The figure 255 bellow illustrates this mechanism. 257 ER server & 258 Authenticator EAP Proxy Home EAP server 259 ============= =========== =============== 260 -------------------------> 261 Diameter EAP/DER 262 (EAP-Response) 263 -------------------------> 264 Diameter EAP/DER 265 (EAP-Response) 266 (ERP-RK-Request) 268 <==================================================> 269 Multi-round Diameter EAP exchanges, unmodified 271 <------------------------- 272 Diameter EAP/DEA 273 (EAP-Success) 274 (MSK) 275 (Key AVP (rRK)) 276 <------------------------- 277 Diameter EAP/DEA 278 (EAP-Success) 279 (MSK) 281 [ERP-Realm] 283 Figure 2: ERP Bootstrapping During Full EAP Authentication 285 The authenticator creates the first DER of the full EAP 286 authentication and sends it to the ER server. The ER server proxies 287 the first DER of the full EAP authentication and adds the ERP-RK- 288 Request AVP inside, then forwards the request to the home EAP server. 290 If the home Diameter server does not support the Diameter ERP 291 extensions, it simply ignores the ERP-RK-Request AVP and continues as 292 specified in RFC 4072 [RFC4072]. If the server supports the ERP 293 extensions, it saves the value of the ERP-Realm AVP found inside the 294 ERP-RK-Request AVP, and continues with the EAP authentication. When 295 the authentication completes, if it is successful and the EAP method 296 has generated an EMSK, the server MUST derive the rRK as specified in 297 RFC 5296 [RFC5296], using the saved domain name. It then includes 298 the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to 299 rRK, before sending the DEA as usual. 301 When the ER server proxies a Diameter-EAP-Answer message with a 302 Session-Id corresponding to a message to which it added an ERP-RK- 303 Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine 304 the message and save and remove any Key AVP (Section 8.3) with Key- 305 Type AVP set to rRK. If the message does not contain such Key AVP, 306 the ER server may cache the information that ERP is not possible for 307 this session to avoid possible subsequent attempts. In any case, the 308 information stored in ER server concerning a session should not have 309 a lifetime greater than the EMSK for this session. 311 If the ER server is successfully bootstrapped, it should also add the 312 ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the 313 EAP/DEA message. This ERP-Realm information can be used by the 314 authenticator to notify the peer that ER server is bootstrapped, and 315 for which domain. How this information can be transmitted to the 316 peer is outside the scope of this document. This information needs 317 to be sent to the peer if both implicit and explicit bootstrapping 318 mechanisms are possible, because the ERP message and the root key 319 used for protecting this message are different in bootstrapping 320 exchanges and non-bootstrapping exchanges. 322 5.2. Bootstrapping During the First Re-authentication 324 Bootstrapping the ER server during the first re-authentication (also 325 known as explicit bootstrapping) is only needed when there is no 326 local ER server in the visited domain and there is an ER server in 327 the home domain. It is less resource-intensive, since the EMSK 328 generated during initial EAP authentication is reused to derive root 329 keys. On the other hand, the first re-authentication requires a one- 330 round-trip exchange with the home EAP server, since the EMSK is 331 generated during the initial EAP authentication and never leaves the 332 home EAP server, which is less efficient than the implicit 333 bootstrapping scenario. 335 The EAP-Initiate/Re-auth message is sent to the home ER server. The 336 home ER server receives the ERP/DER message containing the EAP- 337 Initiate/Re-Auth message with the 'B' flag set. It creates the new 338 EAP/DER message using the received DRP/DER message and performs the 339 following processing: 341 Set the Application Id in the header of the message to [RFC4072] 344 Extract the ERP-RK-Request AVP from the ERP/DER message, which 345 contains the name of the domain where the ER server is located and 346 add it to the newly created ERP/DER message. 348 Then the newly created EAP/DER is sent and routed to the home 349 Diameter EAP application server. 351 If the home Diameter EAP server does not support ERP extensions, EAP 352 packets with an unknown ERP-specific code (EAP-Initiate) are not 353 understood. In such a case, the home Diameter EAP server MUST send 354 an EAP/DEA with a Result-Code set to DIAMETER_ERROR_EAP_CODE_UNKNOWN. 355 The Failed-AVP AVP MUST be included and contain a copy of the EAP- 356 Payload AVP. Otherwise, it processes the DSRK request as described 357 in [RFC5296]. In particular, it includes the Domain- Name TLV 358 attribute with the content from the ERP-Realm AVP. The server 359 creates the EAP/DEA reply message [RFC4072] including an instance of 360 the Key AVP (Section 8.3) with Key-Type AVP set to rRK and an 361 instance of the Domain-Name TLV attribute with the content from the 362 ERP-Realm AVP. 364 The ER server receives this EAP/DEA and proxies it as follows, in 365 addition to standard proxy operations: 367 Set the Application Id back to Diameter ERP Application Id 368 (Section 12.1 ) 370 Extract and cache the content of the Key AVP with Key-Type set to 371 rRK, as described in the implicit scenario (Section 5.1). 373 The ERP/DEA message is then forwarded to the authenticator, that can 374 use the rMSK as described in RFC 5296 [RFC5296]. 376 The figure below captures this proxy behavior: 378 Authenticator ER server Home Diameter server 379 ============= ========= ==================== 380 -----------------------> 381 Diameter ERP/DER 382 (EAP-Initiate) 383 ------------------------> 384 Diameter EAP/DER 385 (EAP-Response) 386 (ERP-RK-Request) 388 <------------------------ 389 Diameter EAP/DEA 390 (EAP-Success) 391 (Key AVP (rRK)) 392 (Key AVP (rMSK)) 393 <---------------------- 394 Diameter ERP/DEA 395 (EAP-Finish) 396 (Key AVP (rMSK)) 398 Figure 3: ERP Explicit Bootstrapping Message Flow 400 6. Re-Authentication 402 This section describes in detail a re-authentication exchange with an 403 ER server that was previously bootstrapped. The following figure 404 summarizes the re-authentication exchange. 406 ER server 407 Peer Authenticator (bootstrapped) 408 ==== ============= ====================== 409 [ <------------------------ ] 410 [optional EAP-Initiate/Re-auth-start,] 411 [ possibly with ERP domain name ] 413 -----------------------> 414 EAP-Initiate/Re-auth 415 ===============================> 416 Diameter ERP, cmd code DER 417 User-Name: Keyname-NAI 418 EAP-Payload: EAP-Initiate/Re-auth 420 <=============================== 421 Diameter ERP, cmd code DEA 422 EAP-Payload: EAP-Finish/Re-auth 423 Key AVP: rMSK 424 <---------------------- 425 EAP-Finish/Re-auth 427 Figure 4: Diameter ERP Re-authentication Exchange 429 The peer sends an EAP-Initiate/Re-auth message to the ER server via 430 the authenticator. Alternatively, the authenticator may send an EAP- 431 Initiate/Re-auth-Start message to the peer to trigger the mechanism. 432 In this case, the peer responds with an EAP-Initiate/Re-auth message. 434 If the authenticator does not support ERP (pure Diameter EAP 435 [RFC4072] support), it discards the EAP packets with an unknown ERP- 436 specific code (EAP-Initiate). The peer should fallback to full EAP 437 authentication in this case. 439 When the authenticator receives an EAP-Initiate/Re-auth message from 440 the peer, the message is processed as described in [RFC5296] with 441 regard to the EAP state machine. It creates a Diameter ERP/DER 442 message following the general process of Diameter EAP [RFC4072], with 443 the following differences: 445 The Application Id in the header is set to (code 446 TBD ). 448 The value in Auth-Application-Id AVP is also set to . 451 The keyName-NAI attribute from the ERP message is used to create 452 the content of the User-Name and Destination-Realm AVPs. 454 The Auth-Request-Type AVP content is set to the appropriate value. 456 The EAP-Payload AVP contains the EAP-Initiate/Re-Auth meassge. 458 Then this ERP/DER message is sent as described in Section 4. 460 The ER server receives and processes this request as described in 461 Section 4. It then creates an ERP/DEA message following the general 462 process described in RFC4072 [RFC4072], with the following 463 differences: 465 The Application Id in the header is set to (code 466 TBD). 468 The value of the Auth-Application-Id AVP is also set to . 471 The EAP-Payload AVP contains the EAP-Finish/Re-auth message. 473 If authentication is successful, an instance of the Key AVP 474 containing the Re-authentication Master Session Key (rMSK) derived 475 by ERP is included. 477 When the authenticator receives this ERP/DEA answer, it processes it 478 as described in Diameter EAP [RFC4072] and RFC5296 [RFC5296]: the 479 content of the EAP-Payload AVP is forwarded to the peer, and the 480 contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is 481 used as a shared secret for a secure association protocol specific to 482 the lower-layer in use. 484 7. Application Id 486 We define a new Diameter application in this document, Diameter ERP 487 Application, with an Application Id value of TBD. Diameter nodes 488 conforming to this specification in the role of ER server MUST 489 advertise support by including an Auth-Application-Id AVP with a 490 value of Diameter ERP in the Capabilities-Exchange-Request and 491 Capabilities-Exchange-Answer commands [I-D.ietf-dime-rfc3588bis]. 493 The primary use of the Diameter ERP Application Id is to ensure 494 proper routing of the messages, and that the nodes that advertise the 495 support for this application do understand the new AVPs defined in 496 Section 8, although these AVP have the 'M' flag cleared. 498 8. AVPs 500 The following sub-sections discuss the AVPs used by the Diameter ERP 501 application. 503 8.1. ERP-RK-Request AVP 505 The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This 506 AVP is used by the ER server to indicate its willingness to act as ER 507 server for a particular session. 509 This AVP has the M and V bits cleared. 511 ERP-RK-Request ::= < AVP Header: TBD > 512 { ERP-Realm } 513 * [ AVP ] 515 Figure 5: ERP-RK-Request ABNF 517 8.2. ERP-Realm AVP 519 The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It 520 contains the name of the realm in which the ER server is located. 522 This AVP has the M and V bits cleared. 524 8.3. Key AVP 526 The Key AVP [I-D.ietf-dime-local-keytran] is of type "Grouped" and is 527 used to carry the rRK or rMSK and associated attributes. The usage 528 of the Key AVP and its constituent AVPs in this application is 529 specified in the following sub-sections. 531 8.3.1. Key-Type AVP 533 The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. 535 8.3.2. Keying-Material AVP 537 The Keying-Material AVP contains the rRK sent by the home EAP server 538 to the ER server, in answer to a request containing an ERP-RK-Request 539 AVP, or the rMSK sent by the ER server to the authenticator. How 540 this material is derived and used is specified in RFC 5296 [RFC5296]. 542 8.3.3. Key-Name AVP 544 This AVP contains the EMSKname which identifies the keying material. 545 The derivation of this name is specified in RGC 5296 [RFC5296]. 547 8.3.4. Key-Lifetime AVP 549 The Key-Lifetime AVP contains the lifetime of the keying material in 550 seconds. It MUST NOT be greater than the remaining lifetime of the 551 EMSK from which the material was derived. 553 9. Result-Code AVP Values 555 This section defines new Result-Code [I-D.ietf-dime-rfc3588bis] 556 values that MUST be supported by all Diameter implementations that 557 conform to this specification. 559 9.1. Permanent Failures 561 Errors that fall within the Permanent Failures category are used to 562 inform the peer that the request failed and SHOULD NOT be attempted 563 again. 565 DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD) 567 This error code is used by the Diameter server to inform the 568 peer that the received EAP-PAYLOAD AVP contains an EAP packet 569 with an unknown EAP code. 571 10. Contributors 573 Hannes Tschofenig wrote the initial draft of this document. 575 Lakshminath Dondeti contributed to the early versions of the 576 document. 578 11. Acknowledgements 580 Hannes Tschofenig provided useful reviews. 582 Vidya Narayanan reviewed a rough draft version of the document and 583 found some errors. 585 Many thanks to these people! 587 12. IANA Considerations 589 This document requires IANA registration of the following new 590 elements in the Authentication, Authorization, and Accounting (AAA) 591 Parameters [1] registries. 593 12.1. Diameter Application Identifier 595 This specification requires IANA to allocate a new value "Diameter 596 ERP" in the "Application IDs" registry using the policy specified in 597 Section 11.3 of RFC 3588 [RFC3588]. 599 12.2. New AVPs 601 This specification requires IANA to allocate new values from the "AVP 602 Codes" registry according to the policy specified in Section 11.1 of 603 Fajardo, et al. [I-D.ietf-dime-rfc3588bis] for the following AVPs: 605 ERP-RK-Request 607 ERP-Realm 609 These AVPs are defined in Section 8. 611 12.3. New Permanent Failures Result-Code AVP Values 613 This specification requires IANA to allocate a new value from the 614 "Result-Code AVP Values (code 268) - Permanent Failure" registry 615 according to the policy specified in Section 11.3.2 of Fajardo, et 616 al. [I-D.ietf-dime-rfc3588bis] for the following Result-Code: 618 DIAMETER_ERROR_EAP_CODE_UNKNOWN TBD 620 This result-code value is defined in Section 9. 622 13. Security Considerations 624 The security considerations from the following documents apply here: 626 o Fajardo, et al. [I-D.ietf-dime-rfc3588bis] 628 o RFC 4072 [RFC4072] 630 o RFC 5296 [RFC5296] 632 o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran] 634 14. Normative References 636 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 637 "Diameter Attribute-Value Pairs for 638 Cryptographic Key Transport", 639 draft-ietf-dime-local-keytran-14 (work 640 in progress), August 2011. 642 [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., 643 and G. Zorn, "Diameter Base Protocol", 644 draft-ietf-dime-rfc3588bis-33 (work in 645 progress), May 2012. 647 [RFC2119] Bradner, S., "Key words for use in 648 RFCs to Indicate Requirement Levels", 649 BCP 14, RFC 2119, March 1997. 651 [RFC3588] Calhoun, P., Loughney, J., Guttman, 652 E., Zorn, G., and J. Arkko, "Diameter 653 Base Protocol", RFC 3588, 654 September 2003. 656 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 657 Carlson, J., and H. Levkowetz, 658 "Extensible Authentication Protocol 659 (EAP)", RFC 3748, June 2004. 661 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, 662 "Diameter Extensible Authentication 663 Protocol (EAP) Application", RFC 4072, 664 August 2005. 666 [RFC5295] Salowey, J., Dondeti, L., Narayanan, 667 V., and M. Nakhjiri, "Specification 668 for the Derivation of Root Keys from 669 an Extended Master Session Key 670 (EMSK)", RFC 5295, August 2008. 672 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 673 Extensions for EAP Re-authentication 674 Protocol (ERP)", RFC 5296, 675 August 2008. 677 [1] 679 Authors' Addresses 681 Julien Bournelle 682 Orange Labs 683 38-40 rue du general Leclerc 684 Issy-Les-Moulineaux 92794 685 France 687 EMail: julien.bournelle@orange-ftgroup.com 689 Lionel Morand 690 Orange Labs 691 38-40 rue du general Leclerc 692 Issy-Les-Moulineaux 92794 693 France 695 EMail: lionel.morand@orange-ftgroup.com 697 Sebastien Decugis 698 INSIDE Secure 699 41 Parc Club du Golf 700 Aix-en-Provence 13856 701 France 703 Phone: +33 (0)4 42 39 63 00 704 EMail: sdecugis@freediameter.net 706 Qin Wu 707 Huawei Technologies Co., Ltd 708 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 709 Nanjing 210001 710 China 712 EMail: sunseawq@huawei.com 714 Glen Zorn 715 Network Zen 716 227/358 Thanon Sanphawut 717 Bang Na, Bangkok 10260 718 Thailand 720 EMail: glenzorn@gmail.com