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