idnits 2.17.1 draft-ietf-abfab-arch-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3539 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 144 -- Looks like a reference, but probably isn't: '2' on line 310 -- Looks like a reference, but probably isn't: '3' on line 743 -- Looks like a reference, but probably isn't: '4' on line 758 -- Looks like a reference, but probably isn't: '5' on line 1606 == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-09 == Outdated reference: A later version (-15) exists of draft-ietf-radext-nai-06 == Outdated reference: A later version (-12) exists of draft-ietf-radext-radius-fragmentation-06 == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-11 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 22, 2015 Painless Security 6 H. Tschofenig 7 ARM Ltd. 8 E. Lear 9 Cisco Systems GmbH 10 J. Schaad 11 Soaring Hawk Consulting 12 July 21, 2014 14 Application Bridging for Federated Access Beyond Web (ABFAB) 15 Architecture 16 draft-ietf-abfab-arch-13.txt 18 Abstract 20 Over the last decade a substantial amount of work has occurred in the 21 space of federated access management. Most of this effort has 22 focused on two use cases: network access and web-based access. 23 However, the solutions to these use cases that have been proposed and 24 deployed tend to have few building blocks in common. 26 This memo describes an architecture that makes use of extensions to 27 the commonly used security mechanisms for both federated and non- 28 federated access management, including the Remote Authentication Dial 29 In User Service (RADIUS) the Generic Security Service Application 30 Program Interface (GSS-API), the Extensible Authentication Protocol 31 (EAP) and the Security Assertion Markup Language (SAML). The 32 architecture addresses the problem of federated access management to 33 primarily non-web-based services, in a manner that will scale to 34 large numbers of identity providers, relying parties, and 35 federations. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 22, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.1.1. Channel Binding . . . . . . . . . . . . . . . . . . . 6 74 1.2. An Overview of Federation . . . . . . . . . . . . . . . . 7 75 1.3. Challenges for Contemporary Federation . . . . . . . . . 10 76 1.4. An Overview of ABFAB-based Federation . . . . . . . . . . 10 77 1.5. Design Goals . . . . . . . . . . . . . . . . . . . . . . 13 78 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14 79 2.1. Relying Party to Identity Provider . . . . . . . . . . . 15 80 2.1.1. AAA, RADIUS and Diameter . . . . . . . . . . . . . . 16 81 2.1.2. Discovery and Rules Determination . . . . . . . . . . 18 82 2.1.3. Routing and Technical Trust . . . . . . . . . . . . . 19 83 2.1.4. AAA Security . . . . . . . . . . . . . . . . . . . . 21 84 2.1.5. SAML Assertions . . . . . . . . . . . . . . . . . . . 21 85 2.2. Client To Identity Provider . . . . . . . . . . . . . . . 23 86 2.2.1. Extensible Authentication Protocol (EAP) . . . . . . 23 87 2.2.2. EAP Channel Binding . . . . . . . . . . . . . . . . . 25 88 2.3. Client to Relying Party . . . . . . . . . . . . . . . . . 25 89 2.3.1. GSS-API . . . . . . . . . . . . . . . . . . . . . . . 26 90 2.3.2. Protocol Transport . . . . . . . . . . . . . . . . . 27 91 2.3.3. Reauthentication . . . . . . . . . . . . . . . . . . 28 92 3. Application Security Services . . . . . . . . . . . . . . . . 28 93 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 28 94 3.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 30 95 3.3. Host-Based Service Names . . . . . . . . . . . . . . . . 31 96 3.4. Additional GSS-API Services . . . . . . . . . . . . . . . 32 98 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 99 4.1. Entities and their roles . . . . . . . . . . . . . . . . 34 100 4.2. Privacy Aspects of ABFAB Communication Flows . . . . . . 35 101 4.2.1. Client to RP . . . . . . . . . . . . . . . . . . . . 35 102 4.2.2. Client to IdP (via Federation Substrate) . . . . . . 36 103 4.2.3. IdP to RP (via Federation Substrate) . . . . . . . . 37 104 4.3. Relationship between User and Entities . . . . . . . . . 37 105 4.4. Accounting Information . . . . . . . . . . . . . . . . . 38 106 4.5. Collection and retention of data and identifiers . . . . 38 107 4.6. User Participation . . . . . . . . . . . . . . . . . . . 39 108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 110 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 112 8.1. Normative References . . . . . . . . . . . . . . . . . . 40 113 8.2. Informative References . . . . . . . . . . . . . . . . . 41 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 116 1. Introduction 118 Numerous security mechanisms have been deployed on the Internet to 119 manage access to various resources. These mechanisms have been 120 generalized and scaled over the last decade through mechanisms such 121 as Simple Authentication and Security Layer (SASL) with the Generic 122 Security Server Application Program Interface (GSS-API) (known as the 123 GS2 family) [RFC5801], Security Assertion Markup Language (SAML) 124 [OASIS.saml-core-2.0-os], and the Authentication, Authorization, and 125 Accounting (AAA) architecture as embodied in RADIUS [RFC2865] and 126 Diameter [RFC6733]. 128 A Relying Party (RP) is the entity that manages access to some 129 resource. The entity that is requesting access to that resource is 130 often described as the Client. Many security mechanisms are 131 manifested as an exchange of information between these entities. The 132 RP is therefore able to decide whether the Client is authorized, or 133 not. 135 Some security mechanisms allow the RP to delegate aspects of the 136 access management decision to an entity called the Identity Provider 137 (IdP). This delegation requires technical signaling, trust and a 138 common understanding of semantics between the RP and IdP. These 139 aspects are generally managed within a relationship known as a 140 'federation'. This style of access management is accordingly 141 described as 'federated access management'. 143 Federated access management has evolved over the last decade through 144 specifications like SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth 145 [RFC6749] and WS-Trust [WS-TRUST]. The benefits of federated access 146 management include: 148 Single or Simplified sign-on: 150 An Internet service can delegate access management, and the 151 associated responsibilities such as identity management and 152 credentialing, to an organization that already has a long-term 153 relationship with the Client. This is often attractive as Relying 154 Parties frequently do not want these responsibilities. The Client 155 also requires fewer credentials, which is also desirable. 157 Data Minimization and User Participation: 159 Often a Relying Party does not need to know the identity of a 160 Client to reach an access management decision. It is frequently 161 only necessary for the Relying Party to know specific attributes 162 about the client, for example, that the client is affiliated with 163 a particular organization or has a certain role or entitlement. 164 Sometimes the RP only needs to know a pseudonym of the client. 166 Prior to the release of attributes to the RP from the IdP, the IdP 167 will check configuration and policy to determine if the attributes 168 are to be released. There is currently no direct client 169 participation in this decision. 171 Provisioning: 173 Sometimes a Relying Party needs, or would like, to know more about 174 a client than an affiliation or a pseudonym. For example, a 175 Relying Party may want the Client's email address or name. Some 176 federated access management technologies provide the ability for 177 the IdP to supply this information, either on request by the RP or 178 unsolicited. 180 This memo describes the Application Bridging for Federated Access 181 Beyond the Web (ABFAB) architecture. The architecture addresses the 182 problem of federated access management primarily for non-web-based 183 services. This architecture makes use of extensions to the commonly 184 used security mechanisms for both federated and non-federated access 185 management, including RADIUS, the Generic Security Service (GSS), the 186 Extensible Authentication Protocol (EAP) and SAML. The architecture 187 should be extended to use Diameter in the future. It does so in a 188 manner that designed to scale to large numbers of identity providers, 189 relying parties, and federations. 191 1.1. Terminology 193 This document uses identity management and privacy terminology from 194 [RFC6973]. In particular, this document uses the terms identity 195 provider, relying party, identifier, pseudonymity, unlinkability, and 196 anonymity. 198 In this architecture the IdP consists of the following components: an 199 EAP server, a RADIUS server, and optionally a SAML Assertion service. 201 This document uses the term Network Access Identifier (NAI), as 202 defined in [I-D.ietf-radext-nai]. An NAI consists of a realm 203 identifier, which is associated with an AAA server and thus an IdP 204 and a username which is associated with a specific client of the IdP. 206 One of the problems some people have found with reading this document 207 is that the terminology sometimes appears to be inconsistent. This 208 is due the fact that the terms used by the different standards we are 209 referencing are not consistent with each other. In general the 210 document uses either the ABFAB term or the term associated with the 211 standard under discussion as appropriate. For reference we include 212 this table which maps the different terms into a single table. 214 +------------+-------------+---------------------+------------------+ 215 | Protocol | Client | Relying Party | Identity | 216 | | | | Provider | 217 +------------+-------------+---------------------+------------------+ 218 | ABFAB | Client | Relying Party (RP) | Identity | 219 | | | | Provider (IdP) | 220 | | | | | 221 | | Initiator | Acceptor | | 222 | | | | | 223 | | | Server | | 224 | | | | | 225 | SAML | Subject | Service Provider | Issuer | 226 | | | | | 227 | GSS-API | Initiator | Acceptor | | 228 | | | | | 229 | EAP | EAP peer | EAP Authenticator | EAP server | 230 | | | | | 231 | AAA | | AAA Client | AAA server | 232 | | | | | 233 | RADIUS | user | NAS | RADIUS server | 234 | | | | | 235 | | | RADIUS client | | 236 +------------+-------------+---------------------+------------------+ 238 Table 1. Terminology 240 Note that in some cases a cell has been left empty; in these cases 241 there is no name that represents the entity. 243 1.1.1. Channel Binding 245 This document uses the term channel binding in two different 246 contexts. The term channel binding has a different meaning in each 247 of these contexts. 249 EAP channel binding is used to implement GSS-API naming semantics. 250 EAP channel binding sends a set of attributes from the peer to the 251 EAP server either as part of the EAP conversation or as part of a 252 secure association protocol. In addition, attributes are sent in the 253 backend protocol from the EAP authenticator to the EAP server. The 254 EAP server confirms the consistency of these attributes and provides 255 the confirmation back to the peer. In this document, channel binding 256 without qualification refers to EAP channel binding. 258 GSS-API channel binding provides protection against man-in-the-middle 259 attacks when GSS-API is used for authentication inside of some 260 tunnel; it is similar to a facility called cryptographic binding in 261 EAP. The binding works by each side deriving a cryptographic value 262 from the tunnel itself and then using that cryptographic value to 263 prove to the other side that it knows the value. 265 See [RFC5056] for a discussion of the differences between these two 266 facilities. However, the difference can be summarized as GSS-API 267 channel binding says that there is nobody between the client and the 268 EAP authenticator while EAP channel binding allows the client to have 269 knowledge about attributes of the EAP authenticator (such as its 270 name). 272 Typically when considering both EAP and GSS-API channel binding, 273 people think of channel binding in combination with mutual 274 authentication. This is sufficiently common that without additional 275 qualification channel binding should be assumed to imply mutual 276 authentication. In GSS-API, without mutual authentication only the 277 acceptor has authenticated the initiator. Similarly in EAP, only the 278 EAP server has authenticated the peer. That's sometimes useful. 279 Consider for example a user who wishes to access a protected resource 280 for a shared whiteboard in a conference room. The whiteboard is the 281 acceptor; it knows that the initiator is authorized to give it a 282 presentation and the user can validate the whitebord got the correct 283 presentation by visual means. (The presention should not be 284 confidential in this case.) If channel binding is used without 285 mutual authentication, it is effectively a request to disclose the 286 resource in the context of a particular channel. Such an 287 authentication would be similar in concept to a holder-of-key SAML 288 assertion. However, also note that while it is not happening in the 289 protocol, mutual authentication is happening in the overall system: 290 the user is able to visually authenticate the content. This is 291 consistent with all uses of channel binding without protocol level 292 mutual authentication found so far. 294 1.2. An Overview of Federation 296 In the previous section we introduced the following entities: 298 o the Client, 300 o the Identity Provider, and 302 o the Relying Party. 304 The final entity that needs to be introduced is the Individual. An 305 Individual is a human being that is using the Client. In any given 306 situation, an Individual may or may not exist. Clients can act 307 either as front ends for Individuals or they may be independent 308 entities that are setup and allowed to run autonomously. An example 309 of such an independent entity can be found in the trust routing 310 protocol [2] where the routers use ABFAB to authenticate to each 311 other. 313 These entities and their relationships are illustrated graphically in 314 Figure 1. 316 ,----------\ ,---------\ 317 | Identity | Federation | Relying | 318 | Provider + <-------------------> + Party | 319 `----------' '---------' 320 < 321 \ 322 \ Authentication 323 \ 324 \ 325 \ 326 \ 327 \ +---------+ 328 \ | | O 329 v| Client | \|/ Individual 330 | | | 331 +---------+ / \ 333 Figure 1: Entities and their Relationships 335 The relationships between the entities in Figure 1 are: 337 Federation 339 The Identity Provider and the Relying Parties are part of a 340 Federation. The relationship may be direct (they have an explicit 341 trust relationship) or transitive (the trust relationship is 342 mediated by one or more entities). The federation relationship is 343 governed by a federation agreement. Within a single federation, 344 there may be multiple Identity Providers as well as multiple 345 Relying Parties. 347 Authentication 349 There is a direct relationship between the Client and the Identity 350 Provider. This relationship provides the means by which they 351 trust each other and can securely authenticate each other. 353 A federation agreement typically encompasses operational 354 specifications and legal rules: 356 Operational Specifications: 358 The goal of operational specifications is to provide enough 359 definition that the system works and interoperability is possible. 360 These include the technical specifications (e.g. protocols used to 361 communicate between the three parties), process standards, 362 policies, identity proofing, credential and authentication 363 algorithm requirements, performance requirements, assessment and 364 audit criteria, etc. 366 Legal Rules: 368 The legal rules take the legal framework into consideration and 369 provide contractual obligations for each entity. The rules define 370 the responsibilities of each party and provide further 371 clarification of the operational specifications. These legal 372 rules regulate the operational specifications, make operational 373 specifications legally binding to the participants, define and 374 govern the rights and responsibilities of the participants. The 375 legal rules may, for example, describe liability for losses, 376 termination rights, enforcement mechanisms, measures of damage, 377 dispute resolution, warranties, etc. 379 The Operational Specifications can demand the usage of a specific 380 technical infrastructure, including requirements on the message 381 routing intermediaries, to offer the required technical 382 functionality. In other environments, the Operational Specifications 383 require fewer technical components in order to meet the required 384 technical functionality. 386 The Legal Rules include many non-technical aspects of federation, 387 such as business practices and legal arrangements, which are outside 388 the scope of the IETF. The Legal Rules can still have an impact on 389 the architectural setup or on how to ensure the dynamic establishment 390 of trust. 392 While a federation agreement is often discussed within the context of 393 formal relationships, such as between an enterprise and an employee 394 or a government and a citizen, a federation agreement does not have 395 to require any particular level of formality. For an IdP and a 396 Client, it is sufficient for a relationship to be established by 397 something as simple as using a web form and confirmation email. For 398 an IdP and an RP, it is sufficient for the IdP to publish contact 399 information along with a public key and for the RP to use that data. 400 Within the framework of ABFAB, it will generally be required that a 401 mechanism exists for the IdP to be able to trust the identity of the 402 RP, if this is not present then the IdP cannot provide the assurances 403 to the client that the identity of the RP has been established. 405 The nature of federation dictates that there is some form of 406 relationship between the identity provider and the relying party. 407 This is particularly important when the relying party wants to use 408 information obtained from the identity provider for access management 409 decisions and when the identity provider does not want to release 410 information to every relying party (or only under certain 411 conditions). 413 While it is possible to have a bilateral agreement between every IdP 414 and every RP; on an Internet scale this setup requires the 415 introduction of the multi-lateral federation concept, as the 416 management of such pair-wise relationships would otherwise prove 417 burdensome. 419 The IdP will typically have a long-term relationship with the Client. 420 This relationship typically involves the IdP positively identifying 421 and credentialing the Client (for example, at time of employment 422 within an organization). When dealing with individuals, this process 423 is called identity proofing [NIST-SP.800-63]. The relationship will 424 often be instantiated within an agreement between the IdP and the 425 Client (for example, within an employment contract or terms of use 426 that stipulates the appropriate use of credentials and so forth). 428 The nature and quality of the relationship between the Client and the 429 IdP is an important contributor to the level of trust that an RP may 430 assign to an assertion describing a Client made by an IdP. This is 431 sometimes described as the Level of Assurance [NIST-SP.800-63]. 433 Federation does not require an a priori relationship or a long-term 434 relationship between the RP and the Client; it is this property of 435 federation that yields many of the federation benefits. However, 436 federation does not preclude the possibility of a pre-existing 437 relationship between the RP and the Client, nor that they may use the 438 introduction to create a new long-term relationship independent of 439 the federation. 441 Finally, it is important to reiterate that in some scenarios there 442 might indeed be an Individual behind the Client and in other cases 443 the Client may be autonomous. 445 1.3. Challenges for Contemporary Federation 447 As the number of federated IdPs and RPs (services) proliferats, the 448 role of the individual can become ambiguous in certain circumstances. 449 For example, a school might provide online access for a student's 450 grades to their parents for review, and to the student's teacher for 451 modification. A teacher who is also a parent must clearly 452 distinguish her role upon access. 454 Similarly, as the number of federations proliferates, it becomes 455 increasingly difficult to discover which identity provider(s) a user 456 is associated with. This is true for both the web and non-web case, 457 but is particularly acute for the latter as many non-web 458 authentication systems are not semantically rich enough on their own 459 to allow for such ambiguities. For instance, in the case of an email 460 provider, the SMTP and IMAP protocols do not have the ability for the 461 server to request information from the client, beyond the clients 462 NAI, that the server would then use to decide between the multiple 463 federations it is associated with. However, the building blocks do 464 exist to add this functionality. 466 1.4. An Overview of ABFAB-based Federation 468 The previous section described the general model of federation, and 469 the application of access management within the federation. This 470 section provides a brief overview of ABFAB in the context of this 471 model. 473 In this example, a client is attempting to connect to a server in 474 order to either get access to some data or perform some type of 475 transaction. In order for the client to mutually authenticate with 476 the server, the following steps are taken in an ABFAB architecture (a 477 graphical view of the steps can be found in figure Figure 2): 479 1. Client Configuration: The Client Application is configured with 480 an NAI assigned by the IdP. It is also configured with any 481 keys, certificates, passwords or other secret and public 482 information needed to run the EAP protocols between it and the 483 IdP. 485 2. Authentication mechanism selection: The Client Application is 486 configured to use the GSS-EAP GSS-API mechanism for 487 authentication/authorization. 489 3. Client provides an NAI to RP: The client application sets up a 490 transport to the RP and begins the GSS-EAP authentication. In 491 response, the RP sends an EAP request message (nested in the 492 GSS-EAP protocol) asking for the Client's name. The Client 493 sends an EAP response with an NAI name form that, at a minimum, 494 contains the realm portion of its full NAI. 496 4. Discovery of federated IdP: The RP uses pre-configured 497 information or a federation proxy to determine what IdP to use 498 based on policy and the realm portion of the provided Client 499 NAI. This is discussed in detail below (Section 2.1.2). 501 5. Request from Relying Party to IdP: Once the RP knows who the IdP 502 is, it (or its agent) will send a RADIUS request to the IdP. 503 The RADIUS access request encapsulates the EAP response. At 504 this stage, the RP will likely have no idea who the client is. 505 The RP sends its identity to the IdP in AAA attributes, and it 506 may send a SAML Attribute Request in a AAA attribute. The AAA 507 network checks that the identity claimed by the RP is valid. 509 6. IdP begins EAP with the client: The IdP sends an EAP message to 510 the client with an EAP method to be used. The IdP should not 511 re-request the clients name in this message, but clients need to 512 be able to handle it. In this case the IdP must accept a realm 513 only in order to protect the client's name from the RP. The 514 available and appropriate methods are discussed below in this 515 memo (Section 2.2.1). 517 7. The EAP protocol is run: A bunch of EAP messages are passed 518 between the client (EAP peer) and the IdP (EAP server), until 519 the result of the authentication protocol is determined. The 520 number and content of those messages depends on the EAP method 521 selected. If the IdP is unable to authenticate the client, the 522 IdP sends an EAP failure message to the RP. As part of the EAP 523 protocol, the client sends a channel bindings EAP message to the 524 IdP (Section 2.2.2). In the channel binding message the client 525 identifies, among other things, the RP to which it is attempting 526 to authenticate. The IdP checks the channel binding data from 527 the client with that provided by the RP via the AAA protocol. 528 If the bindings do not match the IdP sends an EAP failure 529 message to the RP. 531 8. Successful EAP Authentication: At this point, the IdP (EAP 532 server) and client (EAP peer) have mutually authenticated each 533 other. As a result, the client and the IdP hold two 534 cryptographic keys: a Master Session Key (MSK), and an Extended 535 MSK (EMSK). At this point the client has a level of assurance 536 about the identity of the RP based on the name checking the IdP 537 has done using the RP naming information from the AAA framework 538 and from the client (by the channel binding data). 540 9. Local IdP Policy Check: At this stage, the IdP checks local 541 policy to determine whether the RP and client are authorized for 542 a given transaction/service, and if so, what if any, attributes 543 will be released to the RP. If the IdP gets a policy failure, 544 it sends an EAP failure message to the RP and client. (The RP 545 will have done its policy checks during the discovery process.) 547 10. IdP provides the RP with the MSK: The IdP sends a positive 548 result EAP to the RP, along with an optional set of AAA 549 attributes associated with the client (usually as one or more 550 SAML assertions). In addition, the EAP MSK is returned to the 551 RP. 553 11. RP Processes Results: When the RP receives the result from the 554 IdP, it should have enough information to either grant or refuse 555 a resource access request. It may have information that 556 associates the client with specific authorization identities. 557 If additional attributes are needed from the IdP the RP may make 558 a new SAML Request to the IdP. It will apply these results in 559 an application-specific way. 561 12. RP returns results to client: Once the RP has a response it must 562 inform the client application of the result. If all has gone 563 well, all are authenticated, and the application proceeds with 564 appropriate authorization levels. The client can now complete 565 the authentication of the RP by the use of the EAP MSK value. 567 Relying Client Identity 568 Party App Provider 570 | (1) | Client Configuration 571 | | | 572 |<-----(2)----->| | Mechanism Selection 573 | | | 574 |<-----(3)-----<| | NAI transmitted to RP 575 | | | 576 |<=====(4)====================>| Discovery 577 | | | 578 |>=====(5)====================>| Access request from RP to IdP 579 | | | 580 | |< - - (6) - -<| EAP method to Client 581 | | | 582 | |< - - (7) - ->| EAP Exchange to authenticate 583 | | | Client 584 | | | 585 | | (8 & 9) Local Policy Check 586 | | | 587 |<====(10)====================<| IdP Assertion to RP 588 | | | 589 (11) | | RP processes results 590 | | | 591 |>----(12)----->| | Results to client app. 593 ----- = Between Client App and RP 594 ===== = Between RP and IdP 595 - - - = Between Client App and IdP (via RP) 597 Figure 2: ABFAB Authentication Steps 599 1.5. Design Goals 601 Our key design goals are as follows: 603 o Each party in a transaction will be authenticated, although 604 perhaps not identified, and the client will be authorized for 605 access to a specific resource. 607 o Means of authentication is decoupled from the application protocol 608 so as to allow for multiple authentication methods with minimal 609 changes to the application. 611 o The architecture requires no sharing of long term private keys 612 between clients and RPs. 614 o The system will scale to large numbers of identity providers, 615 relying parties, and users. 617 o The system will be designed primarily for non-Web-based 618 authentication. 620 o The system will build upon existing standards, components, and 621 operational practices. 623 Designing new three party authentication and authorization protocols 624 is hard and fraught with risk of cryptographic flaws. Achieving 625 widespread deployment is even more difficult. A lot of attention on 626 federated access has been devoted to the Web. This document instead 627 focuses on a non-Web-based environment and focuses on those protocols 628 where HTTP is not used. Despite the growing trend to layer every 629 protocol on top of HTTP there are still a number of protocols 630 available that do not use HTTP-based transports. Many of these 631 protocols are lacking a native authentication and authorization 632 framework of the style shown in Figure 1. 634 2. Architecture 636 We have already introduced the federated access architecture, with 637 the illustration of the different actors that need to interact, but 638 did not expand on the specifics of providing support for non-Web 639 based applications. This section details this aspect and motivates 640 design decisions. The main theme of the work described in this 641 document is focused on re-using existing building blocks that have 642 been deployed already and to re-arrange them in a novel way. 644 Although this architecture assumes updates to the relying party, the 645 client application, and the IdP, those changes are kept at a minimum. 646 A mechanism that can demonstrate deployment benefits (based on ease 647 of update of existing software, low implementation effort, etc.) is 648 preferred and there may be a need to specify multiple mechanisms to 649 support the range of different deployment scenarios. 651 There are a number of ways to encapsulate EAP into an application 652 protocol. For ease of integration with a wide range of non-Web based 653 application protocols, GSS-API was chosen. The technical 654 specification of GSS-EAP can be found in [RFC7055]. 656 The architecture consists of several building blocks, which is shown 657 graphically in Figure 3. In the following sections, we discuss the 658 data flow between each of the entities, the protocols used for that 659 data flow and some of the trade-offs made in choosing the protocols. 661 +--------------+ 662 | Identity | 663 | Provider | 664 | (IdP) | 665 +-^----------^-+ 666 * EAP o RADIUS 667 * o 668 --v----------v-- 669 /// \\\ 670 // \\ 671 | Federation | 672 | Substrate | 673 \\ // 674 \\\ /// 675 --^----------^-- 676 * EAP o RADIUS 677 * o 678 +-------------+ +-v----------v--+ 679 | | | | 680 | Client | EAP/EAP Method | Relying Party | 681 | Application |<****************>| (RP) | 682 | | GSS-API | | 683 | |<---------------->| | 684 | | Application | | 685 | | Protocol | | 686 | |<================>| | 687 +-------------+ +---------------+ 689 Legend: 691 <****>: Client-to-IdP Exchange 692 <---->: Client-to-RP Exchange 693 : RP-to-IdP Exchange 694 <====>: Protocol through which GSS-API/GS2 exchanges are tunneled 696 Figure 3: ABFAB Protocol Instantiation 698 2.1. Relying Party to Identity Provider 700 Communications between the Relying Party and the Identity Provider is 701 done by the federation substrate. This communication channel is 702 responsible for: 704 o Establishing the trust relationship between the RP and the IdP. 706 o Determining the rules governing the relationship. 708 o Conveying authentication packets from the client to the IdP and 709 back. 711 o Providing the means of establishing a trust relationship between 712 the RP and the client. 714 o Providing a means for the RP to obtain attributes about the client 715 from the IdP. 717 The ABFAB working group has chosen the AAA framework for the messages 718 transported between the RP and IdP. The AAA framework supports the 719 requirements stated above as follows: 721 o The AAA backbone supplies the trust relationship between the RP 722 and the IdP. 724 o The agreements governing a specific AAA backbone contains the 725 rules governing the relationships within the AAA federation. 727 o A method exists for carrying EAP packets within RADIUS [RFC3579] 728 and Diameter [RFC4072]. 730 o The use of EAP channel binding [RFC6677] along with the core ABFAB 731 protocol provide the pieces necessary to establish the identities 732 of the RP and the client, while EAP provides the cryptographic 733 methods for the RP and the client to validate they are talking to 734 each other. 736 o A method exists for carrying SAML packets within RADIUS 737 [I-D.ietf-abfab-aaa-saml] which allows the RP to query attributes 738 about the client from the IdP. 740 Protocols that support the same framework, but do different routing 741 are expected to be defined and used the future. One such effort call 742 the Trust Router is to setup a framework that creates a trusted 743 point-to-point channel on the fly [3]. 745 2.1.1. AAA, RADIUS and Diameter 747 The usage of the AAA framework with RADIUS [RFC2865] and Diameter 748 [RFC6733] for network access authentication has been successful from 749 a deployment point of view. To map to the terminology used in Figure 750 1 to the AAA framework the IdP corresponds to the AAA server, the RP 751 corresponds to the AAA client, and the technical building blocks of a 752 federation are AAA proxies, relays and redirect agents (particularly 753 if they are operated by third parties, such as AAA brokers and 754 clearing houses). The front-end, i.e. the end host to AAA client 755 communication, is in case of network access authentication offered by 756 link layer protocols that forward authentication protocol exchanges 757 back-and-forth. An example of a large scale RADIUS-based federation 758 is EDUROAM [4]. 760 By using the AAA framework, ABFAB can be built on the federation 761 agreements already exist, the agreements can then merely be expanded 762 to cover the ABFAB. The AAA framework has already addressed some of 763 the problems outlined above. For example, 765 o It already has a method for routing requests based on a domain. 767 o It already has an extensible architecture allowing for new 768 attributes to be defined and transported. 770 o Pre-existing relationships can be re-used. 772 The astute reader will notice that RADIUS and Diameter have 773 substantially similar characteristics. Why not pick one? RADIUS and 774 Diameter are deployed in different environments. RADIUS can often be 775 found in enterprise and university networks, and is also in use by 776 fixed network operators. Diameter, on the other hand, is deployed by 777 mobile operators. Another key difference is that today RADIUS is 778 largely transported upon UDP. We leave as a deployment decision, 779 which protocol will be appropriate. The protocol defines all the 780 necessary new AAA attributes as RADIUS attributes. A future document 781 could define the same AAA attributes for a Diameter environment. We 782 also note that there exist proxies which convert from RADIUS to 783 Diameter and back. This makes it possible for both to be deployed in 784 a single federation substrate. 786 Through the integrity protection mechanisms in the AAA framework, the 787 identity provider can establish technical trust that messages are 788 being sent by the appropriate relying party. Any given interaction 789 will be associated with one federation at the policy level. The 790 legal or business relationship defines what statements the identity 791 provider is trusted to make and how these statements are interpreted 792 by the relying party. The AAA framework also permits the relying 793 party or elements between the relying party and identity provider to 794 make statements about the relying party. 796 The AAA framework provides transport for attributes. Statements made 797 about the client by the identity provider, statements made about the 798 relying party and other information are transported as attributes. 800 One demand that the AAA substrate makes of the upper layers is that 801 they must properly identify the end points of the communication. It 802 must be possible for the AAA client at the RP to determine where to 803 send each RADIUS or Diameter message. Without this requirement, it 804 would be the RP's responsibility to determine the identity of the 805 client on its own, without the assistance of an IdP. This 806 architecture makes use of the Network Access Identifier (NAI), where 807 the IdP is indicated by the realm component [I-D.ietf-radext-nai]. 808 The NAI is represented and consumed by the GSS-API layer as 809 GSS_C_NT_USER_NAME as specified in [RFC2743]. The GSS-API EAP 810 mechanism includes the NAI in the EAP Response/Identity message. 812 As of the time this document was published, no profiles for the use 813 of Diameter have been created. 815 2.1.2. Discovery and Rules Determination 817 While we are using the AAA protocols to communicate with the IdP, the 818 RP may have multiple federation substrates to select from. The RP 819 has a number of criteria that it will use in selecting which of the 820 different federations to use: 822 o The federation selected must be able to communicate with the IdP. 824 o The federation selected must match the business rules and 825 technical policies required for the RP security requirements. 827 The RP needs to discover which federation will be used to contact the 828 IdP. The first selection criterion used during discovery is going to 829 be the name of the IdP to be contacted. The second selection 830 criteria used during discovery is going to be the set of business 831 rules and technical policies governing the relationship; this is 832 called rules determination. The RP also needs to establish technical 833 trust in the communications with the IdP. 835 Rules determination covers a broad range of decisions about the 836 exchange. One of these is whether the given RP is permitted to talk 837 to the IdP using a given federation at all, so rules determination 838 encompasses the basic authorization decision. Other factors are 839 included, such as what policies govern release of information about 840 the client to the RP and what policies govern the RP's use of this 841 information. While rules determination is ultimately a business 842 function, it has significant impact on the technical exchanges. The 843 protocols need to communicate the result of authorization. When 844 multiple sets of rules are possible, the protocol must disambiguate 845 which set of rules are in play. Some rules have technical 846 enforcement mechanisms; for example in some federations 847 intermediaries validate information that is being communicated within 848 the federation. 850 At the time of writing no protocol mechanism has been specified to 851 allow a AAA client to determine whether a AAA proxy will indeed be 852 able to route AAA requests to a specific IdP. The AAA routing is 853 impacted by business rules and technical policies that may be quite 854 complex and at the present time, the route selection is based on 855 manual configuration. 857 2.1.3. Routing and Technical Trust 859 Several approaches to having messages routed through the federation 860 substrate are possible. These routing methods can most easily be 861 classified based on the mechanism for technical trust that is used. 862 The choice of technical trust mechanism constrains how rules 863 determination is implemented. Regardless of what deployment strategy 864 is chosen, it is important that the technical trust mechanism be able 865 to validate the identities of both parties to the exchange. The 866 trust mechanism must ensure that the entity acting as IdP for a given 867 NAI is permitted to be the IdP for that realm, and that any service 868 name claimed by the RP is permitted to be claimed by that entity. 869 Here are the categories of technical trust determination: 871 AAA Proxy: 872 The simplest model is that an RP is an AAA client and can send the 873 request directly to an AAA proxy. The hop-by-hop integrity 874 protection of the AAA fabric provides technical trust. An RP can 875 submit a request directly to the correct federation. 876 Alternatively, a federation disambiguation fabric can be used. 877 Such a fabric takes information about what federations the RP is 878 part of and what federations the IdP is part of and routes a 879 message to the appropriate federation. The routing of messages 880 across the fabric plus attributes added to requests and responses 881 provides rules determination. For example, when a disambiguation 882 fabric routes a message to a given federation, that federation's 883 rules are chosen. Name validation is enforced as messages travel 884 across the fabric. The entities near the RP confirm its identity 885 and validate names it claims. The fabric routes the message 886 towards the appropriate IdP, validating the name of the IdP in the 887 process. The routing can be statically configured. Alternatively 888 a routing protocol could be developed to exchange reachability 889 information about a given IdP and to apply policy across the AAA 890 fabric. Such a routing protocol could flood naming constraints to 891 the appropriate points in the fabric. 893 Trust Broker: 894 Instead of routing messages through AAA proxies, some trust broker 895 could establish keys between entities near the RP and entities 896 near the IdP. The advantage of this approach is efficiency of 897 message handling. Fewer entities are needed to be involved for 898 each message. Security may be improved by sending individual 899 messages over fewer hops. Rules determination involves decisions 900 made by trust brokers about what keys to grant. Also, associated 901 with each credential is context about rules and about other 902 aspects of technical trust including names that may be claimed. A 903 routing protocol similar to the one for AAA proxies is likely to 904 be useful to trust brokers in flooding rules and naming 905 constraints. 907 Global Credential: 908 A global credential such as a public key and certificate in a 909 public key infrastructure can be used to establish technical 910 trust. A directory or distributed database such as the Domain 911 Name System is used by the RP to discover the endpoint to contact 912 for a given NAI. Either the database or certificates can provide 913 a place to store information about rules determination and naming 914 constraints. Provided that no intermediates are required (or 915 appear to be required) and that the RP and IdP are sufficient to 916 enforce and determine rules, rules determination is reasonably 917 simple. However applying certain rules is likely to be quite 918 complex. For example if multiple sets of rules are possible 919 between an IdP and RP, confirming the correct set is used may be 920 difficult. This is particularly true if intermediates are 921 involved in making the decision. Also, to the extent that 922 directory information needs to be trusted, rules determination may 923 be more complex. 925 Real-world deployments are likely to be mixtures of these basic 926 approaches. For example, it will be quite common for an RP to route 927 traffic to a AAA proxy within an organization. That proxy could then 928 use any of the three methods to get closer to the IdP. It is also 929 likely that rather than being directly reachable, the IdP may have a 930 proxy on the edge of its organization. Federations will likely 931 provide a traditional AAA proxy interface even if they also provide 932 another mechanism for increased efficiency or security. 934 2.1.4. AAA Security 936 For the AAA framework there are two different places where security 937 needs to be examined. The first is the security that is in place for 938 the links in the AAA backbone being used. The second are the nodes 939 that form the AAA backbone. 941 The default link security for RADIUS is showing its age as it uses 942 MD5 and a shared secret to both obfuscate passwords and to provide 943 integrity on the RADIUS messages. While some EAP methods include the 944 ability to protect the client authentication credentials, the MSK 945 returned from the IdP to the RP is protected only by the RADIUS 946 security. In many environments this is considered to be 947 insufficient, especially as not all attributes are obfuscated and can 948 thus leak information to a passive eavesdropper. The use of RADIUS 949 with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] addresses these 950 attacks. The same level of security is included in the base Diameter 951 specifications. 953 2.1.5. SAML Assertions 955 For the traditional use of AAA frameworks, network access, an 956 affirmative response from the IdP can be sufficient to grant access. 957 In the ABFAB world, the RP may need to get significantly more 958 additional information about the client before granting access. 959 ABFAB therefore has a requirement that it can transport an arbitrary 960 set of attributes about the client from the IdP to the RP. 962 Security Assertions Markup Language (SAML) [OASIS.saml-core-2.0-os] 963 was designed in order to carry an extensible set of attributes about 964 a subject. Since SAML is extensible in the attribute space, ABFAB 965 has no immediate needs to update the core SAML specifications for our 966 work. It will be necessary to update IdPs that need to return SAML 967 assertions to RPs and for both the IdP and the RP to implement a new 968 SAML profile designed to carry SAML assertions in AAA. The new 969 profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. As SAML 970 statements will frequently be large, RADIUS servers and clients that 971 deal with SAML statements will need to implement RFC XXXX 972 [I-D.ietf-radext-radius-fragmentation] 974 There are several issues that need to be highlighted: 976 o The security of SAML assertions. 978 o Namespaces and mapping of SAML attributes. 980 o Subject naming of entities. 982 o Making multiple queries about the subject(s). 984 o Level of Assurance for authentication. 986 SAML assertions have an optional signature that can be used to 987 protect and provide origination of the assertion. These signatures 988 are normally based on asymmetric key operations and require that the 989 verifier be able to check not only the cryptographic operation, but 990 also the binding of the originators name and the public key. In a 991 federated environment it will not always be possible for the RP to 992 validate the binding, for this reason the technical trust established 993 in the federation is used as an alternate method of validating the 994 origination and integrity of the SAML Assertion. 996 Attributes in a SAML assertion are identified by a name string. The 997 name string is either assigned by the SAML issuer context or is 998 scoped by a namespace (for example a URI or object identifier (OID)). 999 This means that the same attribute can have different name strings 1000 used to identify it. In many, but not all, cases the federation 1001 agreements will determine what attributes and names can be used in a 1002 SAML statement. This means that the RP needs to map from the SAML 1003 issuer or federation name, type and semantic into the name, type and 1004 semantics that the policies of the RP are written in. In other cases 1005 the federation substrate, in the form of proxies, will modify the 1006 SAML assertions in transit to do the necessary name, type and value 1007 mappings as the assertion crosses boundaries in the federation. If 1008 the proxies are modifying the SAML Assertion, then they will remove 1009 any signatures on the SAML as changing the content of the SAML 1010 statement would invalidate the signature. In this case the technical 1011 trust is the required mechanism for validating the integrity of the 1012 assertion. (The proxy could re-sign the SAML assertion, but the same 1013 issues of establishing trust in the proxy would still exist.) 1014 Finally, the attributes may still be in the namespace of the 1015 originating IdP. When this occurs the RP will need to get the 1016 required mapping operations from the federation agreements and do the 1017 appropriate mappings itself. 1019 The RADIUS SAML RFC [I-D.ietf-abfab-aaa-saml] has defined a new SAML 1020 name format that corresponds to the NAI name form defined by RFC XXXX 1021 [I-D.ietf-radext-nai]. This allows for easy name matching in many 1022 cases as the name form in the SAML statement and the name form used 1023 in RADIUS or Diameter will be the same. In addition to the NAI name 1024 form, the document also defines a pair of implicit name forms 1025 corresponding to the Client and the Client's machine. These implicit 1026 name forms are based on the Identity-Type enumeration defined in TEAP 1027 [I-D.ietf-emu-eap-tunnel-method]. If the name form returned in a 1028 SAML statement is not based on the NAI, then it is a requirement on 1029 the EAP server that it validate that the subject of the SAML 1030 assertion, if any, is equivalent to the subject identified by the NAI 1031 used in the RADIUS or Diameter session. 1033 RADIUS has the ability to deal with multiple SAML queries for those 1034 EAP Servers which follow RFC 5080 [RFC5080]. In this case a State 1035 attribute will always be returned with the Access-Accept. The EAP 1036 client can then send a new Access-Request with the State attribute 1037 and the new SAML Request Multiple SAML queries can then be done by 1038 making a new Access-Request using the State attribute returned in the 1039 last Access-Accept to link together the different RADIUS sessions. 1041 Some RPs need to ensure that specific criteria are met during the 1042 authentication process. This need is met by using Levels of 1043 Assurance. The way a Level of Assurance is communicated to the RP 1044 from the EAP server is by the use of a SAML Authentication Request 1045 using the Authentication Profile from RFC XXX 1046 [I-D.ietf-abfab-aaa-saml] When crossing boundaries between different 1047 federations, either the policy specified will need to be shared 1048 between the two federations, the policy will need to be mapped by the 1049 proxy server on the boundary or the proxy server on the boundary will 1050 need to supply information the EAP server so that it can do the 1051 required mapping. If this mapping is not done, then the EAP server 1052 will not be able to enforce the desired Level of Assurance as it will 1053 not understand the policy requirements. 1055 2.2. Client To Identity Provider 1057 Looking at the communications between the client and the IdP, the 1058 following items need to be dealt with: 1060 o The client and the IdP need to mutually authenticate each other. 1062 o The client and the IdP need to mutually agree on the identity of 1063 the RP. 1065 ABFAB selected EAP for the purposes of mutual authentication and 1066 assisted in creating some new EAP channel binding documents for 1067 dealing with determining the identity of the RP. A framework for the 1068 channel binding mechanism has been defined in RFC 6677 [RFC6677] that 1069 allows the IdP to check the identity of the RP provided by the AAA 1070 framework with that provided by the client. 1072 2.2.1. Extensible Authentication Protocol (EAP) 1074 Traditional web federation does not describe how a client interacts 1075 with an identity provider for authentication. As a result, this 1076 communication is not standardized. There are several disadvantages 1077 to this approach. Since the communication is not standardized, it is 1078 difficult for machines to recognize which entity is going to do the 1079 authentication and thus which credentials to use and where in the 1080 authentication form that the credentials are to be entered. Humans 1081 have a much easier time to correctly deal with these problems. The 1082 use of browsers for authentication restricts the deployment of more 1083 secure forms of authentication beyond plaintext username and password 1084 known by the server. In a number of cases the authentication 1085 interface may be presented before the client has adequately validated 1086 they are talking to the intended server. By giving control of the 1087 authentication interface to a potential attacker, the security of the 1088 system may be reduced and phishing opportunities introduced. 1090 As a result, it is desirable to choose some standardized approach for 1091 communication between the client's end-host and the identity 1092 provider. There are a number of requirements this approach must 1093 meet. 1095 Experience has taught us one key security and scalability 1096 requirement: it is important that the relying party not get 1097 possession of the long-term secret of the client. Aside from a 1098 valuable secret being exposed, a synchronization problem can develop 1099 when the client changes keys with the IdP. 1101 Since there is no single authentication mechanism that will be used 1102 everywhere there is another associated requirement: The 1103 authentication framework must allow for the flexible integration of 1104 authentication mechanisms. For instance, some IdPs require hardware 1105 tokens while others use passwords. A service provider wants to 1106 provide support for both authentication methods, and other methods 1107 from IdPs not yet seen. 1109 These requirements can be met by utilizing standardized and 1110 successfully deployed technology, namely by the Extensible 1111 Authentication Protocol (EAP) framework [RFC3748]. Figure 3 1112 illustrates the integration graphically. 1114 EAP is an end-to-end framework; it provides for two-way communication 1115 between a peer (i.e. client or individual) through the EAP 1116 authenticator (i.e., relying party) to the back-end (i.e., identity 1117 provider). Conveniently, this is precisely the communication path 1118 that is needed for federated identity. Although EAP support is 1119 already integrated in AAA systems (see [RFC3579] and [RFC4072]) 1120 several challenges remain: 1122 o The first is how to carry EAP payloads from the end host to the 1123 relying party. 1125 o Another is to verify statements the relying party has made to the 1126 client, confirm these statements are consistent with statements 1127 made to the identity provider and confirm all of the above are 1128 consistent with the federation and any federation-specific policy 1129 or configuration. 1131 o Another challenge is choosing which identity provider to use for 1132 which service. 1134 The EAP method used for ABFAB needs to meet the following 1135 requirements: 1137 o It needs to provide mutual authentication of the client and IdP. 1139 o It needs to support channel binding. 1141 As of this writing, the only EAP method that meets these criteria is 1142 TEAP [I-D.ietf-emu-eap-tunnel-method] either alone (if client 1143 certificates are used) or with an inner EAP method that does mutual 1144 authentication. 1146 2.2.2. EAP Channel Binding 1148 EAP channel binding is easily confused with a facility in GSS-API 1149 also called channel binding. GSS-API channel binding provides 1150 protection against man-in-the-middle attacks when GSS-API is used as 1151 authentication inside some tunnel; it is similar to a facility called 1152 cryptographic binding in EAP. See [RFC5056] for a discussion of the 1153 differences between these two facilities. 1155 The client knows, in theory, the name of the RP that it attempted to 1156 connect to, however in the event that an attacker has intercepted the 1157 protocol, the client and the IdP need to be able to detect this 1158 situation. A general overview of the problem along with a 1159 recommended way to deal with the channel binding issues can be found 1160 in RFC 6677 [RFC6677]. 1162 Since that document was published, a number of possible attacks were 1163 found and methods to address these attacks have been outlined in 1164 [RFC7029]. 1166 2.3. Client to Relying Party 1168 The final set of interactions between the parties to consider are 1169 those between the client and the RP. In some ways this is the most 1170 complex set since at least part of it is outside the scope of the 1171 ABFAB work. The interactions between these parties include: 1173 o Running the protocol that implements the service that is provided 1174 by the RP and desired by the client. 1176 o Authenticating the client to the RP and the RP to the client. 1178 o Providing the necessary security services to the service protocol 1179 that it needs beyond authentication. 1181 o Deal with client re-authentication where desired. 1183 2.3.1. GSS-API 1185 One of the remaining layers is responsible for integration of 1186 federated authentication into the application. There are a number of 1187 approaches that applications have adopted for security. So, there 1188 may need to be multiple strategies for integration of federated 1189 authentication into applications. However, we have started with a 1190 strategy that provides integration to a large number of application 1191 protocols. 1193 Many applications such as SSH [RFC4462], NFS [RFC2203], DNS [RFC3645] 1194 and several non-IETF applications support the Generic Security 1195 Services Application Programming Interface [RFC2743]. Many 1196 applications such as IMAP, SMTP, XMPP and LDAP support the Simple 1197 Authentication and Security Layer (SASL) [RFC4422] framework. These 1198 two approaches work together nicely: by creating a GSS-API mechanism, 1199 SASL integration is also addressed. In effect, using a GSS-API 1200 mechanism with SASL simply requires placing some headers on the front 1201 of the mechanism and constraining certain GSS-API options. 1203 GSS-API is specified in terms of an abstract set of operations which 1204 can be mapped into a programming language to form an API. When 1205 people are first introduced to GSS-API, they focus on it as an API. 1206 However, from the prospective of authentication for non-web 1207 applications, GSS-API should be thought of as a protocol as well as 1208 an API. When looked at as a protocol, it consists of abstract 1209 operations such as the initial context exchange, which includes two 1210 sub-operations (gss_init_sec_context and gss_accept_sec_context). An 1211 application defines which abstract operations it is going to use and 1212 where messages produced by these operations fit into the application 1213 architecture. A GSS-API mechanism will define what actual protocol 1214 messages result from that abstract message for a given abstract 1215 operation. So, since this work is focusing on a particular GSS-API 1216 mechanism, we generally focus on protocol elements rather than the 1217 API view of GSS-API. 1219 The API view of GSS-API does have significant value as well, since 1220 the abstract operations are well defined, the set of information that 1221 a mechanism gets from the application is well defined. Also, the set 1222 of assumptions the application is permitted to make is generally well 1223 defined. As a result, an application protocol that supports GSS-API 1224 or SASL is very likely to be usable with a new approach to 1225 authentication including this one with no required modifications. In 1226 some cases, support for a new authentication mechanism has been added 1227 using plugin interfaces to applications without the application being 1228 modified at all. Even when modifications are required, they can 1229 often be limited to supporting a new naming and authorization model. 1230 For example, this work focuses on privacy; an application that 1231 assumes it will always obtain an identifier for the client will need 1232 to be modified to support anonymity, unlinkability or pseudonymity. 1234 So, we use GSS-API and SASL because a number of the application 1235 protocols we wish to federate support these strategies for security 1236 integration. What does this mean from a protocol standpoint and how 1237 does this relate to other layers? This means we need to design a 1238 concrete GSS-API mechanism. We have chosen to use a GSS-API 1239 mechanism that encapsulates EAP authentication. So, GSS-API (and 1240 SASL) encapsulates EAP between the end-host and the service. The AAA 1241 framework encapsulates EAP between the relying party and the identity 1242 provider. The GSS-API mechanism includes rules about how initiators 1243 and services are named as well as per-message security and other 1244 facilities required by the applications we wish to support. 1246 2.3.2. Protocol Transport 1248 The transport of data between the client and the relying party is not 1249 provided by GSS-API. GSS-API creates and consumes messages, but it 1250 does not provide the transport itself, instead the protocol using 1251 GSS-API needs to provide the transport. In many cases HTTP or HTTPS 1252 is used for this transport, but other transports are perfectly 1253 acceptable. The core GSS-API document [RFC2743] provides some 1254 details on what requirements exist. 1256 In addition we highlight the following: 1258 o The transport does not need to provide either confidentiality or 1259 integrity. After GSS-EAP has finished negotiation, GSS-API can be 1260 used to provide both services. If the negotiation process itself 1261 needs protection from eavesdroppers then the transport would need 1262 to provide the necessary services. 1264 o The transport needs to provide reliable transport of the messages. 1266 o The transport needs to ensure that tokens are delivered in order 1267 during the negotiation process. 1269 o GSS-API messages need to be delivered atomically. If the 1270 transport breaks up a message it must also reassemble the message 1271 before delivery. 1273 2.3.3. Reauthentication 1275 There are circumstances where the RP will want to have the client 1276 reauthenticate itself. These include very long sessions, where the 1277 original authentication is time limited or cases where in order to 1278 complete an operation a different authentication is required. GSS- 1279 EAP does not have any mechanism for the server to initiate a 1280 reauthentication as all authentication operations start from the 1281 client. If a protocol using GSS-EAP needs to support 1282 reauthentication that is initiated by the server, then a request from 1283 the server to the client for the reauthentiction to start needs to be 1284 placed in the protocol. 1286 Clients can re-use the existing secure connection established by GSS- 1287 API to run the new authentication in by calling GSS_Init_sec_context. 1288 At this point a full reauthentication will be done. 1290 3. Application Security Services 1292 One of the key goals is to integrate federated authentication into 1293 existing application protocols and where possible, existing 1294 implementations of these protocols. Another goal is to perform this 1295 integration while meeting the best security practices of the 1296 technologies used to perform the integration. This section describes 1297 security services and properties required by the EAP GSS-API 1298 mechanism in order to meet these goals. This information could be 1299 viewed as specific to that mechanism. However, other future 1300 application integration strategies are very likely to need similar 1301 services. So, it is likely that these services will be expanded 1302 across application integration strategies if new application 1303 integration strategies are adopted. 1305 3.1. Authentication 1307 GSS-API provides an optional security service called mutual 1308 authentication. This service means that in addition to the initiator 1309 providing (potentially anonymous or pseudonymous) identity to the 1310 acceptor, the acceptor confirms its identity to the initiator. 1311 Especially for the ABFAB context, this service is confusingly named. 1312 We still say that mutual authentication is provided when the identity 1313 of an acceptor is strongly authenticated to an anonymous initiator. 1315 RFC 2743, unfortunately, does not explicitly talk about what mutual 1316 authentication means. Within this document we therefore define 1317 mutual authentication as: 1319 o If a target name is configured for the initiator, then the 1320 initiator trusts that the supplied target name describes the 1321 acceptor. This implies both that appropriate cryptographic 1322 exchanges took place for the initiator to make such a trust 1323 decision, and that after evaluating the results of these 1324 exchanges, the initiator's policy trusts that the target name is 1325 accurate. 1327 o If no target name is configured for the initiator, then the 1328 initiator trusts that the acceptor name, supplied by the acceptor, 1329 correctly names the entity it is communicating with. 1331 o Both the initiator and acceptor have the same key material for 1332 per-message keys and both parties have confirmed they actually 1333 have the key material. In EAP terms, there is a protected 1334 indication of success. 1336 Mutual authentication is an important defense against certain aspects 1337 of phishing. Intuitively, clients would like to assume that if some 1338 party asks for their credentials as part of authentication, 1339 successfully gaining access to the resource means that they are 1340 talking to the expected party. Without mutual authentication, the 1341 server could "grant access" regardless of what credentials are 1342 supplied. Mutual authentication better matches this user intuition. 1344 It is important, therefore, that the GSS-EAP mechanism implement 1345 mutual authentication. That is, an initiator needs to be able to 1346 request mutual authentication. When mutual authentication is 1347 requested, only EAP methods capable of providing the necessary 1348 service can be used, and appropriate steps need to be taken to 1349 provide mutual authentication. While a broader set of EAP methods 1350 could be supported by not requiring mutual authentication, it was 1351 decided that the client needs to always have the ability to request 1352 it. In some cases the IdP and the RP will not support mutual 1353 authentication, however the client will always be able to detect this 1354 and make an appropriate security decision. 1356 The AAA infrastructure may hide the initiator's identity from the 1357 GSS-API acceptor, providing anonymity between the initiator and the 1358 acceptor. At this time, whether the identity is disclosed is 1359 determined by EAP server policy rather than by an indication from the 1360 initiator. Also, initiators are unlikely to be able to determine 1361 whether anonymous communication will be provided. For this reason, 1362 initiators are unlikely to set the anonymous return flag from 1363 GSS_Init_Sec_context (Section 4.2.1 in [RFC4178]. 1365 3.2. GSS-API Channel Binding 1367 [RFC5056] defines a concept of channel binding which is used prevent 1368 man-in-the-middle attacks. The channel binding works by taking a 1369 cryptographic value from the transport security and checks that both 1370 sides of the GSS-API conversation know this value. Transport Layer 1371 Security (TLS) [RFC5246] is the most common transport security layer 1372 used for this purpose. 1374 It needs to be stressed that RFC 5056 channel binding (also called 1375 GSS-API channel binding when GSS-API is involved) is not the same 1376 thing as EAP channel binding. GSS-API channel binding is used for 1377 detecting Man-In-The-Middle attacks. EAP channel binding is used for 1378 mutual authentication and acceptor naming checks. Details are 1379 discussed in the mechanisms specification [RFC7055]. A fuller 1380 description of the differences between the facilities can be found in 1381 RFC 5056 [RFC5056]. 1383 The use of TLS can provide both encryption and integrity on the 1384 channel. It is common to provide SASL and GSS-API with these other 1385 security services. 1387 One of the benefits that the use of TLS provides, is that client has 1388 the ability to validate the name of the server. However this 1389 validation is predicated on a couple of things. The TLS sessions 1390 needs to be using certificates and not be an anonymous session. The 1391 client and the TLS server need to share a common trust point for the 1392 certificate used in validating the server. TLS provides its own 1393 server authentication. However there are a variety of situations 1394 where this authentication is not checked for policy or usability 1395 reasons. When the TLS authentication is checked, if the trust 1396 infrastructure behind the TLS authentication is different from the 1397 trust infrastructure behind the GSS-API mutual authentication then 1398 confirming the end-points using both trust infrastructures is likely 1399 to enhance security. If the endpoints of the GSS-API authentication 1400 are different than the endpoints of the lower layer, this is a strong 1401 indication of a problem such as a man-in-the-middle attack. Channel 1402 binding provides a facility to determine whether these endpoints are 1403 the same. 1405 The GSS-EAP mechanism needs to support channel binding. When an 1406 application provides channel binding data, the mechanism needs to 1407 confirm this is the same on both sides consistent with the GSS-API 1408 specification. 1410 3.3. Host-Based Service Names 1412 IETF security mechanisms typically take a host name and perhaps a 1413 service, entered by a user, and make some trust decision about 1414 whether the remote party in the interaction is the intended party. 1415 This decision can be made by the use of certificates, pre-configured 1416 key information or a previous leap of trust. GSS-API has defined a 1417 relatively flexible name convention, however most of the IETF 1418 applications that use GSS-API (including SSH, NFS, IMAP, LDAP and 1419 XMPP) have chosen to use a more restricted naming convention based on 1420 the host name. The GSS-EAP mechanism needs to support host-based 1421 service names in order to work with existing IETF protocols. 1423 The use of host-based service names leads to a challenging trust 1424 delegation problem. Who is allowed to decide whether a particular 1425 host name maps to a specific entity? Possible solutions to this 1426 problem have been looked at. 1428 o The public-key infrastructure (PKI) used by the web has chosen to 1429 have a number of trust anchors (root certificate authorities) each 1430 of which can map any host name to a public key. 1432 o A number of GSS-API mechanisms, such as Kerberos [RFC1964], have 1433 split the problem into two parts. A new concept called a realm is 1434 introduced, the realm is responsible for host mapping within that 1435 realm. The mechanism then decides what realm is responsible for a 1436 given name. This is the approach adopted by ABFAB. 1438 GSS-EAP defines a host naming convention that takes into account the 1439 host name, the realm, the service and the service parameters. An 1440 example of GSS-API service name is "xmpp/foo@example.com". This 1441 identifies the XMPP service on the host foo in the realm example.com. 1442 Any of the components, except for the service name may be omitted 1443 from a name. When omitted, then a local default would be used for 1444 that component of the name. 1446 While there is no requirement that realm names map to Fully Qualified 1447 Domain Names (FQDN) within DNS, in practice this is normally true. 1448 Doing so allows for the realm portion of service names and the 1449 portion of NAIs to be the same. It also allows for the use of DNS in 1450 locating the host of a service while establishing the transport 1451 channel between the client and the relying party. 1453 It is the responsibility of the application to determine the server 1454 that it is going to communicate with; GSS-API has the ability to help 1455 confirm that the server is the desired server but not to determine 1456 the name of the server to use. It is also the responsibility of the 1457 application to determine how much of the information identifying the 1458 service needs to be validated by the ABFAB system. The information 1459 that needs to be validated is used to build up the service name 1460 passed into the GSS-EAP mechanism. What information is to be 1461 validated will depend on both what information was provided by the 1462 client, and what information is considered significant. If the 1463 client only cares about getting a specific service, then the host and 1464 realm that provides the service does not need to be validated. 1466 Applications may retrieve information about providers of services 1467 from DNS. Service Records (SRV) [RFC2782] and Naming Authority 1468 Pointer (NAPTR) [RFC3401] records are used to help find a host that 1469 provides a service; however the necessity of having DNSSEC on the 1470 queries depends on how the information is going to be used. If the 1471 host name returned is not going to be validated by EAP channel 1472 binding, because only the service is being validated, then DNSSEC 1473 [RFC4033] is not required. However, if the host name is going to be 1474 validated by EAP channel binding then DNSSEC needs to be use to 1475 ensure that the correct host name is validated. In general, if the 1476 information that is returned from the DNS query is to be validated, 1477 then it needs to be obtained in a secure manner. 1479 Another issue that needs to be addressed for host-based service names 1480 is that they do not work ideally when different instances of a 1481 service are running on different ports. If the services are 1482 equivalent, then it does not matter. However if there are 1483 substantial differences in the quality of the service that 1484 information needs to be part of the validation process. If one has 1485 just a host name and not a port in the information being validated, 1486 then this is not going to be a successful strategy. 1488 3.4. Additional GSS-API Services 1490 GSS-API provides per-message security services that can provide 1491 confidentiality and/or integrity. Some IETF protocols such as NFS 1492 and SSH take advantage of these services. As a result GSS-EAP needs 1493 to support these services. As with mutual authentication, per- 1494 message security services will limit the set of EAP methods that can 1495 be used to those that generate a Master Session Key (MSK). Any EAP 1496 method that produces an MSK is able to support per-message security 1497 services described in [RFC2743]. 1499 GSS-API provides a pseudo-random function. This function generates a 1500 pseudo-random sequence using the shared session key as the seed for 1501 the bytes generated. This provides an algorithm that both the 1502 initiator and acceptor can run in order to arrive at the same key 1503 value. The use of this feature allows for an application to generate 1504 keys or other shared secrets for use in other places in the protocol. 1505 In this regards, it is similar in concept to the TLS extractor (RFC 1506 5705 [RFC5705].). While no current IETF protocols require this, non- 1507 IETF protocols are expected to take advantage of this in the near 1508 future. Additionally, a number of protocols have found the TLS 1509 extractor to be useful in this regards so it is highly probable that 1510 IETF protocols may also start using this feature. 1512 4. Privacy Considerations 1514 ABFAB, as an architecture designed to enable federated authentication 1515 and allow for the secure transmission of identity information between 1516 entities, obviously requires careful consideration around privacy and 1517 the potential for privacy violations. 1519 This section examines the privacy related information presented in 1520 this document, summarizing the entities that are involved in ABFAB 1521 communications and what exposure they have to identity information. 1522 In discussing these privacy considerations in this section, we use 1523 terminology and ideas from [RFC6973]. 1525 Note that the ABFAB architecture uses at its core several existing 1526 technologies and protocols; detailed privacy discussion around these 1527 is not examined. This section instead focuses on privacy 1528 considerations specifically related to overall architecture and usage 1529 of ABFAB. 1531 +--------+ +---------------+ +--------------+ 1532 | Client | <---> | RP | <---> | AAA Client | 1533 +--------+ +---------------+ +--------------+ 1534 ^ 1535 | 1536 v 1537 +---------------+ +--------------+ 1538 | SAML Server | | AAA Proxy(s) | 1539 +---------------+ +--------------+ 1540 ^ ^ 1541 | | 1542 v v 1543 +------------+ +---------------+ +--------------+ 1544 | EAP Server | <---> | IdP | <---> | AAA Server | 1545 +------------+ +---------------+ +--------------+ 1547 Figure 4: Entities and Data Flow 1549 4.1. Entities and their roles 1551 Categorizing the ABFAB entities shown in the Figure 4 according to 1552 the taxonomy of terms from [RFC6973] the entities shown in Figure 4 1553 is somewhat complicated as during the various phases of ABFAB 1554 communications the roles of each entity changes. The three main 1555 phases of relevance are the Client to RP communication phase, the 1556 Client to IdP (via the Federation Substrate) phase, and the IdP to RP 1557 (via the Federation Substrate) phase. 1559 In the Client to RP communication phase, we have: 1561 Initiator: Client. 1563 Observers: Client, RP. 1565 Recipient: RP. 1567 In the Client to IdP (via the Federation Substrate) communication 1568 phase, we have: 1570 Initiator: Client. 1572 Observers: Client, RP, AAA Client, AAA Proxy(s), AAA Server, IdP. 1574 Recipient: IdP 1576 In the IdP to Relying party (via the Federation Substrate) 1577 communication phase, we have: 1579 Initiator: RP. 1581 Observers: IdP, AAA Server, AAA Proxy(s), AAA Client, RP. 1583 Recipient: IdP 1585 Eavesdroppers and Attackers can reside on any or all communication 1586 links between entities in Figure 4. 1588 The various entities in the system might also collude or be coerced 1589 into colluding. Some of the significant collusions to look at are: 1591 o If two RPs are colluding, they have the information available to 1592 both nodes. This can be analyzed as if a single RP was offering 1593 multiple services. 1595 o If an RP and a AAA proxy are colluding, then the trust of the 1596 system is broken as the RP would be able to lie about its own 1597 identity to the IdP. There is no known way to deal with this 1598 situation. 1600 o If multiple AAA proxies are colluding, it can be treated as a 1601 single node for analysis. 1603 The Federation Substrate consists of all of the AAA entities. In 1604 some cases the AAA Proxies entities may not exist as the AAA Client 1605 can talk directly to the AAA Server. Specifications such as the 1606 Trust Router Protocol [5] and RADIUS dynamic discovery 1607 [I-D.ietf-radext-dynamic-discovery] can be used to shorten the path 1608 between the AAA client and the AAA server (and thus stop these AAA 1609 Proxies from being Observers); however even in these circumstances 1610 there may be AAA Proxies in the path. 1612 In Figure 4 the IdP has been divided into multiple logical pieces, in 1613 actual implementations these pieces will frequently be tightly 1614 coupled. The links between these pieces provide the greatest 1615 opportunity for attackers and eavesdroppers to acquire information, 1616 however, as they are all under the control of a single entity they 1617 are also the easiest to have tightly secured. 1619 4.2. Privacy Aspects of ABFAB Communication Flows 1621 In the ABFAB architecture, there are a few different types of data 1622 and identifiers in use. The best way to understand them, and the 1623 potential privacy impacts of them, is to look at each phase of 1624 communication in ABFAB. 1626 4.2.1. Client to RP 1628 The flow of data between the client and the RP is divided into two 1629 parts. The first part consists of all of the data exchanged as part 1630 of the ABFAB authentication process. The second part consists of all 1631 of the data exchanged after the authentication process has been 1632 finished. 1634 During the initial communications phase, the client sends an NAI (see 1635 [I-D.ietf-radext-nai]) to the RP. Many EAP methods (but not all) 1636 allow for the client to disclose an NAI to RP the in a form that 1637 includes only a realm component during this communications phase. 1638 This is the minimum amount of identity information necessary for 1639 ABFAB to work - it indicates an IdP that the principal has a 1640 relationship with. EAP methods that do not allow this will 1641 necessarily also reveal an identifier for the principal in the IdP 1642 realm (e.g. a username). 1644 The data shared during the initial communication phase may be 1645 protected by a channel protocol such as TLS. This will prevent the 1646 leak of information to passive eavesdroppers, however an active 1647 attacker may still be able to setup as a man-in-the-middle. The 1648 client may not be able to validate the certificates (if any) provided 1649 by the service, deferring the check of the identity of the RP until 1650 the completion of the ABFAB authentication protocol (i.e., using EAP 1651 channel binding). 1653 The data exchanged after the authentication process can have privacy 1654 and authentication using the GSS-API services. If the overall 1655 application protocol allows for the process of re-authentication, 1656 then the same privacy implications as discussed in previous 1657 paragraphs apply. 1659 4.2.2. Client to IdP (via Federation Substrate) 1661 This phase sees a secure TLS tunnel initiated between the Client and 1662 the IdP via the RP and federation substrate. The process is 1663 initiated by the RP using the realm information given to it by the 1664 client. Once set up, the tunnel is used to send credentials to IdP 1665 to authenticate. 1667 Various operational information is transported between RP and IdP, 1668 over the AAA infrastructure, for example using RADIUS headers. As no 1669 end-to-end security is provided by AAA, all AAA entities on the path 1670 between the RP and IdP have the ability to eavesdrop on this 1671 information unless additional security measures are taken (such as 1672 the use of TLS for RADIUS [I-D.ietf-radext-dtls]). Some of this 1673 information may form identifiers or explicit identity information: 1675 o The Relying Party knows the IP address of the Client. It is 1676 possible that the Relying Party could choose to expose this IP 1677 address by including it in a RADIUS header such as Calling Station 1678 ID. This is a privacy consideration to take into account of the 1679 application protocol. 1681 o The EAP MSK is transported between the IdP and the RP over the AAA 1682 infrastructure, for example through RADIUS headers. This is a 1683 particularly important privacy consideration, as any AAA Proxy 1684 that has access to the EAP MSK is able to decrypt and eavesdrop on 1685 any traffic encrypted using that EAP MSK (i.e., all communications 1686 between the Client and RP). This problem can be mitigted by the 1687 application protocol setting up a secure tunnel between the Client 1688 and the RP and performing a cryptographic binding between the 1689 tunnel and EAP MSK. 1691 o Related to the above, the AAA server has access to the material 1692 necessary to derive the session key, thus the AAA server can 1693 observe any traffic encrypted between the Client and RP. This 1694 "feature" was chosen as a simplification and to make performance 1695 faster; if it was decided that this trade-off was not desirable 1696 for privacy and security reasons, then extensions to ABFAB that 1697 make use of techniques such as Diffie-Helman key exchange would 1698 mitigate against this. 1700 The choice of EAP method used has other potential privacy 1701 implications. For example, if the EAP method in use does not support 1702 trust anchors to enable mutual authentication, then there are no 1703 guarantees that the IdP is who it claims to be, and thus the full NAI 1704 including a username and a realm might be sent to any entity 1705 masquerading as a particular IdP. 1707 Note that ABFAB has not specified any AAA accounting requirements. 1708 Implementations that use the accounting portion of AAA should 1709 consider privacy appropriately when designing this aspect. 1711 4.2.3. IdP to RP (via Federation Substrate) 1713 In this phase, the IdP communicates with the RP informing it as to 1714 the success or failure of authentication of the user, and optionally, 1715 the sending of identity information about the principal. 1717 As in the previous flow (Client to IdP), various operation 1718 information is transported between IdP and RP over the AAA 1719 infrastructure, and the same privacy considerations apply. However, 1720 in this flow, explicit identity information about the authenticated 1721 principal can be sent from the IdP to the RP. This information can 1722 be sent through RADIUS headers, or using SAML 1723 [I-D.ietf-abfab-aaa-saml]. This can include protocol specific 1724 identifiers, such as SAML NameIDs, as well as arbitrary attribute 1725 information about the principal. What information will be released 1726 is controlled by policy on the Identity Provider. As before, when 1727 sending this through RADIUS headers, all AAA entities on the path 1728 between the RP and IdP have the ability to eavesdrop unless 1729 additional security measures are taken (such as the use of TLS for 1730 RADIUS [I-D.ietf-radext-dtls]). When sending this using SAML, as 1731 specified in [I-D.ietf-abfab-aaa-saml], confidentiality of the 1732 information should however be guaranteed as [I-D.ietf-abfab-aaa-saml] 1733 requires the use of TLS for RADIUS. 1735 4.3. Relationship between User and Entities 1737 o Between User and IdP - the IdP is an entity the user will have a 1738 direct relationship with, created when the organization that 1739 operates the entity provisioned and exchanged the user's 1740 credentials. Privacy and data protection guarantees may form a 1741 part of this relationship. 1743 o Between User and RP - the RP is an entity the user may or may not 1744 have a direct relationship with, depending on the service in 1745 question. Some services may only be offered to those users where 1746 such a direct relationship exists (for particularly sensitive 1747 services, for example), while some may not require this and would 1748 instead be satisfied with basic federation trust guarantees 1749 between themselves and the IdP). This may well include the option 1750 that the user stays anonymous with respect to the RP (though 1751 obviously never to the IdP). If attempting to preserve privacy 1752 through the mitigation of data minimization, then the only 1753 attribute information about individuals exposed to the RP should 1754 be that which is strictly necessary for the operation of the 1755 service. 1757 o Between User and Federation substrate - the user is highly likely 1758 to have no knowledge of, or relationship with, any entities 1759 involved with the federation substrate (not that the IdP and/or RP 1760 may, however). Knowledge of attribute information about 1761 individuals for these entities is not necessary, and thus such 1762 information should be protected in such a way as to prevent access 1763 to this information from being possible. 1765 4.4. Accounting Information 1767 Alongside the core authentication and authorization that occurs in 1768 AAA communications, accounting information about resource consumption 1769 may be delivered as part of the accounting exchange during the 1770 lifetime of the granted application session. 1772 4.5. Collection and retention of data and identifiers 1774 In cases where Relying Parties are not required to identify a 1775 particular individual when an individual wishes to make use of their 1776 service, the ABFAB architecture enables anonymous or pseudonymous 1777 access. Thus data and identifiers other than pseudonyms and 1778 unlinkable attribute information need not be stored and retained. 1780 However, in cases where Relying Parties require the ability to 1781 identify a particular individual (e.g. so they can link this identity 1782 information to a particular account in their service, or where 1783 identity information is required for audit purposes), the service 1784 will need to collect and store such information, and to retain it for 1785 as long as they require. Deprovisioning of such accounts and 1786 information is out of scope for ABFAB, but obviously for privacy 1787 protection any identifiers collected should be deleted when they are 1788 no longer needed. 1790 4.6. User Participation 1792 In the ABFAB architecture, by its very nature users are active 1793 participants in the sharing of their identifiers as they initiate the 1794 communications exchange every time they wish to access a server. 1795 They are, however, not involved in control of the set of information 1796 related to them that transmitted from the IdP to RP for authorization 1797 purposes; rather, this is under the control of policy on the IdP. 1798 Due to the nature of the AAA communication flows, with the current 1799 ABFAB architecture there is no place for a process of gaining user 1800 consent for the information to be released from IdP to RP. 1802 5. Security Considerations 1804 This document describes the architecture for Application Bridging for 1805 Federated Access Beyond Web (ABFAB) and security is therefore the 1806 main focus. Many of the items that are security considerations have 1807 already been discussed in the Privacy Considerations section. 1808 Readers should be sure to read that section as well. 1810 There are many places in this document where TLS is used. While in 1811 some places (i.e. client to RP) anonymous connections can be used, it 1812 is very important that TLS connections within the AAA infrastructure 1813 and between the client and the IdP be fully authenticated and, if 1814 using certificates, that revocation be checked as well. When using 1815 anonymous connections between the client and the RP, all messages and 1816 data exchanged between those two entities will be visible to an 1817 active attacker. In situations where the client is not yet on the 1818 net, the status_request extension [RFC6066] can be used to obtain 1819 revocation checking data inside of the TLS protocol. Clients also 1820 need to get the Trust Anchor for the IdP configured correctly in 1821 order to prevent attacks, this is a hard problem in general and is 1822 going to be even harder for kiosk environments. 1824 Selection of the EAP methods to be permitted by clients and IdPs is 1825 important. The use of a tunneling method such as TEAP 1826 [I-D.ietf-emu-eap-tunnel-method] allows for other EAP methods to be 1827 used while hiding the contents of those EAP exchanges from the RP and 1828 the AAA framework. When considering inner EAP methods the 1829 considerations outlined in [RFC7029] about binding the inner and 1830 outer EAP methods needs to be considered. Finally, one wants to have 1831 the ability to support channel binding in those cases where the 1832 client needs to validate that it is talking to the correct RP. 1834 In those places where SAML statements are used, RPs will generally be 1835 unable to validate signatures on the SAML statement, either because 1836 it is stripped off by the IdP or because it is unable to validate the 1837 binding between the signer, the key used to sign and the realm 1838 represented by the IdP. For these reasons it is required that IdPs 1839 do the necessary trust checking on the SAML statements and RPs can 1840 trust the AAA infrastructure to keep the SAML statement valid. 1842 When a pseudonym is generated as a unique long term identifier for a 1843 client by an IdP, care must be taken in the algorithm that it cannot 1844 easily be reverse engineered by the service provider. If it can be 1845 reversed then the service provider can consult an oracle to determine 1846 if a given unique long term identifier is associated with a different 1847 known identifier. 1849 6. IANA Considerations 1851 This document does not require actions by IANA. 1853 7. Acknowledgments 1855 We would like to thank Mayutan Arumaithurai, Klaas Wierenga and Rhys 1856 Smith for their feedback. Additionally, we would like to thank Eve 1857 Maler, Nicolas Williams, Bob Morgan, Scott Cantor, Jim Fenton, Paul 1858 Leach, and Luke Howard for their feedback on the federation 1859 terminology question. 1861 Furthermore, we would like to thank Klaas Wierenga for his review of 1862 the pre-00 draft version. 1864 8. References 1866 8.1. Normative References 1868 [RFC2743] Linn, J., "Generic Security Service Application Program 1869 Interface Version 2, Update 1", RFC 2743, January 2000. 1871 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1872 "Remote Authentication Dial In User Service (RADIUS)", RFC 1873 2865, June 2000. 1875 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1876 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1877 3748, June 2004. 1879 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1880 Dial In User Service) Support For Extensible 1881 Authentication Protocol (EAP)", RFC 3579, September 2003. 1883 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1884 Authentication Protocol (EAP) Application", RFC 4072, 1885 August 2005. 1887 [RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 1888 Extensible Authentication Protocol", RFC 7055, December 1889 2013. 1891 [I-D.ietf-abfab-aaa-saml] 1892 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 1893 Profiles, Name Identifier Format, and Confirmation Methods 1894 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 1895 progress), February 2014. 1897 [I-D.ietf-radext-nai] 1898 DeKok, A., "The Network Access Identifier", draft-ietf- 1899 radext-nai-06 (work in progress), June 2014. 1901 [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding 1902 Support for Extensible Authentication Protocol (EAP) 1903 Methods", RFC 6677, July 2012. 1905 8.2. Informative References 1907 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1908 "Diameter Base Protocol", RFC 6733, October 2012. 1910 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 1911 6749, October 2012. 1913 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1914 Morris, J., Hansen, M., and R. Smith, "Privacy 1915 Considerations for Internet Protocols", RFC 6973, July 1916 2013. 1918 [I-D.ietf-radext-radius-fragmentation] 1919 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 1920 Millan, G., Lopez, D., and A. DeKok, "Support of 1921 fragmentation of RADIUS packets", draft-ietf-radext- 1922 radius-fragmentation-06 (work in progress), April 2014. 1924 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1925 1964, June 1996. 1927 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 1928 Specification", RFC 2203, September 1997. 1930 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., 1931 and R. Hall, "Generic Security Service Algorithm for 1932 Secret Key Transaction Authentication for DNS (GSS-TSIG)", 1933 RFC 3645, October 2003. 1935 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 1936 "Generic Security Service Application Program Interface 1937 (GSS-API) Authentication and Key Exchange for the Secure 1938 Shell (SSH) Protocol", RFC 4462, May 2006. 1940 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1941 Security Layer (SASL)", RFC 4422, June 2006. 1943 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1944 Channels", RFC 5056, November 2007. 1946 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1947 Dial In User Service (RADIUS) Implementation Issues and 1948 Suggested Fixes", RFC 5080, December 2007. 1950 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1951 Layer Security (TLS)", RFC 5705, March 2010. 1953 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1954 Service Application Program Interface (GSS-API) Mechanisms 1955 in Simple Authentication and Security Layer (SASL): The 1956 GS2 Mechanism Family", RFC 5801, July 2010. 1958 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1959 "Transport Layer Security (TLS) Encryption for RADIUS", 1960 RFC 6614, May 2012. 1962 [OASIS.saml-core-2.0-os] 1963 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1964 "Assertions and Protocol for the OASIS Security Assertion 1965 Markup Language (SAML) V2.0", OASIS Standard saml- 1966 core-2.0-os, March 2005. 1968 [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible 1969 Authentication Protocol (EAP) Mutual Cryptographic 1970 Binding", RFC 7029, October 2013. 1972 [I-D.ietf-emu-eap-tunnel-method] 1973 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1974 "Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap- 1975 tunnel-method-10 (work in progress), January 2014. 1977 [I-D.ietf-radext-dtls] 1978 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- 1979 ietf-radext-dtls-13 (work in progress), July 2014. 1981 [I-D.ietf-radext-dynamic-discovery] 1982 Winter, S. and M. McCauley, "NAI-based Dynamic Peer 1983 Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf- 1984 radext-dynamic-discovery-11 (work in progress), March 1985 2014. 1987 [WS-TRUST] 1988 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, 1989 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS 1990 Standard ws-trust-200902, February 2009, . 1993 [NIST-SP.800-63] 1994 Burr, W., Dodson, D., and W. Polk, "Electronic 1995 Authentication Guideline", NIST Special Publication 1996 800-63, April 2006. 1998 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 1999 Simple and Protected Generic Security Service Application 2000 Program Interface (GSS-API) Negotiation Mechanism", RFC 2001 4178, October 2005. 2003 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2004 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2006 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2007 specifying the location of services (DNS SRV)", RFC 2782, 2008 February 2000. 2010 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 2011 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 2013 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2014 Rose, "DNS Security Introduction and Requirements", RFC 2015 4033, March 2005. 2017 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 2018 Extension Definitions", RFC 6066, January 2011. 2020 Authors' Addresses 2021 Josh Howlett 2022 JANET(UK) 2023 Lumen House, Library Avenue, Harwell 2024 Oxford OX11 0SG 2025 UK 2027 Phone: +44 1235 822363 2028 Email: Josh.Howlett@ja.net 2030 Sam Hartman 2031 Painless Security 2033 Email: hartmans-ietf@mit.edu 2035 Hannes Tschofenig 2036 ARM Ltd. 2037 110 Fulbourn Rd 2038 Cambridge CB1 9NJ 2039 Great Britain 2041 Email: Hannes.tschofenig@gmx.net 2042 URI: http://www.tschofenig.priv.at 2044 Eliot Lear 2045 Cisco Systems GmbH 2046 Richtistrasse 7 2047 Wallisellen, ZH CH-8304 2048 Switzerland 2050 Phone: +41 44 878 9200 2051 Email: lear@cisco.com 2053 Jim Schaad 2054 Soaring Hawk Consulting 2056 Email: ietf@augustcellars.com