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