idnits 2.17.00 (12 Aug 2021) /tmp/idnits16754/draft-mrw-abfab-multihop-fed-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2011) is 3849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-howlett-radsec-knp (ref. 'I-D.howlett-radsec-knp') ** Downref: Normative reference to an Informational draft: draft-lear-abfab-arch (ref. 'I-D.lear-abfab-arch') == Outdated reference: A later version (-02) exists of draft-mrw-abfab-trust-router-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 2, 2012 Nokia Siemens Networks 6 October 30, 2011 8 Multihop Federations for Application Bridging for Federation Beyond the 9 Web (ABFAB) 10 draft-mrw-abfab-multihop-fed-02.txt 12 Abstract 14 This document describes a mechanism for establishing trust across a 15 multihop federation within the Application Bridging for Federation 16 Beyond the Web (ABFAB) framework. 18 This document introduces a new entity, the Trust Router. Trust 19 Routers exchange information about the availability of Trust Paths 20 across a multihop federation. They can be queried by a Relying Party 21 to obtain the best Trust Path to reach an Identity Provider. They 22 also provide temporary identities that can be used by a Relying Party 23 to traverse a Trust Path. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 2, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Multihop Federation Example . . . . . . . . . . . . . . . . . 7 63 5. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . 9 64 6. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Temporary Identity Request . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12 71 11.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 12 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 12.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 This document describes a mechanism for establishing trust across a 80 multihop federation within the Application Bridging for Federation 81 Beyond the Web (ABFAB) framework [I-D.lear-abfab-arch]. 83 This document introduces a new ABFAB entity, the Trust Router. Trust 84 Routers exchange information about the availability of Trust Paths 85 across a multihop federation. ABFAB entity, the Trust Router. These 86 paths are used by RPs to contruct transitive trust chains across a 87 federation to a AAA Server (a RADIUS, RadSec or Diameter Server) 88 within a target IdP. 90 A Trust Path consists of one or more Trust Links. A Trust Link is an 91 assertion that a specific Trust Router is capable of providing 92 temporary identies that can be used to access another entity in the 93 ABFAB system. At this point, we anticipate that there will be two 94 types of Trust Links in ABFAB: a Trust Link that indicates that one 95 Trust Router can be used to reach another Trust Router, and a Trust 96 Link that indicates that a Trust Router can be used to reach a AAA 97 Server. The first type (Trust Router Links) are shown as A->B(T), 98 which indicates that the Trust Router in realm A can create 99 identities to reach the trust router in Realm B. The second type (AAA 100 Links) are shown as A->B(R), to indicate that a trust router in Realm 101 A can be used to reach a AAA Server in Realm B. 103 Trust Routers exchange information about available Trust Links within 104 a federation, and each Trust Router maintains a tree of available 105 paths to reach all of the IdPs within the federation that can be 106 reached from the local realm of the Trust Router. 108 When an RP receives a request from a party within a realm that not 109 known directly to the RP, the RP will query its local Trust Router to 110 obtain the best Trust Path to reach that IdP. Note that we use the 111 term 'best' here to highlight that there may well be multiple paths 112 to reach an IdP from a given RP, and the selection of the 'best' path 113 may involve several factors in addition to the length of the path, 114 such as security and privacy practices, or monetary costs. 116 The RP will traverse the Trust Path obtained from it's local Trust 117 Router. At each step, the RP will request a temporary identity to 118 access the next step in the Trust Path, constructing a transitive 119 chain of trust to a AAA Server within the target IdP. 121 To summarize, the Trust Router performs three functions: 123 o Trust Routers peer with other Trust Routers to exchange 124 information about available Trust Links, and Trust Paths. This 125 information is exchanged between Trust Routers using the Trust 126 Router Protocol. The Trust Router Protocol is described in more 127 detail in [I-D.mrw-abfab-trust-router]. 129 o Trust Routers respond to queries from Relying Parties to make 130 information about Trust Paths available. This exchange is 131 referred to as a Trust Path Query Protocol, which is described in 132 Section 6. 134 o To follow the Trust Path across a federation, the RP will use KNP 135 to ask each Trust Router along the path to provision a temporary 136 identity that can be used to gain access to the next step in the 137 path. This mechanism is called a Temporary Identity Request, 138 which is described in [I-D.howlett-radsec-knp]. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 This document introduces the following terms: 148 Trust Router: 150 This is a logical ABFAB entity that exchanges information about 151 Trust Paths that Relying Parties can use to create transtitive 152 chains of trust across multihop ABFAB federations. 154 Trust Link: 156 A Trust Link is an assertion that a given Trust Router is capable 157 of providing a temporary identity to communicate with another 158 ABFAB entity (either another Trust Router, or a AAA Server within 159 an IdP). 161 Trust Path: 163 A Trust Path is a concatenation of Trust Links that can be used by 164 an RP to contruct a transitive trust chain across a federation to 165 a target IdP. 167 Trust Router Protocol: 169 The Trust Router Protocol is the mechanism used by two Trust 170 Routers to exchange information about Trust Links and Trust Paths. 172 Community of Interest: 174 A Community of Interest defines a group of Services and IdPs that 175 have agreed to cooperate to provide access to a specific set of 176 services only to those users within a particular community. 177 Communities of Interest can be layered on top of the base Trust 178 Router infrastructure to allow selected access to IdPs that have 179 joined a specific group, or agreed to a set of community-specific 180 policies. 182 The terms Identity Provider (IdP), Relying Party (RP), Subject, and 183 Federation are used as defined in [I-D.lear-abfab-arch]. 185 3. Motivation 187 Figure 1 shows an example federation where the Relying Party Foo, has 188 established relationships with various Identity Providers. 190 +---------------+ 191 | Identity | 192 | Provider | `.. 193 | Example-A.org | `-._ 194 +---------------+ `.. 195 `-._ 196 +---------------+ `._ +-----------+ 197 | Identity | `- | Relying | 198 | Provider | ------------------ | Party Foo | 199 | Example-B.org | _.- +-----------+ 200 +---------------+ _,-' 201 ,,' 202 +---------------+ _.-' o 203 | Identity | _,-' \|/ 204 | Provider | ' | 205 | Example-C.org | / \ 206 +---------------+ Subject 208 Figure 1: One-to-many Federation Example 210 When an RP receives a request to access a protected resource (or 211 requires authentication and authorization for other purposes) the 212 request includes a realm name that indicates the IdP the Subject has 213 selected for this exchange. Offering the Subject the ability to 214 choose among many different IdPs is necessary because a Subject may 215 have, and want to maintain, uncorrelated identities in several 216 different realms within a single federation (i.e. work, school, 217 social networking, etc.). However, this also places a burden on the 218 RPs to establish and maintain business agreements and exchange 219 security credentials with a potentially large number of Identity 220 Providers. 222 In order for a single-hop federation to function, each IdP needs to 223 maintain business agreements and exchange credentials with every RP 224 that its Subjects are authorized to access. Figure 2, shows the 225 likely outcome, which is that a single-hop federation will come to 226 resemble a dense mesh topology. 228 +---------------+ 229 | Identity | 230 | Provider |-.._ 231 | Example-A.org |`. ``-.._ 232 +---------------+ `-. ``-..__ +-----------+ 233 `. `--.| Relying | 234 +---------------+ `. __..--| Party Foo | 235 | Identity | __:.--'' .-'+-----------+ 236 | Provider |_..--'' `. .-' 237 | Example-B.org | .-'. 238 +---------------+ .' '. +-----------+ 239 .-' -. | Relying | 240 +---------------+ .-' `-.| Party Bar | 241 | Identity |.-' ____....---''+-----------+ 242 | Provider |.----''' 243 | Example-C.org | 244 +---------------+ o 245 \|/ 246 | 247 / \ 248 Subject 250 Figure 2: Mesh Federation Example 252 As discussed in section 2.1.1 of [I-D.lear-abfab-arch], as the number 253 of organizations involved in a ABFAB federation increase, static 254 configuration may not scale sufficiently. Also, using a Trust Broker 255 to establish keys between entities near the RP and entities near the 256 IDP with improve the security and privacy of an ABFAB federation. 257 Figure 3 shows the structure of a federation where each IdP and RP 258 has a single connection to the Trust Router infrastructure. 260 +---------------+ 261 | Identity | 262 | Provider |\ 263 | Example-A.org | `. 264 +---------------+ \ +-----------+ 265 \ .-'| Relying | 266 +---------------+ `. +---------------+ .' | Party Foo | 267 | Identity | \| Trust |.-' +-----------+ 268 | Provider |........| Broker | 269 | Example-B.org | /| |`-. 270 +---------------+ .' +---------------+ `. +-----------+ 271 / `-.| Relying | 272 +---------------+ / | Party Bar | 273 | Identity | .' +-----------+ 274 | Provider |/ O 275 | Example-C.org | \|/ 276 +---------------+ | 277 / \ 278 Subject 280 Figure 3: Federation Broker 282 To improve the operational scalability and security of large ABFAB 283 federations, this document proposes a Trust Broker solution 284 consisting of of a set of Trust Routers, as described in this 285 document, and the Key Negotiation Protocol (KNP), as described in 286 [I-D.howlett-radsec-knp]. 288 4. Multihop Federation Example 290 The diagram below shows an example of a successful exchange in a 291 multihop federation using the Trust Router Protocol and KNP: 293 Realm D | Realm C | Realm B | Realm A 295 | | | 296 +----------+ +----------+ +----------+ +----------+ 297 | Trust | | | Trust | | | Trust | | | Trust | 298 | Router D |<-1->| Router C |<-1->| Router B |<-1->| Router A | 299 +----------+ | +----------+ | +----------+ | +----------+ 300 ^ ^ ^ ^ 301 | | | | | | | 302 | | +---4------------ + | 303 | | | | | | | 304 | +----------------5---------------+ | 3 305 | | | | | | | 306 +----------------6------------------------------+ | | | 307 | | | | | | | 308 v v v v 309 +----------+ | | | +----------+ 310 | Identity |<---------7--------------------------->| Relying | 311 | Provider | | | | | Party | 312 +----------+ +----------+ 313 ^ | | | ^ 314 1 | 315 | | | | | 316 v | 317 +----------+ | | | | 318 | Subject |----------2---------------------------------+ 319 | | | | | 320 +----------+ 321 | | | 323 A multihop federation exchange matching the above diagram can be 324 summarized as follows: 326 1. We start with a single federation including four realms, each 327 containing a single Trust Router. The Trust Routers are peered, 328 such that their interconnections form a multihop federation. 330 2. A Subject (with an identity in Realm D) attempts to access a 331 service provided by a Relying Party in Realm A. 333 3. The Relying Party does not have direct access to a AAA Server in 334 Realm D that it can use to authenticate the Subject, so it asks 335 its local Trust Router for a Trust Path to reach Realm D. The 336 Trust Router in Realm A returns the path 337 A->B(T)->C(T)->D(T)->D(R), which indicates that the Relying Party 338 should use the Trust Routers in Realms B, C and D to reach a AAA 339 Server in Realm D, which could then be used to authenticate the 340 Subject. 342 4. The Relying Party contacts a Trust Router in Realm B (using its 343 permanent identity in Realm A), and requests the creation of a 344 temporary identity that can be used to communicate with the Trust 345 Router in Realm C. 347 5. The Relying Party then contacts the Trust Router in Realm C 348 (using the temporary identity returned in the previous step), and 349 asks for a temporary identity that can be used to communicate 350 with the Trust Router in realm D. 352 6. The Relying Party then contacts the Trust Router in Realm D 353 (using the temporary identity returned in the previous step), and 354 asks the Trust Router to provision an identity that it can use to 355 speak to the AAA Server in Realm D (which is part of Realm D's 356 Identity Provider). 358 7. At this point, the Relying Party can reach the Subject's Identity 359 provider, and the rest of the ABFAB exchange can continue, as 360 described in [I-D.lear-abfab-arch]. 362 5. Trust Router Protocol 364 Trust Routers use the Trust Router Protocol to exchange information 365 about available Trust Links, and Trust Paths across a federation. 367 The Trust Router Protocol differs from an Internet Routing Protocol 368 in a couple of important ways: 370 o Trust Links are unidirectional. It can not be assumed that the 371 fact that a Trust Router in Realm A is authorized to create 372 temporary identities to access a Trust Router in realm B, that the 373 opposite is also true (A -> B(T) does not imply B->A(T)). 375 o Realm names are not necessarily hierarchical. Although 376 aggregation might be possible as a later optimization, the ability 377 to aggregate realm names based on shared roots is not currently 378 assumed. 380 In addition to the existence of the links themselves, Trust Links 381 have a set of associated attributes that can be used for filtering 382 and tree computation, including: 384 o The cost of the link. 386 o Any security and privacy characteristics associated with the link. 388 o Information indicating how/if the link should be propagated across 389 the federation. 391 Current thinking is that we will use a BGP-based algorithm for 392 computation of the local tree at each Trust Router, and that we will 393 communicate a similar set of information between Trust Routers as 394 would be communicated between Internet Routers running BGP. 396 6. Trust Path Query 398 A Trust Path Query is generated by a RP to request a Trust Path to 399 reach a specific realm within a given Community of Interest. If 400 possible, the Trust Router will reply with a Trust Path that consists 401 of zero or more Trust Router steps and ends with a AAA Server (or a 402 path of multiple AAA Servers) within the IdP for the indicated realm. 404 The Trust Path Query is initiated by the RP, and the initial query 405 message will contain the destination realm and Community of Interest. 407 When a Trust Path Query is received by a Trust Router, the router 408 will first authenticate the RP, and check local policy information to 409 determine whether or not to reply. 411 Assuming that the RP is successfully authenticated and the request 412 passes local policy checks, the Trust Router will search it's tree of 413 Trust Path information to determine whether a Trust Path exists that 414 will reach the destination Realm within the indicated Community of 415 Interest. If so, the shortest/best Trust Path will be returned to 416 the Relying Party. 418 A Trust Path will consist of a list of steps, each of which will 419 contain: The type of the step (Trust Router or AAA Server), the 420 Community of Interest associated with each step, information needed 421 to reach the indicated Trust Router or server (domain name or IP 422 address), and any special attributes associated with that step. 424 7. Temporary Identity Request 426 A Temporary Identity Request is issued by a Relying Party in order to 427 obtain an identity that can be used to traverse each step in the 428 Trust Path. When a Temporary Identity is requested, a Trust Router 429 will provision a new identity in its local AAA infrastructure that 430 can be used by the Relying Party to communicate with the Trust Router 431 or AAA Server that represents the next step in the Trust Path. 433 Current thinking is that KNP will be used as the protocol mechanism 434 for these requests. 436 These Temporary Identities will have a finite lifetime and, when 437 authenticated, will include a Radius Attribute/Diameter AVP 438 indicating that they were generated based on a Temporary Identity 439 Request. This attribute will inlcude the chain of identities that 440 preceeded the current identity in the traversal of the Trust Path. 442 The details of how these messages will be encoded has not yet been 443 determined. However, it is expected that, for each Trust Router step 444 in the Trust Path, the following actions will take place: 446 1. The Relying Party will send a Temporary Identity Request message 447 to the Trust Router, containing the identity of the next step in 448 the Trust Path, the destination realm that it is trying to reach, 449 and the Community of Interest in use. This request will be sent 450 using the identity that the Trust Router obtained from the 451 previous step in the Trust Path (or the Trust Router's permanent 452 identity in it's home realm, if this is the first step). 454 2. The Trust Router will authenticate the Relying Party. 456 3. If the authentication is successful, the Trust Router will check 457 local policy to determine whether it should provision an identity 458 for the Relying Party for the indicated purpose (details of this 459 check may be implementation dependent). 461 4. If the request passes any policy requirements, the Trust Router 462 will provision a temporary identity for the Relying Party within 463 the Trust Router's local realm that can be used to access the 464 next-hop Trust Router or AAA Server in the Trust Path. 466 8. Security Considerations 468 This document describes an architecture for the establishment of 469 transitive trust across an ABFAB federation. It describes, at a high 470 level, the entities and protocols that will be used to establish 471 transitive trust, but it does not describe the actual protocols that 472 will be used in detail. Those details, and the detailed Security 473 Considerations associated with them are described in separate 474 documents. 476 It is important to note that the trust established using a transitive 477 trust mechanism described in this document will only be as good as 478 the weakest link in the transitive trust chain. To service the needs 479 of a highly sensitive Community of Interest, stringent criteria must 480 be applied to join the Community, sites must be monitored to ensure 481 that they are adhering to the Community's standards, and local policy 482 may be required to ensure that the chain of trust does not traverse 483 any untrusted, or insufficiently trusted, realms. 485 9. IANA Considerations 487 There are no IANA actions required for this document. 489 10. Acknowledgements 491 This document was written using the xml2rfc tool described in RFC 492 2629 [RFC2629]. 494 11. Change Log 496 11.1. Changes from -01 to -02 498 o Changed the term "Policy Regime" to "Community of Interest" 499 throughout the document. 501 o Replaced explicit references to RADIUS and Diameter servers with 502 more generic references to AAA Servers. 504 o Minor editorial changes. 506 11.2. Changes from -00 to -01 508 o Editorial changes, and additional text throughout document. 510 12. References 512 12.1. Normative References 514 [I-D.howlett-radsec-knp] 515 Howlett, J. and S. Hartman, "Key Negotiation Protocol 516 (KNP)", draft-howlett-radsec-knp-02 (work in progress), 517 October 2011. 519 [I-D.lear-abfab-arch] 520 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 521 "Application Bridging for Federated Access Beyond Web 522 (ABFAB) Architecture", draft-lear-abfab-arch-02 (work in 523 progress), March 2011. 525 [I-D.mrw-abfab-trust-router] 526 Wasserman, M., "Application Bridging for Federation Beyond 527 the Web (ABFAB) Trust Router Protocol", 528 draft-mrw-abfab-trust-router-00 (work in progress), 529 October 2011. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 12.2. Informative References 536 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 537 June 1999. 539 Authors' Addresses 541 Margaret Wasserman 542 Painless Security 543 356 Abbott Street 544 North Andover, MA 01845 545 USA 547 Phone: +1 781 405 7464 548 Email: mrw@painless-security.com 549 URI: http://www.painless-security.com 551 Hannes Tschofenig 552 Nokia Siemens Networks 553 Linnoitustie 6 554 Espoo 02600 555 Finland 557 Phone: +358 (50) 4871445 558 Email: Hannes.Tschofenig@gmx.net 559 URI: http://www.tschofenig.priv.at