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