Trust Router Problem Statement
draft-howlett-abfab-trust-router-ps-00

ABFAB                                                         J. Howlett
Internet-Draft                                                 JANET(UK)
Intended status: Informational                              M. Wasserman
Expires: September 7, 2012                             Painless Security
                                                           March 6, 2012

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

Abstract

   This document is a problem statement for the Trust Router Protocol.
   The Trust Router Protocol has been designed to support 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 September 7, 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.

Howlett & Wasserman     Expires September 7, 2012               [Page 1]
Internet-Draft       Trust Router Problem Statement           March 2012

Table of Contents

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

Howlett & Wasserman     Expires September 7, 2012               [Page 2]
Internet-Draft       Trust Router Problem Statement           March 2012

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.

   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 the Trust Router Protocol
   [I-D.mrw-abfab-trust-router].  The Trust Router Protocol has been
   designed to support multihop federations
   [I-D.mrw-abfab-multihop-fed], eliminating the need for a bilateral
   connection between each IdP and RP.

   The 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.  The Trust Router
   protocol addresses the problems described in this document by
   distributing information about existing trust relationships within
   the partnership, avoiding the operational costs and limiations of 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.

Howlett & Wasserman     Expires September 7, 2012               [Page 3]
Internet-Draft       Trust Router Problem Statement           March 2012

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:

   o  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.

   o  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.

   o  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

Howlett & Wasserman     Expires September 7, 2012               [Page 4]
Internet-Draft       Trust Router Problem Statement           March 2012

   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 the Trust Router, 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 a
   large 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.

   The Trust Router protocol removes the need for this bilateral
   credential exchange, by flooding information about availalbe Trust
   Links across the Trust Router network, and forging multi-hop Trust
   Paths that can be used by an RP to access a AAA Server in the target
   IdP's realm.

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.

   With the Trust Router protocol, a new partner will make arrangements
   with an existing member (or a small number of existing members) of
   the Trust Router infrastructure to either advertise the new partner's
   realm, or peer with a Trust Router run by the new partner.  The
   existence of the new partner will be dynamically flooded throughout
   the Trust Router network, and the new partner will be able to gain
   access to all of the service available to the partnership.

   When an organization leaves the partnership, the Trust Links for that
   partner will be removed, and that information will also be propogated
   across the Trust Router infrastructure.  Trust Links also include a

Howlett & Wasserman     Expires September 7, 2012               [Page 5]
Internet-Draft       Trust Router Problem Statement           March 2012

   lifetime, which can be set to ensure that cached Trust Links will
   expire before the end of an existig partner's 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.

   With the Trust Router protocol, the operational costs of adding a new
   member to an existing partnership are constrained to the partner and
   a small number of peers that advertise the new partner's realm within
   the Trust Router infrastructure.

3.4.  Costs Incurred by the Party that Benefits

   Without Trust Router, 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 access to the services, but in a less-
   centralized partnership, and can serve as a disincentive for
   organizations to provider 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.

   With Trust Router, the operational costs of adding a new member to
   the partnership are incurred by the new member organization, and by a
   single (or small number) of organizations whe peer with the new
   partner's Trust Routers or advertise the new partner's realm.
   Partners who choose to provide services to teh partnership are not
   affected by the addition of new members, unless they choose to peer
   with them.

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, and

Howlett & Wasserman     Expires September 7, 2012               [Page 6]
Internet-Draft       Trust Router Problem Statement           March 2012

   the costs are unfairly distributed to RPs.

   (This section needs further work and examples.)

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.  Informative References

   [I-D.lear-abfab-arch]         Howlett, J., Hartman, S., Tschofenig,
                                 H., and E. Lear, "Application Bridging
                                 for Federated Access Beyond Web (ABFAB)
                                 Architecture", draft-lear-abfab-arch-02
                                 (work in progress), March 2011.

   [I-D.ietf-abfab-usecases]     Smith, R., "Application Bridging for
                                 Federated Access Beyond web (ABFAB) Use
                                 Cases", draft-ietf-abfab-usecases-01
                                 (work in progress), July 2011.

   [I-D.mrw-abfab-trust-router]  Wasserman, M., Hartman, S., and J.
                                 Howlett, "Application Bridging for
                                 Federation Beyond the Web (ABFAB) Trust
                                 Router Protocol",
                                 draft-mrw-abfab-trust-router-01 (work
                                 in progress), October 2011.

   [I-D.mrw-abfab-multihop-fed]  Wasserman, M., Tschofenig, H., and S.
                                 Hartman, "Multihop Federations for
                                 Application Bridging for Federation
                                 Beyond the Web (ABFAB)",
                                 draft-mrw-abfab-multihop-fed-01 (work
                                 in progress), July 2011.

Howlett & Wasserman     Expires September 7, 2012               [Page 7]
Internet-Draft       Trust Router Problem Statement           March 2012

   [RFC2629]                     Rose, M., "Writing I-Ds and RFCs using
                                 XML", RFC 2629, June 1999.

Authors' Addresses

   Josh Howlett
   JANET(UK)

   EMail: josh.howlett@ja.net

   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845
   USA

   Phone: +1 781 405 7464
   EMail: mrw@painless-security.com
   URI:   http://www.painless-security.com

Howlett & Wasserman     Expires September 7, 2012               [Page 8]