Trust Router Problem Statement
draft-howlett-abfab-trust-router-ps-01.txt

Abstract

This document is a problem statement for a Trust Router Protocol. A Trust Router Protocol is needed to support large, multihop ABFAB federations, without the need for credentials to be configured for every pair of Identity Providers and Relying Parties.

Status of this Memo

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 August 31, 2012.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Introduction
• 2. High-Level Problems
• 2.1. Connecting your Partners
• 2.2. Identifying your Partners
• 2.3. Knowing your Partners
• 2.4. Policing and Managing Policy
• 3. Specific Problems
• 3.1. Many IdPs, Many RPs
• 3.2. Frequent Changes in Membership
• 3.3. Minimal Costs for Adding a New Partner
• 3.4. Costs Incurred by the Party that Benefits
• 3.5. Deployment Challenges with Public Key Infrastructure
• 4. Security Considerations
• 5. Acknowledgments
• 6. References
• Authors' Addresses

1. Introduction

The ABFAB architecture [I-D.lear-abfab-arch] describes an access management model that enables the application of federated identity within a broad range of use cases. This is achieved by building on proven technologies and widely deployed infrastructures. Some of these use cases are described in [I-D.ietf-abfab-usecases].

In the canonical case, an ABFAB transaction only implies two organizations: an Identity Provider (IdP) and a Relying Party (RP). In this simplest case of a bilateral connection, the amount of configuration needed by both partners is very small; probably just an AAA credential and the peer system's host name for the other party.

However, in practice an organization may have more than one partner. In the case where bilateral connections are used, the amount of configuration at each partner increases in proportion to the number of connections. As the number of partners increases, the amount of configuration churn may become too onerous to manage. Also, the operational costs of managing that configuration information is borne, to an unreasonable degree, by the RPs. When a new IdP is added to a partnership, it is necessary for all of the RPs to update their configuration information before the new IdP's users will have full access to the services accessible to the partnership.

This document is a problem statement for a Trust Router Protocol. A Trust Router Protocol is needed to eliminate the need the need for a bilateral exchange of credentials between each IdP and RP.

A Trust Router Protocol allows a new partner to be added to an ABFAB partnership by peering with any member of the Trust Router network, instead of requiring configuration changes by every partner who may wish to connect with the new partner. A Trust Router protocol addresses the problems described in this document by distributing information about existing trust relationships within the partnership, thus avoiding the operational costs and limitations of using a Public Key Infrastructure (PKI).

This document is broken into two sections: High-Level Problems and Specific Problems. The High-Level Problems section describes the problems that the Trust Router Protocol has been designed to address at a conceptual level, and the Specific Problems section discusses a more concrete set of problems that the Trust Router Protocol is intended to address.

2. High-Level Problems

2.1. Connecting your Partners

Organizations want to be able to connect to an arbitrary number of partners without being overwhelmed by configuration management of many bilateral connections.

2.2. Identifying your Partners

It is not generally sufficient to simply configure a partner. In most cases, it is also necessary for organizations to have confidence that the configuration that they have for their partner(s) actually corresponds to their partner(s) and is not, for example, an attacker claiming to be their partner. Unfortunately identifying partners and binding them cryptographically to the corresponding configuration can be very expensive.

Organizations want to minimise the cost of validating their partners' identities, and of proving their own identity to their partners.

2.3. Knowing your Partners

Organizations and their partners generally interact within the context of a particular context. The context can be established in a number of ways; for example:

• A pair of organization may have a formal business relationship that unambiguously establishes the nature of the relationship between the partners (for example, in the case of a supplier's relationship with a customer). In this case, the customer's ABFAB-based interactions with the supplier are governed by this business relationship.
• A group of organization may also share a formal business relationship (for example, a number of suppliers within a manufacturer's supply chain). In this case, the business relationship might govern the ABFAB-based interactions between the suppliers, and the suppliers and the manufacturer.
• A group of organizations may not share a formal business relationship but instead share common best practices. In this case, the best practices might govern the ABFAB-based interactions between these organizations.

Given the potential diversity of contexts, organizations need to know which context is in force for a particular ABFAB-based transaction and apply policy that controls which entities within an organization are permitted to operate within particular business contexts.

2.4. Policing and Managing Policy

Organizations want to have effective tools for policing and managing policies controlling ABFAB-based transactions with their partners.

3. Specific Problems

3.1. Many IdPs, Many RPs

It is fairly easy to see how ABFAB, without Trust Routers, could be deployed in a small federation with stable membership, or even in a large federation with a single RP that provides services to all of the other members, such as an industry consortium.

However, there are operational problems that arise when ABFAB is used in a federation with a large number of RPs providing services to an even larger number of IdPs. In these cases, it can be challenging to manage the credentials that need to be exchanged, and manually configured, between each RP/IdP pair.

3.2. Frequent Changes in Membership

It must be possible to support changes in membership (adding new partners, or removing former partners) with minimal operational effort, and without requiring manual configuration changes that could result in new partners having delayed or incomplete access to services, or former partners retaining some access to services beyond the end of their membership.

3.3. Minimal Costs for Adding a New Partner

There is a need to support large federations in a cost-effective manner. This includes minimizing the operational costs of adding a new member (either an IdP or RP) to an existing partnership. Without Trust Router, the operational costs of adding a new member to an existing partnership might be quite high -- requiring credential exchange between a large number of parties, and requiring manual configuration changes on a large number of different systems.

3.4. Costs Incurred by the Party that Benefits

Without Trust Routers, a high portion of the operational cost related to adding and removing partners is born by the RPs, who need to maintain bilateral credentials for each IdP whose users can access the services provided by the RP. This is fine in a case where a single RP provides services to a group of IdPs that pay for membership in the group or pay for access to the services, but in a less-centralized partnership the costs of exchanging credentials with each IdP could serve as a disincentive for organizations to provide services to the partnership and/or result in cases where an RP is unwilling or unable to incur the costs of providing access to new members. Therefore, it is important that we devise a mechanism where the operational costs are distributed to the organizations that are receiving benefit from incurring the costs.

3.5. Deployment Challenges with Public Key Infrastructure

Deployment problems with Public Key Infrastructure (PKI) make it unsuitable for use by many ABFAB federations. The costs are prohibitive for the use of ABFAB federations in many educational environments, the policies of PKI Certificate Authorities are not well-aligned with the policies of many membership organizations. Also, the support costs associated with having every every IdP generate keys and provide a public key (but not their private key) to each RP in a partnership may be prohivitive.

4. Security Considerations

The topics discussed in this document are likely to be of interest to the IETF Security Area, and the Internet security community, in general. However, this is a problem statement document, not a protocol definition, and therefore it does not define anything with its own Security Considerations. The Security Considerations for the protocols discussed in this document are (or will be) provided in the documents defining those protocols.

5. Acknowledgments

This document was written using the xml2rfc tool described in RFC 2629 [RFC2629].

The following people have provided useful feedback on the contents of this document: Sam Hartman.

6. References

Authors' Addresses