idnits 2.17.00 (12 Aug 2021) /tmp/idnits2173/draft-mrw-abfab-multihop-fed-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 4, 2011) is 3973 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-lear-abfab-arch (ref. 'I-D.lear-abfab-arch') -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 2 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 July 4, 2011 5 Expires: January 5, 2012 7 Application Bridging for Federation Beyond the Web (ABFAB) Multihop 8 Federations 9 draft-mrw-abfab-multihop-fed-00.txt 11 Abstract 13 This document describes a mechanism for establishing trust across a 14 multihop federation within the Application Bridging for Federation 15 Beyond the Wed (ABFAB) framework. 17 This document introduces a new ABFAB entity, the Trust Router. Trust 18 Routers exchange information about the availability of Trust Paths 19 across a multiphop federation. They can be queried by a Relying 20 Party to obtain the best Trust Path to reach a RADIUS or RADSEC 21 server in a given realm. They also provide temporary identities that 22 can be used by a Relying Party to traverse a Trust Path. 24 This document is currently limited to discussing a proposed mechanism 25 to achieve a multihop federation in the ABFAB framework. Later 26 versions of this document (or companion documents) will describe the 27 protocols and algorithms in more detail. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 6, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Multihop Federation Example . . . . . . . . . . . . . . . . 3 65 1.2. Trust Router Overview . . . . . . . . . . . . . . . . . . . 5 66 1.3. Multiple Federations . . . . . . . . . . . . . . . . . . . 6 67 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . . 6 70 5. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Temporary Identity Request . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 This document describes a mechanism for establishing trust across a 83 multihop federation within the Application Bridging for Federation 84 Beyond the Web (ABFAB) framework [I-D.lear-abfab-arch]. 86 In a single hop federation, every Relying Party has a pre-existing 87 relationship with every Identity Provider. In other words, each 88 Relying Party is pre-configured with the required information and 89 credentials to reach a RADIUS or RADSEC server in every Identity 90 Provider withing the federation. In a multihop federation, this is 91 not necessary, as a Relying Party can reach the RADIUS or RADSEC 92 server within a previously unknown Identity Provider by traversing a 93 transitive Trust Path across a federation. 95 This document introduces a new ABFAB entity, the Trust Router. Trust 96 Routers exchange information about the availability of Trust Paths 97 across a multihop federation. They can be queried by a Relying Party 98 to obtain the best Trust Path to reach a RADIUS or RADSEC server in a 99 given realm. They also provide temporary identities that can be used 100 by a Relying Party to traverse a Trust Path. 102 This document is currently limited to discussing a proposed mechanism 103 to achieve a multihop federation in the ABFAB framework. Later 104 versions of this document (or companion documents) will describe the 105 protocols and algorithms in more detail. 107 1.1. Multihop Federation Example 109 The diagram below shows an example of a successful authentication 110 exchange in a multihop federation: 112 Realm D | Realm C | Realm B | Realm A 114 | | | 115 +----------+ +----------+ +----------+ +----------+ 116 | Trust | | | Trust | | | Trust | | | Trust | 117 | Router D |<-1->| Router C |<-1->| Router B |<-1->| Router A | 118 +----------+ | +----------+ | +----------+ | +----------+ 119 ^ ^ ^ ^ 120 | | | | | | | 121 | | +---4------------ + | 122 | | | | | | | 123 | +----------------5---------------+ | 3 124 | | | | | | | 125 +----------------6------------------------------+ | | | 126 | | | | | | | 127 v v v v 128 +----------+ | | | +----------+ 129 | Identity |<---------7--------------------------->| Relying | 130 | Provider | | | | | Party | 131 +----------+ +----------+ 132 ^ | | | ^ 133 1 | 134 | | | | | 135 v | 136 +----------+ | | | | 137 | Subject |----------2---------------------------------+ 138 | | | | | 139 +----------+ 140 | | | 142 A multihop federation exchange matching the above diagram can be 143 summarized as follows: 145 1. We start with a single federation including 4 realms, each 146 containing a single Trust Router. The Trust Routers are peered, 147 such that their interconnections form a multihop federation. 149 2. A Subject (with an identity in Realm D) attempts to access a 150 service provided by a Relying Party in Realm A. 152 3. The Relying Party does not have direct access to a RADIUS or 153 RADSEC server in Realm D that it can use to authenticate the 154 user, so it asks its local Trust Router for a Trust Path to reach 155 Realm D. The Trust Router in Realm A returns the path 156 A->B(T)->C(T)->D(T)->D(R), which indicates that the Relying Party 157 should use the Trust Routers in Realms B, C and D to reach a 158 RADIUS or RADSEC server in Realm D, which could then be used to 159 authenticate the user. 161 4. The Relying Party contacts a trust router in Realm B (using its 162 permanent identity in Realm A), and requests the creation of a 163 temporary identity that can be used to communicate with the Trust 164 Router in Realm C. 166 5. The Relying Party then contacts the Trust Router in Realm C 167 (using the temporary identity returned in the previous step), and 168 asks for a temporary identity that can be used to communicate 169 with the Trust Router in realm D. 171 6. The Relying Party then contacts the Trust Router in Realm D 172 (using the temporary identity returned in the previous step), and 173 asks the Trust Router to provision an identity that it can use to 174 speak to the RADIUS or RADSEC server in Realm D (which is part of 175 Realm D's Identity Provider). 177 7. At this point, the Relying Party can reach the Subject's Identity 178 provider, and the rest of the ABFAB exchange can continue, as 179 described in [I-D.lear-abfab-arch]. 181 1.2. Trust Router Overview 183 As shown in the example above, the Trust Router performs three 184 functions: 186 o Trust Routers peer with one another to exchange information about 187 available Trust Paths. This information is exchanged between 188 Trust Routers using the Trust Router Protocol. The Trust Router 189 Protocol is described in more detail in a later section. 191 o The Relying Party queries a local Trust Router to determine the 192 best path to use to reach the destination realm. This exchange is 193 referred to as a Trust Path Query, and is described in more detail 194 in a later section. 196 o The Relying Party will ask each Trust Router along the path to 197 provision a temporary identity that can be used to gain access to 198 the next step in the path. This mechanism is called a Temporary 199 Identity Request, and is described in more detail in a later 200 section. 202 1.3. Multiple Federations 204 The example above shows a number of Trust Routers running within a 205 single federation. In real deployments, it is expected that some 206 Trust Routers will serve multiple federations. Also, it is possible 207 that services will be available across multiple federations, or that 208 Subjects with have identities within multiple federations. In order 209 to support these cases, a Policy Regime (essentially a federation 210 name) is passed as a parameter or attribute in many of the exchanges 211 shown above, typically paired with the name of a realm. Trust 212 Routers will, conceptually, calculate a separate tree for each Policy 213 Regime, and the Trust Path provided to the Relying Party will consist 214 of Trust Links within a single Policy Regime (or federation). 216 2. Requirements Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 3. Terminology 224 o Trust Router 226 o Trust Path 228 o Trust Link 230 o Trust Router Protocol 232 o Policy Regime 234 4. Trust Router Protocol 236 The Trust Router Protocol has some similarities to an Internet 237 Routing Protocol, with some exceptions: Links are unidirectional, and 238 realm names are not hierarchical, so no aggregation is possible. 239 Also, it is necessary to associate a set of information with each 240 link that can be used for filtering and tree computation, including: 241 the cost of the link, the Policy Regime associated with the link, and 242 information indicating how/if the link should be propagated across 243 the federation. 245 Current thinking is that we will use a BGP-based algorithm for 246 computation of the local tree at each Trust Router, and that we will 247 communicate a similar set of information between Trust Routers as 248 would be communicated between Internet Routers running BGP. However, 249 BGP does not have the security properties that would be desirable in 250 a Trust Router Protocol, so we will not use the standard BGP 251 encapsulation. 253 5. Trust Path Query 255 A Trust Path Query is generated by a Relying Party to request a Trust 256 Path to reach a specific realm within a given Policy Regime. If 257 possible, the Trust Router will reply with a Trust Path that consists 258 of one or more Trust Router steps and ends with a RADIUS or RADSEC 259 server within the Identify Provider for the indicated realm. The 260 returned Trust Path represents the best path for the Relying Party to 261 use to reach an Identity Provider in the destination realm. 263 The Trust Path Query is initiated by the Relying Party, and the 264 initial query message will contain the destination realm and Policy 265 Regime. 267 When a Trust Path Query is received by a Trust Router, the router 268 will first authenticate the Relying Party, and check local policy 269 information to determine whether or not to reply. 271 Assuming that the Relying Party is successfully authenticated and the 272 request passes local policy checks, the Trust Router will search it's 273 tree of Trust Path information to determine whether a Trust Path 274 exists that will reach the destination Realm within the indicated 275 regime. If so, the shortest/best Trust Path will be returned to the 276 Relying Party. 278 A Trust Path will consist of a list of steps, each of which will 279 contain: The type of the step (Trust Router, RADIUS or RADSEC), the 280 Policy Regime associated with each step, information needed to reach 281 the indicated Trust Router or server (domain name or IP address), and 282 any special attributes associated with that step. 284 6. Temporary Identity Request 286 A Temporary Identity Request is issued by a Relying Party in order to 287 obtain an identity that can be used to traverse each step in the 288 Trust Path. When a Temporary Identity is requested, a Trust Router 289 will provision a new identity in its local RADIUS infrastructure that 290 can be used by the Relying Party to communicate with the Trust Router 291 or RADIUS/RADSEC server that represents the next step in the Trust 292 Path. 294 These Temporary Identities will have a finite lifetime and, when 295 authenticated, will include a RADIUS attribute indicating that they 296 were generated based on a Temporary Identity Request. This attribute 297 will inlcude the chain of identities that preceeded the current 298 identity in the traversal of the Trust Path. 300 The details of how these messages will be encoded has not yet been 301 determined. However, it is expected that, for each Trust Router step 302 in the Trust Path, the following actions will take place: 304 1. The Relying Party will send a Temporary Identity Request message 305 to the Trust Router, containing the identity of the next step in 306 the Trust Path, the destination realm that it is trying to reach, 307 and the Policy Regime in use. This request will be sent using 308 the identity that the Trust Router obtained from the previous 309 step in the Trust Path (or the Trust Router's permanent identity 310 in it's home realm, if this is the first step). 312 2. The Trust Router will authenticate the Relying Party. 314 3. If the authentication is successful, the Trust Router will check 315 local policy to determine whether it should provision an identity 316 for the Relying Party for the indicated purpose (details of this 317 check may be implementation dependent). 319 4. If the request passes any policy requirements, the Trust Router 320 will provision a temporary identity for the Relying Party within 321 the Trust Router's local realm that can be used to access the 322 next-hop Trust Router or RADIUS/RADSEC server in the Trust Path. 324 7. Security Considerations 326 TBD. 328 8. IANA Considerations 330 There are no IANA actions required for this document at this time. 332 9. Acknowledgements 334 This document was written using the xml2rfc tool described in RFC 335 2629 [RFC2629]. 337 10. References 338 10.1. Normative References 340 [I-D.lear-abfab-arch] 341 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 342 "Application Bridging for Federated Access Beyond Web 343 (ABFAB) Architecture", draft-lear-abfab-arch-02 (work in 344 progress), March 2011. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 10.2. Informative References 351 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 352 June 1999. 354 Author's Address 356 Margaret Wasserman 357 Painless Security 358 356 Abbott Street 359 North Andover, MA 01845 360 USA 362 Phone: +1 781 405 7464 363 Email: mrw@painless-security.com 364 URI: http://www.painless-security.com