idnits 2.17.00 (12 Aug 2021) /tmp/idnits28225/draft-perez-abfab-wg-arch-erp-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-abfab-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 2763 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-abfab-arch has been published as RFC 7831 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-abfab-aaa-saml has been published as RFC 7833 == Outdated reference: draft-ietf-abfab-usecases has been published as RFC 7832 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB A. Perez-Mendez 3 Internet-Draft R. Marin-Lopez 4 Updates: RFC7055 (if approved) G. Lopez-Millan 5 Intended status: Experimental University of Murcia 6 Expires: April 30, 2015 F. Pereniguez-Garcia 7 Catholic University of Murcia 8 October 27, 2014 10 ERP extensions for the ABFAB architecture 11 draft-perez-abfab-wg-arch-erp-00 13 Abstract 15 The Application Bridging for Federated Access Beyond Web (ABFAB) 16 architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform 17 access control to a wide range of applications. This document 18 describes the extensions required to incorporate support for the EAP 19 Extensions for the EAP Re-authentication Protocol (ERP) to this 20 architecture, in order to provide an enhanced fast re-authentication 21 and Single Sign-On (SSO) support and a better resource utilization. 22 Authorization aspects are also described. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 30, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Applicability considerations . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Motivation use case . . . . . . . . . . . . . . . . . . . . . 6 63 5. Modifications to the ABFAB architecture . . . . . . . . . . . 7 64 5.1. ERP extensions to GSS-EAP . . . . . . . . . . . . . . . . 7 65 5.1.1. GSS-EAP initial state . . . . . . . . . . . . . . . . 7 66 5.1.1.1. ERP-Supported Subtoken . . . . . . . . . . . . . . 8 67 5.1.2. GSS-EAP authentication state . . . . . . . . . . . . . 9 68 5.1.3. GSS-EAP extensions state . . . . . . . . . . . . . . . 9 69 5.2. Authorization Considerations . . . . . . . . . . . . . . . 9 70 5.3. Updates to the backend (AAA) infrastructure . . . . . . . 10 71 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. ERP implicit bootstrapping . . . . . . . . . . . . . . . . 11 73 6.2. ERP explicit bootstrapping . . . . . . . . . . . . . . . . 12 74 6.3. ERP local operation . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The Application Bridging for Federated Access Beyond Web (ABFAB) 86 architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform 87 access control to a wide range of applications. This is mainly 88 achieved by the definition of the GSS-API Mechanism for the 89 Extensible Authentication Protocol [RFC7055], which can be used with 90 any application that provides support for the GSS-API or the SASL 91 framework (through the GS2 family of mechanisms). Since EAP is 92 mostly used in conjunction with a backend Authentication, 93 Authorization, and Accounting (AAA) infrastructure, the use of this 94 mechanism automatically brings federated authentication capabilities 95 to these applications. Besides, the ABFAB architecture also defines 96 how attributes about the Client can be transported from the home 97 organization to the application in order to perform an authorization 98 process based on this federated identity information. Hence, 99 altogether the ABFAB architecture provides a consistent federated 100 access control framework usable in multiple scenarios, as described 101 in [I-D.ietf-abfab-usecases]. 103 However, neither EAP nor the GSS-EAP mechanism provide any particular 104 means of performing fast re-authentication. This implies that, 105 whenever a Client accesses to different applications, regardless they 106 are deployed in the same organization or in different ones, a 107 complete EAP authentication process must be performed for each one of 108 them. Depending on the selected EAP method (e.g. EAP-TTLS, PEAP, 109 etc.), this exchange may consist of several roundtrips executed 110 between the Client and her Home organization, with the inherent costs 111 in terms of network bandwidth consumption and computational resources 112 used (e.g. to perform asymmetric cryptography operations). 114 Therefore, in order to provide a better resource utilization, 115 Clients, organizations, and applications using EAP have to rely on 116 the fast re-authentication capabilities provided by the selected EAP 117 method, when possible. There are a number of EAP methods that 118 already provide some fast re-authentication capabilities (e.g. EAP- 119 AKA, EAP-TTLS...). However, although they can achieve a reduction of 120 the required round-trips to complete the authentication process, they 121 all require the execution of at least two round-trips in the best 122 case. Besides, these exchanges are always performed between the 123 Client and the Home AAA server. 125 The EAP Extensions for the EAP Re-authentication Protocol (ERP) 126 [RFC6696] modifies certain aspects of the EAP protocol to 1) allow 127 the execution of a re-authentication process in a single round trip; 128 and 2) allow performing the re-authentication process in a local 129 fashion whenever the Client repeatedly accesses to different 130 applications within the same organization. In particular, ERP allows 131 the Client and an AAA server (either in the home or in the visited 132 organization) to mutually verify proof of possession of key material 133 from an earlier EAP method run. Although ERP, as EAP, was originally 134 conceived to be used only in the network access context, the ABFAB WG 135 extended the EAP applicability statement [RFC7057] to allow its use 136 for generic application authentication. This fact also enables ERP 137 to be used to provide fast re-authentication for generic 138 applications. 140 The extensions defined by ERP consist of a pair of new EAP codes, and 141 some updates to the EAP state machines required to generate and 142 process these codes accordingly. Therefore, adding support for ERP 143 implies updating the EAP lower layer specifications. This document 144 describes the modifications to the ABFAB architecture that are 145 required to incorporate support for the EAP Extensions for the EAP 146 Re-authentication Protocol (ERP). 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 When these words appear in lower case, they have their natural 154 language meaning. 156 2. Applicability considerations 158 Although EAP, and thus ERP, was originally conceived to be used only 159 in the network access context, the ABFAB WG extended the EAP 160 applicability statement [RFC7057] to allow its use for generic 161 application authentication. This fact also enables ERP to be used to 162 provide fast re-authentication for generic applications when used in 163 combination with the GSS-EAP mechanism. 165 3. Terminology 167 Although this document is not intended to serve as an ERP or ABFAB 168 guide, this section provides some terminology notes to help the 169 reader to follow the rest of this document. 171 o Client. The entity which wants to access a particular service by 172 means of ABFAB technologies. It plays the role of GSS-API 173 initiator and EAP/ERP peer. 175 o RP (Relying party). The application server the Client is trying 176 to access to. It plays the role of GSS-API acceptor and EAP/ERP 177 authenticator. 179 o Visited organization. The organization where the RP is deployed. 181 o Home organization. The organization where the Client has a 182 registration. 184 o Visited AAA server. The AAA server that connects the Visited 185 organization to the AAA federation. It plays the role of AAA 186 proxy and of ERP server for the ERP local operation (see below). 188 o Home AAA server. The AAA server that connects the Home 189 organization to the AAA federation. It plays the role of EAP 190 server and of ERP server for the bootstrapping processes (see 191 below). 193 o ERP keys. The keys used to perform authentication in ERP. They 194 are named rIK/rRK when shared with the Home AAA server, and DS- 195 rIK/DS-rRK when shared with the Visited AAA server. They are 196 derived during the bootstrapping processes (see below). Besides, 197 an rMSK is derived from them to play the role of a typical MSK, 198 being installed in the RP. 200 o ERP Bootstrapping. When the Client tries to use ERP with a 201 particular RP, but she does not share any ERP key with the Visited 202 organization, a bootstrapping process is required to derive and 203 install such keys. 205 * Implicit bootstrapping. It is performed when the Client does 206 not share any ERP key with the Home AAA server either. The 207 Client authenticates with the Home AAA server by means of an 208 EAP method. ERP keys for the Home and Visited organizations 209 are derived from the cryptographic material generated by this 210 method, and installed in the Home AAA server and Visited AAA 211 server respectively. 213 * Explicit bootstrapping. It is performed when the Client shares 214 ERP keys with the Home AAA server from a previous implicit 215 bootstrapping process. The authentication consists on a single 216 round-trip ERP exchange where both entities prove their 217 knowledge of these keys. New ERP keys for the Visited 218 organization are derived and installed in the Visited AAA 219 server. 221 o ERP local operation. When the Client tries to use ERP with a 222 particular RP and she shares ERP keys with the Visited 223 organization, the ERP authentication is performed locally by the 224 Visited AAA server in a single round-trip exchange. 226 4. Motivation use case 228 As an example use case let us picture the following situation. Alice 229 (Client) has a subscription with an organization (Home organization). 230 This means that Alice has some long-term credentials that allow her 231 to authenticate with this organization. Let us assume there are also 232 other organizations, called Organization A and Organization B 233 (Visited organizations), which have a set of services deployed (RPs). 234 These three organizations are interconnected through an AAA 235 federation, and the services they offer support the use of the ABFAB 236 technologies for access control. 238 What Alice and the organizations would want is to allow her to access 239 to any of the services deployed by the different organizations 240 without requiring her to perform a complete EAP authentication for 241 each one of them. Instead, only one complete EAP authentication 242 would be required, at the beginning of the session. The rest of 243 authentication processes would be based on the cryptographic material 244 derived from it, regardless whether the organization of the RP being 245 accessed is different from the one where the first EAP authentication 246 process was performed. Moreover, whenever possible, the 247 authentication process should be performed without involving the home 248 institution. 250 In this way, Alice avoids being prompted to introduce her long-term 251 credentials once and again, and goes through the process as fast as 252 possible to start enjoying the service. On the other hand, 253 organizations are able to reduce the amount of network traffic 254 exchanged between them, as well as the computational cost of 255 performing this process. This should improve scalability and reduce 256 infrastructure costs. 258 In this scenario, using the standard mechanism defined within the 259 IETF to provide fast re-authentication in EAP (i.e. ERP) seems to be 260 the most reasonable way to proceed. This solution would be valid not 261 only for any application making use of the ABFAB architecture or the 262 GSS-EAP mechanism. 264 This use case is directly applicable within the context of the CLASSe 265 project [CLASSe], which focuses on allowing GEANT users to access to 266 cloud services using their home institution credentials. Although 267 this objective is mainly achieved by the use of ABFAB technologies, 268 the project is also interested in ways to improve the SSO 269 capabilities of the ABFAB architecture, in such a way that a Client 270 moving among a number of different cloud services deployed within the 271 same federation do not require performing more than one complete EAP 272 authentication process. 274 5. Modifications to the ABFAB architecture 276 The integration of ERP with the ABFAB architecture requires of some 277 changes to the GSS-EAP mechanism, some modifications to the 278 authorization handling, and some updates to the back-end (AAA) 279 infrastructure. The following subsections describe them with further 280 detail. Section 6 provides a detailed flow based description of the 281 overall ABFAB/ERP process. 283 5.1. ERP extensions to GSS-EAP 285 ERP follows a different exchange scheme than EAP. Whereas a typical 286 EAP exchange is a server-initiated flow, ERP may follow a client- 287 initiated one. Therefore, supporting ERP would require changes on 288 how these lower layers deal with re-transmissions. However, the GSS- 289 API (and thus the GSS-EAP mechanism) operation also follows a client- 290 initiated scheme. This aspect favors the integration of ERP into its 291 message flow, minimizing the number of adaptations required to 292 incorporate the ERP functionality. Specifically, this allows an 293 easier negotiation of ERP capabilities and parameters between the 294 GSS-EAP initiator (Client) and the GSS-EAP acceptor (RP), and a 295 simpler handling of error conditions (e.g. re-transmissions). 297 Following subsections describe how the different states of the GSS- 298 EAP mechanism must be adapted to enable ERP functionality. 300 5.1.1. GSS-EAP initial state 302 As defined in [RFC7055], the Initial State is used to start the 303 context establishment process. In particular, it is used to exchange 304 information such as vendor information or acceptor (RP) name. This 305 document defines a new Subtoken, called ERP-Supported Subtoken, that 306 is exchanged in this state, and it is used to negotiate ERP-related 307 parameters. It MUST be included by any compliant Client willing to 308 start an ERP exchange. The presence of this Subtoken indicates that 309 the Client supports this specification, and the kind of ERP exchange 310 to be performed. Section 5.1.1.1 provides further details on this 311 Subtoken. 313 When the Client sends an ERP-Supported Subtoken indicating that an 314 implicit bootstrapping is requested, a compliant RP MUST include an 315 ERP-Supported Subtoken in the response, indicating that it supports 316 ERP and the realm name to be used to derive the ERP keys. As the 317 Subtoken is not marked as critical, non-compliant RPs will ignore 318 such Subtokens and continue as indicated in [RFC7055]. 320 On the contrary, when an explicit bootstrapping or an ERP local 321 operation is requested, the RP MUST start the ERP exchange by 322 including an EAP-Initiate/Re-auth-Start packet within the first EAP 323 Request Subtoken. This packet is sent instead of the EAP request/ 324 identity one. The reception of this ERP packet will notify the 325 Client that the RP supports the ERP extensions, and provide the realm 326 name to be used to derive the ERP keys. 328 Although ERP allows the Client to send an EAP-Initiate/Re-auth packet 329 without having received any EAP-Initiate/Re-auth-Start packet first, 330 this behavior is not allowed in this specification for two main 331 reasons. First, the Client might not know the ERP realm of the 332 application yet, as it could not be inferred from the DNS name or 333 GSS-API Acceptor Name. Indeed, the RP (acceptor) name is being 334 negotiated during this state. Hence, the Client must wait until an 335 EAP-Initiate/Re-auth-start message, or an ERP Supported Subtoken, is 336 received from the RP, as explained above. Besides, during the GSS- 337 EAP initial state, neither the Client nor the RP are expected to 338 perform any authentication processing. That belongs to the 339 authentication state (see below). Allowing authentication in this 340 state will require deeper changes to the GSS-EAP state machine, 341 resulting on a more complex specification. 343 5.1.1.1. ERP-Supported Subtoken 345 The ERP-Supported Subtoken is sent from the Client to the RP, 346 indicating that the former wishes to start an ERP exchange with the 347 latter, and specifying whether it will be an implicit bootstrapping 348 or not. Besides, it can be sent from the RP to the Client whenever 349 an implicit bootstrapping has been requested by the Client, in order 350 to 1) indicate that ERP is supported; and 2) to provide the Client 351 with the ERP realm name required to derive they ERP keys at the end 352 of the EAP authentication process. 354 The ERP-Supported Subtoken has the structure depicted in Figure 1 356 +-------------+------------------------------------------------+ 357 | Pos | Description | 358 +-------------+------------------------------------------------+ 359 | 0..3 | TBD (not critical) | 360 | | | 361 | 4..7 | length of token | 362 | | | 363 | 8 | implicit bootstrapping? (0x00=no, 0x01=yes) | 364 | | | 365 | 9..8+length | Visited organization's realm (sent by RP only) | 366 +-------------+------------------------------------------------+ 368 Figure 1: ERP-Supported Subtoken 370 5.1.2. GSS-EAP authentication state 372 As defined in [RFC7055], this state is used to perform the exchange 373 of EAP packets between the Client and the RP. When performing an ERP 374 implicit bootstrapping, a compliant Client MUST derive and store the 375 ERP keys associated with its Home organization for later use (i.e rRK 376 and rIK). Besides, it MUST derive and store the ERP keys associated 377 to the Visited organization whenever the latter indicates support of 378 ERP (i.e. DS-rRK and DS-rIK). Both derivation processes are 379 performed after having completed a successful EAP authentication. 381 Besides, during an implicit bootstrapping, a compliant RP SHOULD 382 notify the Visited AAA server whenever an ERP implicit bootstrapping 383 process has been requested. This notification can be performed by 384 including an AAA attribute, such as the ERP-Realm one defined in 385 [RFC6942], to the first request sent to the Home AAA server. This 386 would trigger the Visited AAA server to request a DSRK from the Home 387 AAA server. Without this notification, an ERP-capable Visited AAA 388 server would need to send a DSRK request for every EAP 389 authentication, regardless the Client supports ERP or not. This 390 would result into the generation of an amount of useless state in the 391 Visited and Home AAA servers when the Client does not support ERP. 393 When performing other types of ERP exchanges (i.e. explicit 394 bootstrapping or local operation), this specification adds an 395 additional way to end the EAP conversation to the ones listed in 396 [RFC7055]. In particular, when an ERP exchange is successfully 397 executed, the conversation will end with the generation (and 398 reception) of an EAP-Finish/Re-auth message. The behavior at GSS-EAP 399 layer associated to this message is identical to the one associated 400 with the EAP Success message. It also includes the derivation of the 401 ERP keys associated with the Visited organization, and the rMSK 402 derived from them by the Client. Note that the rMSK is used as the 403 MSK for all purposes, including the derivation of the GSS-API Master 404 Session Key (GMSK) defined in [RFC7055]. 406 5.1.3. GSS-EAP extensions state 408 This state requires no modifications, and it can be performed as 409 described in [RFC7055]. 411 5.2. Authorization Considerations 413 Another important aspect has to do with how authorization should be 414 handled in ABFAB when ERP is in use. The ABFAB architecture defines 415 that the Home AAA server generates a SAML assertion with information 416 about the Client, and delivers it to the RP, after the EAP 417 authentication has been successfully completed 419 [I-D.ietf-abfab-aaa-saml]. Whenever an ERP bootstrapping process 420 (either implicit or explicit) is performed, no changes are required 421 to this behavior. That is, when the Home AAA server generates the 422 EAP-Finish/Re-auth message, it also generates and delivers the SAML 423 in the same way it would do with an EAP-Success message. 425 However, there is an important consideration when it comes to the ERP 426 local operation. Since the Home AAA server is not involved in the 427 process, in principle, an SAML assertion is not generated as 428 specified in GSS-EAP. To overcome this limitation, and to take 429 advantage of the ERP local operation, the Visited AAA server SHOULD 430 store the SAML assertion received during any of the bootstrapping 431 processes (either implicit or explicit) executed previously, 432 associated to the Client's identifiers (e.g. User-Name, CUI...). In 433 this way, the stored SAML assertion can be delivered to the RP during 434 the ERP local operation. 436 5.3. Updates to the backend (AAA) infrastructure 438 Another architecture element that needs to be updated, in order to 439 add support for ERP to the ABFAB architecture, is the backend AAA 440 infrastructure. Basically, the Home AAA server and the Visited AAA 441 server need to implement ERP as described in [RFC6696]. In 442 particular, the Home AAA server needs to be updated to support the 443 different ERP bootstrapping exchanges. This includes the generation 444 and parsing of ERP messages, as well as the derivation, storage, 445 distribution and usage of the ERP-related keys (i.e. rIK, rRK, DS- 446 rIK, rMSK...). 448 In the same way, the Visited AAA server needs to be updated in order 449 to be able to request the required ERP key material (i.e. DSRK) from 450 the Home AAA server during any of the ERP bootstrapping exchanges. 451 This key material needs to be stored for its use during the ERP local 452 operation (see below). Besides, the Visited AAA server MAY need to 453 support the storage of the SAML assertion as described in 454 Section 5.2. 456 Finally, the Visited AAA server also needs to be updated to support 457 the execution of the ERP local operation with the Client, based on 458 the key material obtained during any of the bootstrapping exchanges 459 performed before. 461 When the Visited AAA server does not provide support for ERP, the 462 Client will only be able to perform bootstrapping processes. 463 Although this is not optimal, a typical explicit bootstrapping 464 process will require a single round-trip performed between the Client 465 and its Home AAA server. The main drawback of not having ERP-capable 466 AAA proxies is the impossibility of executing the ERP local 467 operation, which implies communicating with the home AAA server to 468 perform the authentication. 470 6. Operation 472 Previous section has explained the extensions that are required to 473 GSS-EAP for supporting ERP. This section provides a detailed 474 description of how the different ERP exchanges would be executed. In 475 these descriptions it is assumed that all the participants support 476 the ERP extensions described in this document. 478 6.1. ERP implicit bootstrapping 480 TBD This ERP exchange is performed when the Client wants to use ERP 481 with a particular RP, but she does not have neither a DS-rRK/DS-rIK 482 shared with the Visited AAA server nor a rRK/rIK shared with her Home 483 AAA server. The process is depicted in Figure 2 and described below. 485 +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 486 | Client | | RP | | Visited AAA | | Home AAA | 487 +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 488 | | | | 489 |------ 1 ----->| | | 490 | | | | 491 |<----- 2 ------| | | 492 | | | | 493 |------ 3 ----->| | | 494 | |------ 4 ----->| | 495 | | |------ 5 ----->| 496 | | | | 497 |<---------------------- 6 -------------------->| 498 | | | | 499 | | | (7) 500 | | | | 501 | | |<----- 8 ------| 502 | | | | 503 | | (9) | 504 | | | | 505 | |<----- 10 -----| | 506 | | | | 507 |<----- 11 -----| | | 508 | | | | 509 (12) | | | 510 | | | | 512 Figure 2: ERP implicit bootstrapping 514 1. The Client starts the GSS-EAP mechanism, also including an ERP 515 Supported Subtoken indicating an implicit bootstrapping is 516 required. 518 2. The RP continues with the standard GSS-EAP mechanism, also 519 including an ERP Supported Subtoken indicating implicit 520 bootstrapping and the Visited organization's realm. 522 3. The Client sends the EAP-Response/Identity message. 524 4. The RP forwards this EAP message to the Visited AAA server, also 525 including an indication (e.g. ERP-Realm attribute) that an 526 implicit bootstrapping was requested. 528 5. The Visited AAA server forwards the EAP message to the Home AAA 529 server, also including a request for a DSRK key (used to derive 530 the ERP keys). 532 6. The Client and the Home AAA run the EAP protocol. 534 7. The Home AAA server derives the MSK and SAML assertion(as 535 usual). It also generates the rRK and rIK, and the requested 536 DSRK. 538 8. The Home AAA server sends the EAP-Success, MSK, SAML assertion 539 and DSRK to the Visited AAA server. 541 9. The Visited AAA server derives the DS-rRK and DS-rIK from the 542 DSRK, and stores the SAML assertion. 544 10. The Visited AAA server sends the EAP-Success, the SAML assertion 545 and the MSK to the RP. 547 11. The RP sends the EAP-Success to the Client and finalizes the 548 GSS-EAP mechanism. 550 12. The Client derives the MSK, rRK, rIK, DS-rRK, and DS-rIK. 552 6.2. ERP explicit bootstrapping 554 TBD 556 6.3. ERP local operation 558 This ERP exchange is performed when the Client wants to use ERP with 559 a particular RP, having DS-rRK/DS-rIK shared with the Visited AAA 560 server. The process is depicted in Figure 3 and described below. 562 +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 563 | Client | | RP | | Visited AAA | | Home AAA | 564 +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ 565 | | | | 566 |------ 1 ----->| | | 567 | | | | 568 |<----- 2 ------| | | 569 | | | | 570 |------ 3 ----->| | | 571 | |------ 4 ----->| | 572 | | | | 573 | | (5) | 574 | | | | 575 | |<------ 6 -----| | 576 | | | | 577 |<------ 7 -----| | | 578 | | | | 579 (8) | | | 580 | | | | 582 Figure 3: ERP local operation 584 1. The Client starts the GSS-EAP mechanism, also including an ERP 585 Supported Subtoken indicating an implicit bootstrapping is not 586 required. At this point the Client does not know whether an 587 explicit bootstrapping or an ERP local operation will be 588 performed, as the ERP realm is unknown. 590 2. The RP continues with the standard GSS-EAP mechanism, sending an 591 EAP-Initiate/Re-Auth-Start, instead of an EAP-Identity/Request, 592 indicating the Visited organization's realm. 594 3. The Client sends an EAP-Initiate/Re-Auth generated using the 595 available DS-rRK/DS-rIK keys. 597 4. The RP forwards this EAP message to the Visited AAA server. 599 5. The Visited AAA server verifies the EAP message using the stored 600 DS-rRK/DS-rIK keys, and derives the rMSK. It also retrieves the 601 stored SAML assertion. 603 6. The Visited AAA server sends the EAP-Finish/Re-Auth, the SAML 604 assertion and the rMSK to the RP. 606 7. The RP sends the EAP-Finish/Re-auth to the Client and finalizes 607 the GSS-EAP mechanism. 609 8. The Client derives the rMSK. 611 7. Security Considerations 613 TBD 615 8. IANA Considerations 617 The authors request that GSS-EAP Subtoken types defined in this 618 document be registered by the Internet Assigned Numbers Authority 619 (IANA) from the "Extensible Authentication Protocol Mechanism for the 620 Generic Security Service Application Programming Interface (GSS-EAP) 621 Parameters" registry defined in section 7.3 of [RFC7055], in 622 accordance with BCP 26 [RFC5226]. 624 9. Acknowledgements 626 This work has been partly funded by the GN3plus OpenCall CLASSe 627 project [CLASSe] . 629 10. References 631 10.1. Normative References 633 [I-D.ietf-abfab-arch] 634 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 635 Schaad, "Application Bridging for Federated Access Beyond 636 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 637 in progress), July 2014. 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, March 1997. 642 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 643 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 644 May 2008. 646 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP 647 Extensions for the EAP Re-authentication Protocol (ERP)", 648 RFC 6696, July 2012. 650 [RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 651 Extensible Authentication Protocol", RFC 7055, 652 December 2013. 654 10.2. Informative References 656 [CLASSe] "CLASSe project home page", . 658 [I-D.ietf-abfab-aaa-saml] 659 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 660 Profiles, Name Identifier Format, and Confirmation Methods 661 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 662 progress), February 2014. 664 [I-D.ietf-abfab-usecases] 665 Smith, R., "Application Bridging for Federated Access 666 Beyond web (ABFAB) Use Cases", 667 draft-ietf-abfab-usecases-05 (work in progress), 668 September 2012. 670 [RFC6942] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G. 671 Zorn, "Diameter Support for the EAP Re-authentication 672 Protocol (ERP)", RFC 6942, May 2013. 674 [RFC7057] Winter, S. and J. Salowey, "Update to the Extensible 675 Authentication Protocol (EAP) Applicability Statement for 676 Application Bridging for Federated Access Beyond Web 677 (ABFAB)", RFC 7057, December 2013. 679 Authors' Addresses 681 Alejandro Perez-Mendez (Ed.) 682 University of Murcia 683 Campus de Espinardo S/N, Faculty of Computer Science 684 Murcia, 30100 685 Spain 687 Phone: +34 868 88 46 44 688 Email: alex@um.es 690 Rafa Marin-Lopez 691 University of Murcia 692 Campus de Espinardo S/N, Faculty of Computer Science 693 Murcia, 30100 694 Spain 696 Phone: +34 868 88 85 01 697 Email: rafa@um.es 698 Gabriel Lopez-Millan 699 University of Murcia 700 Campus de Espinardo S/N, Faculty of Computer Science 701 Murcia, 30100 702 Spain 704 Phone: +34 868 88 85 04 705 Email: gabilm@um.es 707 Fernando Pereniguez-Garcia 708 Catholic University of Murcia 709 Av Jeronimos, 135 710 Murcia, 30107 711 Spain 713 Email: pereniguez@um.es