idnits 2.17.00 (12 Aug 2021) /tmp/idnits57781/draft-ietf-abfab-arch-02.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 775: '...n an organization. That proxy MAY use...' RFC 2119 keyword, line 778: '...on. Federations MAY provide a traditi...' RFC 2119 keyword, line 962: '...A infrastructure MAY hide the peer's i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2012) is 3648 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: draft-ietf-abfab-gss-eap has been published as RFC 7055 == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 == Outdated reference: draft-iab-privacy-considerations has been published as RFC 6973 -- Obsolete informational reference (is this intentional?): RFC 2138 (Obsoleted by RFC 2865) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB J. Howlett 3 Internet-Draft JANET(UK) 4 Intended status: Informational S. Hartman 5 Expires: November 25, 2012 Painless Security 6 H. Tschofenig 7 Nokia Siemens Networks 8 E. Lear 9 Cisco Systems GmbH 10 J. Schaad 11 Soaring Hawk Consulting 12 May 24, 2012 14 Application Bridging for Federated Access Beyond Web (ABFAB) 15 Architecture 16 draft-ietf-abfab-arch-02.txt 18 Abstract 20 Over the last decade a substantial amount of work has occurred in the 21 space of federated access management. Most of this effort has 22 focused on two use-cases: network and web-based access. However, the 23 solutions to these use-cases that have been proposed and deployed 24 tend to have few common building blocks in common. 26 This memo describes an architecture that makes use of extensions to 27 the commonly used security mechanisms for both federated and non- 28 federated access management, including the Remote Authentication Dial 29 In User Service (RADIUS) and the Diameter protocol, the Generic 30 Security Service (GSS), the GS2 family, the Extensible Authentication 31 Protocol (EAP) and the Security Assertion Markup Language (SAML). 32 The architecture addresses the problem of federated access management 33 to primarily non-web-based services, in a manner that will scale to 34 large numbers of identity providers, relying parties, and 35 federations. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on November 25, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. An Overview of Federation . . . . . . . . . . . . . . . . 6 74 1.3. Challenges to Contemporary Federation . . . . . . . . . . 9 75 1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 9 76 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 12 77 1.6. Client to Relying Party Transport . . . . . . . . . . . . 13 78 1.7. Use of AAA . . . . . . . . . . . . . . . . . . . . . . . . 14 79 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 2.1. Relying Party to Identity Provider . . . . . . . . . . . . 16 81 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 19 82 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 20 83 3. Application Security Services . . . . . . . . . . . . . . . . 23 84 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 23 85 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 24 86 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . . 25 87 3.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 26 88 4. Future Work: Attribute Providers . . . . . . . . . . . . . . . 27 89 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 90 5.1. What Entities collect and use Data? . . . . . . . . . . . 28 91 5.2. Relationship between User's and other Entities . . . . . . 29 92 5.3. What Data about the User is likely Needed to be 93 Collected? . . . . . . . . . . . . . . . . . . . . . . . . 29 94 5.4. What is the Identification Level of the Data? . . . . . . 29 95 5.5. Privacy Challenges . . . . . . . . . . . . . . . . . . . . 30 96 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 31 97 6.1. EAP Channel Binding . . . . . . . . . . . . . . . . . . . 31 98 6.2. AAA Proxy Behavior . . . . . . . . . . . . . . . . . . . . 31 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 107 1. Introduction 109 The Internet uses numerous security mechanisms to manage access to 110 various resources. These mechanisms have been generalized and scaled 111 over the last decade through mechanisms such as Simple Authentication 112 and Security Layer (SASL) with the Generic Security Server 113 Application Program Interface (GSS-API) (known as the GS2 family) 114 [RFC5801], Security Assertion Markup Language (SAML) 115 [OASIS.saml-core-2.0-os], RADIUS [RFC2865], and Diameter [RFC3588]. 117 A Relying Party (RP) is the entity that manages access to some 118 resource. The actor that is requesting access to that resource is 119 often described as the Subject. Many security mechanisms are 120 manifested as an exchange of information between these actors. The 121 RP is therefore able to decide whether the Subject is authorised, or 122 not. 124 Some security mechanisms allow the RP to delegate aspects of the 125 access management decision to an actor called the Identity Provider 126 (IdP). This delegation requires technical signaling, trust and a 127 common understanding of semantics between the RP and IdP. These 128 aspects are generally managed within a relationship known as a 129 'federation'. This style of access management is accordingly 130 described as 'federated access management'. 132 Federated access management has evolved over the last decade through 133 such standards as SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth 134 [RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST]. The benefits 135 of federated access management include: 137 Single or Simplified sign-on: 139 An Internet service can delegate access management, and the 140 associated responsibilities such as identity management and 141 credentialing, to an organisation that already has a long-term 142 relationship with the Subject. This is often attractive for 143 Relying Parties who frequently do not want these responsibilities. 144 The Subject may also therefore require fewer credentials, which is 145 often desirable. 147 Privacy: 149 Often a Relying Party does not need to know the identity of a 150 Subject to reach an access management decision. It is frequently 151 only necessary for the Relying Party to establish, for example, 152 that the Subject is affiliated with a particular organisation or 153 has a certain role or entitlement. Sometimes the RP does require 154 an identifier for the Subject (for example, so that it can 155 recognise the Subject subsequently); in this case, it is a common 156 practise for the IdP to only release a pseudonym that is specific 157 to that particular Relying Party. Federated access management 158 therefore provides various strategies for protecting the Subject's 159 privacy. Other privacy aspects typically of concern are the 160 policy for releasing personal data about the Subject from the IdP 161 to the RP, the purpose of the usage, the retention period of the 162 data, and many more. 164 Provisioning 166 Sometimes a Relying Party needs, or would like, to know more about 167 a subject than an affiliation or a pseudonym. For example, a 168 Relying Party may want the Subject's email address or name. Some 169 federated access management technologies provide the ability for 170 the IdP to supply this information, either on request by the RP or 171 unsolicited. 173 This memo describes the Application Bridging for Federated Access 174 Beyond the Web (ABFAB) architecture. This architecture makes use of 175 extensions to the commonly used security mechanisms for both 176 federated and non-federated access management, including the RADIUS 177 and the Diameter protocol, the Generic Security Service (GSS), the 178 GS2 family, the Extensible Authentication Protocol (EAP) and SAML. 179 The architecture addresses the problem of federated access management 180 to primarily non-web-based services, in a manner that will scale to 181 large numbers of identity providers, relying parties, and 182 federations. 184 1.1. Terminology 186 This document uses identity management and privacy terminology from 187 [I-D.iab-privacy-terminology]. In particular, this document uses the 188 terms identity provider, relying party, (data) subject, identifier, 189 pseudonymity, unlinkability, and anonymity. 191 In this architecture the IdP consists of the following components: an 192 EAP server, a RADIUS or a Diameter server, and optionally a SAML 193 Assertion service. 195 This document uses the term Network Access Identifier (NAI), as 196 defined in [RFC4282]. 198 One of the problems people will find with reading this document is 199 that the terminology somestimes appears to be inconsistant. This is 200 do the fact that the terms used by the different standards we are 201 picking up don't use the same terms. In general the document uses 202 either a consistant term or the term associated with the standard 203 under discussion as appropriate. For reference we include this table 204 which maps the different terms into a single table. 206 +----------+------------+-------------------+-----------------------+ 207 | Protocol | Subject | Relying Party | Identity Provider | 208 +----------+------------+-------------------+-----------------------+ 209 | ABFAB | Subject | Relying Party | Identity Provider | 210 | | | (RP) | (IdP) | 211 | | | | | 212 | | Principal | | | 213 | | | | | 214 | SAML | | | | 215 | | | | | 216 | GSS-API | | | | 217 | | | | | 218 | EAP | EAP client | | EAP server | 219 | | | | | 220 | | EAP peer | | | 221 | | | | | 222 | SASL | | | | 223 | | | | | 224 | AAA | | AAA Client | AAA server | 225 | | | | | 226 | RADIUS | client | NAS | RADIUS server | 227 +----------+------------+-------------------+-----------------------+ 229 Note that in some cases a cell has been left empty, in these cases 230 there is no direct name that represents this concept. 232 Note to reviewers - I have most likely missed some entries in the 233 table. Please provide me with both correct names from the protocol 234 and missing names that are used in the text below. 236 1.2. An Overview of Federation 238 In the previous section we introduced the following actors: 240 o the Subject, 242 o the Identity Provider, and 244 o the Relying Party. 246 These entities and their relationships are illustrated graphically in 247 Figure 1. 249 ,----------\ ,---------\ 250 | Identity | Federation | Relying | 251 | Provider + <-------------------> + Party | 252 `----------' '---------' 253 < 254 \ 255 \ Authentication 256 \ 257 \ 258 \ 259 \ 260 \ +---------+ 261 \ | | O 262 v| Client | \|/ Subject 263 | | | 264 +---------+ / \ 266 Figure 1: Entities and their Relationships 268 A federation agreement typically encompasses operational 269 specifications and legal rules: 271 Operational Specifications: 273 These includes the technical specifications (e.g. protocols used 274 to communicate between the three parties), process standards, 275 policies, identity proofing, credential and authentication 276 algorithm requirements, performance requirements, assessment and 277 audit criteria, etc. The goal of these specifications to make the 278 system work and to accomplish interoperability. 280 Legal Rules: 282 The legal rules take existing laws into consideration and provide 283 contractual obligations to provide further clarification and 284 define responsibilities. These legal rules regulate the 285 operational specifications, make operational specifications 286 legally binding to the participants, define and govern the rights 287 and responsibilities of the participants. These legal rules may, 288 for example, describe liability for losses, termination rights, 289 enforcement mechanisms, measures of damage, dispute resolution, 290 warranties, etc. 292 The nature of federation dictates that there is some form of 293 relationship between the identity provider and the relying party. 294 This is particularly important when the relying party wants to use 295 information obtained from the identity provider for access management 296 decisions and when the identity provider does not want to release 297 information to every relying party (or only under certain 298 conditions). 300 While it is possible to have a bilateral agreement between every IdP 301 and every RP; on an Internet scale this setup requires the 302 introduction of the multi-lateral federation concept, as the 303 management of such pair-wise relationships would otherwise prove 304 burdensome. 306 While many of the non-technical aspects of federation, such as 307 business practices and legal arrangements, are outside the scope of 308 the IETF they still impact the architectural setup on how to ensure 309 the dynamic establishment of trust. 311 Some deployments demand the deployment of sophisticated technical 312 infrastructure, including message routing intermediaries, to offer 313 the required technical functionality. In other deployments fewer 314 technical components are needed. 316 Figure 1 also shows the relationship between the IdP and the Subject. 317 Often a real world entity is associated with the Subject; for 318 example, a person or some software. 320 The IdP will typically have a long-term relationship with the 321 Subject. This relationship would typically involve the IdP 322 positively identifying and credentialling the Subject (for example, 323 at time of enrollment in the context of employment within an 324 organisation). The relationship will often be instantiated within an 325 agreement between the IdP and the Subject (for example, within an 326 employment contract or terms of use that stipulates the appropriate 327 use of credentials and so forth). 329 While federation is often discussed within the context of relatively 330 formal relationships, such as between an enterprise and an employee 331 or a government and a citizen, federation does not in any way require 332 this; nor, indeed, does it require any particular level of formality. 333 It is, for example, entirely compatible with a relationship between 334 the IdP and Subject that is only as weak as completing a web form and 335 confirming the verification email. 337 However, the nature and quality of the relationship between the 338 Subject and the IdP is an important contributor to the level of trust 339 that an RP may attribute to an assertion describing a Subject made by 340 an IdP. This is sometimes described as the Level of Assurance. 342 Similarly it is also important to note that, in the general case, 343 there is no requirement of a long-term relationship between the RP 344 and the Subject. This is a property of federation that yields many 345 of its benefits. However, federation does not preclude the 346 possibility of a pre-existing relationship existing between the RP 347 and the Subject, nor that they may use the introduction to create a 348 new long-term relationship independent of the federation. 350 Finally, it is important to reiterate that in some scenarios there 351 might indeed be a human behind the device denoted as Client and in 352 other cases there is no human involved in the actual protocol 353 execution. 355 1.3. Challenges to Contemporary Federation 357 As the number of federated services has proliferated, the role of the 358 individual can become ambiguous in certain circumstances. For 359 example, a school might provide online access for a student's grades 360 to their parents for review, and to the student's teacher for 361 modifying the grades. A teacher who is also a parent must clearly 362 distinguish here role upon access. 364 Similarly, as the number of federations proliferates, it becomes 365 increasingly difficult to discover which identity provider(s) a user 366 is associated with. This is true for both the web and non-web case, 367 but is particularly acute for the latter as many non-web 368 authentication systems are not semantically rich enough on their own 369 to allow for such ambiguities. For instance, in the case of an email 370 provider, the use of SMTP and IMAP protocols does not on its own 371 provide for a way to select a federation. However, the building 372 blocks do exist to add this functionality. 374 1.4. An Overview of ABFAB-based Federation 376 The previous section described the general model of federation, and 377 its the application of federated access management. This section 378 provides a brief overview of ABFAB in the context of this model. 380 The steps taken in an ABFAB federated authentication/authorization 381 exchange are as follows: 383 1. Principal provides an NAI to Application: The client application 384 is configured with an NAI. The provided name contains, at a 385 minimum, the realm of an NAI. The realm represents the IdP to 386 be discovered. 388 2. Authentication mechanism selection: The GSS-EAP SASL/GS2 389 mechanism is selected for authentication/authorization. 391 3. Client Application provides the NAI to RP: The client 392 application setups a transport to the RP and begins the GSS-EAP 393 authentication. The RP initiates the EAP protocol to the client 394 application, and the client provides the NAI to the RP in the 395 form of the EAP response. 397 4. Discovery of federated IdP: The RP uses pre-configured 398 information or a federation proxy to determine what IdP to use 399 based on policy and the provided NAI. This is discussed in 400 detail below. 402 5. Request from Relying Party to IdP: Once the RP knows who the IdP 403 is, it (or its agent) will send a RADIUS/Diameter request to the 404 IdP. The RADIUS/Diameter access request encapsulates the EAP 405 response. At this stage, the RP will likely have no idea who 406 the principal is. The RP claims its identity to the IdP in AAA 407 attributes, and it may contain a SAML Attribute Requests in a 408 AAA attribute. 410 6. IdP informs the principal of which EAP method to use: The 411 available and appropriate methods are discussed below in this 412 memo. 414 7. The EAP protocol is run: A bunch of EAP messages are passed 415 between the EAP peer and the EAP server, i.e., the principal and 416 the IdP in our identity management terminology, until the result 417 of the authentication protocol is determined. The number and 418 content of those messages will depend on the EAP method. If the 419 IdP is unable to authenticate the principal, the process 420 concludes here. As part of the EAP protocol, the principal will 421 create a channel bindings message to the IdP identifying, among 422 other things, the RP to which it is attempting to authenticate. 423 The IdP checks the channel binding data from the principal with 424 that provided by the RP via the AAA protocol. If the bindings 425 do not match the IdP fails the EAP protocol. 427 8. Successful Authentication: The IdP (its EAP server) and EAP peer 428 / subject have mutually authenticated each other. As a result 429 of this step, the subject and the IdP hold two cryptographic 430 keys- a Master Session Key (MSK), and an Extended MSK (EMSK). 431 There is some confidence that the RP is the one the principal is 432 communicating with as the channel binding data validated. This 433 allows for a claim of authentication for the RP to the 434 principal. 436 9. Local IdP Policy Check: At this stage, the IdP checks local 437 policy to determine whether the RP and subject are authorized 438 for a given transaction/service, and if so, what if any, 439 attributes will be released to the RP. The RP will have done 440 it's policy checks during the discovery process. 442 10. Response from the IdP to the Relying Party: Once the IdP has 443 made a determination of whether and how to authenticate and 444 authorize the principal to the RP, it returns either a negative 445 AAA result to the RP, or it returns a positive result to the RP, 446 along with an optional set of AAA attributes associated with the 447 principal that could include one or more SAML assertions. In 448 addition, an EAP MSK is returned to the RP. 450 11. RP Processes Results: When the RP receives the result from the 451 IdP, it should have enough information to either grant or refuse 452 a resource access request. It may have information that 453 associates the principal with specific authorization identities. 454 If additional attributes are needed from the IdP the RP may make 455 a new SAML Request to the IdP. It will apply these results in 456 an application-specific way. 458 12. RP returns results to principal: Once the RP has a response it 459 must inform the client application of the result. If all has 460 gone well, all are authenticated, and the application proceeds 461 with appropriate authorization levels. 463 An example communication flow is given below: 465 Relying Client Identity 466 Party App Provider 468 | (1) | Client App gets NAI (somehow) 469 | | | 470 |<-----(2)----->| | Mechanism Selection 471 | | | 472 |<-----(3)-----<| | NAI transmitted to RP 473 | | | 474 |<=====(4)====================>| Discovery 475 | | | 476 |>=====(5)====================>| Access request from RP to IdP 477 | | | 478 | |< - - (6) - -<| EAP method to Principal 479 | | | 480 | |< - - (7) - ->| EAP Exchange to authenticate 481 | | | Principal 482 | | | 483 | | (8 & 9) Local Policy Check 484 | | | 485 |<====(10)====================<| IdP Assertion to RP 486 | | | 487 | | (11) RP processes results 488 | | | 489 |>----(12)----->| | Results to client app. 491 ----- = Between Client App and RP 492 ===== = Between RP and IdP 493 - - - = Between Client App and IdP 495 1.5. Design Goals 497 Our key design goals are as follows: 499 o Each party of a transaction will be authenticated, and the 500 principal will be authorized for access to a specific resource . 502 o Means of authentication is decoupled so as to allow for multiple 503 authentication methods. 505 o Hence, the architecture requires no sharing of long term private 506 keys. 508 o The system will scale to large numbers of identity providers, 509 relying parties, and users. 511 o The system will be designed primarily for non-Web-based 512 authentication. 514 o The system will build upon existing standards, components, and 515 operational practices. 517 Designing new three party authentication and authorization protocols 518 is hard and frought with risk of cryptographic flaws. Achieving 519 widespead deployment is even more difficult. A lot of attention on 520 federated access has been devoted to the Web. This document instead 521 focuses on a non-Web-based environment and focuses on those protocols 522 where HTTP is not used. Despite the increased excitement for 523 layering every protocol on top of HTTP there are still a number of 524 protocols available that do not use HTTP-based transports. Many of 525 these protocols are lacking a native authentication and authorization 526 framework of the style shown in Figure 1. 528 1.6. Client to Relying Party Transport 530 The transport of data between the client and the relying part is not 531 provided by GSS-API. GSS-API creates and consumes messages, but it 532 does not provide the transport itself, instead the protocol using 533 GSS-API needs to provide the transport. In many cases HTTP or HTTPS 534 is used for this transport, but other transports are perfectly 535 acceptable. The core GSS-API document [RFC2743] provides some 536 details on what requirements exist. 538 In addition we highlight the following: 540 o The transport does not need to provide either privacy or 541 integrity. After GSS-EAP has finished negotiation, GSS-API can be 542 used to provide both services. If the negotiation process itself 543 needs protection from eavesdroppers then the transport would need 544 to provide the necessary services. 546 o The transport needs to provide reliable transport of the messages. 548 o The transport needs to ensure that tokens are delivered in order 549 during the negotiation process. 551 o GSS-API messages need to be delivered atomically. If the 552 transport breaks up a message it must also reassemble the message 553 before delivery. 555 1.7. Use of AAA 557 Interestingly, for network access authentication the usage of the AAA 558 framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite 559 successful from a deployment point of view. To map the terminology 560 used in Figure 1 to the AAA framework the IdP corresponds to the AAA 561 server, the RP corresponds to the AAA client, and the technical 562 building blocks of a federation are AAA proxies, relays and redirect 563 agents (particularly if they are operated by third parties, such as 564 AAA brokers and clearing houses). The front-end, i.e. the end host 565 to AAA client communication, is in case of network access 566 authentication offered by link layer protocols that forward 567 authentication protocol exchanges back-and-forth. An example of a 568 large scale RADIUS-based federation is EDUROAM [2]. 570 Is it possible to design a system that builds on top of successful 571 protocols to offer non-Web-based protocols with a solid starting 572 point for authentication and authorization in a distributed system? 574 2. Architecture 576 Section 1 already introduced the federated access architecture, with 577 the illustration of the different actors that need to interact, but 578 it did not expand on the specifics of providing support for non-Web 579 based applications. This section details this aspect and motivates 580 design decisions. The main theme of the work described in this 581 document is focused on re-using existing building blocks that have 582 been deployed already and to re-arrange them in a novel way. 584 Although this architecture assumes updates to both the relying party 585 as well as to the client for application integration, those changes 586 are kept at a minimum. A mechanism that can demonstrate deployment 587 benefits (based on ease of update of existing software, low 588 implementation effort, etc.) is preferred and there may be a need to 589 specify multiple mechanisms to support the range of different 590 deployment scenarios. 592 There are a number of ways for encapsulating EAP into an application 593 protocol. For ease of integration with a wide range of non-Web based 594 application protocols the usage of the GSS-API was chosen. 595 Encapsulating EAP into the GSS-API also allows EAP to be used in 596 SASL. A description of the technical specification can be found in 597 [I-D.ietf-abfab-gss-eap]. Other alternatives exist as well and may 598 be considered later, such as "TLS using EAP Authentication" 599 [I-D.nir-tls-eap]. 601 The architecture consists of several buiding blocks, which is shown 602 graphically in Figure 2. The subsections below explain relationship 603 of the protocol components in more detail. 605 +--------------+ 606 | Identity | 607 | Provider | 608 | (IdP) | 609 +-^----------^-+ 610 * EAP o RADIUS/ 611 * o Diameter 612 --v----------v-- 613 /// \\\ 614 // \\ 615 | Federation | 616 | Substrate | 617 \\ // 618 \\\ /// 619 --^----------^-- 620 * EAP o RADIUS/ 621 * o Diameter 622 +-------------+ +-v----------v--+ 623 | |<---------------->| | 624 | Client | EAP/EAP Method | Relying Party | 625 | Application |<****************>| (RP) | 626 | | GSS-API | | 627 | |<---------------->| | 628 | | Application | | 629 | | Protocol | | 630 | |<================>| | 631 +-------------+ +---------------+ 633 Legend: 635 <****>: Client-to-IdP Exchange 636 <---->: Client-to-RP Exchange 637 : RP-to-IdP Exchange 638 <====>: Protocol through which GSS-API/GS2 exchanges are tunnelled 640 Figure 2: ABFAB Protocol Instantiation 642 2.1. Relying Party to Identity Provider 644 The federation substrate is responsible for the communication between 645 the relying party and the identity provider. This layer is 646 responsible for the inter-domain communication and for the technical 647 mechanisms necessary to establish inter-domain trust. 649 A key design goal is the re-use of an existing infrastructure, we 650 build upon the AAA framework as utilized by RADIUS [RFC2138] and 651 Diameter [RFC3588]. Since this document does not aim to re-describe 652 the AAA framework the interested reader is referred to [RFC2904]. 654 Building on the AAA infrastructure, and RADIUS and Diameter as 655 protocols, modifications to that infrastructure is to be avoided. 656 Also, modifications to AAA servers should be kept at a minimum. 658 The astute reader will notice that RADIUS and Diameter have 659 substantially similar characteristics. Why not pick one? A key 660 difference is that today RADIUS is largely transported upon UDP, and 661 its use is largely, though not exclusively, intra-domain. Diameter 662 itself was designed to scale to broader uses. We leave as a 663 deployment decision, which protocol will be appropriate. 665 Through the integrity protection mechanisms in the AAA framework, the 666 relying party can establish technical trust that messages are being 667 sent by the appropriate relying party. Any given interaction will be 668 associated with one federation at the policy level. The legal or 669 business relationship defines what statements the identity provider 670 is trusted to make and how these statements are interpreted by the 671 relying party. The AAA framework also permits the relying party or 672 elements between the relying party and identity provider to make 673 statements about the relying party. 675 The AAA framework provides transport for attributes. Statements made 676 about the subject by the identity provider, statements made about the 677 relying party and other information is transported as attributes. 679 One demand that the AAA substrate makes of the upper layers is that 680 they must properly identify the end points of the communication. It 681 must be possible for the AAA client at the RP to determine where to 682 send each RADIUS or Diameter message. Without this requirement, it 683 would be the RP's responsibility to determine the identity of the 684 principal on its own, without the assistance of an IdP. This 685 architecture makes use of the Network Access Identifier (NAI), where 686 the IdP is indicated in the realm component [RFC4282]. The NAI is 687 represented and consumed by the GSS-API layer as GSS_C_NT_USER_NAME 688 as specified in [RFC2743]. The GSS-API EAP mechanism includes the 689 NAI in the EAP Response/Identity message. 691 The RP needs to discover which federation will be used to contact the 692 IDP. As part of this process, the RP determines the set of business 693 rules and technical policies governing the relationship; this is 694 called rules determination. The RP also needs to establish technical 695 trust in the communications with the IDP. 697 Rules determination covers a broad range of decisions about the 698 exchange. One of these is whether the given RP is permitted to talk 699 to the IDP using a given federation at all, so rules determination 700 encompasses the basic authorization decision. Other factors are 701 included, such as what policies govern release of information about 702 the principal to the RP and what policies govern the RP's use of this 703 information. While rules determination is ultimately a business 704 function, it has significant impact on the technical exchanges. The 705 protocols need to communicate the result of authorization. When 706 multiple sets of rules are possible, the protocol must disambiguate 707 which set of rules are in play. Some rules have technical 708 enforcement mechanisms; for example in some federations intermediates 709 validate information that is being communicated within the 710 federation. 712 Several deployment approaches are possible. These can most easily be 713 classified based on the mechanism for technical trust that is used. 714 The choice of technical trust mechanism constrains how rules 715 determination is implemented. Regardless of what deployment strategy 716 is chosen, it is important that the technical trust mechanism 717 constrain the names of both parties to the exchange. The trust 718 mechanism ought to ensure that the entity acting as IDP for a given 719 NAI is permitted to be the IDP for that realm, and that any service 720 name claimed by the RP is permitted to be claimed by that entity. 721 Here are the categories of technical trust determination: 723 AAA Proxy: The simplest model is that an RP supports a request 724 directly to an AAA proxy. The hop-by-hop integrity protection of 725 the AAA fabric provides technical trust. An RP can submit a 726 request directly to a federation. Alternatively, a federation 727 disambiguation fabric can be used. Such a fabric takes 728 information about what federations the RP is part of and what 729 federations the IDP is part of and routes a message to the 730 appropriate federation. The routing of messages across the fabric 731 plus attributes added to requests and responses provides rules 732 determination. For example, when a disambiguation fabric routes a 733 message to a given federation, that federation's rules are chosen. 734 Naming is enforced as messages travel across the fabric. The 735 entities near the RP confirm its identity and validate names it 736 claims. The fabric routes the message towards the appropriate 737 IDP, validating the IDP's name in the process. The routing can be 738 statically configured. Alternatively a routing protocol could be 739 developed to exchange reachability information about given IDPs 740 and to apply policy across the AAA fabric. Such a routing 741 protocol could flood naming constraints to the appropriate points 742 in the fabric. 744 Trust Broker: Instead of routing messages through AAA proxies, some 745 trust broker could establish keys between entities near the RP and 746 entities near the IDP. The advantage of this approach is 747 efficiency of message handling. Fewer entities are needed to be 748 involved for each message. Security may be improved by sending 749 individual messages over fewer hops. Rules determination involves 750 decisions made by trust brokers about what keys to grant. Also, 751 associated with each credential is context about rules and about 752 other aspects of technical trust including names that may be 753 claimed. A routing protocol similar to the one for AAA proxies is 754 likely to be useful to trust brokers in flooding rules and naming 755 constraints. 757 Global Credential: A global credential such as a public key and 758 certificate in a public key infrastructure can be used to 759 establish technical trust. A directory or distributed database 760 such as the Domain Name System is needed for an RP to discover 761 what endpoint to contact for a given NAI. Certificates provide a 762 place to store information about rules determination and naming 763 constraints. Provided that no intermediates are required and that 764 the RP and IDP are sufficient to enforce and determine rules, 765 rules determination is reasonably simple. However applying 766 certain rules is likely to be quite complex. For example if 767 multiple sets of rules are possible between an IDP and RP, 768 confirming the correct set is used may be difficult. This is 769 particularly true if intermediates are involved in making the 770 decision. Also, to the extent that directory information needs to 771 be trusted, rules determination may be more complex. 773 Real-world deployments are likely to be mixtures of these basic 774 approaches. For example, it will be quite common for an RP to route 775 traffic to a AAA proxy within an organization. That proxy MAY use 776 any of the three methods to get closer to the IDP. It is also likely 777 that rather than being directly reachable, an IDP may have a proxy 778 within its organization. Federations MAY provide a traditional AAA 779 proxy interface even if they also provide another mechanism for 780 increased efficiency or security. 782 2.2. Client To Identity Provider 784 Traditional web federation does not describe how a subject interacts 785 with an identity provider for authentication. As a result, this 786 communication is not standardized. There are several disadvantages 787 to this approach. It is difficult to have subjects that are machines 788 rather than humans that use some sort of programatic credential. In 789 addition, use of browsers for authentication restricts the deployment 790 of more secure forms of authentication beyond plaintext username and 791 password known by the server. In a number of cases the 792 authentication interface may be presented before the subject has 793 adequately validated they are talking to the intended server. By 794 giving control of the authentication interface to a potential 795 attacker, then the security of the system may be reduced and phishing 796 opportunities introduced. 798 As a result, it is desirable to choose some standardized approach for 799 communication between the subject's end-host and the identity 800 provider. There are a number of requirements this approach must 801 meet. 803 Experience has taught us one key security and scalability 804 requirement: it is important that the relying party not get 805 possession of the long-term secret of the client. Aside from a 806 valuable secret being exposed, a synchronization problem can develop 807 when the client changes keys with the IdP. 809 Since there is no single authentication mechanism that will be used 810 everywhere there is another associated requirement: The 811 authentication framework must allow for the flexible integration of 812 authentication mechanisms. For instance, some IdPs require hardware 813 tokens while others use passwords. A service provider wants to 814 provide support for both authentication methods, and other methods 815 from IdPs not yet seen. 817 Fortunately, these requirements can be met by utilizing standardized 818 and successfully deployed technology, namely by the Extensible 819 Authentication Protocol (EAP) framework [RFC3748]. Figure 2 820 illustrates the integration graphically. 822 EAP is an end-to-end framework; it provides for two-way communication 823 between a peer (i.e,service client or principal) through the 824 authenticator (i.e., service provider) to the back-end (i.e., 825 identity provider). Conveniently, this is precisely the 826 communication path that is needed for federated identity. Although 827 EAP support is already integrated in AAA systems (see [RFC3579] and 828 [RFC4072]) several challenges remain: one is to carry EAP payloads 829 from the end host to the relying party. Another is to verify 830 statements the relying party has made to the subject, confirm these 831 statements are consistent with statements made to the identity 832 provider and confirm all the above are consistent with the federation 833 and any federation-specific policy or configuration. Another 834 challenge is choosing which identity provider to use for which 835 service. 837 2.3. Client to Relying Party 839 One of the remaining layers is responsible for integration of 840 federated authentication into the application. There are a number of 841 approaches that applications have adopted for security. So, there 842 may need to be multiple strategies for integration of federated 843 authentication into applications. However, we have started with a 844 strategy that provides integration to a large number of application 845 protocols. 847 Many applications such as SSH [RFC4462], NFS [RFC2203], DNS [RFC3645] 848 and several non-IETF applications support the Generic Security 849 Services Application Programming Interface [RFC2743]. Many 850 applications such as IMAP, SMTP, XMPP and LDAP support the Simple 851 Authentication and Security Layer (SASL) [RFC4422] framework. These 852 two approaches work together nicely: by creating a GSS-API mechanism, 853 SASL integration is also addressed. In effect, using a GSS-API 854 mechanism with SASL simply requires placing some headers on the front 855 of the mechanism and constraining certain GSS-API options. 857 GSS-API is specified in terms of an abstract set of operations which 858 can be mapped into a programming language to form an API. When 859 people are first introduced to GSS-API, they focus on it as an API. 860 However, from the prospective of authentication for non-web 861 applications, GSS-API should be thought of as a protocol not an API. 862 It consists of some abstract operations such as the initial context 863 exchange, which includes two sub-operations (gss_init_sec_context and 864 gss_accept_sec_context). An application defines which abstract 865 operations it is going to use and where messages produced by these 866 operations fit into the application architecture. A GSS-API 867 mechanism will define what actual protocol messages result from that 868 abstract message for a given abstract operation. So, since this work 869 is focusing on a particular GSS-API mechanism, we generally focus on 870 protocol elements rather than the API view of GSS-API. 872 The API view has significant value. Since the abstract operations 873 are well defined, the set of information that a mechanism gets from 874 the application is well defined. Also, the set of assumptions the 875 application is permitted to make is generally well defined. As a 876 result, an application protocol that supports GSS-API or SASL is very 877 likely to be usable with a new approach to authentication including 878 this one with no required modifications. In some cases, support for 879 a new authentication mechanism has been added using plugin interfaces 880 to applications without the application being modified at all. Even 881 when modifications are required, they can often be limited to 882 supporting a new naming and authorization model. For example, this 883 work focuses on privacy; an application that assumes it will always 884 obtain an identifier for the principal will need to be modified to 885 support anonymity, unlinkability or pseudonymity. 887 So, we use GSS-API and SASL because a number of the application 888 protocols we wish to federate support these strategies for security 889 integration. What does this mean from a protocol standpoint and how 890 does this relate to other layers? This means we need to design a 891 concrete GSS-API mechanism. We have chosen to use a GSS-API 892 mechanism that encapsulates EAP authentication. So, GSS-API (and 893 SASL) encapsulate EAP between the end-host and the service. The AAA 894 framework encapsulates EAP between the relying party and the identity 895 provider. The GSS-API mechanism includes rules about how principals 896 and services are named as well as per-message security and other 897 facilities required by the applications we wish to support. 899 3. Application Security Services 901 One of the key goals is to integrate federated authentication into 902 existing application protocols and where possible, existing 903 implementations of these protocols. Another goal is to perform this 904 integration while meeting the best security practices of the 905 technologies used to perform the integration. This section describes 906 security services and properties required by the EAP GSS-API 907 mechanism in order to meet these goals. This information could be 908 viewed as specific to that mechanism. However, other future 909 application integration strategies are very likely to need similar 910 services. So, it is likely that these services will be expanded 911 across application integration strategies if new application 912 integration strategies are adopted. 914 3.1. Authentication 916 GSS-API provides an optional security service called mutual 917 authentication. This service means that in addition to the initiator 918 providing (potentially anonymous or pseudonymous) identity to the 919 acceptor, the acceptor confirms its identity to the initiator. 920 Especially for the ABFAB context, this service is confusingly named. 921 We still say that mutual authentication is provided when the identity 922 of an acceptor is strongly authenticated to an anonymous initiator. 924 RFC 2743, unfortunately, does not explicitly talk about what mutual 925 authentication means. Within this document we therefore define it 926 as: 928 o If a target name is supplied by the initiator, then the initiator 929 trusts that the supplied target name describes the acceptor. This 930 implies both that appropriate cryptographic exchanges took place 931 for the initiator to make such a trust decision, and that after 932 evaluating the results of these exchanges, the initiator's policy 933 trusts that the target name is accurate. 935 o If no target name is supplied by the initiator, then the initiator 936 trusts that its idea of the acceptor name correctly names the 937 entity it is communicating with. 939 o Both the initiator and acceptor have the same key material for 940 per-message keys and both parties have confirmed they actually 941 have the key material. In EAP terms, there is a protected 942 indication of success. 944 Mutual authentication is an important defense against certain aspects 945 of phishing. Intuitively, users would like to assume that if some 946 party asks for their credentials as part of authentication, 947 successfully gaining access to the resource means that they are 948 talking to the expected party. Without mutual authentication, the 949 acceptor could "grant access" regardless of what credentials are 950 supplied. Mutual authentication better matches this user intuition. 952 It is important, therefore, that the GSS-EAP mechanism implement 953 mutual authentication. That is, an initiator needs to be able to 954 request mutual authentication. When mutual authentication is 955 requested, only EAP methods capabale of providing the necessary 956 service can be used, and appropriate steps need to be taken to 957 provide mutual authentication. A broader set of EAP methods could be 958 supported when a particular application does not request mutual 959 authentication. It is an open question whether the mechanism will 960 permit this. 962 The AAA infrastructure MAY hide the peer's identity from the GSS-API 963 acceptor, providing anonymity between the peer and initiator. At 964 this time, whether the identity is disclosed is determined by EAP 965 server policy rather than by an indication from the peer. Also, 966 peers are unlikely to be able to determine whether anonymous 967 communication will be provided. For this reason, peers are unlikely 968 to set the anonymous return flag from GSS_Init_Sec_context. 970 3.2. GSS-API Channel Binding 972 [RFC5056] defines a concept of channel binding to prevent man-in-the- 973 middle attacks. It is common to provide SASL and GSS-API with 974 another layer to provide transport security; Transport Layer Security 975 (TLS) is the most common such layer. TLS provides its own server 976 authentication. However there are a variety of situations where this 977 authentication is not checked for policy or usability reasons. Even 978 when it is checked, if the trust infrastructure behind the TLS 979 authentication is different from the trust infrastructure behind the 980 GSS-API mutual authentication. If the endpoints of the GSS-API 981 authentication are different than the endpoints of the lower layer, 982 this is a strong indication of a problem such as a man-in-the-middle 983 attack. Channel binding provides a facility to determine whether 984 these endpoints are the same. 986 The GSS-EAP mechanism needs to support channel binding. When an 987 application provides channel binding data, the mechanism needs to 988 confirm this is the same on both sides consistent with the GSS-API 989 specification. XXXThere is an open question here as to the details; 990 today RFC 5554 governs. We could use that and the current draft 991 assumes we will. However in Beijing we became aware of some changes 992 to these details that would make life much better for GSS 993 authentication of HTTP. We should resolve this with kitten and 994 replace this note with a reference to the spec we're actually 995 following. 997 Typically when considering channel binding, people think of channel 998 binding in combination with mutual authentication. This is 999 sufficiently common that without additional qualification channel 1000 binding should be assumed to imply mutual authentication. Without 1001 mutual authentication, only one party knows that the endpoints are 1002 correct. That's sometimes useful. Consider for example a user who 1003 wishes to access a protected resource from a shared whiteboard in a 1004 conference room. The whiteboard is the initiator; it does not need 1005 to actually authenticate that it is talking to the correct resource 1006 because the user will be able to recognize whether the displayed 1007 content is correct. If channel binding were used without mutual 1008 authentication, it would in effect be a request to only disclose the 1009 resource in the context of a particular channel. Such an 1010 authentication would be similar in concept to a holder-of-key SAML 1011 assertion. However, also note that while it is not happening in the 1012 protocol, mutual authentication is happening in the overall system: 1013 the user is able to visually authenticate the content. This is 1014 consistent with all uses of channel binding without protocol level 1015 mutual authentication found so far. 1017 RFC 5056 channel binding (also called GSS-API channel binding when 1018 GSS-API is involved) is not the same thing as EAP channel binding. 1019 EAP channel binding is also used in the ABFAB context in order to 1020 implement acceptor naming and mutual authentication. Details are 1021 discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. 1023 3.3. Host-Based Service Names 1025 IETF security mechanisms typically take the name of a service entered 1026 by a user and make some trust decision about whether the remote party 1027 in an interaction is the intended party. GSS-API has a relatively 1028 flexible naming architecture. However most of the IETF applications 1029 that use GSS-API, including SSH, NFS, IMAP, LDAP and XMPP, have 1030 chosen to use host-based service names when they use GSS-API. In 1031 this model, the initiator names an acceptor based on a service such 1032 as "imap" or "host" (for login services such as SSH) and a host name. 1034 Using host-based service names leads to a challenging trust 1035 delegation problem. Who is allowed to decide whether a particular 1036 hostname maps to an entity. The public-key infrastructure (PKI) used 1037 by the web has chosen to have a number of trust anchors (root 1038 certificate authorities) each of wich can map any name to a public 1039 key. A number of GSS-API mechanisms suchs as Kerberos [RFC1964] 1040 split the problem into two parts. A new concept called a realm is 1041 introduced. Then the mechanism decides what realm is responsible for 1042 a given name. That realm is responsible for deciding if the acceptor 1043 entity is allowed to claim the name. ABFAB needs to adopt this 1044 approach. 1046 Host-based service names do not work ideally when different instances 1047 of a service are running on different ports. Also, these do not work 1048 ideally when SRV record or other insecure referrals are used. 1050 The GSS-EAP mechanism needs to support host-based service names in 1051 order to work with existing IETF protocols. 1053 3.4. Per-Message Tokens 1055 GSS-API provides per-message security services that can provide 1056 confidentiality and integrity. Some IETF protocols such as NFS and 1057 SSH take advantage of these services. As a result GSS-EAP needs to 1058 support these services. As with mutual authentication, per-message 1059 services will limit the set of EAP methods that are available. Any 1060 method that produces a Master Session Key (MSK) should be able to 1061 support per-message security services. 1063 GSS-API provides a pseudo-random function. While the pseudo-random 1064 function does not involve sending data over the wire, it provides an 1065 algorithm that both the initiator and acceptor can run in order to 1066 arrive at the same key value. This is useful for designs where a 1067 successful authentication is used to key some other function. This 1068 is similar in concept to the TLS extractor. No current IETF 1069 protocols require this. However GSS-EAP supports this service 1070 because it is valuable for the future and easy to do given per- 1071 message services. Non-IETF protocols are expected to take advantage 1072 of this in the near future. 1074 4. Future Work: Attribute Providers 1076 This architecture provides for a federated authentication and 1077 authorization framework between IdPs, RPs, principals, and subjects. 1078 It does not at this time provide for a means to retrieve attributes 1079 from 3rd parties. However, it envisions such a possibility. We note 1080 that in any extension to the model, an attribute provider must be 1081 authorized to release specific attributes to a specific RP for a 1082 specific principal. In addition, we note that it is an open question 1083 beyond this architecture as to how the RP should know to trust a 1084 particular attribute provider. 1086 There are a number of possible technical means to provide attribute 1087 provider capabilities. One possible approach is for the IdP to 1088 provide a signed attribute request to RP that it in turn will provide 1089 to the attribute authority. Another approach would be for the IdP to 1090 provide a URI to the RP that contains a token of some form. The form 1091 of communications between the IdP and attribute provider as well as 1092 other considerations are left for the future. One thing we can say 1093 now is that the IdP would merely be asserting who the attribute 1094 authority is, and not the contents of what the attribute authority 1095 would return. (Otherwise, the IdP might as well make the query to 1096 the attribute authority and then resign it.) 1098 5. Privacy Considerations 1100 Sharing identity information raises privacy violations and as 1101 described throughout this document an existing architecture is re- 1102 used for a different usage environment. As such, a discussion about 1103 the privacy properties has to take these pre-conditions into 1104 consideration. We use the approach suggested in 1105 [I-D.iab-privacy-considerations] to shed light into what data is 1106 collected and used by which entity, what the relationship between 1107 these entities and the end user is, what data about the user is 1108 likely needed to be collected, and what the identification level of 1109 the data is. 1111 5.1. What Entities collect and use Data? 1113 Figure 2 shows the architecture with the involved entities. Message 1114 exchanges are exchanged between the client application, via the 1115 relying part to the AAA server. There will likely be intermediaries 1116 between the relying party and the AAA server, labeled generically as 1117 "federation". 1119 In order for the relying party to route messages to the AAA server it 1120 is necessary for the client application to provide enough information 1121 to enable the identification of the AAA server's domain. While often 1122 the username is attached to the domain (in the form of a Network 1123 Access Identity (NAI) this is not necessary for the actual protocol 1124 operation. The EAP server component within the AAA server needs to 1125 authenticate the user and therefore needs to execute the respective 1126 authentication protocol. Once the authentication exchange is 1127 complete authorization information needs to be conveyed to the 1128 relying party to grant the user the necessary application rights. 1129 Information about resource consumption may be delivered as part of 1130 the accounting exchange during the lifetime of the granted 1131 application session. 1133 The authentication exchange may reveal an identifier that can be 1134 linked to a user. Additionally, a sequence of authentication 1135 protocol exchanges may be linked together. Depending on the chosen 1136 authentication protocol information at varying degrees may be 1137 revealed to all parties along the communication path. This 1138 authorization information exchange may disclose identity information 1139 about the user. While accounting information is created by the 1140 relying party it is likely to needed by intermediaries in the 1141 federation for financial settlement purposes and will be stored for 1142 billing, fraud detection, statistical purposes, and for service 1143 improvement by the AAA server operator. 1145 5.2. Relationship between User's and other Entities 1147 The AAA server is a first-party site the user typically has a 1148 relationship with. This relationship will be created at the time 1149 when the security credentials are exchange and provisioned. The 1150 relying party and potential intermediares in the federation are 1151 typically operate under the contract of the first-party site. The 1152 user typically does not know about the intermediaries in the 1153 federation nor does he have any relationship with them. The protocol 1154 interaction triggered by the client application happens with the 1155 relying party at the time of application access. The relying party 1156 does not have a direct contractual relationship with the user but 1157 depending on the application the interaction may expose the brand of 1158 the application running by the relying party to the end user via some 1159 user interface. 1161 5.3. What Data about the User is likely Needed to be Collected? 1163 The data that is likely going to be collected as part of a protocol 1164 exchange with application access at the relying party is accounting 1165 information and authorization information. This information is 1166 likely to be kept beyond the terminated application usage for trouble 1167 shooting, statistical purposes, etc. There is also like to be 1168 additional data collected to to improve application service usage by 1169 the relying party that is not conveyed to the AAA server as part of 1170 the accounting stream. 1172 5.4. What is the Identification Level of the Data? 1174 With regard to identification there are several protocol layers that 1175 need to be considered separately. First, there is the EAP method 1176 exchange, which as an authentication and key exchange protocol has 1177 properties related to identification and protocol linkage. Second, 1178 there is identification at the EAP layer for routing of messages. 1179 Then, in the exchange between the client application and the relying 1180 party the identification depends on the underlying application layer 1181 protocol the EAP/GSS-API exchange is tunneled over. Finally, there 1182 is the backend exchange via the AAA infrastructure, which involves a 1183 range of RADIUS and Diameter extensions and yet to be defined 1184 extensions, such as encoding authorization information inside SAML 1185 assertions. 1187 Since this document does not attempt to define any of these exchanges 1188 but rather re-uses existing mechanisms the level of identification 1189 heavily depends on the selected mechanisms. The following two 1190 examples aim to illustrate the amount of existing work with respect 1191 to decrease exposure of personal data. 1193 1. When designing EAP methods a number of different requirements may 1194 need to get considered; some of them are conflicting. RFC 4017 1195 [RFC4017], for example, tried to list requirements for EAP 1196 methods utilized for network access over Wireless LANs. It also 1197 recommends the end-user identity hiding requirement, which is 1198 privacy-relevant. Some EAP methods, such as EAP-IKEv2 [RFC5106], 1199 also fulfill this requirement. 1201 2. EAP, as the layer encapsulating EAP method specific information, 1202 needs identity information to allow routing requests towards the 1203 user's home AAA server. This information is carried within the 1204 Network Access Identifier (NAI) and the username part of the NAI 1205 (as supported by RFC 4282 [RFC4282]) can be obfuscated. 1207 5.5. Privacy Challenges 1209 While a lot of standarization work was done to avoid leakage of 1210 identity information to intermediaries (such as eavesdroppers on the 1211 communication path between the client application and the relying 1212 party) in the area of authentication and key exchange protocols. 1213 However, from current deployments the weak aspects with respect to 1214 security are: 1216 1. Today business contracts are used to create federations between 1217 identity providers and relying parties. These contracts are not 1218 only financial agreements but they also define the rules about 1219 what information is exchanged between the AAA server and the 1220 relying party and the potential involvement of AAA proxies and 1221 brokers as intermediaries. While these contracts are openly 1222 available for university federations they are not public in case 1223 of commercial deployments. Quite naturally, there is a lack of 1224 transparency for external parties. 1226 2. In today's deployments the ability for users to determine the 1227 amount of information exchanged with other parties over time, as 1228 well as the possibility to control the amount of information 1229 exposed via an explict consent is limited. This is partially due 1230 the nature of application capabilities at the time of network 1231 access authentication. However, with the envisioned extension of 1232 the usage, as described in this document, it is desirable to 1233 offer these capabilities. 1235 6. Deployment Considerations 1237 6.1. EAP Channel Binding 1239 Discuss the implications of needing EAP channel binding. 1241 6.2. AAA Proxy Behavior 1243 Discuss deployment implications of our proxy requirements. 1245 7. Security Considerations 1247 This document describes the architecture for Application Bridging for 1248 Federated Access Beyond Web (ABFAB) and security is therefore the 1249 main focus. This section highlights the main communication channels 1250 and their security properties: 1252 Client-to-RP Channel: 1254 The channel binding material is provided by any certificates and 1255 the final message (i.e., a cryptographic token for the channel). 1256 Authentication may be provided by the RP to the client but a 1257 deployment without authentication at the TLS layer is possible as 1258 well. In addition, there is a channel between the GSS requestor 1259 and the GSS acceptor, but the keying material is provided by a 1260 "third party" to both entities. The client can derive keying 1261 material locally, but the RP gets the material from the IdP. In 1262 the absence of a transport that provides encryption and/or 1263 integrity, the channel between the client and the RP has no 1264 ability to have any cryptographic protection until the EAP 1265 authentication has been completed and the MSK is transfered from 1266 the IdP to the RP. 1268 RP-to-IdP Channel: 1270 The security of this communication channel is mainly provided by 1271 the functionality offered via RADIUS and Diameter. At the time of 1272 writing there are no end-to-end security mechanisms standardized 1273 and thereby the architecture has to rely on hop-by-hop security 1274 with trusted AAA entities or, as an alternative but possible 1275 deployment variant, direct communication between the AAA client to 1276 the AAA server. Note that the authorization result the IdP 1277 provides to the RP in the form of a SAML assertion may, however, 1278 be protected such that the SAML related components are secured 1279 end-to-end. 1281 The MSK is transported from the IdP to the RP over this channel. 1282 As no end-to-end security is provided by AAA, all AAA entities on 1283 the path between the RP and IdP have the ability to eavesdrop if 1284 no additional security measures are taken. One such measure is to 1285 use a transport between the client and the IdP that provides 1286 confidentiality. 1288 Client-to-IdP Channel: 1290 This communication interaction is accomplished with the help of 1291 EAP and EAP methods. The offered security protection will depend 1292 on the EAP method that is chosen but a minimum requirement fis to 1293 offer mutual authentication, and key derivation. The IdP is 1294 responsible during this process to determine that the RP that is 1295 communication to the client over the RP-to-IdP channel is the same 1296 one talking to the IdP. This is accomplished via the EAP channel 1297 binding. 1299 Partial list of issues to be addressed in this section: Privacy, 1300 SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA 1301 Issues, Naming of Entities, Protection of passwords, Channel Binding, 1302 End-point-connections (TLS), Proxy problems 1304 8. IANA Considerations 1306 This document does not require actions by IANA. 1308 9. Acknowledgments 1310 We would like to thank Mayutan Arumaithurai and Klaas Wierenga for 1311 their feedback. Additionally, we would like to thank Eve Maler, 1312 Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, and Luke 1313 Howard for their feedback on the federation terminology question. 1315 Furthermore, we would like to thank Klaas Wierenga for his review of 1316 the pre-00 draft version. 1318 10. References 1320 10.1. Normative References 1322 [RFC2743] Linn, J., "Generic Security Service Application Program 1323 Interface Version 2, Update 1", RFC 2743, January 2000. 1325 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1326 "Remote Authentication Dial In User Service (RADIUS)", 1327 RFC 2865, June 2000. 1329 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1330 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1332 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1333 Levkowetz, "Extensible Authentication Protocol (EAP)", 1334 RFC 3748, June 2004. 1336 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1337 Dial In User Service) Support For Extensible 1338 Authentication Protocol (EAP)", RFC 3579, September 2003. 1340 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1341 Authentication Protocol (EAP) Application", RFC 4072, 1342 August 2005. 1344 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1345 Network Access Identifier", RFC 4282, December 2005. 1347 [I-D.iab-privacy-terminology] 1348 Hansen, M., Tschofenig, H., Smith, R., and A. Cooper, 1349 "Privacy Terminology and Concepts", 1350 draft-iab-privacy-terminology-01 (work in progress), 1351 March 2012. 1353 [I-D.ietf-abfab-gss-eap] 1354 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 1355 Extensible Authentication Protocol", 1356 draft-ietf-abfab-gss-eap-07 (work in progress), May 2012. 1358 10.2. Informative References 1360 [I-D.nir-tls-eap] 1361 Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A 1362 Flexible Authentication Framework for the Transport Layer 1363 Security (TLS) Protocol using the Extensible 1364 Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work 1365 in progress), December 2011. 1367 [I-D.ietf-oauth-v2] 1368 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 1369 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 1370 in progress), May 2012. 1372 [I-D.iab-privacy-considerations] 1373 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and 1374 J. Morris, "Privacy Considerations for Internet 1375 Protocols", draft-iab-privacy-considerations-02 (work in 1376 progress), March 2012. 1378 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1379 Authentication Protocol (EAP) Method Requirements for 1380 Wireless LANs", RFC 4017, March 2005. 1382 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 1383 and F. Bersani, "The Extensible Authentication Protocol- 1384 Internet Key Exchange Protocol version 2 (EAP-IKEv2) 1385 Method", RFC 5106, February 2008. 1387 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1388 RFC 1964, June 1996. 1390 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1391 Specification", RFC 2203, September 1997. 1393 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., 1394 and R. Hall, "Generic Security Service Algorithm for 1395 Secret Key Transaction Authentication for DNS (GSS-TSIG)", 1396 RFC 3645, October 2003. 1398 [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S. 1399 Willens, "Remote Authentication Dial In User Service 1400 (RADIUS)", RFC 2138, April 1997. 1402 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1403 "Generic Security Service Application Program Interface 1404 (GSS-API) Authentication and Key Exchange for the Secure 1405 Shell (SSH) Protocol", RFC 4462, May 2006. 1407 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1408 Security Layer (SASL)", RFC 4422, June 2006. 1410 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1411 Channels", RFC 5056, November 2007. 1413 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1414 Service Application Program Interface (GSS-API) Mechanisms 1415 in Simple Authentication and Security Layer (SASL): The 1416 GS2 Mechanism Family", RFC 5801, July 2010. 1418 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1419 April 2010. 1421 [OASIS.saml-core-2.0-os] 1422 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1423 "Assertions and Protocol for the OASIS Security Assertion 1424 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1425 2.0-os, March 2005. 1427 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1428 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1429 D. Spence, "AAA Authorization Framework", RFC 2904, 1430 August 2000. 1432 [WS-TRUST] 1433 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, 1434 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS 1435 Standard ws-trust-200902, February 2009, . 1438 URIs 1440 [1] 1442 [2] 1444 Authors' Addresses 1446 Josh Howlett 1447 JANET(UK) 1448 Lumen House, Library Avenue, Harwell 1449 Oxford OX11 0SG 1450 UK 1452 Phone: +44 1235 822363 1453 Email: Josh.Howlett@ja.net 1455 Sam Hartman 1456 Painless Security 1458 Phone: 1459 Email: hartmans-ietf@mit.edu 1461 Hannes Tschofenig 1462 Nokia Siemens Networks 1463 Linnoitustie 6 1464 Espoo 02600 1465 Finland 1467 Phone: +358 (50) 4871445 1468 Email: Hannes.Tschofenig@gmx.net 1469 URI: http://www.tschofenig.priv.at 1471 Eliot Lear 1472 Cisco Systems GmbH 1473 Richtistrasse 7 1474 Wallisellen, ZH CH-8304 1475 Switzerland 1477 Phone: +41 44 878 9200 1478 Email: lear@cisco.com 1480 Jim Schaad 1481 Soaring Hawk Consulting 1483 Email: ietf@augustcellars.com