idnits 2.17.00 (12 Aug 2021) /tmp/idnits24510/draft-sdecugis-dime-diameter-erp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Line 793 has weird spacing: '...ver and home ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The ERP-RK-Lifetime AVP (AVP Code [[IANA7: TBD]]) is of type [[Editor6: Unsigned64? 32?]] and contains the root key material remaining lifetime in seconds. It MUST not be greater than the remaining lifetime of the EMSK it is derived from. [[Editor7: FFS: is it better to pass an absolute value here, for example expiration date? How to express it then (TZ, ...)? Synchronization problems?]] -- The document date (June 8, 2009) is 4730 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 417, but not defined == Unused Reference: 'I-D.gaonkar-radext-erp-attrs' is defined on line 765, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 797, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) == Outdated reference: draft-ietf-dime-app-design-guide has been published as RFC 7423 == Outdated reference: draft-ietf-dime-erp has been published as RFC 6942 == Outdated reference: draft-ietf-hokey-key-mgm has been published as RFC 5749 == Outdated reference: A later version (-03) exists of draft-wu-dime-local-keytran-00 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and S. Decugis, Ed. 3 Extensions (DIME) NICT 4 Internet-Draft June 8, 2009 5 Intended status: Standards Track 6 Expires: December 10, 2009 8 Diameter support for EAP Re-authentication Protocol (ERP) 9 draft-sdecugis-dime-diameter-erp-01 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 10, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The EAP Re-authentication Protocol (ERP) provides a mechanism to 48 optimize EAP authentication delay in the case of re-authentication, 49 which can be significant in roaming mobile situation. This mechanism 50 assumes that a protocol for Authentication, Authorization and 51 Accounting (AAA) is available to transport ERP between the 52 authenticator(s) and the EAP/ERP server. 53 draft-gaonkar-radext-erp-attrs-03 specifies the transport of ERP 54 using RADIUS. This document specifies the transport of ERP using 55 Diameter. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Differences with other documents . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 6 67 5.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 6 68 5.3. ERP-RK-Answer AVP . . . . . . . . . . . . . . . . . . . . 6 69 5.4. ERP-RK AVP . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.5. ERP-RK-Name AVP . . . . . . . . . . . . . . . . . . . . . 7 71 5.6. ERP-RK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 7 72 6. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7. Bootstrapping options . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Bootstrapping during initial EAP authentication . . . . . 8 75 7.2. Bootstrapping during first re-authentication . . . . . . . 10 76 8. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 12 77 9. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 12.1. Diameter ERP application . . . . . . . . . . . . . . . . . 15 82 12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 [RFC5296] defines the EAP Re-authentication Protocol (ERP) and 91 mechanism that consists in the two following steps: 93 1. Bootstrapping: creation of a root key for re-authentication, 94 after initial EAP authentication of the peer. This root key is 95 distributed from the EAP server to the ER server. How this key 96 is tranported is not specified in the ERP mechanism. 98 2. Re-authentication: one-round-trip exchange between the peer and 99 the ER server, functionally equivalent to a full EAP 100 authentication. 102 This document specifies how Diameter is used to carry the re- 103 authentication exchange (second step). For this purpose, we define a 104 new Application Id for ERP, and re-use the Diameter EAP commands 105 (DER/DEA). 107 We also discuss the key distribution (first step, bootstrapping) and 108 propose some solutions for different architectures. Anyway, 109 implementors are free to choose a different mechanism for key 110 distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm]. 111 Security considerations for key distribution are explained in 112 [RFC5295]. 114 1.1. Differences with other documents 116 This document differs from [I-D.ietf-dime-erp] in its design and 117 scope. In this new version, we use a new Diameter application id for 118 messages with ERP payload exchanged between authenticator and ER 119 server. This simplifies the routing of Diameter messages to the 120 appropriate server, and allows more flexibility in the deployment of 121 ERP. 123 The scope of previous documents ([I-D.ietf-dime-erp] and 124 [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the 125 mechanism. In particular, these documents did not consider the 126 routing of Diameter message for re-authentication exchanges (ERP 127 exchange, and also [RFC4187] for the second document). By re-using 128 the Diameter EAP application, they create implicit constraints on 129 routing of messages that cannot be met by standard Diameter routing 130 algorithm, as defined in the Diameter Base Protocol [RFC3588]. 132 A separate Diameter application solves this routing issue, and can 133 also allow the authenticator to dynamically discover if the local 134 domain supports re-authentication or not. 136 2. Terminology 138 We re-use in this document the terminology from [RFC5296]. In 139 particular, unless specified otherwise, the EAP server has implicit 140 support for ERP extensions for generation of ERP keying material and 141 its transmission to ER server. These terms "authenticator", "ER 142 server", "EAP server" designate logical functional entities and make 143 no assumption on the real implementation and deployment. 145 "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK 146 derived from an EMSK, depending on the location of the ER server in 147 home or foreign domain. 149 We re-use also some terminology and abbreviations from [RFC4072], for 150 example DER/DEA. 152 2.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 3. Overview 160 During the lifetime of an EMSK (derived during a full EAP 161 authentication by compatible EAP methods), a peer may attach to 162 several authenticators. In this case, re-authentication is more 163 efficient than full authentication, especially in the case of 164 roaming. ERP provides a mechanism for re-authentication independent 165 of the link layer, so it can be used in case of multihoming or 166 handovers between different access technologies. The following 167 figure shows the components involved in ERP, and their interactions. 168 When the peer attaches to a new authenticator, the ER server involved 169 in the transaction may change, for example in the case of inter- 170 domain roaming. The home EAP server is assumed to be constant for a 171 given peer. 173 Diameter +--------+ 174 +-------------+ ERP +-----------+ (*) | Home | 175 Peer <->|Authenticator|<=======>| ER server | <---> | EAP | 176 +-------------+ +-----------+ | server | 177 +--------+ 178 (*) Several protocols can be used between ER server and 179 home EAP server to transport bootstrapping material. 181 Figure 1. Diameter applications used in the ERP mechanism. 183 The ER server may be located in the home domain (same as EAP server) 184 or the visited domain (same as authenticator, when it differs from 185 the home domain). [[Editor1: Can the ER server be located in a third 186 domain (ex: broker's)?]] 188 The bootstrapping of the ER server has to occur sometime between the 189 initial EAP authentication and the first ERP re-authentication with 190 this ER server. See section Section 7 for detail on this process. 191 Then, the peer re-authenticates, for example after a movement that 192 makes it attach to a new authenticator. The following figure 193 describes this re-authentication, and shows how Diameter is used in 194 this context. See section Section 8 for a detailed description, and 195 following sections for details on the Diameter messages format. 197 ER server 198 (bootstrapped) 199 Peer Authenticator (local or home domain) 200 ==== ============= ====================== 201 [ <------------------------ ] 202 [optional EAP-Initiate/Re-auth-start] 204 -----------------------> 205 EAP-Initiate/Re-auth 206 ==================================> 207 Diameter ERP, cmd code DER 208 User-Name: Keyname-NAI 209 EAP-Payload: EAP-Initiate/Re-auth 211 <================================== 212 Diameter ERP, cmd code DEA 213 EAP-Payload: EAP-Finish/Re-auth 214 EAP-Master-Session-Key: rMSK 215 <---------------------- 216 EAP-Finish/Re-auth 218 Figure 2. Diameter ERP exchange. 220 4. Application Id 222 We define a Diameter ERP Application in this document, with an 223 Application Id value of [[IANA1: TBD]]. Diameter nodes conforming to 224 this specification (in the role of ER server or authenticator) MUST 225 advertise support by including the Diameter ERP Application ID value 226 in the Auth-Application-Id AVP of the Capabilities-Exchange-Request 227 and Capabilities-Exchange-Answer command [RFC3588]. 229 The primary use of the Diameter ERP Application Id is to ensure 230 proper routing of the messages, and that the nodes that advertise the 231 support for this application do understand the new AVPs defined in 232 the next section (although these AVP have the 'M' flag cleared). 234 5. AVPs 236 This specification defines the following new AVPs. 238 5.1. ERP-RK-Request AVP 240 The ERP-RK-Request AVP (AVP Code [[IANA2: TBD]]) is of type grouped 241 AVP. It is used by the ER server to request root key material used 242 in ERP. 244 This AVP has the M and V bits cleared. 246 ERP-RK-Request ::= < AVP Header: TBD > 247 { ERP-Realm } 248 * [ AVP ] 250 Figure 3. ERP-RK-Request ABNF 252 5.2. ERP-Realm AVP 254 The ERP-Realm AVP (AVP Code [[IANA3: TBD]]) is of type [[Editor2: 255 DiameterIdentity? OctetString?]]. It contains the name of the realm 256 in which the ER server is located. 258 [[Editor3: FFS: We may re-use Origin-Realm here instead? On the 259 other hand, ERP-Realm may be useful in CER/CEA with a NAS...]] 261 This AVP has the M and V bits cleared. 263 5.3. ERP-RK-Answer AVP 265 The ERP-RK-Answer AVP (AVP Code [[IANA4: TBD]]) is of type grouped 266 AVP. It is used by the home EAP server to provide ERP root key 267 material to the ER server. 269 This AVP has the M and V bits cleared. 271 ERP-RK-Answer ::= < AVP Header: TBD > 272 { ERP-RK } 273 { ERP-RK-Name } 274 { ERP-RK-Lifetime } 275 * [ AVP ] 277 Figure 4. ERP-RK-Answer ABNF 279 5.4. ERP-RK AVP 281 The ERP-RK AVP (AVP Code [[IANA5: TBD]]) is of type OctetString. It 282 contains the root key (either rRK or rDSRK) to be used for ERP with 283 the peer to which the current session belongs. How this material is 284 derived and used is specified in [RFC5296]. 286 [[Editor4: Can we re-use EAP-Master-Session-Key here?]] 288 This AVP has the M and V bits cleared. 290 5.5. ERP-RK-Name AVP 292 The ERP-RK AVP (AVP Code [[IANA6: TBD]]) is of type OctetString. 293 This AVP contains the EMSKname which identifies the keying material. 294 How this name is derived is beyond the scope of this document and 295 defined in [RFC5296]. 297 [[Editor5: Can we re-use EAP-Key-Name here?]] 299 This AVP has the M and V bits cleared. 301 5.6. ERP-RK-Lifetime AVP 303 The ERP-RK-Lifetime AVP (AVP Code [[IANA7: TBD]]) is of type 304 [[Editor6: Unsigned64? 32?]] and contains the root key material 305 remaining lifetime in seconds. It MUST not be greater than the 306 remaining lifetime of the EMSK it is derived from. [[Editor7: FFS: 307 is it better to pass an absolute value here, for example expiration 308 date? How to express it then (TZ, ...)? Synchronization problems?]] 310 This AVP has the M and V bits cleared. 312 6. Commands 314 We do not define any new command in this specification. We reuse the 315 Diameter-EAP-Request and Diameter-EAP-Answer commands defined in 316 [RFC4072]. 318 The Application Id field in the command header [[Editor8: and the 319 value in Auth-Application-Id AVP which is redundant???]] can be set 320 to Diameter EAP application or Diameter ERP application, depending on 321 the situation, as explained in the next sections. 323 Since the original ABNF of these commands allow other optional AVPs 324 ("* [ AVP ]"), and the new AVPs defined in this specification do not 325 have the 'M' flag set, the ABNF does not need any change. Anyway, a 326 Diameter node that advertize support for the Diameter ERP application 327 MUST support the ERP-RK-Request and ERP-RK-Answer AVP [[Editor9: 328 Therefore, in DER/DEA with Diameter ERP application ID, do we set the 329 'M' flag to these AVPs?]]. 331 Command-Name Abbrev. Code Reference Application 332 --------------------------------------------------------- 333 Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP 334 Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP 336 Figure 5. Command Codes 338 7. Bootstrapping options 340 Bootstrapping involves the ER server and the EAP server directly, but 341 also indirectly the peer and the authenticator. For ERP to be 342 successful, the peer must derive the same keying material as the ER 343 server. To make this possible, it must learn the domain name of the 344 ER server. How this is achieved is outside the scope of this 345 specification, but it usually involves that the authenticator is 346 configured to advertize this domain name. This could be achieved for 347 example by including the ERP-Realm AVP in a CER/CEA exchange. 349 As stated in the Section 3, the bootstrapping of an ER server has to 350 happen between the initial EAP authentication of the peer, when the 351 EMSK is created, and the moment the peer re-authenticates with this 352 ER server, when the bootstrapping material is needed. While 353 asynchrounous solutions are perfectly possible, it is usually easier 354 to bootstrap the ER server during one of these events. 356 7.1. Bootstrapping during initial EAP authentication 358 Bootstrapping an ER server during the initial EAP authentication 359 offers the advantage that the server is immediatly available for re- 360 authentication of the peer, thus minimizing the re-authentication 361 delay. 363 On the other hand, re-authentication may only concern a small number 364 of peers in the visited domain. Deriving and caching key material 365 for all the peers (for example, for the peers that do not support 366 ERP, or that are not mobile) is a waste of resources and SHOULD be 367 avoided. In addition, bootstrapping ERP during full EAP 368 authentication may prevent re-authentication in case of inter-domain 369 roaming. Hence, while this mecanism is useful in some situations, it 370 should be deployed with care. 372 In the case where ER server is collocated with the Home EAP server, 373 ER bootstrapping is transparent with regards to this specification, 374 although some sort of communication might be needed inside the node. 376 In this case, the server MUST advertise support of both the Diameter 377 EAP application and the Diameter ERP application, but the new AVPs 378 defined in this specification are not used. 380 When ER server and EAP server are different entities with regards to 381 Diameter, one or more Diameter EAP proxy(ies) is(are) needed in the 382 same domain as the ER server. While this(these) proxy(ies) might be 383 separate entity(ies) with secure communication channel with the ER 384 server, it is functionally equivalent to consider that the ER server 385 acts as a Diameter EAP proxy. In the rest of this section, we 386 consider that the ER server acts as a Diameter EAP proxy in its 387 domain. 389 In order to bootstrap the ER server during full EAP authentication, 390 this server must be on the route, and act as a proxy, for the first 391 and last round of exchanges of the full EAP authentication, as 392 captured in the figure bellow. 394 ER server & 395 Authenticator EAP Proxy Home EAP server 396 ============= =========== =============== 397 -------------------------> 398 Diameter EAP/DER 399 (EAP-Response) 400 -------------------------> 401 Diameter EAP/DER 402 (EAP-Response) 403 (ERP-RK-Request) 405 <==================================================> 406 Multi-round Diameter EAP exchanges, unmodified 408 <------------------------- 409 Diameter EAP/DEA 410 (EAP-Success) 411 (MSK) 412 (ERP-RK-Answer) 413 <------------------------- 414 Diameter EAP/DEA 415 (EAP-Success) 416 (MSK) 417 [ERP-Realm] 419 Figure 6. ERP bootstrapping during full EAP authentication 421 The ER server proxies the first DER of the full EAP authentication 422 and adds the ERP-RK-Request AVP inside, if this AVP is not already in 423 the message, then forwards the request. 425 If the EAP server does not support ERP extensions, it will simply 426 ignore this grouped AVP and continue as specified in [RFC4072]. If 427 the server supports the ERP extensions, it caches the ERP-Realm value 428 with the session, and continues the EAP authentication. When the 429 authentication is complete, if it is successful and the EAP method 430 generated an EMSK, the server MUST compute the rRK or rDSRK 431 (depending on the value of ERP-Realm) as specified in [RFC5296], and 432 add an ERP-RK-Answer AVP in the Diameter-EAP-Request message, in 433 addition to the MSK and EAP-Success payload. [[Editor10: FFS: is it 434 important to check that the server that added the ERP-RK-Request is 435 in the path of the answer? What's the worst that can happen?]] 437 When the ER server proxies a Diameter-EAP-Answer message with a 438 Session-Id corresponding to a message to which it added an ERP-RK- 439 Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST examine the 440 message and remove any ERP-RK-Answer AVP, and save its content. If 441 the message does not contain an ERP-RK-Answer AVP, the ER server MAY 442 save this information to avoid possible attempts later for this 443 session. In any case, the information stored SHOULD NOT have a 444 lifetime greater than the EMSK lifetime [[Editor11: FFS: how does the 445 ER server knows the EMSK lifetime, if there is no ERP-RK-Answer? 446 What is the lifetime of the MSK for example?]] 448 If the ER server is successfully bootstrapped, it MAY also add the 449 ERP-Realm AVP after removing the ERP-RK-Answer AVP in the Diameter- 450 EAP-Answer message. This could be used by the authenticator to 451 notify the peer that ERP is bootstrapped, with the ER domain 452 information. How this information can be transmitted to the peer is 453 outside the scope of this document. [[Editor12: Is it possible? It 454 would be useful...]] 456 7.2. Bootstrapping during first re-authentication 458 Bootstrapping the ER server during the first re-authentication offers 459 several advantages: it saves resources, since we generate and cache 460 only useful keying material, it can also accomodate inter-domain 461 roaming or ER servers that loose their state (for example after 462 reboot). 464 On the other hand, the first re-authentication with the ER server 465 requires a one-round-trip with the home EAP server, which adds some 466 delay to the process (but it is more efficient than a full EAP 467 authentication in any case). Note that following re-authentications 468 for the same session with the same ER server will not have this 469 additional delay. 471 [RFC5296] describes two types of bootstrapping for ERP: implicit 472 bootstrapping and explicit bootstrapping. In implicit bootstrapping, 473 the peer knows the domain it is located in, and assumes that the ER 474 server already possess the keying material for the session. In this 475 case, the peer uses a Keyname-NAI in the form "EMSKname@localdomain". 476 In explicit bootstrapping, the Keyname-NAI is in the form 477 "EMSKname@homedomain". As we will see in next section Section 8, the 478 domain part of the Keyname-NAI becomes the Destination-Realm of the 479 Diameter message, and the Application Id is set to Diameter ERP 480 application. 482 In the case of implicit bootstrapping (how the peer learns that the 483 ER server is bootstrapped is outside the scope of this specification) 484 or after a first succesful re-authentication in the visited domain, 485 the message is routed to the local ER server following normal 486 Diameter routing. If the ER server does not have key information 487 corresponding to this EMSKname, [[Editor13: return an error to the 488 peer? proxy the request and send ERP-RK-Request to the home EAP 489 server? How do we learn which is the home domain?]]. See the next 490 section Section 8 for detail. 492 In the case of explicit bootstrapping (the ERP message has its 'B' 493 flag set), if an ER server exists in the visited domain, it SHOULD be 494 configured for and act as a Diameter ERP proxy, and process the 495 messages as described below. If not, the ER server in the home 496 domain will be used, which is less efficient. The description that 497 follow for the ER server in the visited domain is also valid for the 498 ER server in the home domain. 500 [[Editor14: What should we do if the ER server receives an explicit 501 bootstrapping request but already possess the rDSRK?]] 503 The ER server proxies the request (DER with Diameter ERP application 504 code) as follow, in addition to standard proxy operations: 506 Change the Application Id in the header of the message to Diameter 507 EAP Application (code 5). [[Editor15: What about the Application- 508 Auth-Id AVP?]] 510 Add the ERP-RK-Request AVP, which contains the name of the domain 511 the ER server is located in (with regards to ERP). 513 Then the request is forwarded as usual. With its Diameter EAP 514 application id and Destination-Realm set to the home domain of the 515 peer, the request reaches the home EAP server. If this server does 516 not support ERP extensions, it replies with an error since the 517 encapsulated EAP-Initiate/Re-auth command is not understood. 518 Otherwise, it processes the ERP request as described in [RFC5296]. 519 In particular, it includes the Domain-Name TLV attribute with the 520 content from the ERP-Realm AVP. It creates the DEA reply message 521 following standard processing from [RFC4072] (in particular EAP- 522 Master-Session-Key AVP is used to transport the rMSK), and includes 523 the ERP-RK-Answer AVP. 525 The ER server receives this DEA and proxies it as follow, in addition 526 to standard proxy operations: 528 Set the Application Id back to Diameter ERP (code [[IANA8: TBD]]) 530 Extract and cache the content of the ERP-RK-Answer. 532 The DEA is then forwarded to the authenticator, that can use the rMSK 533 as described in [RFC5296]. 535 The figure below captures this Diameter ERP Proxy behavior: 537 Authenticator ER server Home EAP server 538 ============= ========= =============== 539 -----------------------> 540 Diameter ERP/DER 541 (EAP-Initiate) 542 ------------------------> 543 Diameter EAP/DER 544 (EAP-Initiate) 545 (ERP-RK-Request) 547 <------------------------ 548 Diameter EAP/DEA 549 (EAP-Finish) 550 (ERP-RK-Answer) 551 (rMSK) 552 <---------------------- 553 Diameter ERP/DEA 554 (EAP-Finish) 555 (rMSK) 557 Figure 7. ERP explicit bootstrapping message flow 559 8. Re-Authentication 561 This section describes a re-authentication exchange with a 562 bootstrapped ER server. The peer is assumed to know the domain of 563 the bootstrapped ER server in advance. See previous section 564 Section 7 for more information. EAP-Initiate/Re-auth-start with 565 Domain-Name TLV is a possibility for the peer to learn the domain of 566 the ER server attached to the authenticator. 568 The following figure describes the re-authentication exchange. 570 Explication follow. 572 Bootstrapped ER server 573 Peer Authenticator (in local or home domain) 574 ==== ============= ========================= 575 [ <------------------------ ] 576 [optional EAP-Initiate/Re-auth-start] 578 -----------------------> 579 EAP-Initiate/Re-auth 580 =================================> 581 Diameter ERP, cmd code DER 582 User-Name: Keyname-NAI 583 EAP-Payload: EAP-Initiate/Re-auth 585 <================================= 586 Diameter ERP, cmd code DEA 587 EAP-Payload: EAP-Finish/Re-auth 588 EAP-Master-Session-Key: rMSK 589 <---------------------- 590 EAP-Finish/Re-auth 592 Figure 8. Diameter ERP exchange 594 The authenticator that does not support ERP [RFC4072] discards EAP 595 packets with unknown ERP-specific code (EAP-Initiate). The peer 596 falls back to full EAP authentication in that case. 598 When the ERP-compatible authenticator receives an EAP-Initiate/ 599 Re-auth message from the peer (or after having sent a EAP-Initiate/ 600 Re-auth-start packet), it process as described in [RFC5296] with 601 regards to the EAP state machine, and similarly to Diameter EAP 602 [RFC4072], with regards to Diameter, with the following differences: 604 The application id is set to Diameter ERP instead of Diameter EAP. 606 The User-Name and Destination-Realm are derived from the Keyname- 607 NAI. 609 [[Editor16: How do we create / retrieve the Session-Id?]] 611 The ER server receives this request and process the ERP payload as 612 described in [RFC5296]. If re-authentication is successful, it 613 creates a DEA answer as described in Diameter EAP, with the following 614 differences: 616 The application id is set to Diameter ERP. 618 The EAP-Payload AVP contains the ERP message: EAP-Finish/Re-auth 620 The EAP-Master-Session-Key AVP contains the rMSK 622 The Result-Code AVP contains DIAMETER_SUCCESS. 624 In case the re-authentication fails, the Result-Code AVP contains an 625 error code, and no EAP-Master-Session-Key AVP is included. 627 When the authenticator receives this answer, it processes it as 628 described in Diameter EAP: forwards the EAP payload to the peer, and 629 use the rMSK as a shared secret in Secure Association Protocol. 631 9. Sessions 633 This section describes how sessions are handled in case of re- 634 authentication. 636 [[Editor17: The content of this section is to be written, I am just 637 listing the ideas here.]] 639 See guidelines in [I-D.ietf-dime-app-design-guide]. 641 During initial full EAP authentication, the identity of the peer is 642 used to create the Session-Id AVP, which is then used during 643 accounting. When the peer attaches to a new authenticator and 644 performs ERP, its identity is not disclosed to the authenticator. 645 Instead, the peer presents the Keyname-NAI. This identifiers 646 contains the EMSKName as user part. The new authenticator will 647 therefore derive the new Session-Id from this EMSKName and use this 648 for accounting purpose. 650 Although the home EAP server is able to link EMSKName with the peer's 651 identity, the other Diameter entities do not have this mapping. In 652 particular, the realm part of Keyname-NAI is the visited network. 653 How does the authenticator figures out that the account records must 654 be sent to the home domain of the peer? 656 It is possible to cache the necessary information at the ER server 657 level. Is it useful to specify this mechanism in this document? It 658 would involve: 660 An additional AVP during bootstrapping of ER server, in the ERP- 661 RK-Answer, to pass the real User-Name and Session-Id (only in case 662 of explicit bootstrapping) 664 An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to pass 665 the real Session-Id and User-Name and Destination-Realm of the re- 666 authenticated peer, for accounting messages. 668 10. Contributors 670 Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel 671 Morand wrote the initial Diameter ERP draft document. 673 11. Acknowledgements 675 Vidya Narayanan reviewed a rough draft version of the previous 676 document and found some errors. 678 Qin Wu and Glen Zorn actively participated in the discussions on the 679 design for Diameter ERP, providing the point of view and experience 680 from HOKEY workgroup. 682 Hannes Tschofenig provided useful advices for the writing of this 683 document. 685 Many thanks to these people! 687 12. IANA Considerations 689 This document requires IANA registration of the following new 690 elements in the Authentication, Authorization, and Accounting (AAA) 691 Parameters [1] registries. 693 12.1. Diameter ERP application 695 This specification requires IANA to allocate a new value "Diameter 696 ERP" in the "Application IDs" registry created by in [RFC3588]. 698 Application Identifier | Value 699 -----------------------------------+------ 700 Diameter ERP | TBD 702 IANA consideration for Diameter ERP application 704 12.2. New AVPs 706 This specification requires IANA to allocate new values from the "AVP 707 Codes" registry defined in [RFC3588] for the following AVPs: 709 ERP-RK-Request 711 ERP-Realm 712 ERP-RK-Answer 714 ERP-RK 716 ERP-RK-Name 718 ERP-RK-Lifetime 720 These AVPs are defined in section Section 5. 722 13. Security Considerations 724 The security considerations from the following RFC apply here: 725 [RFC3588], [RFC4072], [RFC5247], [RFC5295], and [RFC5296]. 727 [[Editor18: FFS: Do we really respect these security considerations 728 with the mechanism we describe here? Is it safe to use ERP-RK- 729 Request / Answer AVPs? What is the worst case?]] 731 14. References 733 14.1. Normative References 735 [RFC2119] Bradner, S., "Key words for use in 736 RFCs to Indicate Requirement 737 Levels", BCP 14, RFC 2119, 738 March 1997. 740 [RFC3588] Calhoun, P., Loughney, J., Guttman, 741 E., Zorn, G., and J. Arkko, 742 "Diameter Base Protocol", RFC 3588, 743 September 2003. 745 [RFC4072] Eronen, P., Hiller, T., and G. 746 Zorn, "Diameter Extensible 747 Authentication Protocol (EAP) 748 Application", RFC 4072, 749 August 2005. 751 [RFC5295] Salowey, J., Dondeti, L., 752 Narayanan, V., and M. Nakhjiri, 753 "Specification for the Derivation 754 of Root Keys from an Extended 755 Master Session Key (EMSK)", 756 RFC 5295, August 2008. 758 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 759 Extensions for EAP Re- 760 authentication Protocol (ERP)", 761 RFC 5296, August 2008. 763 14.2. Informative References 765 [I-D.gaonkar-radext-erp-attrs] Gaonkar, K., Dondeti, L., 766 Narayanan, V., and G. Zorn, "RADIUS 767 Support for EAP Re-authentication 768 Protocol", 769 draft-gaonkar-radext-erp-attrs-03 770 (work in progress), February 2008. 772 [I-D.ietf-dime-app-design-guide] Fajardo, V., Asveren, T., 773 Tschofenig, H., McGregor, G., and 774 J. Loughney, "Diameter Applications 775 Design Guidelines", 776 draft-ietf-dime-app-design-guide-08 777 (work in progress), November 2008. 779 [I-D.ietf-dime-erp] Dondeti, L., Bournelle, J., Morand, 780 L., and S. Decugis, "Diameter 781 Support for EAP Re-authentication 782 Protocol", draft-ietf-dime-erp-00 783 (work in progress), January 2009. 785 [I-D.ietf-hokey-key-mgm] Hoeper, K. and Y. Ohba, 786 "Distribution of EAP based keys for 787 handover and re-authentication", 788 draft-ietf-hokey-key-mgm-06 (work 789 in progress), April 2009. 791 [I-D.wu-dime-local-keytran] Wu, W., "Diameter support for local 792 key transport protocol between 793 local server and home AAA server", 794 draft-wu-dime-local-keytran-00 795 (work in progress), May 2009. 797 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, 798 J., Carlson, J., and H. Levkowetz, 799 "Extensible Authentication Protocol 800 (EAP)", RFC 3748, June 2004. 802 [RFC4187] Arkko, J. and H. Haverinen, 803 "Extensible Authentication Protocol 804 Method for 3rd Generation 805 Authentication and Key Agreement 806 (EAP-AKA)", RFC 4187, January 2006. 808 [RFC5247] Aboba, B., Simon, D., and P. 809 Eronen, "Extensible Authentication 810 Protocol (EAP) Key Management 811 Framework", RFC 5247, August 2008. 813 URIs 815 [1] 817 Author's Address 819 Sebastien Decugis (editor) 820 NICT 821 4-2-1 Nukui-Kitamachi 822 Koganei, Tokyo 184-8795 823 JP 825 EMail: sdecugis@nict.go.jp