idnits 2.17.00 (12 Aug 2021) /tmp/idnits25869/draft-ietf-dime-erp-09.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 (February 10, 2012) is 3753 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 278, 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: August 13, 2012 S. Decugis 6 INSIDE Secure 7 Q. Wu 8 Huawei 9 G. Zorn 10 Network Zen 11 February 10, 2012 13 Diameter Support for the EAP Re-authentication Protocol (ERP) 14 draft-ietf-dime-erp-09.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 August 13, 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 11.1. Diameter Application Identifier . . . . . . . . . . . . . 13 83 11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 13. Normative References . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 RFC5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP). 90 It consists of the following steps: 92 Bootstrapping 94 A root key for re-authentication is derived from the Extended 95 Master Session Key (EMSK) created during EAP authentication 96 [RFC5295]. This root key is transported from the EAP server to 97 the ER server. 99 Re-authentication 101 A one-round-trip exchange between the peer and the ER server, 102 resulting in mutual authentication. To support the EAP 103 reauthentication functionality, ERP defines two new EAP codes - 104 EAP-Initiate and EAP-Finish. 106 This document defines how Diameter transports the ERP messages during 107 the re-authentication process. For this purpose, we define a new 108 Application Identifier for ERP, and re-use the Diameter EAP commands 109 (DER/DEA). 111 This document also discusses the distribution of the root key during 112 bootstrapping, in conjunction with either the initial EAP 113 authentication (implicit bootstrapping) or the first ERP exchange 114 (explicit bootstrapping). Security considerations for this key 115 distribution are detailed in RFC 5295 [RFC5295]. 117 2. Terminology 119 This document uses terminology defined in RFC3748 [RFC3748], RFC5295 120 [RFC5295], RFC5296 [RFC5296], and RFC4072 [RFC4072]. 122 "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK 123 derived from an EMSK, depending on the location of the ER server in 124 home or foreign domain. 126 We use the notation "ERP/DER" and "ERP/DEA" in this document to refer 127 to Diameter-EAP-Request and Diameter-EAP-Answer commands with the 128 Application Id set to Section 11.1; the 129 same commands are denoted "EAP/DER" and "EAP/DEA" when the 130 Application Id in the message is set to 131 [RFC4072]. 133 2.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Assumptions 141 This document assumes the existence of at most one logical ER server 142 entity in a domain. If several physical servers are deployed for 143 robustness, a replication mechanism must be deployed to synchronize 144 the ERP states (root keys) between these servers. This replication 145 mechanism is out of the scope of this document. If multiple ER 146 servers are deployed in the domain, we assume that they can be used 147 interchangeably. If multiple ER servers are deployed across the 148 domains, we assume only one ER server that is near to the peer is 149 getting involved in the ERP. 151 Also this document assumes the existence of at most one EAP server 152 entity in the home domain. In case of multiple physical home EAP 153 servers in the same domain, if the ER server wants to reach the same 154 home EAP server, the ER server may cache the Destination-Host AVP 155 corresponding to the home EAP server it requests. 157 4. Protocol Overview 159 The following figure shows the components involved in ERP, and their 160 interactions. 162 Diameter +--------+ 163 +-------------+ ERP +-----------+ (*) | Home | 164 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 165 +-------------+ +-----------+ | server | 166 +--------+ 167 (*) Diameter EAP application, explicit bootstrapping scenario only. 169 Figure 1: Diameter ERP Overview. 171 The ER server is located either in the home domain (same as EAP 172 server) or in the visited domain (same as authenticator, when it 173 differs from the home domain). 175 When the peer initiates an ERP exchange, the authenticator creates a 176 Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of 177 the message is set to that of the Diameter ERP application 178 Section 11.1 in the message. The generation of the ERP/DER message 179 is detailed in Section 6. 181 If there is an ER server in the same domain as the authenticator 182 (i.e., the local domain), Diameter routing MUST be configured so that 183 this ERP/DER message reaches that server, even if the Destination- 184 Realm is not the same as local domain. 186 If there is no local ER server, the message is routed according to 187 its Destination-Realm AVP content, extracted from the realm component 188 of the keyName-NAI attribute. As specified in RFC5296 [RFC5296], 189 this realm is the home domain of the peer in the case of 190 bootstrapping exchange ('B' flag is set in ERP message) or the domain 191 of the bootstrapped ER server otherwise . 193 If no ER server is available in the home domain either, the ERP/DER 194 message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER 195 MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and 196 returned to the authenticator. The authenticator MAY cache this 197 information (with limited duration) to avoid further attempts to 198 execute ERP with this realm. It MAY also fallback to full EAP 199 authentication to authenticate the peer. 201 When an ER server receives the ERP/DER message, it searches its local 202 database for a valid, unexpired root key matching the keyName part of 203 the User-Name AVP. If such key is found, the ER server processes the 204 ERP message as described in [RFC5296] then creates the ERP/DEA answer 205 as described in Section 6. The rMSK is included in this answer. 207 Finally, the authenticator extracts the rMSK from the ERP/DEA as 208 described in RFC5296 [RFC5296], and forwards the content of the EAP- 209 Payload AVP, the EAP-Finish/Re-Auth message, to the peer. 211 The ER server may or may not possess the root key in its local 212 database. If the EAP-Initiate/Re-Auth message has its 'B' flag set 213 (Bootstrapping exchange) and the ER server possesses the root key, 214 the ER server SHOULD respond directly to the peer that initiated the 215 ERP exchange. Otherwise, the ER server SHOULD act as a proxy and 216 forward the message to the home EAP server after changing its 217 Application Id to Diameter EAP and adding the ERP-RK-Request AVP to 218 request the root key. See Section 5 for more detail on this process. 220 5. Bootstrapping the ER Server 222 The bootstrapping process involves the home EAP server and the ER 223 server, but also impacts the peer and the authenticator. In ERP, the 224 peer must derive the same keying material as the ER server. To 225 achieve this, it must learn the domain name of the ER server. How 226 this information is acquired is outside the scope of this 227 specification, but the authenticator might be configured to advertize 228 this domain name, especially in the case of re-authentication after a 229 handover. 231 The bootstrapping of an ER server with a given root key happens 232 either during the initial EAP authentication of the peer when the 233 EMSK -- from which the root key is derived -- is created, during the 234 first re-authentication, or sometime between those events. We only 235 consider the first two possibilities in this specification, in the 236 following sub-sections. 238 5.1. Bootstrapping During the Initial EAP authentication 240 Bootstrapping the ER server during the initial EAP authentication 241 (also known as implicit bootstrapping) offers the advantage that the 242 server is immediately available for re-authentication of the peer, 243 thus minimizing the re-authentication delay. On the other hand, it 244 is possible that only a small number of peers will use re- 245 authentication in the visited domain. Deriving and caching key 246 material for all the peers (for example, for the peers that do not 247 support ERP) is a waste of resources and should be avoided. 249 To achieve implicit bootstrapping, the ER server acts as a Diameter 250 EAP Proxy , and Diameter routing MUST be configured so that Diameter 251 EAP application messages are routed through this proxy. The figure 252 bellow illustrates this mechanism. 254 ER server & 255 Authenticator EAP Proxy Home EAP server 256 ============= =========== =============== 257 -------------------------> 258 Diameter EAP/DER 259 (EAP-Response) 260 -------------------------> 261 Diameter EAP/DER 262 (EAP-Response) 263 (ERP-RK-Request) 265 <==================================================> 266 Multi-round Diameter EAP exchanges, unmodified 268 <------------------------- 269 Diameter EAP/DEA 270 (EAP-Success) 271 (MSK) 272 (Key AVP (rRK)) 273 <------------------------- 274 Diameter EAP/DEA 275 (EAP-Success) 276 (MSK) 278 [ERP-Realm] 280 Figure 2: ERP Bootstrapping During Full EAP Authentication 282 The authenticator creates the first DER of the full EAP 283 authentication and sends it to the ER server. The ER server proxies 284 the first DER of the full EAP authentication and adds the ERP-RK- 285 Request AVP inside, then forwards the request to the home EAP server. 287 If the home Diameter server does not support the Diameter ERP 288 extensions, it simply ignores the ERP-RK-Request AVP and continues as 289 specified in RFC 4072 [RFC4072]. If the server supports the ERP 290 extensions, it saves the value of the ERP-Realm AVP found inside the 291 ERP-RK-Request AVP, and continues with the EAP authentication. When 292 the authentication completes, if it is successful and the EAP method 293 has generated an EMSK, the server MUST derive the rRK as specified in 294 RFC 5296 [RFC5296], using the saved domain name. It then includes 295 the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to 296 rRK, before sending the DEA as usual. 298 When the ER server proxies a Diameter-EAP-Answer message with a 299 Session-Id corresponding to a message to which it added an ERP-RK- 300 Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine 301 the message and save and remove any Key AVP (Section 8.3) with Key- 302 Type AVP set to rRK. If the message does not contain such Key AVP, 303 the ER server may cache the information that ERP is not possible for 304 this session to avoid possible subsequent attempts. In any case, the 305 information stored in ER server concerning a session should not have 306 a lifetime greater than the EMSK for this session. 308 If the ER server is successfully bootstrapped, it should also add the 309 ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the 310 EAP/DEA message. This ERP-Realm information can be used by the 311 authenticator to notify the peer that ER server is bootstrapped, and 312 for which domain. How this information can be transmitted to the 313 peer is outside the scope of this document. This information needs 314 to be sent to the peer if both implicit and explicit bootstrapping 315 mechanisms are possible, because the ERP message and the root key 316 used for protecting this message are different in bootstrapping 317 exchanges and non-bootstrapping exchanges. 319 5.2. Bootstrapping During the First Re-authentication 321 Bootstrapping the ER server during the first re-authentication (also 322 known as explicit bootstrapping) is only needed when there is no 323 local ER server in the visited domain and there is an ER server in 324 the home domain. It is less resource-intensive, since the EMSK 325 generated during initial EAP authentication is reused to derive root 326 keys. On the other hand, the first re-authentication requires a one- 327 round-trip exchange with the home EAP server, since the EMSK is 328 generated during the initial EAP authentication and never leaves the 329 home EAP server, which is less efficient than the implicit 330 bootstrapping scenario. 332 The EAP-Initiate/Re-auth message is sent to the home ER server. The 333 home ER server receives the ERP/DER message containing the EAP- 334 Initiate/Re-Auth message with the 'B' flag set. It creates the new 335 EAP/DER message using the received DRP/DER message and performs the 336 following processing: 338 Set the Application Id in the header of the message to [RFC4072] 341 Extract the ERP-RK-Request AVP from the ERP/DER message, which 342 contains the name of the domain where the ER server is located and 343 add it to the newly created ERP/DER message. 345 Then the newly created EAP/DER is sent and routed to the home 346 Diameter EAP application server. 348 If the home Diameter server does not support ERP extensions, it 349 replies with an error since the encapsulated ERP-RK-Request AVP is 350 not understood. Otherwise, it processes the DSRK request as 351 described in [RFC5296]. In particular, it includes the Domain- Name 352 TLV attribute with the content from the ERP-Realm AVP. The server 353 creates the EAP/DEA reply message [RFC4072] including an instance of 354 the Key AVP (Section 8.3) with Key-Type AVP set to rRK and an 355 instance of the Domain-Name TLV attribute with the content from the 356 ERP-Realm AVP. 358 The ER server receives this EAP/DEA and proxies it as follows, in 359 addition to standard proxy operations: 361 Set the Application Id back to Diameter ERP Application Id 362 (Section 11.1 ) 364 Extract and cache the content of the Key AVP with Key-Type set to 365 rRK, as described in the implicit scenario (Section 5.1). 367 The ERP/DEA message is then forwarded to the authenticator, that can 368 use the rMSK as described in RFC 5296 [RFC5296]. 370 The figure below captures this proxy behavior: 372 Authenticator ER server Home Diameter server 373 ============= ========= ==================== 374 -----------------------> 375 Diameter ERP/DER 376 (EAP-Initiate) 377 ------------------------> 378 Diameter EAP/DER 379 (EAP-Response) 380 (ERP-RK-Request) 382 <------------------------ 383 Diameter EAP/DEA 384 (EAP-Success) 385 (Key AVP (rRK)) 386 (Key AVP (rMSK)) 387 <---------------------- 388 Diameter ERP/DEA 389 (EAP-Finish) 390 (Key AVP (rMSK)) 392 Figure 3: ERP Explicit Bootstrapping Message Flow 394 6. Re-Authentication 396 This section describes in detail a re-authentication exchange with an 397 ER server that was previously bootstrapped. The following figure 398 summarizes the re-authentication exchange. 400 ER server 401 Peer Authenticator (bootstrapped) 402 ==== ============= ====================== 403 [ <------------------------ ] 404 [optional EAP-Initiate/Re-auth-start,] 405 [ possibly with ERP domain name ] 407 -----------------------> 408 EAP-Initiate/Re-auth 409 ===============================> 410 Diameter ERP, cmd code DER 411 User-Name: Keyname-NAI 412 EAP-Payload: EAP-Initiate/Re-auth 414 <=============================== 415 Diameter ERP, cmd code DEA 416 EAP-Payload: EAP-Finish/Re-auth 417 Key AVP: rMSK 418 <---------------------- 419 EAP-Finish/Re-auth 421 Figure 4: Diameter ERP Re-authentication Exchange 423 The peer sends an EAP-Initiate/Re-auth message to the ER server via 424 the authenticator. Alternatively, the authenticator may send an EAP- 425 Initiate/Re-auth-Start message to the peer to trigger the mechanism. 426 In this case, the peer responds with an EAP-Initiate/Re-auth message. 428 If the authenticator does not support ERP (pure Diameter EAP 429 [RFC4072] support), it discards the EAP packets with an unknown ERP- 430 specific code (EAP-Initiate). The peer should fallback to full EAP 431 authentication in this case. 433 When the authenticator receives an EAP-Initiate/Re-auth message from 434 the peer, the message is processed as described in [RFC5296] with 435 regard to the EAP state machine. It creates a Diameter ERP/DER 436 message following the general process of Diameter EAP [RFC4072], with 437 the following differences: 439 The Application Id in the header is set to (code 440 TBD ). 442 The value in Auth-Application-Id AVP is also set to . 445 The keyName-NAI attribute from the ERP message is used to create 446 the content of the User-Name and Destination-Realm AVPs. 448 The Auth-Request-Type AVP content is set to the appropriate value. 450 The EAP-Payload AVP contains the EAP-Initiate/Re-Auth meassge. 452 Then this ERP/DER message is sent as described in Section 4. 454 The ER server receives and processes this request as described in 455 Section 4. It then creates an ERP/DEA message following the general 456 process described in RFC4072 [RFC4072], with the following 457 differences: 459 The Application Id in the header is set to (code 460 TBD). 462 The value of the Auth-Application-Id AVP is also set to . 465 The EAP-Payload AVP contains the EAP-Finish/Re-auth message. 467 If authentication is successful, an instance of the Key AVP 468 containing the Re-authentication Master Session Key (rMSK) derived 469 by ERP is included. 471 When the authenticator receives this ERP/DEA answer, it processes it 472 as described in Diameter EAP [RFC4072] and RFC5296 [RFC5296]: the 473 content of the EAP-Payload AVP is forwarded to the peer, and the 474 contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is 475 used as a shared secret for a secure association protocol specific to 476 the lower-layer in use. 478 7. Application Id 480 We define a new Diameter application in this document, Diameter ERP 481 Application, with an Application Id value of TBD. Diameter nodes 482 conforming to this specification in the role of ER server MUST 483 advertise support by including an Auth-Application-Id AVP with a 484 value of Diameter ERP in the Capabilities-Exchange-Request and 485 Capabilities-Exchange-Answer commands [I-D.ietf-dime-rfc3588bis]. 487 The primary use of the Diameter ERP Application Id is to ensure 488 proper routing of the messages, and that the nodes that advertise the 489 support for this application do understand the new AVPs defined in 490 Section 8, although these AVP have the 'M' flag cleared. 492 8. AVPs 494 The following sub-sections discuss the AVPs used by the Diameter ERP 495 application. 497 8.1. ERP-RK-Request AVP 499 The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This 500 AVP is used by the ER server to indicate its willingness to act as ER 501 server for a particular session. 503 This AVP has the M and V bits cleared. 505 ERP-RK-Request ::= < AVP Header: TBD > 506 { ERP-Realm } 507 * [ AVP ] 509 Figure 5: ERP-RK-Request ABNF 511 8.2. ERP-Realm AVP 513 The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It 514 contains the name of the realm in which the ER server is located. 516 This AVP has the M and V bits cleared. 518 8.3. Key AVP 520 The Key AVP [I-D.ietf-dime-local-keytran] is of type "Grouped" and is 521 used to carry the rRK or rMSK and associated attributes. The usage 522 of the Key AVP and its constituent AVPs in this application is 523 specified in the following sub-sections. 525 8.3.1. Key-Type AVP 527 The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK. 529 8.3.2. Keying-Material AVP 531 The Keying-Material AVP contains the rRK sent by the home EAP server 532 to the ER server, in answer to a request containing an ERP-RK-Request 533 AVP, or the rMSK sent by the ER server to the authenticator. How 534 this material is derived and used is specified in RFC 5296 [RFC5296]. 536 8.3.3. Key-Name AVP 538 This AVP contains the EMSKname which identifies the keying material. 539 The derivation of this name is specified in RGC 5296 [RFC5296]. 541 8.3.4. Key-Lifetime AVP 543 The Key-Lifetime AVP contains the lifetime of the keying material in 544 seconds. It MUST NOT be greater than the remaining lifetime of the 545 EMSK from which the material was derived. 547 9. Contributors 549 Hannes Tschofenig wrote the initial draft of this document. 551 Lakshminath Dondeti contributed to the early versions of the 552 document. 554 10. Acknowledgements 556 Hannes Tschofenig provided useful reviews. 558 Vidya Narayanan reviewed a rough draft version of the document and 559 found some errors. 561 Many thanks to these people! 563 11. IANA Considerations 565 This document requires IANA registration of the following new 566 elements in the Authentication, Authorization, and Accounting (AAA) 567 Parameters [1] registries. 569 11.1. Diameter Application Identifier 571 This specification requires IANA to allocate a new value "Diameter 572 ERP" in the "Application IDs" registry using the policy specified in 573 Section 11.3 of RFC 3588 [RFC3588]. 575 11.2. New AVPs 577 This specification requires IANA to allocate new values from the "AVP 578 Codes" registry according to the policy specified in Section 11.1 of 579 Fajardo, et al. [I-D.ietf-dime-rfc3588bis] for the following AVPs: 581 ERP-RK-Request 582 ERP-Realm 584 These AVPs are defined in Section 8. 586 12. Security Considerations 588 The security considerations from the following documents apply here: 590 o Fajardo, et al. [I-D.ietf-dime-rfc3588bis] 592 o RFC 4072 [RFC4072] 594 o RFC 5296 [RFC5296] 596 o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran] 598 13. Normative References 600 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 601 "Diameter Attribute-Value Pairs for 602 Cryptographic Key Transport", 603 draft-ietf-dime-local-keytran-14 (work 604 in progress), August 2011. 606 [I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., 607 and G. Zorn, "Diameter Base Protocol", 608 draft-ietf-dime-rfc3588bis-29 (work in 609 progress), August 2011. 611 [RFC2119] Bradner, S., "Key words for use in 612 RFCs to Indicate Requirement Levels", 613 BCP 14, RFC 2119, March 1997. 615 [RFC3588] Calhoun, P., Loughney, J., Guttman, 616 E., Zorn, G., and J. Arkko, "Diameter 617 Base Protocol", RFC 3588, 618 September 2003. 620 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 621 Carlson, J., and H. Levkowetz, 622 "Extensible Authentication Protocol 623 (EAP)", RFC 3748, June 2004. 625 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, 626 "Diameter Extensible Authentication 627 Protocol (EAP) Application", RFC 4072, 628 August 2005. 630 [RFC5295] Salowey, J., Dondeti, L., Narayanan, 631 V., and M. Nakhjiri, "Specification 632 for the Derivation of Root Keys from 633 an Extended Master Session Key 634 (EMSK)", RFC 5295, August 2008. 636 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 637 Extensions for EAP Re-authentication 638 Protocol (ERP)", RFC 5296, 639 August 2008. 641 [1] 643 Authors' Addresses 645 Julien Bournelle 646 Orange Labs 647 38-40 rue du general Leclerc 648 Issy-Les-Moulineaux 92794 649 France 651 EMail: julien.bournelle@orange-ftgroup.com 653 Lionel Morand 654 Orange Labs 655 38-40 rue du general Leclerc 656 Issy-Les-Moulineaux 92794 657 France 659 EMail: lionel.morand@orange-ftgroup.com 661 Sebastien Decugis 662 INSIDE Secure 663 41 Parc Club du Golf 664 Aix-en-Provence 13856 665 France 667 Phone: +33 (0)4 42 39 63 00 668 EMail: sdecugis@freediameter.net 669 Qin Wu 670 Huawei Technologies Co., Ltd 671 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 672 Nanjing 210001 673 China 675 EMail: sunseawq@huawei.com 677 Glen Zorn 678 Network Zen 679 227/358 Thanon Sanphawut 680 Bang Na, Bangkok 10260 681 Thailand 683 EMail: glenzorn@gmail.com