One document matched: draft-howlett-abfab-trust-router-ps-00.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 I-D.mrw-abfab-trust-router SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mrw-abfab-trust-router-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-00.txt" ipr="trust200902">
<front>
<title>Trust Router Problem Statement</title>
<author fullname="Josh Howlett" surname="Howlett" initials="J" >
<organization>JANET(UK)</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 year="2012" />
<area>Security Area</area>
<workgroup>ABFAB</workgroup>
<abstract>
<t>
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.
</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.
</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 the Trust
Router Protocol
<xref target="I-D.mrw-abfab-trust-router"/>. The
Trust Router Protocol has been designed to support
multihop federations
<xref target="I-D.mrw-abfab-multihop-fed"/>, eliminating
the need for a bilateral connection between each IdP and
RP.
</t>
<t>
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).
</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 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.
</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 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.
</t>
<t>
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.
</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>
<t>
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.
</t>
<t>
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 lifetime,
which can be set to ensure that cached Trust Links will
expire before the end of an existig partner's 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>
<t>
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.
</t>
</section>
<section title="Costs Incurred by the Party that Benefits">
<t>
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.
</t>
<t>
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.
</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, and the costs are unfairly distributed
to RPs.
</t>
<t>
(This section needs further work and examples.)
</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-trust-router;
&I-D.mrw-abfab-multihop-fed;
&rfc2629;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 13:45:56 |