One document matched: draft-howlett-abfab-trust-router-ps-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.lear-abfab-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lear-abfab-arch-02.xml">
<!ENTITY I-D.ietf-abfab-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-abfab-usecases-01.xml">
<!ENTITY I-D.mrw-abfab-multihop-fed SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mrw-abfab-multihop-fed-01.xml">
<!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
]>
<rfc category="info" docName="draft-howlett-abfab-trust-router-ps-01.txt" ipr="trust200902">
<front>
<title>Trust Router Problem Statement</title>
<author fullname="Josh Howlett" surname="Howlett" initials="J" >
<organization>Janet</organization>
<address>
<email>josh.howlett@ja.net</email>
</address>
</author>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405 7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<date month="March" year="2012" />
<area>Security Area</area>
<workgroup>ABFAB</workgroup>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The ABFAB architecture
<xref target="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
<xref target="I-D.ietf-abfab-usecases" />.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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.
</t>
</section>
<section title="High-Level Problems">
<section title="Connecting your Partners">
<t>
Organizations want to be able to connect to an arbitrary
number of partners without being overwhelmed by
configuration management of many bilateral connections.
</t>
</section>
<section title="Identifying your Partners ">
<t>
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.
</t>
<t>
Organizations want to minimise the cost of validating
their partners' identities, and of proving their own
identity to their partners.
</t>
</section>
<section title="Knowing your Partners">
<t>
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:
<list style="symbols">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="Policing and Managing Policy">
<t>
Organizations want to have effective tools for policing
and managing policies controlling ABFAB-based
transactions with their partners.
</t>
</section>
</section>
<section title="Specific Problems">
<section title="Many IdPs, Many RPs">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Frequent Changes in Membership">
<t>
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.
</t>
</section>
<section title="Minimal Costs for Adding a New Partner">
<t>
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.
</t>
</section>
<section title="Costs Incurred by the Party that Benefits">
<t>
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.
</t>
</section>
<section title="Deployment Challenges with Public Key Infrastructure">
<t>
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.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
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.
</t>
</section>
<section title="Acknowledgments">
<t>
This document was written using the xml2rfc tool described
in RFC 2629 <xref target="RFC2629"/>.
</t>
<t>
The following people have provided useful feedback on the
contents of this document: Sam Hartman.
</t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.lear-abfab-arch;
&I-D.ietf-abfab-usecases;
&I-D.mrw-abfab-multihop-fed;
&rfc2629;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:38:10 |