idnits 2.17.1 draft-schaad-trust-router-problem-01.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 (May 30, 2013) is 3983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-abfab-arch-06 == Outdated reference: A later version (-15) exists of draft-ietf-radext-dynamic-discovery-06 == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Informational May 30, 2013 5 Expires: December 01, 2013 7 Trust Router Problem Statement 8 draft-schaad-trust-router-problem-01.txt 10 Abstract 12 There are a number of problems with using the current AAA framework 13 for doing access control, this document looks at a number of these 14 issues and poses some questions about how to create a new trust 15 router system. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 01, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. AAA Routing Problems . . . . . . . . . . . . . . . . . . 3 54 2.2. AAA Security Issues . . . . . . . . . . . . . . . . . . . 4 55 2.3. X.509 Security Issues . . . . . . . . . . . . . . . . . . 5 56 3. Trust Router Objectives . . . . . . . . . . . . . . . . . . . 6 57 4. Entities in the system . . . . . . . . . . . . . . . . . . . 6 58 4.1. End User . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Service Provider . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Community of Registration (COR) . . . . . . . . . . . . . 7 61 4.3.1. Atomic CORs . . . . . . . . . . . . . . . . . . . . . 7 62 4.3.2. Mesh CORs . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3.3. Release of Information . . . . . . . . . . . . . . . 8 64 4.4. Communities of Interest (COI) . . . . . . . . . . . . . . 8 65 4.4.1. Security Issues . . . . . . . . . . . . . . . . . . . 10 66 4.5. Trust Backbone . . . . . . . . . . . . . . . . . . . . . 10 67 4.6. Trusted Introducers . . . . . . . . . . . . . . . . . . . 11 68 4.6.1. Trusted Introducer Initiator . . . . . . . . . . . . 11 69 4.6.2. Trusted Introducer Router . . . . . . . . . . . . . . 11 70 4.6.3. Trusted Introducer Target . . . . . . . . . . . . . . 11 71 5. Communication Flows . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. COI Distribution . . . . . . . . . . . . . . . . . . . . 12 73 5.2. COR Connectivity . . . . . . . . . . . . . . . . . . . . 12 74 5.3. AAA Entity Introduction . . . . . . . . . . . . . . . . . 12 75 6. Putting it all together . . . . . . . . . . . . . . . . . . . 13 76 6.1. Scenario - One Trust Backbone . . . . . . . . . . . . . . 13 77 6.2. Scenario - Three Trust Backbones . . . . . . . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 10.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 The following document is a product of my diseased mind as opposed to 89 the deceased minds of the Janet Group or Painless Security. 90 Specifically, this document uses terms that are defined in 91 [I-D.howlett-abfab-trust-router-ps] and in 92 [I-D.mrw-abfab-trust-router] but in completely different ways. One 93 therefor needs to be clear about which document one is looking at 94 when referring to these documents as oppose to this one. 96 The ABFAB architecture as outlined by [I-D.ietf-abfab-arch] provides 97 the necessary information for understanding the basic needs of ABFAB. 98 As outlined in that document, there are still number of worries in 99 terms of trying to implement the ABFAB architecture in the real 100 world. These worries come out of the way that some of the basic 101 components used by ABFAB where orignally designed to be used, and the 102 way that they are actually used in the AFBAB architecture. This 103 document examines some of the perceived short comings of those 104 component and provides a basic paradigm that is believed to address 105 those short comings. In this document a number of issues that any 106 solution adopting that paradigm is also going need to be addressed 107 are outlined. 109 This write up of the problem statement reflects to some degree a 110 proposed solution to the problem, however it does so in the most 111 general terms possible. Some pieces are fixed by the ABFAB 112 architecture, such as the use of RADIUS clients and servers for user 113 authentication, however other pieces are intentionally left nebulous 114 (what does the inter AAA server routing look like). A basic picture 115 of how the different pieces are put together can be found in Figure 116 1. 118 2. Justification 120 This section outlines a number of different areas where components of 121 the current architecture are considered to be deficient. 123 2.1. AAA Routing Problems 125 The fist selection of problems that are examined are related to how 126 routing is done in the AAA architecture. These issues are, in many 127 cases, specific to the RADIUS version of AAA. The problems may or 128 may not also apply to Diameter, however as ABFAB as currently 129 deployed is focused on RADIUS rather than Diameter these issues still 130 need to be addressed. 132 o There is expected to be a large amount of data that is passed 133 between the EAP server and the EAP client as part of the 134 validation process. This is a logical consequence of the fact 135 that we will be using TEAP [I-D.ietf-emu-eap-tunnel-method] which 136 is based on TLS and thus can contain large certificates, CRLs and 137 other cryptographic information. Hosting this on top of UDP is 138 not going to be successful in the long run, the amount of 139 fragmenting both at the UDP level and at the RADIUS and EAP levels 140 will lead to poor performance in many cases. The use of TLS/TCP 141 [RFC6613][RFC6614], with it's session state and recovery will help 142 this problem. 144 o Routing needs to be static rather than dynamic from end-to-end. 145 Given that the routing is based on the conditions required for the 146 set of messages under consideration, the policy enforcement needs 147 to be consistent, allowing for routing of each packet in the 148 stream independently means that enforcement of constraints cannot 149 be consistently enforced. Again, the use of TLS/TCP helps if one 150 assumes that sessions are kept up for longer 152 o Adding and removing destinations from the routing tables is hard 153 as it must be done for every entity on the backbone. 155 o There is currently no way to apply policy to the routing of items 156 based on such things as the LOA desired by the message. 158 2.2. AAA Security Issues 160 The next selection of problems to be examined are the security issues 161 related to the AAA routing infrastructure is deficient to meet the 162 needs of a truly secure system. 164 The following represents a set of reasons why the current RADIUS 165 security is not adequate. 167 o Link level security is the current state of the art for RADIUS 168 servers, however it is frequently missing on individual links and 169 it is not possible for either end point to verify that link level 170 security is provided over the entirety of the system. 172 o Link level security is currently configured on each hop in the 173 link. It would be preferable that the security could be 174 "centrally" configured. 176 o Different message need to be routed differently based on the level 177 of security needed for the message. This is currently addressed 178 by either having all of the links configured to be at the highest 179 level of security or for there to be multiple links between 180 different entities based on the different levels. Since the 181 configuration is done on each pair of RADIUS entities, there is no 182 easy way for a third party auditing service to either add or 183 remove entities from the backbone based on an evaluation of their 184 security practices. 186 o RADIUS security is monolithic in concept, this means that one 187 cannot readily have multiple different communities with different 188 needs use a single RADIUS network. The network would need to be 189 configured at the highest needs, but that may not be is not 190 necessary for all of the communities. 192 RADIUS dynamic discovery [I-D.ietf-radext-dynamic-discovery] has 193 attempted to address some of these issues, however based on the 194 discussions on the RADEXT mailing list this has not always been 195 successful. Some of the issues found are: 197 o Setting up the correct security infrastructure based on X.509 198 certificates is still too high of a bar for some RADIUS server 199 operators. This means that people are setting up proxy servers 200 which are discoverer and these then talk to the actual RADIUS 201 server. 203 o There are problems with how naming of entities should be done and 204 what name checking needs to be done when comparing a RADIUS server 205 with the contents of an X.509 certificate. This becomes even more 206 complex when there are proxy servers in the path. 208 o The use of unsecured DNS records to do the lookup from the 209 original AAA domain name to a server name is problematic as there 210 is no reason to believe that this cannot be easily attacked by DNS 211 cache poisoning. 213 2.3. X.509 Security Issues 215 Finally we look at the some issues with X.509 security. There is no 216 way when using the ABFAB architecture to avoid the possibility of 217 using X.509 certificates. The EAP method TEAP uses TLS, and thus 218 will likely use an X.509 certificate, even if it is self-signed. 220 With in the community of ABFAB architecture proponents, is it an 221 article of faith that the PKIX architecture [RFC5280] is broken and 222 cannot be trusted. There are many components that go into this 223 statement, however it is as much a statement of religion as it is of 224 reality for the proponents of the ABFAB architecture. That being 225 said, there are a number of reasons why this position can be taken. 227 o Correct and usable name formats are very difficult to get correct. 228 This is especially true when proxying needs to be done for. As an 229 example see [I-D.ietf-radext-dynamic-discovery] for why this is 230 the case. 232 o Revocation processing and checking of PKIX systems is frequently 233 missing. 235 o Trust Anchors are a problem when looking in these scenarios. One 236 cannot generally have a single trust anchor due to political a 237 trust problems, however having a multiplicity of trust points can 238 yield problems when trying to decide who and why trust can be 239 placed. Either one is dependent on a general purpose trust system 240 (i.e., the current set of commercial Certificate Authorities) or 241 one needs to setup a special purpose CA for the requirements of 242 the current infrastructure. 244 o Attribute certificates [RFC5755] have never been readily adopted 245 as a way to convey attributes. 247 o Provisioning and restricting of trust anchors is proving 248 problematic in many cases. This can even be seen in terms of how 249 one should provision a clients computer with the appropriate trust 250 anchor for doing EAP validation in the case of using TEAP. 252 3. Trust Router Objectives 254 There are three main objectives for this work: 256 1. Publish the location of AAA servers in a secure manner to all AAA 257 clients within a trusted network. 259 2. Create a mechanism to allow for creation of sub-communities 260 within a AAA system. 262 3. Create a temporary "short-lived" direct link with a DH or ECDH 263 key pair for validation between an AAA client/proxy (near the 264 service) and the AAA server for the user (near the IDP). The 265 link created will carry policy information for governing the 266 release of information from the IDP to the AAA client. 268 4. Entities in the system 270 This section documents a number of basic entities that are 271 participating in the trust router system. Some of these entities are 272 included for completeness as they are part of the ABFAB architecture, 273 but are not direct participants in the Trust Router architecture. 275 4.1. End User 277 The end user is the entity that is requesting a service from the 278 service provider. 280 The end user has no pre-existing relationship with the service 281 provider. The end user does have a pre-existing relationship with an 282 IDP. The relationship with the IDP will include the ability for a 283 set of cryptographic credentials to be used to validate the user to 284 the IDP. This validation is done using one or more EAP methods. 286 4.2. Service Provider 287 The Service Provider is used by the end user to get some service. 288 The Service Provider has a pre-exsting relationship with a local AAA 289 proxy. The Service Provider itself will be a AAA client. 291 There is an issue with the current AAA system that needs to be 292 examined, the ABFAB architecture requires that the AAA proxy that the 293 SP connects to validate information about the SP. With a large 294 number of SPs being added to and removed from the AAA network, we 295 need to look for a way of using the AAA architecture itself to do the 296 validation of the SP rather than using the configuration of public 297 keys in the AAA proxy. This can be done with a X.509 certificate 298 architecture, however this would not match the overall principle of 299 not using X.509 certificates. The use of EAP and a AAA server to do 300 the authentication and attribute checking would make the 301 administration of SPs and End Users similar which would reduce 302 administrative problems. 304 4.3. Community of Registration (COR) 306 At its most basic level, a Community of Registration (COR) consists 307 of a set of entities and an IDP that can authenticate those entities. 308 A COR operator has a specific set of requirements about how entities 309 are to be initially identified, how they are to be authenticated each 310 time they appear and what information is to released to third parties 311 upon request. A COR operator may have a multiplicity of such 312 requirements based on internal policies and requests from service 313 providers. A Level Of Assurance (LOA) is one of the pieces of 314 information that a COR would have in this set of requirements. 316 4.3.1. Atomic CORs 318 An Atomic COR consists of a single database of registration. It may 319 consist of one or more on-line presences, but each on-line presence 320 is required to produce exactly the same results. 322 4.3.2. Mesh CORs 324 The following is a potential feature and may not make it into the 325 final output. 327 It makes sense to allow for CORs to be aggregated together into a 328 single unit, thus for example the University of Washington could run 329 a mesh COR that comprises of the CORs for the undergraduate school, 330 the law school, the medical school, etc.. 332 There is a known privacy issue with allowing the existence of mesh 333 CORs, multiple correlated queries can be constructed that can leak 334 information about which COR an entity is associated, even if that 335 information is not directly provided to the SP. 337 4.3.3. Release of Information 339 The main function of a COR in the ABFAB architecture is to release 340 information about the end user to the service provider. The smallest 341 amount of information that can be provided is to say that the COR 342 does or does not recognized the end user. At the larger end of 343 infomration provided, the COR can responde to an SP request with a 344 large number of attributes about the end user as part of a SAML 345 statement. 347 The decision of releasing attributes about the end user is an 348 important issue, the least possible amount of information should 349 generally be released. If the user can participate in the decision 350 to release information then that should be encouraged, such 351 participation is not always possible. The release of information 352 should always be in accordance with the policy of the IDP and, in 353 many cases, should be an auditible function. 355 There is a need to look at how policies are to be provided for both 356 external review and auditing. It is not clear that this is a strong 357 requirement ala the CPS framework that PKIX created [RFC3647]. 358 However, the more standardized and machine readable this information 359 is, the simpler it would be for tools to be able to process and look 360 at this information. This may be an issue when starting to look at 361 how things such as attributes are mapped when crossing trust 362 boundaries. 364 4.4. Communities of Interest (COI) 366 One of the goals of this work is to allow for the formation of closed 367 subsets of users and services within the overall trust architecture 368 that is created. These closed subsets are called Communities of 369 Interest. 371 A COI is defined by the following properties: 373 o The name of the COI. COIs are expected to be uniquely named 374 within some domain. The domain that is used and how that is 375 expressed needs to be determined. 377 o Version control on the COI. This may be some type of 378 monotonically increasing value or a time of last update indicator. 379 If there are multiple possible configuration locations in the 380 system then a time value may be better as collisions on a counter 381 could collide. In any event there may be a requirement for 382 detection of update collisions. 384 o The set of users that can participate in the COI. The set of 385 users are defined by the use of one or more attribute. These 386 attributes can include the name of the user (expressed as an NAI), 387 the COR for a group of users (i.e. everyone at the University of 388 Washington) roles, departments and so forth. The method of 389 expressing the attributes needs to be defined, however one of the 390 issues that needs to be dealt with is that fact that the 391 attributes are frequently dependent on the COR that issues them. 392 This means that attributes will either need to be defined by the 393 COI, the trust backbone, a global attribute definier or have the 394 ability to some type of mapping of attribute names. 396 o The set of security properties that are required for users. Even 397 when a user might be able to participate in a COI, the location of 398 the user and the methods of authentication used by the user may 399 rule out participating in the COI at a given moment. The security 400 proprities represent a set of dynamic properpties based on how the 401 user is attached to the network rather than relatively static 402 properties that the COR will maintain over time. The security 403 properites may also represent tasks that the COR is requried to 404 perform during the authentication. An example would be that a COI 405 requires a specific LOA to be used in authenticating the user. 406 This is a property of the COI and not a property of the user. 408 o The set of service providers that are permitted to use the COI. 409 SPs may be specified by name or other attributes in a similar 410 manner to that done for users. 412 o The set of security properties that are required for SPs. This is 413 similar to the set of security proprieties that are required for 414 users. 416 o The set of security properties that are required for the Trusted 417 Introducers. This is similar to the set of security properties 418 that are required for users. 420 COIs are managed in a central location rather than being distributed 421 through the system. It is presumed that the management of COIs is 422 connected to the management of Trust Introducers, but that is an 423 issue that will need to be resolved by the protocol. 425 It can be seen that ability to make COIs be hierarchical would be a 426 convenient practice. As an example, a COI could be maintained for 427 every physical location of the University of Washington. It would 428 then be able to group those COIs in a hierarchical manner grouping by 429 larger and larger locations until the entire school is covered. This 430 means that if a new user or service provider were added to one of the 431 leafs in the tree then it automatically propagates into all of the 432 nodes above it in the tree without additional administrative work. 434 4.4.1. Security Issues 436 There are a number of security issues that will need to be addressed: 438 o Should a COI be able to coop a COR without the consent of the COR. 440 o Depending on how COIs are defined, they can be turned into oracles 441 about the members of CORs. 443 o If an SP can use multiple COIs, then it needs a way to select 444 which COI to use for any single transaction. The choice of the 445 COI then needs to be provided to the Trust Backbone. 447 o There are no provisions for the existence of a COI to be published 448 to either SPs or users. Does there need to be a method for doing 449 so? 451 o When COIs are propagated around the trust backbone, does the data 452 about them need to be kept confidential. While the existence of a 453 COI is probably not a big security risk, knowledge of the security 454 parameters and entity attributes about the users of the COI may 455 constitute a security risk. 457 4.5. Trust Backbone 459 The trust backbone is a generic term that is being used to designate 460 the network of systems which are responsible for connecting the 461 different CORs together. A trust backbone can come in two flavors: 462 Intra backbones are maintained by a single entity and operate at a 463 single level of security. Inter backbones consist of multiple intra 464 backbones with special systems that operate on the boundaries between 465 the different intra backbone to mediate the differences in security 466 practices. 468 Information flows both within a single backbone and between different 469 backbones. Within a single backbone, all information flows 470 unmodified. However when information crosses between backbones it is 471 frequently modified to deal with differences in policies or simply 472 prevented from passing across the boundary. 474 A trust backbone will normally have multiple CORs in it. A trust 475 backbone is the location where COIs are introduced into the system. 477 4.6. Trusted Introducers 479 The concept of a trusted introducer has been around for a long time. 480 This is the basic method by which webs of trust are created. The 481 basic model that is to be used will be based on a web of trust and 482 trusted introducers. 484 The trusted introducer subsystem is the method where a direct link is 485 going to be established between the AAA proxy near the SP and the AAA 486 server for the end user. 488 4.6.1. Trusted Introducer Initiator 490 The Trusted Introducer Initiator (TII) is expected to be integrated 491 into the AAA proxy that is adjacent to the SP. The TII is the 492 location where the introduction protocol is kicked off. The TII is 493 required to do the necessary enforcement of the SP identity and 494 attributes with the security properties of the backbone and the COI 495 selected by the SP. 497 4.6.2. Trusted Introducer Router 499 The Trusted Introducer Router (TIR) is the basic routing element of 500 the trusted introducer network. TIRs come in two flavors, internal 501 and boundary TIRs. The internal TIR is a simple thing that just does 502 routing and the necessary security enforcements. A boundary TIR on 503 the other hand is responsible to dealing with all of the security 504 problems that are needed with crossing a security boundary. 506 4.6.3. Trusted Introducer Target 508 A Trusted Introducer Target (TIT) is expected to be integrated into 509 the AAA server. The TIT is the target of the trusted initiator 510 protocol. The TIT is required to do the necessary enforcement of 511 security parameters that are imposed by the AAA server and then 512 return the necessary information for the AAA proxy associated with 513 the TII to setup a direct TLS link between it and the AAA server. 515 Once a TLS link between the AAA server and the AAA proxy has been 516 established, it may be used for more than one AAA protocol exchange. 517 This means that it is a requirement that the AAA server apply all of 518 the security information setup on the TLS link be enforced on each 519 AAA protocol exchange. 521 5. Communication Flows 522 There are going to be three different sets of information that will 523 need to flow through the system. We examine each of those flows and 524 the properties that are needed. 526 5.1. COI Distribution 528 The system will need to distribute information about all COIs from 529 the centralized configuration points to all of the AAA entities in 530 the system. 532 5.2. COR Connectivity 534 The system will need to distribute the information necessary to build 535 a path from any specific Trust Introducer to any given COR. In point 536 of fact, there may be CORs in the system that will not be reachable 537 from a specific Trust Introducer due to security constraints on the 538 distribution of COR connectivity. 540 One of the interesting questions that will need to be explored is: 541 Can the COR and COI information be distributed independently and 542 combined on the AAA systems or does it need to be combined by the 543 Trust Brokers that are doing the distribution of this information. 545 5.3. AAA Entity Introduction 547 This flow of communication represents the final goal of the protocol. 548 We want to be able to build up a TLS connection between the AAA proxy 549 that resides nearest to the SP and the AAA server that is going to be 550 used to validate the user. 552 In building the connection between the proxy and the server the 553 following will need to be taken into account: 555 o The identity of the service provider. 557 o The security properties of the connection between the service 558 provider and the AAA proxy. 560 o The COI that will govern the connection. 562 o The possible routes between the AAA proxy and the AAA server and 563 their security properties. 565 Note that no information about the user except the target COR is used 566 in the path construction as no such information is both available and 567 reliable. Until the authentication between the user and the COR has 568 completed the network will have no idea about the user except for the 569 claimed COR. 571 6. Putting it all together 573 In this section there are a number of pictures of different 574 configurations that are germane to the problem 576 6.1. Scenario - One Trust Backbone 578 In this scenario, we are looking at what is the basic roll out that 579 will be done. In this scenario there are four different security 580 zones: 582 o The trust backbone, 584 o The COR for organization A, 586 o The COR for organization B, 588 o The external world 590 +----------+ 591 | COI | 592 | Manager | 593 +----------+ 594 ^ | 595 | 596 v | 597 +----------+ +----------+ +----------+ 598 | | | | | Edge | 599 | TIR B |<------>| TIR A |<----->| TIR | 600 | | | | | | 601 +----------+ +----------+ +----------+ 602 ^ ^ | 603 | | 604 v v | 605 +----------+ +----------+ 606 | TIT | | TII | | 607 - - | | -+- - - | | - - - - + 608 +----------+ | +----------+ | 609 ^ ^ 610 | | | 611 v v | 612 +----------+ | +----------+ 613 |AAA Server|<-------->| AAA | | External 614 | IDP | | | Proxy | World 615 +----------+ +----------+ | 616 | ^ 617 | | 619 | | 620 v | 621 +----------+ | +----------+ 622 | Subject |--------->| Relying | | 623 | | | | Party & | 624 +----------+ | AAA | | 625 | | Client | 626 +----------+ | 627 | 628 COR B | COR A | 630 Multiple CORs - One Trust Backbone 632 There may be a need to create a different scenario for discussion 633 about what happens if there is a single COR. Specifically, on needs 634 to look at the question: Does one still need to go through a AAA 635 proxy and the trusted introducer protocol or can the SP go directly 636 to the AAA Server? If one goes directly, then there are some 637 security gateways that might not get checked. 639 6.2. Scenario - Three Trust Backbones 641 In this scenario, we are looking at a more complex roll out. In this 642 scenario there are five different security zones: 644 o The trust backbone for A, 646 o The trust backbone for B, 648 o The trust backbone for C, 650 o The COR D, 652 o The COR E. 654 In the picture, there is a distinction between the internal and the 655 edge trust routers. In an actual roll out there may not be distinct 656 components. However for conversation purposes it is easier to keep 657 then separate. 659 Trust Realm A | Trust Realm B | Trust Realm C 661 +----------+ | | +----------+ 662 | COI | | COI | 663 | Manager | | | | Manager | 664 +----------+ +----------+ 665 ^ | | ^ 666 | | 667 v | | v 668 +----------+ +----------+ +----------+ +----------+ 669 | | | Edge | | Edge | | | 670 | TIR A1 |<-->| TIR AB |<-->| TIR BC |<-->| TIR C1 | 671 | | | | | | | | 672 +----------+ +----------+ +----------+ +----------+ 673 ^ | ^ ^ | ^ 674 | v v | 675 5 | +---------+ | 3 676 | | | | 677 v | | TIR B1 | | v 678 +----------+ | | +----------+ 679 | TIT | | +---------+ | | TIC | 680 - -| |- - - - - - - - - | | - - 681 +----------+ | | +----------+ 682 ^ ^ 683 | | | | 684 v v 685 +----------+ | | +----------+ 686 |AAA Server|<-------------------------------->| AAA | 687 | IDP | | | | Proxy | 688 +----------+ +----------+ 689 | | ^ 690 | 691 v 692 +----------+ | | +----------+ 693 | Subject |--------------------------------->| Relying | 694 | | | | | Party & | 695 +----------+ | AAA | 696 | | | Client | 697 +----------+ 698 | | 699 COR D | | COR E 701 Figure 1: Architecture 703 7. Security Considerations 705 This document does not define a protocol and as such has no direct 706 security considerations. The document does pose a number of 707 questions dealing with security that will need to be addressed by a 708 protocol that implements the problem stated here. 710 8. IANA Considerations 712 This document has no IANA considerations. 714 9. Acknowledgments 716 This document is an expansion of an email message that was originally 717 sent to Alan DeKork and was probably passed on to others. 719 10. References 721 10.1. Normative References 723 [I-D.ietf-abfab-arch] 724 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 725 Schaad, "Application Bridging for Federated Access Beyond 726 Web (ABFAB) Architecture", draft-ietf-abfab-arch-06 (work 727 in progress), April 2013. 729 10.2. Informative References 731 [I-D.howlett-abfab-trust-router-ps] 732 Howlett, J., Smith, R., and M. Wasserman, "Trust 733 Requirements in a Federated World", draft-howlett-abfab- 734 trust-router-ps-03 (work in progress), March 2013. 736 [I-D.mrw-abfab-trust-router] 737 Wasserman, M., Hartman, S., and J. Howlett, "Application 738 Bridging for Federation Beyond the Web (ABFAB) Trust 739 Router Protocol", draft-mrw-abfab-trust-router-02 (work in 740 progress), February 2013. 742 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 743 Housley, R., and W. Polk, "Internet X.509 Public Key 744 Infrastructure Certificate and Certificate Revocation List 745 (CRL) Profile", RFC 5280, May 2008. 747 [I-D.ietf-radext-dynamic-discovery] 748 Winter, S. and M. McCauley, "NAI-based Dynamic Peer 749 Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf- 750 radext-dynamic-discovery-06 (work in progress), February 751 2013. 753 [I-D.ietf-emu-eap-tunnel-method] 754 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 755 "Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap- 756 tunnel-method-05 (work in progress), February 2013. 758 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 759 Attribute Certificate Profile for Authorization", RFC 760 5755, January 2010. 762 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 764 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 765 "Transport Layer Security (TLS) Encryption for RADIUS", 766 RFC 6614, May 2012. 768 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 769 Wu, "Internet X.509 Public Key Infrastructure Certificate 770 Policy and Certification Practices Framework", RFC 3647, 771 November 2003. 773 Author's Address 775 Jim Schaad 776 Soaring Hawk Consulting 778 Email: ietf@augustcellars.com