One document matched: draft-mrw-abfab-multihop-fed-00.txt
Network Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Standards Track July 4, 2011
Expires: January 5, 2012
Application Bridging for Federation Beyond the Web (ABFAB) Multihop
Federations
draft-mrw-abfab-multihop-fed-00.txt
Abstract
This document describes a mechanism for establishing trust across a
multihop federation within the Application Bridging for Federation
Beyond the Wed (ABFAB) framework.
This document introduces a new ABFAB entity, the Trust Router. Trust
Routers exchange information about the availability of Trust Paths
across a multiphop federation. They can be queried by a Relying
Party to obtain the best Trust Path to reach a RADIUS or RADSEC
server in a given realm. They also provide temporary identities that
can be used by a Relying Party to traverse a Trust Path.
This document is currently limited to discussing a proposed mechanism
to achieve a multihop federation in the ABFAB framework. Later
versions of this document (or companion documents) will describe the
protocols and algorithms in more detail.
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 January 6, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Wasserman Expires January 6, 2012 [Page 1]
Internet-Draft ABFAB Multihop Federations July 2011
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Multihop Federation Example . . . . . . . . . . . . . . . . 3
1.2. Trust Router Overview . . . . . . . . . . . . . . . . . . . 5
1.3. Multiple Federations . . . . . . . . . . . . . . . . . . . 6
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Trust Router Protocol . . . . . . . . . . . . . . . . . . . . . 6
5. Trust Path Query . . . . . . . . . . . . . . . . . . . . . . . 7
6. Temporary Identity Request . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Wasserman Expires January 6, 2012 [Page 2]
Internet-Draft ABFAB Multihop Federations July 2011
1. Introduction
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].
In a single hop federation, every Relying Party has a pre-existing
relationship with every Identity Provider. In other words, each
Relying Party is pre-configured with the required information and
credentials to reach a RADIUS or RADSEC server in every Identity
Provider withing the federation. In a multihop federation, this is
not necessary, as a Relying Party can reach the RADIUS or RADSEC
server within a previously unknown Identity Provider by traversing a
transitive Trust Path across a federation.
This document introduces a new ABFAB 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 a RADIUS or RADSEC server in a
given realm. They also provide temporary identities that can be used
by a Relying Party to traverse a Trust Path.
This document is currently limited to discussing a proposed mechanism
to achieve a multihop federation in the ABFAB framework. Later
versions of this document (or companion documents) will describe the
protocols and algorithms in more detail.
1.1. Multihop Federation Example
The diagram below shows an example of a successful authentication
exchange in a multihop federation:
Wasserman Expires January 6, 2012 [Page 3]
Internet-Draft ABFAB Multihop Federations July 2011
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:
1. We start with a single federation including 4 realms, each
containing a single Trust Router. The Trust Routers are peered,
such that their interconnections form a multihop federation.
2. A Subject (with an identity in Realm D) attempts to access a
service provided by a Relying Party in Realm A.
3. The Relying Party does not have direct access to a RADIUS or
RADSEC server in Realm D that it can use to authenticate the
user, so it asks its local Trust Router for a Trust Path to reach
Realm D. The Trust Router in Realm A returns the path
A->B(T)->C(T)->D(T)->D(R), which indicates that the Relying Party
should use the Trust Routers in Realms B, C and D to reach a
Wasserman Expires January 6, 2012 [Page 4]
Internet-Draft ABFAB Multihop Federations July 2011
RADIUS or RADSEC server in Realm D, which could then be used to
authenticate the user.
4. The Relying Party contacts a trust router in Realm B (using its
permanent identity in Realm A), and requests the creation of a
temporary identity that can be used to communicate with the Trust
Router in Realm C.
5. The Relying Party then contacts the Trust Router in Realm C
(using the temporary identity returned in the previous step), and
asks for a temporary identity that can be used to communicate
with the Trust Router in realm D.
6. The Relying Party then contacts the Trust Router in Realm D
(using the temporary identity returned in the previous step), and
asks the Trust Router to provision an identity that it can use to
speak to the RADIUS or RADSEC server in Realm D (which is part of
Realm D's Identity Provider).
7. At this point, the Relying Party can reach the Subject's Identity
provider, and the rest of the ABFAB exchange can continue, as
described in [I-D.lear-abfab-arch].
1.2. Trust Router Overview
As shown in the example above, the Trust Router performs three
functions:
o Trust Routers peer with one another to exchange information about
available Trust Paths. This information is exchanged between
Trust Routers using the Trust Router Protocol. The Trust Router
Protocol is described in more detail in a later section.
o The Relying Party queries a local Trust Router to determine the
best path to use to reach the destination realm. This exchange is
referred to as a Trust Path Query, and is described in more detail
in a later section.
o The Relying Party will ask each Trust Router along the path to
provision a temporary identity that can be used to gain access to
the next step in the path. This mechanism is called a Temporary
Identity Request, and is described in more detail in a later
section.
Wasserman Expires January 6, 2012 [Page 5]
Internet-Draft ABFAB Multihop Federations July 2011
1.3. Multiple Federations
The example above shows a number of Trust Routers running within a
single federation. In real deployments, it is expected that some
Trust Routers will serve multiple federations. Also, it is possible
that services will be available across multiple federations, or that
Subjects with have identities within multiple federations. In order
to support these cases, a Policy Regime (essentially a federation
name) is passed as a parameter or attribute in many of the exchanges
shown above, typically paired with the name of a realm. Trust
Routers will, conceptually, calculate a separate tree for each Policy
Regime, and the Trust Path provided to the Relying Party will consist
of Trust Links within a single Policy Regime (or federation).
2. Requirements Terminology
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].
3. Terminology
o Trust Router
o Trust Path
o Trust Link
o Trust Router Protocol
o Policy Regime
4. Trust Router Protocol
The Trust Router Protocol has some similarities to an Internet
Routing Protocol, with some exceptions: Links are unidirectional, and
realm names are not hierarchical, so no aggregation is possible.
Also, it is necessary to associate a set of information with each
link that can be used for filtering and tree computation, including:
the cost of the link, the Policy Regime associated with the link, and
information indicating how/if the link should be propagated across
the federation.
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
Wasserman Expires January 6, 2012 [Page 6]
Internet-Draft ABFAB Multihop Federations July 2011
communicate a similar set of information between Trust Routers as
would be communicated between Internet Routers running BGP. However,
BGP does not have the security properties that would be desirable in
a Trust Router Protocol, so we will not use the standard BGP
encapsulation.
5. Trust Path Query
A Trust Path Query is generated by a Relying Party 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 one or more Trust Router steps and ends with a RADIUS or RADSEC
server within the Identify Provider for the indicated realm. The
returned Trust Path represents the best path for the Relying Party to
use to reach an Identity Provider in the destination realm.
The Trust Path Query is initiated by the Relying Party, 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 Relying Party, and check local policy
information to determine whether or not to reply.
Assuming that the Relying Party 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
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, RADIUS or RADSEC), 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.
6. Temporary Identity Request
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 infrastructure that
can be used by the Relying Party to communicate with the Trust Router
or RADIUS/RADSEC server that represents the next step in the Trust
Path.
Wasserman Expires January 6, 2012 [Page 7]
Internet-Draft ABFAB Multihop Federations July 2011
These Temporary Identities will have a finite lifetime and, when
authenticated, will include a RADIUS attribute 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:
1. The Relying Party will send a Temporary Identity Request message
to the Trust Router, containing the identity of the next step in
the Trust Path, the destination realm that it is trying to reach,
and the Policy Regime in use. This request will be sent using
the identity that the Trust Router obtained from the previous
step in the Trust Path (or the Trust Router's permanent identity
in it's home realm, if this is the first step).
2. The Trust Router will authenticate the Relying Party.
3. If the authentication is successful, the Trust Router will check
local policy to determine whether it should provision an identity
for the Relying Party for the indicated purpose (details of this
check may be implementation dependent).
4. If the request passes any policy requirements, the Trust Router
will provision a temporary identity for the Relying Party within
the Trust Router's local realm that can be used to access the
next-hop Trust Router or RADIUS/RADSEC server in the Trust Path.
7. Security Considerations
TBD.
8. IANA Considerations
There are no IANA actions required for this document at this time.
9. Acknowledgements
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
10. References
Wasserman Expires January 6, 2012 [Page 8]
Internet-Draft ABFAB Multihop Federations July 2011
10.1. Normative 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Author's Address
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
Wasserman Expires January 6, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:09 |