| Network Working Group | M. Wasserman |
| Internet-Draft | Painless Security |
| Intended status: Standards Track | H. Tschofenig |
| Expires: January 13, 2012 | Nokia Siemens Networks |
| S. Hartman | |
| Painless Security | |
| July 12, 2011 |
Multihop Federations for Application Bridging for Federation Beyond the Web (ABFAB)
draft-mrw-abfab-multihop-fed-01.txt
This document describes a mechanism for establishing trust across a multihop federation within the Application Bridging for Federation Beyond the Web (ABFAB) framework.
This document introduces a new entity, the Trust Router. Trust Routers exchange information about the availability of Trust Paths across a multihop federation. They can be queried by a Relying Party to obtain the best Trust Path to reach an Identity Provider. They also provide temporary identities that can be used by a Relying Party to traverse a Trust Path.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes a mechanism for establishing trust across a multihop federation within the Application Bridging for Federation Beyond the Web (ABFAB) framework [I-D.lear-abfab-arch].
This document introduces a new ABFAB entity, the Trust Router. Trust Routers exchange information about the availability of Trust Paths across a multihop federation. ABFAB entity, the Trust Router. These paths are used by RPs to contruct transitive trust chains across a federation to a Radius or Diameter server within a target IdP.
A Trust Path consists of one or more Trust Links. A Trust Link is an assertion that a specific Trust Router is capable of providing temporary identies that can be used to access another entity in the ABFAB system. At this point, we anticipate that there will be two types of Trust Links in ABFAB: a Trust Link that indicates that one Trust Router can be used to reach another Trust Router, and a Trust Link that indicates that a Trust Router can be used to reach a Radius or Diameter Server. The first type (Trust Router Links) are shown as A->B(T), which indicates that the Trust Router in realm A can create identities to reach the trust router in Realm B. The second type (Radius/Diameter Links) are shown as A->B(R), to indicate that a trust router in Realm A can be used to reach a Radius, RadSec or Diameter server in Realm B.
Trust Routers exchange information about available Trust Links within a federation, and each Trust Router maintains a tree of available paths to reach all of the IdPs within the federation that can be reached from the local realm of the Trust Router.
When an RP receives a request from a party within a realm that not known directly to the RP, the RP will query its local Trust Router to obtain the best Trust Path to reach that IdP. Note that we use the term 'best' here to highlight that there may well be multiple paths to reach an IdP from a given RP, and the selection of the 'best' path may involve several factors in addition to the length of the path, such as security and privacy practices, or monetary costs.
The RP will travers the Trust Path obtained from it's local Trust Router. At each step, the RP will request a temporary identity to access the next step in the Trust Path, contructing a transitive chain of trust to a Radius or Diameter server within the target IdP.
To summarize, the Trust Router performs three functions:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
This document introduces the following terms:
The terms Identity Provider (IdP), Relying Party (RP), Subject, and Federation are used as defined in [I-D.lear-abfab-arch].
Figure 1 shows an example federation where the Relying Party Foo, has established relationships with various Identity Providers.
+---------------+
| Identity |
| Provider | `..
| Example-A.org | `-._
+---------------+ `..
`-._
+---------------+ `._ +-----------+
| Identity | `- | Relying |
| Provider | ------------------ | Party Foo |
| Example-B.org | _.- +-----------+
+---------------+ _,-'
,,'
+---------------+ _.-' o
| Identity | _,-' \|/
| Provider | ' |
| Example-C.org | / \
+---------------+ Subject
When an RP receives a request to access a protected resource (or requires authentication and authorization for other purposes) the request includes a realm name that indicates the IdP the Subject has selected for this exchange. Offering the Subject the ability to choose among many different IdPs is necessary because a Subject may have, and want to maintain, uncorrelated identities in several different realms within a single federation (i.e. work, school, social networking, etc.). However, this also places a burden on the RPs to establish and maintain business agreements and exchange security credentials with a potentially large number of Identity Providers.
In order for a single-hop federation to function, each IdP needs to maintain business agreements and exchange credentials with every RP that its Subjects are authorized to access. Figure 2, shows the likely outcome, which is that a single-hop federation will come to resemble a dense mesh topology.
+---------------+
| Identity |
| Provider |-.._
| Example-A.org |`. ``-.._
+---------------+ `-. ``-..__ +-----------+
`. `--.| Relying |
+---------------+ `. __..--| Party Foo |
| Identity | __:.--'' .-'+-----------+
| Provider |_..--'' `. .-'
| Example-B.org | .-'.
+---------------+ .' '. +-----------+
.-' -. | Relying |
+---------------+ .-' `-.| Party Bar |
| Identity |.-' ____....---''+-----------+
| Provider |.----'''
| Example-C.org |
+---------------+ o
\|/
|
/ \
Subject
As discussed in section 2.1.1 of [I-D.lear-abfab-arch], as the number of organizations involved in a ABFAB federation increase, static configuration may not scale sufficiently. Also, using a Trust Broker to establish keys between entities near the RP and entities near the IDP with improve the security and privacy of an ABFAB federation. Figure 3 shows the structure of a federation where each IdP and RP has a single connection to the Trust Router infrastructure.
+---------------+
| Identity |
| Provider |\
| Example-A.org | `.
+---------------+ \ +-----------+
\ .-'| Relying |
+---------------+ `. +---------------+ .' | Party Foo |
| Identity | \| Trust |.-' +-----------+
| Provider |........| Broker |
| Example-B.org | /| |`-.
+---------------+ .' +---------------+ `. +-----------+
/ `-.| Relying |
+---------------+ / | Party Bar |
| Identity | .' +-----------+
| Provider |/ O
| Example-C.org | \|/
+---------------+ |
/ \
Subject
To improve the operational scalability and security of large ABFAB federations, this document proposes a Trust Broker solution consisting of of a set of Trust Routers, as described in this document, and the Key Negotiation Protocol (KNP), as described in [I-D.howlett-radsec-knp].
The diagram below shows an example of a successful exchange in a multihop federation using the Trust Router Protocol and KNP:
Realm D | Realm C | Realm B | Realm A
| | |
+----------+ +----------+ +----------+ +----------+
| Trust | | | Trust | | | Trust | | | Trust |
| Router D |<-1->| Router C |<-1->| Router B |<-1->| Router A |
+----------+ | +----------+ | +----------+ | +----------+
^ ^ ^ ^
| | | | | | |
| | +---4------------ + |
| | | | | | |
| +----------------5---------------+ | 3
| | | | | | |
+----------------6------------------------------+ | | |
| | | | | | |
v v v v
+----------+ | | | +----------+
| Identity |<---------7--------------------------->| Relying |
| Provider | | | | | Party |
+----------+ +----------+
^ | | | ^
1 |
| | | | |
v |
+----------+ | | | |
| Subject |----------2---------------------------------+
| | | | |
+----------+
| | |
A multihop federation exchange matching the above diagram can be summarized as follows:
Trust Routers use the Trust Router Protocol to exchange information about available Trust Links, and Trust Paths across a federation.
The Trust Router Protocol differs from an Internet Routing Protocol in a couple of important ways:
In addition to the existence of the links themselves, Trust Links have a set of associated attributes that can be used for filtering and tree computation, including:
Current thinking is that we will use a BGP-based algorithm for computation of the local tree at each Trust Router, and that we will communicate a similar set of information between Trust Routers as would be communicated between Internet Routers running BGP.
A Trust Path Query is generated by a RP to request a Trust Path to reach a specific realm within a given Policy Regime. If possible, the Trust Router will reply with a Trust Path that consists of zero or more Trust Router steps and ends with a Radius or Diameter server within the IdP for the indicated realm.
The Trust Path Query is initiated by the RP, and the initial query message will contain the destination realm and Policy Regime.
When a Trust Path Query is received by a Trust Router, the router will first authenticate the RP, and check local policy information to determine whether or not to reply.
Assuming that the RP is successfully authenticated and the request passes local policy checks, the Trust Router will search it's tree of Trust Path information to determine whether a Trust Path exists that will reach the destination Realm within the indicated Policy Regime. If so, the shortest/best Trust Path will be returned to the Relying Party.
A Trust Path will consist of a list of steps, each of which will contain: The type of the step (Trust Router or Radius/Diameter), the Policy Regime associated with each step, information needed to reach the indicated Trust Router or server (domain name or IP address), and any special attributes associated with that step.
A Temporary Identity Request is issued by a Relying Party in order to obtain an identity that can be used to traverse each step in the Trust Path. When a Temporary Identity is requested, a Trust Router will provision a new identity in its local Radius or Diameter infrastructure that can be used by the Relying Party to communicate with the Trust Router or Radus/Diameter server that represents the next step in the Trust Path. Current thinking is that KNP will be used as the protocol mechanism for these requests.
These Temporary Identities will have a finite lifetime and, when authenticated, will include a Radius Attribute/Diameter AVP indicating that they were generated based on a Temporary Identity Request. This attribute will inlcude the chain of identities that preceeded the current identity in the traversal of the Trust Path.
The details of how these messages will be encoded has not yet been determined. However, it is expected that, for each Trust Router step in the Trust Path, the following actions will take place:
As discussed in [I-D.lear-abfab-arch], the trust broker architecture is a mechanism for establishing technical trust in an ABFAB federation. Technical trust mechanisms have three primary responsibilities in ABFAB. They are responsible for integrity protection of AAA traffic. They are responsible for constraining the naming of ABFAB entities: for example the technical trust mechanism assures that the entity claiming to be the IDP is authenticated and authorized to act as the IDP for the realm containing the subject. The technical trust mechanism also determines where AAA messages are routed.
The trust broker architecture described in this document is designed to meet the security and operational requirements of federations and groups of federations with large numbers of organizations. In these environments depending on any common credentials or trust mechanism does not make sense. While federations are expected to interconnect, they are not expected to have a common set of trust anchors for a public-key infrastructure. Each realm needs to be able to choose the appropriate credentials and security policies to use when establishing a relationship with another realm.
by design, this approach provides flexibility. Parts of the interconnected set of realms can use high-assurance processes and mechanisms including strong authentication mechanisms and rigorous credentialing and enrollment processes. Other realms can use lower-assurance mechanisms and processes, balancing cost and speed against security. However this flexibility complicates the security policy. Just because the local realm has a high-assurance trust link does not mean that the path is high-assurance. Operational mechanisms are required in order for RPs to express their security requirements and for the trust routers to make sure that resulting trust paths meet these requirements. Similarly, trust routers need to make sure that paths to a given IDP are not announced unless that IDP's security requirements will be met.
Like all Internet protocols, the trust router protocols and KNP need to have strong protection against parties who are not authorized to be part of an exchange. Such attackers do not start out knowing credentials necessary to participate in the system. However these attackers can be assumed to observe trust router, KNP, AAA and ABFAB exchanges. The system needs to maintain integrity of all data, confidentiality of keys and in some cases confidentiality of other data even when these attackers can insert, suppress, modify or replay packets. Reasonable defenses against attacks on the availability of the system are required, although obviously there are limits to these defenses. An attacker who can disrupt connectivity with a realm can impact availability.
The interesting threat model surrounds malicious participants authorized to participate in the system. The threat model is similar to that of routing protocols [I-D.ietf-karp-threats-reqs]. Defending against a compromised actor announcing a trust link that actor would be permitted to announce were it functioning correctly is out of scope. Similarly, defending against an compromised actor performing some action that actor is authorized to take is out of scope for this threat model.
However, it is a requirement that the system needs to provide tools to limit the authorization of actors. For example if a particular session between two trust routers is not authorized to announce a trust link to a given realm or with certain properties, then attacks permitting such a link to be announced are in scope. Similarly an attack permitting a temporary identity with properties inconsistent with administrative limits would be in scope.
The system must permit zones of more or less trust to be created. An attack that permits insiders in the zones of less trust to compromise a zone of higher trust beyond what the zone of lesser trust is permitted is within the scope of threats. However, trust can only decrease as distance across the transitive network of trust routers increases. A peer two hops away cannot be permitted to make any statement that a peer one hop away cannot make. In general, it is unknown whether the peer two hops away actually made the statement.
TBD
TBD
There are no IANA actions required for this document at this time.
This document was written using the xml2rfc tool described in RFC 2629 [RFC2629].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.lear-abfab-arch] | Howlett, J, Hartman, S, Tschofenig, H and E Lear, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Internet-Draft draft-lear-abfab-arch-02, March 2011. |
| [I-D.howlett-radsec-knp] | Howlett, J and S Hartman, "Key Negotiation Protocol (KNP)", Internet-Draft draft-howlett-radsec-knp-02, October 2011. |
| [RFC2629] | Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. |
| [I-D.ietf-karp-threats-reqs] | Lebovitz, G, Bhatia, M and R White, "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", Internet-Draft draft-ietf-karp-threats-reqs-03, June 2011. |