idnits 2.17.00 (12 Aug 2021) /tmp/idnits55882/draft-ietf-abfab-arch-03.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 1143: '...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 (July 9, 2012) is 3602 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-abfab-aaa-saml has been published as RFC 7833 == Outdated reference: draft-ietf-emu-chbind has been published as RFC 6677 == 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 (~~), 6 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: January 10, 2013 Painless Security 6 H. Tschofenig 7 Nokia Siemens Networks 8 E. Lear 9 Cisco Systems GmbH 10 J. Schaad 11 Soaring Hawk Consulting 12 July 9, 2012 14 Application Bridging for Federated Access Beyond Web (ABFAB) 15 Architecture 16 draft-ietf-abfab-arch-03.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 January 10, 2013. 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. Use of AAA . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1.7. Use of GSS-API . . . . . . . . . . . . . . . . . . . . . . 14 79 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 2.1. Relying Party to Identity Provider . . . . . . . . . . . . 16 81 2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . . 17 82 2.1.2. Discovery and Rules Determination . . . . . . . . . . 18 83 2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 19 84 2.1.4. SAML Assertions . . . . . . . . . . . . . . . . . . . 20 85 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 22 86 2.2.1. Extensible Authentication Protocol (EAP) . . . . . . . 22 87 2.2.2. Channel Binding . . . . . . . . . . . . . . . . . . . 23 88 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 23 89 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 24 90 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . . 25 91 3. Application Security Services . . . . . . . . . . . . . . . . 26 92 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 26 93 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 27 94 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . . 28 95 3.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 29 96 4. Future Work: Attribute Providers . . . . . . . . . . . . . . . 30 97 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 31 98 5.1. What Entities collect and use Data? . . . . . . . . . . . 31 99 5.2. Relationship between User's and other Entities . . . . . . 32 100 5.3. What Data about the User is likely Needed to be 101 Collected? . . . . . . . . . . . . . . . . . . . . . . . . 32 102 5.4. What is the Identification Level of the Data? . . . . . . 32 103 5.5. Privacy Challenges . . . . . . . . . . . . . . . . . . . . 33 104 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 34 105 6.1. EAP Channel Binding . . . . . . . . . . . . . . . . . . . 34 106 6.2. AAA Proxy Behavior . . . . . . . . . . . . . . . . . . . . 34 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 113 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 116 1. Introduction 118 The Internet uses numerous security mechanisms to manage access to 119 various resources. These mechanisms have been generalized and scaled 120 over the last decade through mechanisms such as Simple Authentication 121 and Security Layer (SASL) with the Generic Security Server 122 Application Program Interface (GSS-API) (known as the GS2 family) 123 [RFC5801], Security Assertion Markup Language (SAML) 124 [OASIS.saml-core-2.0-os], RADIUS [RFC2865], and Diameter [RFC3588]. 126 A Relying Party (RP) is the entity that manages access to some 127 resource. The actor that is requesting access to that resource is 128 often described as the Subject. Many security mechanisms are 129 manifested as an exchange of information between these actors. The 130 RP is therefore able to decide whether the Subject is authorised, or 131 not. 133 Some security mechanisms allow the RP to delegate aspects of the 134 access management decision to an actor called the Identity Provider 135 (IdP). This delegation requires technical signaling, trust and a 136 common understanding of semantics between the RP and IdP. These 137 aspects are generally managed within a relationship known as a 138 'federation'. This style of access management is accordingly 139 described as 'federated access management'. 141 Federated access management has evolved over the last decade through 142 such standards as SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth 143 [RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST]. The benefits 144 of federated access management include: 146 Single or Simplified sign-on: 148 An Internet service can delegate access management, and the 149 associated responsibilities such as identity management and 150 credentialing, to an organisation that already has a long-term 151 relationship with the Subject. This is often attractive for 152 Relying Parties who frequently do not want these responsibilities. 153 The Subject also requires fewer credentials, which is also 154 desirable. 156 Privacy: 158 Often a Relying Party does not need to know the identity of a 159 Subject to reach an access management decision. It is frequently 160 only necessary for the Relying Party know specific attributes 161 about the subject, for example, that the Subject is affiliated 162 with a particular organisation or has a certain role or 163 entitlement. Sometimes the RP does not need to know the identity 164 of the Subject, but does require a unique identifier for the 165 Subject (for example, so that it can recognise the Subject 166 subsequently); in this case, it is a common practise for the IdP 167 to only release a pseudonym that is specific to that particular 168 Relying Party. Federated access management therefore provides 169 various strategies for protecting the Subject's privacy. Other 170 privacy aspects typically of concern are the policy for releasing 171 personal data about the Subject from the IdP to the RP, the 172 purpose of the usage, the retention period of the data, and many 173 more. 175 Provisioning 177 Sometimes a Relying Party needs, or would like, to know more about 178 a subject than an affiliation or a pseudonym. For example, a 179 Relying Party may want the Subject's email address or name. Some 180 federated access management technologies provide the ability for 181 the IdP to supply this information, either on request by the RP or 182 unsolicited. 184 This memo describes the Application Bridging for Federated Access 185 Beyond the Web (ABFAB) architecture. This architecture makes use of 186 extensions to the commonly used security mechanisms for both 187 federated and non-federated access management, including the RADIUS 188 and the Diameter protocol, the Generic Security Service (GSS), the 189 GS2 family, the Extensible Authentication Protocol (EAP) and SAML. 190 The architecture addresses the problem of federated access management 191 to primarily non-web-based services, in a manner that will scale to 192 large numbers of identity providers, relying parties, and 193 federations. 195 1.1. Terminology 197 This document uses identity management and privacy terminology from 198 [I-D.iab-privacy-terminology]. In particular, this document uses the 199 terms identity provider, relying party, (data) subject, identifier, 200 pseudonymity, unlinkability, and anonymity. 202 In this architecture the IdP consists of the following components: an 203 EAP server, a RADIUS or a Diameter server, and optionally a SAML 204 Assertion service. 206 This document uses the term Network Access Identifier (NAI), as 207 defined in [RFC4282]. 209 One of the problems people will find with reading this document is 210 that the terminology sometimes appears to be inconsistent. This is 211 due the fact that the terms used by the different standards we are 212 picking up don't use the same terms. In general the document uses 213 either a consistent term or the term associated with the standard 214 under discussion as appropriate. For reference we include this table 215 which maps the different terms into a single table. 217 +----------+------------+-------------------+-----------------------+ 218 | Protocol | Subject | Relying Party | Identity Provider | 219 +----------+------------+-------------------+-----------------------+ 220 | ABFAB | Subject | Relying Party | Identity Provider | 221 | | | (RP) | (IdP) | 222 | | | | | 223 | | Principal | | | 224 | | | | | 225 | | Client | | | 226 | | | | | 227 | SAML | Subject | Service Provider | Issuer | 228 | | | | | 229 | GSS-API | Initiator | Acceptor | | 230 | | | | | 231 | EAP | EAP client | | EAP server | 232 | | | | | 233 | | EAP peer | | | 234 | | | | | 235 | SASL | | | | 236 | | | | | 237 | AAA | | AAA Client | AAA server | 238 | | | | | 239 | RADIUS | client | NAS | RADIUS server | 240 +----------+------------+-------------------+-----------------------+ 242 Note that in some cases a cell has been left empty, in these cases 243 there is no direct name that represents this concept. 245 Note to reviewers - I have most likely missed some entries in the 246 table. Please provide me with both correct names from the protocol 247 and missing names that are used in the text below. 249 1.2. An Overview of Federation 251 In the previous section we introduced the following actors: 253 o the Subject, 255 o the Identity Provider, and 257 o the Relying Party. 259 These entities and their relationships are illustrated graphically in 260 Figure 1. 262 ,----------\ ,---------\ 263 | Identity | Federation | Relying | 264 | Provider + <-------------------> + Party | 265 `----------' '---------' 266 < 267 \ 268 \ Authentication 269 \ 270 \ 271 \ 272 \ 273 \ +---------+ 274 \ | | O 275 v| Client | \|/ Principal 276 | | | 277 +---------+ / \ 279 Figure 1: Entities and their Relationships 281 A federation agreement typically encompasses operational 282 specifications and legal rules: 284 Operational Specifications: 286 These includes the technical specifications (e.g. protocols used 287 to communicate between the three parties), process standards, 288 policies, identity proofing, credential and authentication 289 algorithm requirements, performance requirements, assessment and 290 audit criteria, etc. The goal of operational specifications is to 291 provide enough definition that the system works and 292 interoperability is possible. 294 Legal Rules: 296 The legal rules takes the legal framework into consideration and 297 provides contractual obligations for each entity, defines the 298 responsibilities and provides further clarification of the 299 operational specifications. These legal rules regulate the 300 operational specifications, make operational specifications 301 legally binding to the participants, define and govern the rights 302 and responsibilities of the participants. The legal rules may, 303 for example, describe liability for losses, termination rights, 304 enforcement mechanisms, measures of damage, dispute resolution, 305 warranties, etc. 307 The nature of federation dictates that there is some form of 308 relationship between the identity provider and the relying party. 309 This is particularly important when the relying party wants to use 310 information obtained from the identity provider for access management 311 decisions and when the identity provider does not want to release 312 information to every relying party (or only under certain 313 conditions). 315 While it is possible to have a bilateral agreement between every IdP 316 and every RP; on an Internet scale this setup requires the 317 introduction of the multi-lateral federation concept, as the 318 management of such pair-wise relationships would otherwise prove 319 burdensome. 321 While many of the non-technical aspects of federation, such as 322 business practices and legal arrangements, are outside the scope of 323 the IETF, they still impact the architectural setup on how to ensure 324 the dynamic establishment of trust. 326 Some deployments demand the deployment of sophisticated technical 327 infrastructure, including message routing intermediaries, to offer 328 the required technical functionality. In other deployments fewer 329 technical components are needed. 331 Figure 1 also shows the relationship between the IdP and the Subject. 332 Often a real world entity is associated with the Subject; for 333 example, a person or some software. 335 The IdP will typically have a long-term relationship with the 336 Subject. This relationship would typically involve the IdP 337 positively identifying and credentialing the Subject (for example, at 338 time of enrollment in the context of employment within an 339 organisation). The relationship will often be instantiated within an 340 agreement between the IdP and the Subject (for example, within an 341 employment contract or terms of use that stipulates the appropriate 342 use of credentials and so forth). 344 While federation is often discussed within the context of formal 345 relationships, such as between an enterprise and an employee or a 346 government and a citizen, federation does not in require any 347 particular level of formality. For an IdP and a subject, it is 348 entirely compatible with a relationship between the IdP and Subject 349 that is only Requiems completing a web form and confirming the 350 verification email. For an IdP and an RP, it is entirely compatible 351 with the IdP publishing a usage point and the RP using that data. 353 However, the nature and quality of the relationship between the 354 Subject and the IdP is an important contributor to the level of trust 355 that an RP may attribute to an assertion describing a Subject made by 356 an IdP. This is sometimes described as the Level of Assurance. 358 Federation does not imposes requirement of an a priori relationship 359 or a long-term relationship between the RP and the Subject. This is 360 a property of federation that yields many of its benefits. However, 361 federation does not preclude the possibility of a pre-existing 362 relationship existing between the RP and the Subject, nor that they 363 may use the introduction to create a new long-term relationship 364 independent of the federation. 366 Finally, it is important to reiterate that in some scenarios there 367 might indeed be a human behind the device denoted as Client and in 368 other cases there is no human involved in the actual protocol 369 execution. 371 1.3. Challenges to Contemporary Federation 373 As the number of federated services has proliferated, the role of the 374 individual can become ambiguous in certain circumstances. For 375 example, a school might provide online access for a student's grades 376 to their parents for review, and to the student's teacher for 377 modification. A teacher who is also a parent must clearly 378 distinguish her role upon access. 380 Similarly, as the number of federations proliferates, it becomes 381 increasingly difficult to discover which identity provider(s) a user 382 is associated with. This is true for both the web and non-web case, 383 but is particularly acute for the latter as many non-web 384 authentication systems are not semantically rich enough on their own 385 to allow for such ambiguities. For instance, in the case of an email 386 provider, the use of SMTP and IMAP protocols does not on its own 387 provide for a way to select a federation. However, the building 388 blocks do exist to add this functionality. 390 1.4. An Overview of ABFAB-based Federation 392 The previous section described the general model of federation, and 393 its the application of federated access management. This section 394 provides a brief overview of ABFAB in the context of this model. 396 The steps taken in an ABFAB federated authentication/authorization 397 exchange are as follows: 399 1. Principal provides an NAI to Application: The client application 400 is configured with an NAI. The provided name contains, at a 401 minimum, the realm of an NAI. The realm represents the IdP to 402 be discovered. 404 2. Authentication mechanism selection: The GSS-EAP SASL/GS2 405 mechanism is selected for authentication/authorization. 407 3. Client Application provides the NAI to RP: The client 408 application setups a transport to the RP and begins the GSS-EAP 409 authentication. The RP initiates the EAP protocol to the client 410 application, and the client provides the NAI to the RP in the 411 form of the EAP response. 413 4. Discovery of federated IdP: The RP uses pre-configured 414 information or a federation proxy to determine what IdP to use 415 based on policy and the provided NAI. This is discussed in 416 detail below (Section 2.1.2). 418 5. Request from Relying Party to IdP: Once the RP knows who the IdP 419 is, it (or its agent) will send a RADIUS/Diameter request to the 420 IdP. The RADIUS/Diameter access request encapsulates the EAP 421 response. At this stage, the RP will likely have no idea who 422 the client is. The RP claims its identity to the IdP in AAA 423 attributes, and it may contain a SAML Attribute Requests in a 424 AAA attribute. 426 6. IdP informs the client of which EAP method to use: The available 427 and appropriate methods are discussed below in this 428 memo.[anchor4] 430 7. The EAP protocol is run: A bunch of EAP messages are passed 431 between the EAP peer and the EAP server, i.e., the client and 432 the IdP in our identity management terminology, until the result 433 of the authentication protocol is determined. The number and 434 content of those messages will depend on the EAP method. If the 435 IdP is unable to authenticate the client, the process concludes 436 here. As part of the EAP protocol, the client will create a 437 channel bindings message to the IdP identifying, among other 438 things, the RP to which it is attempting to authenticate. The 439 IdP checks the channel binding data from the client with that 440 provided by the RP via the AAA protocol. If the bindings do not 441 match the IdP fails the EAP protocol. 443 8. Successful Authentication: The IdP (its EAP server) and EAP peer 444 / subject have mutually authenticated each other. As a result 445 of this step, the subject and the IdP hold two cryptographic 446 keys- a Master Session Key (MSK), and an Extended MSK (EMSK). 447 There is some confidence that the RP is the one the client is 448 communicating with as the channel binding data validated. This 449 allows for a claim of authentication for the RP to the client. 451 9. Local IdP Policy Check: At this stage, the IdP checks local 452 policy to determine whether the RP and subject are authorized 453 for a given transaction/service, and if so, what if any, 454 attributes will be released to the RP. The RP will have done 455 its policy checks during the discovery process. 457 10. Response from the IdP to the Relying Party: Once the IdP has 458 made a determination of whether and how to authenticate and 459 authorize the client to the RP, it returns either a negative AAA 460 result to the RP, or it returns a positive result to the RP, 461 along with an optional set of AAA attributes associated with the 462 client (usually as one or more SAML assertions). In addition, 463 an EAP MSK is returned to the RP. 465 11. RP Processes Results: When the RP receives the result from the 466 IdP, it should have enough information to either grant or refuse 467 a resource access request. It may have information that 468 associates the client with specific authorization identities. 469 If additional attributes are needed from the IdP the RP may make 470 a new SAML Request to the IdP. It will apply these results in 471 an application-specific way. 473 12. RP returns results to client: Once the RP has a response it must 474 inform the client application of the result. If all has gone 475 well, all are authenticated, and the application proceeds with 476 appropriate authorization levels. 478 An example communication flow is given below: 480 Relying Client Identity 481 Party App Provider 483 | (1) | Client App gets NAI (somehow) 484 | | | 485 |<-----(2)----->| | Mechanism Selection 486 | | | 487 |<-----(3)-----<| | NAI transmitted to RP 488 | | | 489 |<=====(4)====================>| Discovery 490 | | | 491 |>=====(5)====================>| Access request from RP to IdP 492 | | | 493 | |< - - (6) - -<| EAP method to Client 494 | | | 495 | |< - - (7) - ->| EAP Exchange to authenticate 496 | | | Client 497 | | | 498 | | (8 & 9) Local Policy Check 499 | | | 500 |<====(10)====================<| IdP Assertion to RP 501 | | | 502 (11) | | RP processes results 503 | | | 504 |>----(12)----->| | Results to client app. 506 ----- = Between Client App and RP 507 ===== = Between RP and IdP 508 - - - = Between Client App and IdP 510 1.5. Design Goals 512 Our key design goals are as follows: 514 o Each party of a transaction will be authenticated, and the client 515 will be authorized for access to a specific resource. 517 o Means of authentication is decoupled so as to allow for multiple 518 authentication methods. 520 o Hence, the architecture requires no sharing of long term private 521 keys. 523 o The system will scale to large numbers of identity providers, 524 relying parties, and users. 526 o The system will be designed primarily for non-Web-based 527 authentication. 529 o The system will build upon existing standards, components, and 530 operational practices. 532 Designing new three party authentication and authorization protocols 533 is hard and fraught with risk of cryptographic flaws. Achieving 534 widespead deployment is even more difficult. A lot of attention on 535 federated access has been devoted to the Web. This document instead 536 focuses on a non-Web-based environment and focuses on those protocols 537 where HTTP is not used. Despite the increased excitement for 538 layering every protocol on top of HTTP there are still a number of 539 protocols available that do not use HTTP-based transports. Many of 540 these protocols are lacking a native authentication and authorization 541 framework of the style shown in Figure 1. 543 1.6. Use of AAA 545 Interestingly, for network access authentication the usage of the AAA 546 framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite 547 successful from a deployment point of view. To map the terminology 548 used in Figure 1 to the AAA framework the IdP corresponds to the AAA 549 server, the RP corresponds to the AAA client, and the technical 550 building blocks of a federation are AAA proxies, relays and redirect 551 agents (particularly if they are operated by third parties, such as 552 AAA brokers and clearing houses). The front-end, i.e. the end host 553 to AAA client communication, is in case of network access 554 authentication offered by link layer protocols that forward 555 authentication protocol exchanges back-and-forth. An example of a 556 large scale RADIUS-based federation is EDUROAM [2]. 558 By using the AAA framework, ABFAB gets a lot of mileage as many of 559 the federation agreements already exist and merely need to be 560 expanded to cover the ABFAB additions. The AAA framework has already 561 addressed some of the problems outlined above. For example, 563 o It already needs a method of doing routing of requests based on a 564 domain. 566 o It already has an extensible architecture allowing for new 567 attributes to be defined and transported. 569 o Pre-existing relationships can be re-used. 571 1.7. Use of GSS-API 573 Expand here 575 2. Architecture 577 We have already introduced the federated access architecture, with 578 the illustration of the different actors that need to interact, but 579 did not expand on the specifics of providing support for non-Web 580 based applications. This section details this aspect and motivates 581 design decisions. The main theme of the work described in this 582 document is focused on re-using existing building blocks that have 583 been deployed already and to re-arrange them in a novel way. 585 Although this architecture assumes updates to the relying party, the 586 client application and the Identity Provider, those changes are kept 587 at a minimum. A mechanism that can demonstrate deployment benefits 588 (based on ease of update of existing software, low implementation 589 effort, etc.) is preferred and there may be a need to specify 590 multiple mechanisms to support the range of different deployment 591 scenarios. 593 There are a number of ways for encapsulating EAP into an application 594 protocol. For ease of integration with a wide range of non-Web based 595 application protocols the usage of the GSS-API was chosen. 596 Encapsulating EAP into the GSS-API also allows EAP to be used in 597 SASL. A description of the technical specification can be found in 598 [I-D.ietf-abfab-gss-eap]. Other alternatives exist as well and may 599 be considered later, such as "TLS using EAP Authentication" 600 [I-D.nir-tls-eap].[anchor9] 602 The architecture consists of several building blocks, which is shown 603 graphically in Figure 2. In the following sections, we discuss the 604 data flow between each of the entities, the protocols used for that 605 data flow and some of the trade-offs made in choosing the protocols. 607 +--------------+ 608 | Identity | 609 | Provider | 610 | (IdP) | 611 +-^----------^-+ 612 * EAP o RADIUS/ 613 * o Diameter 614 --v----------v-- 615 /// \\\ 616 // \\ 617 | Federation | 618 | Substrate | 619 \\ // 620 \\\ /// 621 --^----------^-- 622 * EAP o RADIUS/ 623 * o Diameter 624 +-------------+ +-v----------v--+ 625 | |<---------------->| | 626 | Client | EAP/EAP Method | Relying Party | 627 | Application |<****************>| (RP) | 628 | | GSS-API | | 629 | |<---------------->| | 630 | | Application | | 631 | | Protocol | | 632 | |<================>| | 633 +-------------+ +---------------+ 635 Legend: 637 <****>: Client-to-IdP Exchange 638 <---->: Client-to-RP Exchange 639 : RP-to-IdP Exchange 640 <====>: Protocol through which GSS-API/GS2 exchanges are tunnelled 642 Figure 2: ABFAB Protocol Instantiation 644 2.1. Relying Party to Identity Provider 646 Communications between the Relying Part and the Identity Provider is 647 done by the federation substrate. This communication channel is 648 responsible for: 650 o Establishing the trust relationship between the RP and the IdP. 652 o Determining the Rules governing the relationship. 654 o Conveying packets between the RP and IdP. 656 o Providing the means of establishing a trust relationship between 657 the RP and the client. 659 The ABFAB working group has chosen the AAA framework for the messages 660 transported between the RP and IdP. This allows for the standard AAA 661 framework to be used to establish the trust relationship between the 662 RP and the IdP while allowing other newer routing mechanisms using 663 the same message format to be used in the future. The ABFAB protocol 664 itself details the method of establishing the trust relationship 665 between the RP and the client. 667 2.1.1. AAA, RADIUS and Diameter 669 The IETF has defined a federation framework already with the 670 Authentication, Authorization and Accounting (AAA) framework 671 [RFC2903], [RFC2904]. Two implementations of the AAA framework exist 672 in RADIUS [RFC2138] and Diameter [RFC3588] protocols. The existence 673 of these protocols allows us to re-use a pair of existing protocols 674 that have been widely deployed and are reasonable well understood. 675 These protocols are nicely designed so that they can carry additional 676 attributes with minimal changes to either the protocol or existing 677 AAA servers. 679 The astute reader will notice that RADIUS and Diameter have 680 substantially similar characteristics. Why not pick one? A key 681 difference is that today RADIUS is largely transported upon UDP, and 682 its use is largely, though not exclusively, intra-domain. Diameter 683 itself was designed to scale to broader uses. We leave as a 684 deployment decision, which protocol will be appropriate. The 685 protocol defines all the necessary new AAA attributes as RADIUS 686 attributes, this allows for the same structures and attributes to be 687 used in both RADIUS and Diameter. We also note that there exist 688 proxies which convert from RADIUS to Diameter and back. This makes 689 it possible for both to be deployed in a single federation substrate. 691 Through the integrity protection mechanisms in the AAA framework, the 692 identity provider can establish technical trust that messages are 693 being sent by the appropriate relying party. Any given interaction 694 will be associated with one federation at the policy level. The 695 legal or business relationship defines what statements the identity 696 provider is trusted to make and how these statements are interpreted 697 by the relying party. The AAA framework also permits the relying 698 party or elements between the relying party and identity provider to 699 make statements about the relying party. 701 The AAA framework provides transport for attributes. Statements made 702 about the subject by the identity provider, statements made about the 703 relying party and other information are transported as attributes. 705 One demand that the AAA substrate makes of the upper layers is that 706 they must properly identify the end points of the communication. It 707 must be possible for the AAA client at the RP to determine where to 708 send each RADIUS or Diameter message. Without this requirement, it 709 would be the RP's responsibility to determine the identity of the 710 client on its own, without the assistance of an IdP. This 711 architecture makes use of the Network Access Identifier (NAI), where 712 the IdP is indicated by the realm component [RFC4282]. The NAI is 713 represented and consumed by the GSS-API layer as GSS_C_NT_USER_NAME 714 as specified in [RFC2743]. The GSS-API EAP mechanism includes the 715 NAI in the EAP Response/Identity message. 717 2.1.2. Discovery and Rules Determination 719 While we are using the AAA protocols to communicate with the IdP, the 720 RP may have multiple federation substrates to select from. The RP 721 has a number of criteria that it will use in selecting which of the 722 different federations to use: 724 o The federation selected must be able to communicate with the IdP. 726 o The federation selected must match the business rules and 727 technical policies required for the RP security requirements. 729 The RP needs to discover which federation will be used to contact the 730 IdP. The first selection criteria in discovery is going to be the 731 name of the IdP to be contacted. The second selection criteria in 732 discovery is going to be the set of business rules and technical 733 policies governing the relationship; this is called rules 734 determination. The RP also needs to establish technical trust in the 735 communications with the IdP. 737 Rules determination covers a broad range of decisions about the 738 exchange. One of these is whether the given RP is permitted to talk 739 to the IdP using a given federation at all, so rules determination 740 encompasses the basic authorization decision. Other factors are 741 included, such as what policies govern release of information about 742 the principal to the RP and what policies govern the RP's use of this 743 information. While rules determination is ultimately a business 744 function, it has significant impact on the technical exchanges. The 745 protocols need to communicate the result of authorization. When 746 multiple sets of rules are possible, the protocol must disambiguate 747 which set of rules are in play. Some rules have technical 748 enforcement mechanisms; for example in some federations intermediates 749 validate information that is being communicated within the 750 federation. 752 ABFAB has not formally defined any part of discovery at this point. 753 The process of specifying and evaluating the business rules and 754 technical policies is too complex to provide a simple framework. 755 There is not currently a way to know if a AAA proxy is able to 756 communicate with a specific IdP, although this may change with some 757 of the routing protocols that are being considered. At the present 758 time, the discovery process is going to be a manual configuration 759 process. 761 2.1.3. Routing and Technical Trust 763 Several approaches to having messages routed through the federation 764 substrate are possible. These routing methods can most easily be 765 classified based on the mechanism for technical trust that is used. 766 The choice of technical trust mechanism constrains how rules 767 determination is implemented. Regardless of what deployment strategy 768 is chosen, it is important that the technical trust mechanism 769 constrain the names of both parties to the exchange. The trust 770 mechanism ought to ensure that the entity acting as IdP for a given 771 NAI is permitted to be the IdP for that realm, and that any service 772 name claimed by the RP is permitted to be claimed by that entity. 773 Here are the categories of technical trust determination: 775 AAA Proxy: 776 The simplest model is that an RP supports a request directly to an 777 AAA proxy. The hop-by-hop integrity protection of the AAA fabric 778 provides technical trust. An RP can submit a request directly to 779 a federation. Alternatively, a federation disambiguation fabric 780 can be used. Such a fabric takes information about what 781 federations the RP is part of and what federations the IdP is part 782 of and routes a message to the appropriate federation. The 783 routing of messages across the fabric plus attributes added to 784 requests and responses provides rules determination. For example, 785 when a disambiguation fabric routes a message to a given 786 federation, that federation's rules are chosen. Naming is 787 enforced as messages travel across the fabric. The entities near 788 the RP confirm its identity and validate names it claims. The 789 fabric routes the message towards the appropriate IdP, validating 790 the IdP's name in the process. The routing can be statically 791 configured. Alternatively a routing protocol could be developed 792 to exchange reachability information about given IdPs and to apply 793 policy across the AAA fabric. Such a routing protocol could flood 794 naming constraints to the appropriate points in the fabric. 796 Trust Broker: 797 Instead of routing messages through AAA proxies, some trust broker 798 could establish keys between entities near the RP and entities 799 near the IdP. The advantage of this approach is efficiency of 800 message handling. Fewer entities are needed to be involved for 801 each message. Security may be improved by sending individual 802 messages over fewer hops. Rules determination involves decisions 803 made by trust brokers about what keys to grant. Also, associated 804 with each credential is context about rules and about other 805 aspects of technical trust including names that may be claimed. A 806 routing protocol similar to the one for AAA proxies is likely to 807 be useful to trust brokers in flooding rules and naming 808 constraints. 810 Global Credential: 811 A global credential such as a public key and certificate in a 812 public key infrastructure can be used to establish technical 813 trust. A directory or distributed database such as the Domain 814 Name System is used by the RP to discover the endpoint to contact 815 for a given NAI. Either the database or certificates can provide 816 a place to store information about rules determination and naming 817 constraints. Provided that no intermediates are required (or 818 appear to be required) and that the RP and IdP are sufficient to 819 enforce and determine rules, rules determination is reasonably 820 simple. However applying certain rules is likely to be quite 821 complex. For example if multiple sets of rules are possible 822 between an IdP and RP, confirming the correct set is used may be 823 difficult. This is particularly true if intermediates are 824 involved in making the decision. Also, to the extent that 825 directory information needs to be trusted, rules determination may 826 be more complex. 828 Real-world deployments are likely to be mixtures of these basic 829 approaches. For example, it will be quite common for an RP to route 830 traffic to a AAA proxy within an organization. That proxy could then 831 use any of the three methods to get closer to the IdP. It is also 832 likely that rather than being directly reachable, the IdP may have a 833 proxy on the edge of its organization. Federations will likely 834 provide a traditional AAA proxy interface even if they also provide 835 another mechanism for increased efficiency or security. 837 2.1.4. SAML Assertions 839 For the traditional use of AAA frameworks, network access, the only 840 requirement that was necessary to grant access was an affirmative 841 response from the IdP. In the ABFAB world, the RP may need to get 842 additional information about the client before granting access. 843 ABFAB therefore has a requirement that it can transport an arbitrary 844 set of attributes about the client from the IdP to the RP. 846 Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os] 847 was designed in order to carry an extensible set of attributes about 848 a subject. Since SAML is extensible in the attribute space, ABFAB 849 has no immediate needs to update the core SAML specifications for our 850 work. It will be necessary to update IdPs that need to return SAML 851 assertions to IdPs and for both the IdP and the RP to implement a new 852 SAML profile designed to carry SAML assertions in AAA. The new 853 profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. 855 There are two issues that need to be highlighted: 857 o The security of SAML Assertions. 859 o Namespaces and mapping of SAML attributes. 861 SAML Assertions have an optional signature that can be used to 862 protect and provide origination of the assertion. These signatures 863 are normally based on asymmetric key operations and require that the 864 verifier be able to check not only the cryptographic operation, but 865 also the binding of the originators name and the public key. In a 866 federated environment it will not always be possible for the RP to 867 validate the binding, for this reason the technical trust established 868 in the federation is used as an alternate method of validating the 869 origination and integrity of the SAML Assertion. 871 Attributes placed in SAML Assertions can have different namespaces 872 assigned to the same name. In many, but not all, cases a the 873 federation agreements will determine what attributes can be used in a 874 SAML statement. This means that the RP needs to map from the 875 federation names, types and semantics into the onces that the 876 policies of the RP are written in. In other cases the federation 877 substrate may modify the SAML Assertions in transit to do the 878 necessary namespace, naming and semantic mappings as the assertion 879 crosses the different boundaries in the federation. If the proxies 880 are modifying the SAML Assertion, then will obviously remove any 881 signatures on the SAML Assertions as they would no longer validate. 882 In this case the technical trust is the required mechanism for 883 validating the integrity of the assertion. In the last case, the 884 attributes may still be in the namespace of the originating IdP. 885 When this occurs the RP will need to get the required mapping 886 operations from the federation agreements and do the appropriate 887 mappings itself. 889 2.2. Client To Identity Provider 891 Looking at the communications between the client and the IdP, the 892 following items need to be dealt with: 894 o The client and the IdP need to mutually authenticate each other. 896 o The client and the IdP need to mutually agree on the identity of 897 the RP. 899 ABFAB selected EAP for the purposes of mutual authentication and 900 assisted in creating some new EAP channel binding documents for 901 dealing with determining the identity of the RP. ABFAB has defined 902 and specified a new channel binding mechanism that operates as an EAP 903 method for the purpose of agreeing on the identity of the RP. 905 2.2.1. Extensible Authentication Protocol (EAP) 907 Traditional web federation does not describe how a subject interacts 908 with an identity provider for authentication. As a result, this 909 communication is not standardized. There are several disadvantages 910 to this approach. It is difficult to have subjects that are machines 911 rather than humans that use some sort of programatic credential. In 912 addition, use of browsers for authentication restricts the deployment 913 of more secure forms of authentication beyond plaintext username and 914 password known by the server. In a number of cases the 915 authentication interface may be presented before the subject has 916 adequately validated they are talking to the intended server. By 917 giving control of the authentication interface to a potential 918 attacker, then the security of the system may be reduced and phishing 919 opportunities introduced. 921 As a result, it is desirable to choose some standardized approach for 922 communication between the subject's end-host and the identity 923 provider. There are a number of requirements this approach must 924 meet. 926 Experience has taught us one key security and scalability 927 requirement: it is important that the relying party not get 928 possession of the long-term secret of the client. Aside from a 929 valuable secret being exposed, a synchronization problem can develop 930 when the client changes keys with the IdP. 932 Since there is no single authentication mechanism that will be used 933 everywhere there is another associated requirement: The 934 authentication framework must allow for the flexible integration of 935 authentication mechanisms. For instance, some IdPs require hardware 936 tokens while others use passwords. A service provider wants to 937 provide support for both authentication methods, and other methods 938 from IdPs not yet seen. 940 Fortunately, these requirements can be met by utilizing standardized 941 and successfully deployed technology, namely by the Extensible 942 Authentication Protocol (EAP) framework [RFC3748]. Figure 2 943 illustrates the integration graphically. 945 EAP is an end-to-end framework; it provides for two-way communication 946 between a peer (i.e,service client or principal) through the 947 authenticator (i.e., service provider) to the back-end (i.e., 948 identity provider). Conveniently, this is precisely the 949 communication path that is needed for federated identity. Although 950 EAP support is already integrated in AAA systems (see [RFC3579] and 951 [RFC4072]) several challenges remain: 953 o The first is how to carry EAP payloads from the end host to the 954 relying party. 956 o Another is to verify statements the relying party has made to the 957 subject, confirm these statements are consistent with statements 958 made to the identity provider and confirm all the above are 959 consistent with the federation and any federation-specific policy 960 or configuration. 962 o Another challenge is choosing which identity provider to use for 963 which service. 965 2.2.2. Channel Binding 967 The client knows, in theory, the name of the RP that it attempted to 968 connect to, however in the event that an attacker has intercepted the 969 protocol, the client and the IdP need to be able to detect this 970 situation. A general overview of the problem can be found in 971 [I-D.hartman-emu-mutual-crypto-bind]. 973 The recommended way to deal with channel binding can be found in RFC 974 XXXX [I-D.ietf-emu-chbind]. 976 2.3. Client to Relying Party 978 The final set of interactions between parties to consider are those 979 between the client and the RP. In some ways this is the most complex 980 set since at least part of it is outside the scope of the ABFAB work. 981 The interactions between these parties include: 983 o Running the protocol that implements the web service that is 984 provided by the RP and desired by the client. 986 o Authenticating the client to the RP and the RP to the client. 988 o Providing the necessary security services to the web service 989 protocol that it needs beyond authentication. 991 2.3.1. GSS-API 993 One of the remaining layers is responsible for integration of 994 federated authentication into the application. There are a number of 995 approaches that applications have adopted for security. So, there 996 may need to be multiple strategies for integration of federated 997 authentication into applications. However, we have started with a 998 strategy that provides integration to a large number of application 999 protocols. 1001 Many applications such as SSH [RFC4462], NFS [RFC2203], DNS [RFC3645] 1002 and several non-IETF applications support the Generic Security 1003 Services Application Programming Interface [RFC2743]. Many 1004 applications such as IMAP, SMTP, XMPP and LDAP support the Simple 1005 Authentication and Security Layer (SASL) [RFC4422] framework. These 1006 two approaches work together nicely: by creating a GSS-API mechanism, 1007 SASL integration is also addressed. In effect, using a GSS-API 1008 mechanism with SASL simply requires placing some headers on the front 1009 of the mechanism and constraining certain GSS-API options. 1011 GSS-API is specified in terms of an abstract set of operations which 1012 can be mapped into a programming language to form an API. When 1013 people are first introduced to GSS-API, they focus on it as an API. 1014 However, from the prospective of authentication for non-web 1015 applications, GSS-API should be thought of as a protocol not an API. 1016 It consists of some abstract operations such as the initial context 1017 exchange, which includes two sub-operations (gss_init_sec_context and 1018 gss_accept_sec_context). An application defines which abstract 1019 operations it is going to use and where messages produced by these 1020 operations fit into the application architecture. A GSS-API 1021 mechanism will define what actual protocol messages result from that 1022 abstract message for a given abstract operation. So, since this work 1023 is focusing on a particular GSS-API mechanism, we generally focus on 1024 protocol elements rather than the API view of GSS-API. 1026 The API view has significant value. Since the abstract operations 1027 are well defined, the set of information that a mechanism gets from 1028 the application is well defined. Also, the set of assumptions the 1029 application is permitted to make is generally well defined. As a 1030 result, an application protocol that supports GSS-API or SASL is very 1031 likely to be usable with a new approach to authentication including 1032 this one with no required modifications. In some cases, support for 1033 a new authentication mechanism has been added using plugin interfaces 1034 to applications without the application being modified at all. Even 1035 when modifications are required, they can often be limited to 1036 supporting a new naming and authorization model. For example, this 1037 work focuses on privacy; an application that assumes it will always 1038 obtain an identifier for the principal will need to be modified to 1039 support anonymity, unlinkability or pseudonymity. 1041 So, we use GSS-API and SASL because a number of the application 1042 protocols we wish to federate support these strategies for security 1043 integration. What does this mean from a protocol standpoint and how 1044 does this relate to other layers? This means we need to design a 1045 concrete GSS-API mechanism. We have chosen to use a GSS-API 1046 mechanism that encapsulates EAP authentication. So, GSS-API (and 1047 SASL) encapsulate EAP between the end-host and the service. The AAA 1048 framework encapsulates EAP between the relying party and the identity 1049 provider. The GSS-API mechanism includes rules about how principals 1050 and services are named as well as per-message security and other 1051 facilities required by the applications we wish to support. 1053 2.3.2. Protocol Transport 1055 The transport of data between the client and the relying party is not 1056 provided by GSS-API. GSS-API creates and consumes messages, but it 1057 does not provide the transport itself, instead the protocol using 1058 GSS-API needs to provide the transport. In many cases HTTP or HTTPS 1059 is used for this transport, but other transports are perfectly 1060 acceptable. The core GSS-API document [RFC2743] provides some 1061 details on what requirements exist. 1063 In addition we highlight the following: 1065 o The transport does not need to provide either privacy or 1066 integrity. After GSS-EAP has finished negotiation, GSS-API can be 1067 used to provide both services. If the negotiation process itself 1068 needs protection from eavesdroppers then the transport would need 1069 to provide the necessary services. 1071 o The transport needs to provide reliable transport of the messages. 1073 o The transport needs to ensure that tokens are delivered in order 1074 during the negotiation process. 1076 o GSS-API messages need to be delivered atomically. If the 1077 transport breaks up a message it must also reassemble the message 1078 before delivery. 1080 3. Application Security Services 1082 One of the key goals is to integrate federated authentication into 1083 existing application protocols and where possible, existing 1084 implementations of these protocols. Another goal is to perform this 1085 integration while meeting the best security practices of the 1086 technologies used to perform the integration. This section describes 1087 security services and properties required by the EAP GSS-API 1088 mechanism in order to meet these goals. This information could be 1089 viewed as specific to that mechanism. However, other future 1090 application integration strategies are very likely to need similar 1091 services. So, it is likely that these services will be expanded 1092 across application integration strategies if new application 1093 integration strategies are adopted. 1095 3.1. Authentication 1097 GSS-API provides an optional security service called mutual 1098 authentication. This service means that in addition to the initiator 1099 providing (potentially anonymous or pseudonymous) identity to the 1100 acceptor, the acceptor confirms its identity to the initiator. 1101 Especially for the ABFAB context, this service is confusingly named. 1102 We still say that mutual authentication is provided when the identity 1103 of an acceptor is strongly authenticated to an anonymous initiator. 1105 RFC 2743, unfortunately, does not explicitly talk about what mutual 1106 authentication means. Within this document we therefore define it 1107 as: 1109 o If a target name is supplied by the initiator, then the initiator 1110 trusts that the supplied target name describes the acceptor. This 1111 implies both that appropriate cryptographic exchanges took place 1112 for the initiator to make such a trust decision, and that after 1113 evaluating the results of these exchanges, the initiator's policy 1114 trusts that the target name is accurate. 1116 o If no target name is supplied by the initiator, then the initiator 1117 trusts that its idea of the acceptor name correctly names the 1118 entity it is communicating with. 1120 o Both the initiator and acceptor have the same key material for 1121 per-message keys and both parties have confirmed they actually 1122 have the key material. In EAP terms, there is a protected 1123 indication of success. 1125 Mutual authentication is an important defense against certain aspects 1126 of phishing. Intuitively, users would like to assume that if some 1127 party asks for their credentials as part of authentication, 1128 successfully gaining access to the resource means that they are 1129 talking to the expected party. Without mutual authentication, the 1130 acceptor could "grant access" regardless of what credentials are 1131 supplied. Mutual authentication better matches this user intuition. 1133 It is important, therefore, that the GSS-EAP mechanism implement 1134 mutual authentication. That is, an initiator needs to be able to 1135 request mutual authentication. When mutual authentication is 1136 requested, only EAP methods capabale of providing the necessary 1137 service can be used, and appropriate steps need to be taken to 1138 provide mutual authentication. A broader set of EAP methods could be 1139 supported when a particular application does not request mutual 1140 authentication. It is an open question whether the mechanism will 1141 permit this. 1143 The AAA infrastructure MAY hide the peer's identity from the GSS-API 1144 acceptor, providing anonymity between the peer and initiator. At 1145 this time, whether the identity is disclosed is determined by EAP 1146 server policy rather than by an indication from the peer. Also, 1147 peers are unlikely to be able to determine whether anonymous 1148 communication will be provided. For this reason, peers are unlikely 1149 to set the anonymous return flag from GSS_Init_Sec_context. 1151 3.2. GSS-API Channel Binding 1153 [RFC5056] defines a concept of channel binding to prevent man-in-the- 1154 middle attacks. It is common to provide SASL and GSS-API with 1155 another layer to provide transport security; Transport Layer Security 1156 (TLS) is the most common such layer. TLS provides its own server 1157 authentication. However there are a variety of situations where this 1158 authentication is not checked for policy or usability reasons. Even 1159 when it is checked, if the trust infrastructure behind the TLS 1160 authentication is different from the trust infrastructure behind the 1161 GSS-API mutual authentication then confirming the end-points using 1162 both trust infrastructures is likely to enhance security. If the 1163 endpoints of the GSS-API authentication are different than the 1164 endpoints of the lower layer, this is a strong indication of a 1165 problem such as a man-in-the-middle attack. Channel binding provides 1166 a facility to determine whether these endpoints are the same. 1168 The GSS-EAP mechanism needs to support channel binding. When an 1169 application provides channel binding data, the mechanism needs to 1170 confirm this is the same on both sides consistent with the GSS-API 1171 specification. XXXThere is an open question here as to the details; 1172 today RFC 5554 governs. We could use that and the current draft 1173 assumes we will. However in Beijing we became aware of some changes 1174 to these details that would make life much better for GSS 1175 authentication of HTTP. We should resolve this with kitten and 1176 replace this note with a reference to the spec we're actually 1177 following. 1179 Typically when considering channel binding, people think of channel 1180 binding in combination with mutual authentication. This is 1181 sufficiently common that without additional qualification channel 1182 binding should be assumed to imply mutual authentication. Without 1183 mutual authentication, only one party knows that the endpoints are 1184 correct. That's sometimes useful. Consider for example a user who 1185 wishes to access a protected resource from a shared whiteboard in a 1186 conference room. The whiteboard is the initiator; it does not need 1187 to actually authenticate that it is talking to the correct resource 1188 because the user will be able to recognize whether the displayed 1189 content is correct. If channel binding were used without mutual 1190 authentication, it would in effect be a request to only disclose the 1191 resource in the context of a particular channel. Such an 1192 authentication would be similar in concept to a holder-of-key SAML 1193 assertion. However, also note that while it is not happening in the 1194 protocol, mutual authentication is happening in the overall system: 1195 the user is able to visually authenticate the content. This is 1196 consistent with all uses of channel binding without protocol level 1197 mutual authentication found so far. 1199 RFC 5056 channel binding (also called GSS-API channel binding when 1200 GSS-API is involved) is not the same thing as EAP channel binding. 1201 EAP channel binding is also used in the ABFAB context in order to 1202 implement acceptor naming and mutual authentication. Details are 1203 discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. 1205 3.3. Host-Based Service Names 1207 IETF security mechanisms typically take the name of a service entered 1208 by a user and make some trust decision about whether the remote party 1209 in an interaction is the intended party. GSS-API has a relatively 1210 flexible naming architecture. However most of the IETF applications 1211 that use GSS-API, including SSH, NFS, IMAP, LDAP and XMPP, have 1212 chosen to use host-based service names when they use GSS-API. In 1213 this model, the initiator names an acceptor based on a service such 1214 as "imap" or "host" (for login services such as SSH) and a host name. 1216 Using host-based service names leads to a challenging trust 1217 delegation problem. Who is allowed to decide whether a particular 1218 hostname maps to an entity. The public-key infrastructure (PKI) used 1219 by the web has chosen to have a number of trust anchors (root 1220 certificate authorities) each of wich can map any name to a public 1221 key. A number of GSS-API mechanisms suchs as Kerberos [RFC1964] 1222 split the problem into two parts. A new concept called a realm is 1223 introduced. Then the mechanism decides what realm is responsible for 1224 a given name. That realm is responsible for deciding if the acceptor 1225 entity is allowed to claim the name. ABFAB needs to adopt this 1226 approach. 1228 Host-based service names do not work ideally when different instances 1229 of a service are running on different ports. Also, these do not work 1230 ideally when SRV record or other insecure referrals are used. 1232 The GSS-EAP mechanism needs to support host-based service names in 1233 order to work with existing IETF protocols. 1235 3.4. Per-Message Tokens 1237 GSS-API provides per-message security services that can provide 1238 confidentiality and integrity. Some IETF protocols such as NFS and 1239 SSH take advantage of these services. As a result GSS-EAP needs to 1240 support these services. As with mutual authentication, per-message 1241 services will limit the set of EAP methods that are available. Any 1242 method that produces a Master Session Key (MSK) should be able to 1243 support per-message security services. 1245 GSS-API provides a pseudo-random function. While the pseudo-random 1246 function does not involve sending data over the wire, it provides an 1247 algorithm that both the initiator and acceptor can run in order to 1248 arrive at the same key value. This is useful for designs where a 1249 successful authentication is used to key some other function. This 1250 is similar in concept to the TLS extractor. No current IETF 1251 protocols require this. However GSS-EAP supports this service 1252 because it is valuable for the future and easy to do given per- 1253 message services. Non-IETF protocols are expected to take advantage 1254 of this in the near future. 1256 4. Future Work: Attribute Providers 1258 This architecture provides for a federated authentication and 1259 authorization framework between IdPs, RPs, principals, and subjects. 1260 It does not at this time provide for a means to retrieve attributes 1261 from 3rd parties. However, it envisions such a possibility. We note 1262 that in any extension to the model, an attribute provider must be 1263 authorized to release specific attributes to a specific RP for a 1264 specific principal. In addition, we note that it is an open question 1265 beyond this architecture as to how the RP should know to trust a 1266 particular attribute provider. 1268 There are a number of possible technical means to provide attribute 1269 provider capabilities. One possible approach is for the IdP to 1270 provide a signed attribute request to RP that it in turn will provide 1271 to the attribute authority. Another approach would be for the IdP to 1272 provide a URI to the RP that contains a token of some form. The form 1273 of communications between the IdP and attribute provider as well as 1274 other considerations are left for the future. One thing we can say 1275 now is that the IdP would merely be asserting who the attribute 1276 authority is, and not the contents of what the attribute authority 1277 would return. (Otherwise, the IdP might as well make the query to 1278 the attribute authority and then resign it.) 1280 5. Privacy Considerations 1282 Sharing identity information raises privacy violations and as 1283 described throughout this document an existing architecture is re- 1284 used for a different usage environment. As such, a discussion about 1285 the privacy properties has to take these pre-conditions into 1286 consideration. We use the approach suggested in 1287 [I-D.iab-privacy-considerations] to shed light into what data is 1288 collected and used by which entity, what the relationship between 1289 these entities and the end user is, what data about the user is 1290 likely needed to be collected, and what the identification level of 1291 the data is. 1293 5.1. What Entities collect and use Data? 1295 Figure 2 shows the architecture with the involved entities. Message 1296 exchanges are exchanged between the client application, via the 1297 relying part to the AAA server. There will likely be intermediaries 1298 between the relying party and the AAA server, labeled generically as 1299 "federation". 1301 In order for the relying party to route messages to the AAA server it 1302 is necessary for the client application to provide enough information 1303 to enable the identification of the AAA server's domain. While often 1304 the username is attached to the domain (in the form of a Network 1305 Access Identity (NAI) this is not necessary for the actual protocol 1306 operation. The EAP server component within the AAA server needs to 1307 authenticate the user and therefore needs to execute the respective 1308 authentication protocol. Once the authentication exchange is 1309 complete authorization information needs to be conveyed to the 1310 relying party to grant the user the necessary application rights. 1311 Information about resource consumption may be delivered as part of 1312 the accounting exchange during the lifetime of the granted 1313 application session. 1315 The authentication exchange may reveal an identifier that can be 1316 linked to a user. Additionally, a sequence of authentication 1317 protocol exchanges may be linked together. Depending on the chosen 1318 authentication protocol information at varying degrees may be 1319 revealed to all parties along the communication path. This 1320 authorization information exchange may disclose identity information 1321 about the user. While accounting information is created by the 1322 relying party it is likely to needed by intermediaries in the 1323 federation for financial settlement purposes and will be stored for 1324 billing, fraud detection, statistical purposes, and for service 1325 improvement by the AAA server operator. 1327 5.2. Relationship between User's and other Entities 1329 The AAA server is a first-party site the user typically has a 1330 relationship with. This relationship will be created at the time 1331 when the security credentials are exchange and provisioned. The 1332 relying party and potential intermediares in the federation are 1333 typically operate under the contract of the first-party site. The 1334 user typically does not know about the intermediaries in the 1335 federation nor does he have any relationship with them. The protocol 1336 interaction triggered by the client application happens with the 1337 relying party at the time of application access. The relying party 1338 does not have a direct contractual relationship with the user but 1339 depending on the application the interaction may expose the brand of 1340 the application running by the relying party to the end user via some 1341 user interface. 1343 5.3. What Data about the User is likely Needed to be Collected? 1345 The data that is likely going to be collected as part of a protocol 1346 exchange with application access at the relying party is accounting 1347 information and authorization information. This information is 1348 likely to be kept beyond the terminated application usage for trouble 1349 shooting, statistical purposes, etc. There is also like to be 1350 additional data collected to to improve application service usage by 1351 the relying party that is not conveyed to the AAA server as part of 1352 the accounting stream. 1354 5.4. What is the Identification Level of the Data? 1356 With regard to identification there are several protocol layers that 1357 need to be considered separately. First, there is the EAP method 1358 exchange, which as an authentication and key exchange protocol has 1359 properties related to identification and protocol linkage. Second, 1360 there is identification at the EAP layer for routing of messages. 1361 Then, in the exchange between the client application and the relying 1362 party the identification depends on the underlying application layer 1363 protocol the EAP/GSS-API exchange is tunneled over. Finally, there 1364 is the backend exchange via the AAA infrastructure, which involves a 1365 range of RADIUS and Diameter extensions and yet to be defined 1366 extensions, such as encoding authorization information inside SAML 1367 assertions. 1369 Since this document does not attempt to define any of these exchanges 1370 but rather re-uses existing mechanisms the level of identification 1371 heavily depends on the selected mechanisms. The following two 1372 examples aim to illustrate the amount of existing work with respect 1373 to decrease exposure of personal data. 1375 1. When designing EAP methods a number of different requirements may 1376 need to get considered; some of them are conflicting. RFC 4017 1377 [RFC4017], for example, tried to list requirements for EAP 1378 methods utilized for network access over Wireless LANs. It also 1379 recommends the end-user identity hiding requirement, which is 1380 privacy-relevant. Some EAP methods, such as EAP-IKEv2 [RFC5106], 1381 also fulfill this requirement. 1383 2. EAP, as the layer encapsulating EAP method specific information, 1384 needs identity information to allow routing requests towards the 1385 user's home AAA server. This information is carried within the 1386 Network Access Identifier (NAI) and the username part of the NAI 1387 (as supported by RFC 4282 [RFC4282]) can be obfuscated. 1389 5.5. Privacy Challenges 1391 While a lot of standarization work was done to avoid leakage of 1392 identity information to intermediaries (such as eavesdroppers on the 1393 communication path between the client application and the relying 1394 party) in the area of authentication and key exchange protocols. 1395 However, from current deployments the weak aspects with respect to 1396 security are: 1398 1. Today business contracts are used to create federations between 1399 identity providers and relying parties. These contracts are not 1400 only financial agreements but they also define the rules about 1401 what information is exchanged between the AAA server and the 1402 relying party and the potential involvement of AAA proxies and 1403 brokers as intermediaries. While these contracts are openly 1404 available for university federations they are not public in case 1405 of commercial deployments. Quite naturally, there is a lack of 1406 transparency for external parties. 1408 2. In today's deployments the ability for users to determine the 1409 amount of information exchanged with other parties over time, as 1410 well as the possibility to control the amount of information 1411 exposed via an explict consent is limited. This is partially due 1412 the nature of application capabilities at the time of network 1413 access authentication. However, with the envisioned extension of 1414 the usage, as described in this document, it is desirable to 1415 offer these capabilities. 1417 6. Deployment Considerations 1419 6.1. EAP Channel Binding 1421 Discuss the implications of needing EAP channel binding. 1423 6.2. AAA Proxy Behavior 1425 Discuss deployment implications of our proxy requirements. 1427 7. Security Considerations 1429 This document describes the architecture for Application Bridging for 1430 Federated Access Beyond Web (ABFAB) and security is therefore the 1431 main focus. This section highlights the main communication channels 1432 and their security properties: 1434 Client-to-RP Channel: 1436 The channel binding material is provided by any certificates and 1437 the final message (i.e., a cryptographic token for the channel). 1438 Authentication may be provided by the RP to the client but a 1439 deployment without authentication at the TLS layer is possible as 1440 well. In addition, there is a channel between the GSS requestor 1441 and the GSS acceptor, but the keying material is provided by a 1442 "third party" to both entities. The client can derive keying 1443 material locally, but the RP gets the material from the IdP. In 1444 the absence of a transport that provides encryption and/or 1445 integrity, the channel between the client and the RP has no 1446 ability to have any cryptographic protection until the EAP 1447 authentication has been completed and the MSK is transfered from 1448 the IdP to the RP. 1450 RP-to-IdP Channel: 1452 The security of this communication channel is mainly provided by 1453 the functionality offered via RADIUS and Diameter. At the time of 1454 writing there are no end-to-end security mechanisms standardized 1455 and thereby the architecture has to rely on hop-by-hop security 1456 with trusted AAA entities or, as an alternative but possible 1457 deployment variant, direct communication between the AAA client to 1458 the AAA server. Note that the authorization result the IdP 1459 provides to the RP in the form of a SAML assertion may, however, 1460 be protected such that the SAML related components are secured 1461 end-to-end. 1463 The MSK is transported from the IdP to the RP over this channel. 1464 As no end-to-end security is provided by AAA, all AAA entities on 1465 the path between the RP and IdP have the ability to eavesdrop if 1466 no additional security measures are taken. One such measure is to 1467 use a transport between the client and the IdP that provides 1468 confidentiality. 1470 Client-to-IdP Channel: 1472 This communication interaction is accomplished with the help of 1473 EAP and EAP methods. The offered security protection will depend 1474 on the EAP method that is chosen but a minimum requirement fis to 1475 offer mutual authentication, and key derivation. The IdP is 1476 responsible during this process to determine that the RP that is 1477 communication to the client over the RP-to-IdP channel is the same 1478 one talking to the IdP. This is accomplished via the EAP channel 1479 binding. 1481 Partial list of issues to be addressed in this section: Privacy, 1482 SAML, Trust Anchors, EAP Algorithm Selection, Diameter/RADIUS/AAA 1483 Issues, Naming of Entities, Protection of passwords, Channel Binding, 1484 End-point-connections (TLS), Proxy problems 1486 8. IANA Considerations 1488 This document does not require actions by IANA. 1490 9. Acknowledgments 1492 We would like to thank Mayutan Arumaithurai and Klaas Wierenga for 1493 their feedback. Additionally, we would like to thank Eve Maler, 1494 Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, and Luke 1495 Howard for their feedback on the federation terminology question. 1497 Furthermore, we would like to thank Klaas Wierenga for his review of 1498 the pre-00 draft version. 1500 10. References 1502 10.1. Normative References 1504 [RFC2743] Linn, J., "Generic Security Service Application Program 1505 Interface Version 2, Update 1", RFC 2743, January 2000. 1507 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1508 "Remote Authentication Dial In User Service (RADIUS)", 1509 RFC 2865, June 2000. 1511 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1512 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1514 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1515 Levkowetz, "Extensible Authentication Protocol (EAP)", 1516 RFC 3748, June 2004. 1518 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1519 Dial In User Service) Support For Extensible 1520 Authentication Protocol (EAP)", RFC 3579, September 2003. 1522 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1523 Authentication Protocol (EAP) Application", RFC 4072, 1524 August 2005. 1526 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1527 Network Access Identifier", RFC 4282, December 2005. 1529 [I-D.iab-privacy-terminology] 1530 Hansen, M., Tschofenig, H., Smith, R., and A. Cooper, 1531 "Privacy Terminology and Concepts", 1532 draft-iab-privacy-terminology-01 (work in progress), 1533 March 2012. 1535 [I-D.ietf-abfab-gss-eap] 1536 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 1537 Extensible Authentication Protocol", 1538 draft-ietf-abfab-gss-eap-08 (work in progress), June 2012. 1540 [I-D.ietf-abfab-aaa-saml] 1541 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding 1542 and Profiles for SAML", draft-ietf-abfab-aaa-saml-03 (work 1543 in progress), March 2012. 1545 [I-D.ietf-emu-chbind] 1546 Hartman, S., Clancy, T., and K. Hoeper, "Channel Binding 1547 Support for EAP Methods", draft-ietf-emu-chbind-16 (work 1548 in progress), May 2012. 1550 10.2. Informative References 1552 [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and 1553 D. Spence, "Generic AAA Architecture", RFC 2903, 1554 August 2000. 1556 [I-D.nir-tls-eap] 1557 Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "A 1558 Flexible Authentication Framework for the Transport Layer 1559 Security (TLS) Protocol using the Extensible 1560 Authentication Protocol (EAP)", draft-nir-tls-eap-13 (work 1561 in progress), December 2011. 1563 [I-D.ietf-oauth-v2] 1564 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 1565 2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work 1566 in progress), June 2012. 1568 [I-D.iab-privacy-considerations] 1569 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and 1570 J. Morris, "Privacy Considerations for Internet 1571 Protocols", draft-iab-privacy-considerations-02 (work in 1572 progress), March 2012. 1574 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1575 Authentication Protocol (EAP) Method Requirements for 1576 Wireless LANs", RFC 4017, March 2005. 1578 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., 1579 and F. Bersani, "The Extensible Authentication Protocol- 1580 Internet Key Exchange Protocol version 2 (EAP-IKEv2) 1581 Method", RFC 5106, February 2008. 1583 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1584 RFC 1964, June 1996. 1586 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1587 Specification", RFC 2203, September 1997. 1589 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., 1590 and R. Hall, "Generic Security Service Algorithm for 1591 Secret Key Transaction Authentication for DNS (GSS-TSIG)", 1592 RFC 3645, October 2003. 1594 [RFC2138] Rigney, C., Rigney, C., Rubens, A., Simpson, W., and S. 1595 Willens, "Remote Authentication Dial In User Service 1596 (RADIUS)", RFC 2138, April 1997. 1598 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1599 "Generic Security Service Application Program Interface 1600 (GSS-API) Authentication and Key Exchange for the Secure 1601 Shell (SSH) Protocol", RFC 4462, May 2006. 1603 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1604 Security Layer (SASL)", RFC 4422, June 2006. 1606 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1607 Channels", RFC 5056, November 2007. 1609 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1610 Service Application Program Interface (GSS-API) Mechanisms 1611 in Simple Authentication and Security Layer (SASL): The 1612 GS2 Mechanism Family", RFC 5801, July 2010. 1614 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1615 April 2010. 1617 [OASIS.saml-core-2.0-os] 1618 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1619 "Assertions and Protocol for the OASIS Security Assertion 1620 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1621 2.0-os, March 2005. 1623 [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., 1624 Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and 1625 D. Spence, "AAA Authorization Framework", RFC 2904, 1626 August 2000. 1628 [I-D.hartman-emu-mutual-crypto-bind] 1629 Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual 1630 Cryptographic Binding", 1631 draft-hartman-emu-mutual-crypto-bind-00 (work in 1632 progress), March 2012. 1634 [WS-TRUST] 1635 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, 1636 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS 1637 Standard ws-trust-200902, February 2009, . 1640 URIs 1642 [1] 1644 [2] 1646 Editorial Comments 1648 [anchor4] JLS: Add section on discussion EAP methods and 1649 requirements there on 1651 [anchor9] JLS: I don't believe this is a true statement - check it 1652 with Josh and Sam. 1654 Authors' Addresses 1656 Josh Howlett 1657 JANET(UK) 1658 Lumen House, Library Avenue, Harwell 1659 Oxford OX11 0SG 1660 UK 1662 Phone: +44 1235 822363 1663 Email: Josh.Howlett@ja.net 1665 Sam Hartman 1666 Painless Security 1668 Phone: 1669 Email: hartmans-ietf@mit.edu 1671 Hannes Tschofenig 1672 Nokia Siemens Networks 1673 Linnoitustie 6 1674 Espoo 02600 1675 Finland 1677 Phone: +358 (50) 4871445 1678 Email: Hannes.Tschofenig@gmx.net 1679 URI: http://www.tschofenig.priv.at 1681 Eliot Lear 1682 Cisco Systems GmbH 1683 Richtistrasse 7 1684 Wallisellen, ZH CH-8304 1685 Switzerland 1687 Phone: +41 44 878 9200 1688 Email: lear@cisco.com 1690 Jim Schaad 1691 Soaring Hawk Consulting 1693 Email: ietf@augustcellars.com