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