<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc2629 PUBLIC '' 
    'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
  <!ENTITY I-D.lear-abfab-arch SYSTEM
     'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lear-abfab-arch'>
  <!ENTITY I-D.howlett-radsec-knp SYSTEM
     'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.howlett-radsec-knp'>
  <!ENTITY I-D.mrw-abfab-trust-router SYSTEM
     'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrw-abfab-trust-router'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="std" ipr="trust200902" docName="draft-mrw-abfab-multihop-fed-02.txt">
  <front>
    <title abbrev="ABFAB Multihop Federations">Multihop Federations for Application Bridging for Federation Beyond the Web (ABFAB)</title>
    <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>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date month="October" year="2011" />
    <area>Security</area>

    <abstract>
      <t>
	This document describes a mechanism for establishing trust
	across a multihop federation within the Application Bridging
	for Federation Beyond the Web (ABFAB) framework.
      </t>
      <t>
	This document introduces a new 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 an
	Identity Provider.  They also provide temporary identities
	that can be used by a Relying Party to traverse a Trust
	Path.
      </t>
    </abstract>
  </front>
  
  <middle>
  
    <!-- ************************************************** -->

    <section title="Introduction">
      <t>
	This document describes a mechanism for establishing trust
	across a multihop federation within the Application Bridging
	for Federation Beyond the Web (ABFAB) framework
	<xref target="I-D.lear-abfab-arch"/>.  
      </t>
      <t>
	This document introduces a new ABFAB entity, the Trust Router.
	Trust Routers exchange information about the availability of
	Trust Paths across a multihop federation.  ABFAB entity, the
	Trust Router. These paths are used by RPs to contruct
	transitive trust chains across a federation to a AAA Server (a
	RADIUS, RadSec or Diameter Server) within a target IdP.
      </t>
      <t>
	A Trust Path consists of one or more Trust Links.  A Trust
	Link is an assertion that a specific Trust Router is capable
	of providing temporary identies that can be used to access
	another entity in the ABFAB system.  At this point, we
	anticipate that there will be two types of Trust Links in
	ABFAB: a Trust Link that indicates that one Trust Router can
	be used to reach another Trust Router, and a Trust Link that
	indicates that a Trust Router can be used to reach a AAA
	Server.  The first type (Trust Router Links) are
	shown as A->B(T), which indicates that the Trust Router in
	realm A can create identities to reach the trust router in
	Realm B.  The second type (AAA Links) are shown as
	A->B(R), to indicate that a trust router in Realm A can be
	used to reach a AAA Server in Realm B.
      </t>
      <t>
	Trust Routers exchange information about available Trust Links
	within a federation, and each Trust Router maintains a tree of
	available paths to reach all of the IdPs within the federation
	that can be reached from the local realm of the Trust Router.
      </t>
      <t>
	When an RP receives a request from a party within a realm that
	not known directly to the RP, the RP will query its local
	Trust Router to obtain the best Trust Path to reach that
	IdP. Note that we use the term 'best' here to highlight that
	there may well be multiple paths to reach an IdP from a given
	RP, and the selection of the 'best' path may involve several
	factors in addition to the length of the path, such as
	security and privacy practices, or monetary costs.
      </t>
      <t>
	The RP will traverse the Trust Path obtained from it's local
	Trust Router.  At each step, the RP will request a temporary
	identity to access the next step in the Trust Path,
	constructing a transitive chain of trust to a AAA Server
	within the target IdP.
      </t>
      <t>
	To summarize, the Trust Router performs three functions:
	<list style="symbols"> 
	  <t>
	    Trust Routers peer with other Trust Routers to exchange
	    information about available Trust Links, and Trust Paths.
	    This information is exchanged between Trust Routers using
	    the Trust Router Protocol.  The Trust Router Protocol is
	    described in more detail in
	    <xref target="I-D.mrw-abfab-trust-router"/>.
	  </t>
	  <t>
	    Trust Routers respond to queries from Relying Parties to
	    make information about Trust Paths available. This
	    exchange is referred to as a Trust Path Query Protocol,
	    which is described in <xref target="TrustPathQuery"/>.
	  </t>
	  <t>
	    To follow the Trust Path across a federation, the RP will
	    use KNP to 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, which is described in
	    <xref target="I-D.howlett-radsec-knp"/>.  
	  </t>
	</list> 
      </t>
      </section> 

    <!-- ********************************************************** -->

    <section title="Terminology">
      <t>
	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 <xref target="RFC2119"/>.
      </t>
      <t>
	This document introduces the following terms:
	<list style="hanging">  
	  <t hangText="Trust Router:"><vspace blankLines="1"/> This is
	    a logical ABFAB entity that exchanges information about 
	    Trust Paths that Relying Parties can use to create
	    transtitive chains of trust across multihop ABFAB
	    federations.
	  </t>
	  <t hangText="Trust Link:"><vspace blankLines="1"/> 
	    A Trust Link is an assertion that a given Trust Router
	    is capable of providing a temporary identity to 
	    communicate with another ABFAB entity (either another
	    Trust Router, or a AAA Server within an
	    IdP).
	  </t>
	  <t hangText="Trust Path:"><vspace blankLines="1"/>
	    A Trust Path is a concatenation of Trust Links that
	    can be used by an RP to contruct a transitive trust
	    chain across a federation to a target IdP.
	  </t>
	  <t hangText="Trust Router Protocol:"><vspace blankLines="1"/>
	    The Trust Router Protocol is the
	    mechanism used by two Trust Routers to exchange
	    information about Trust Links and Trust Paths.
	  </t>
	  <t hangText="Community of Interest:"><vspace blankLines="1"/>
	    A Community of Interest defines a group of Services and
	    IdPs that have agreed to cooperate to provide access to a
	    specific set of services only to those users within a 
	    particular community.  Communities of Interest can be 
	    layered on top of the base Trust Router infrastructure to 
	    allow selected access to IdPs that have joined a specific
	    group, or agreed to a set of community-specific policies.
	  </t>
	</list> 
      </t> 
      <t>
	The terms Identity Provider (IdP), Relying Party (RP),
	Subject, and Federation are used as defined in 
	<xref target="I-D.lear-abfab-arch"/>.
      </t>
  </section>
  <!-- ********************************************************** -->
    
  <section title="Motivation">
      <t>
	<xref target="one-to-many"/> shows an example federation where
	the Relying Party Foo, has established relationships with
	various Identity Providers.
      </t>
      <t>
	<figure anchor="one-to-many" title="One-to-many Federation Example">
	  <artwork> 
<![CDATA[ 
 +---------------+
 | Identity      |   
 | Provider      | `..
 | Example-A.org |    `-._
 +---------------+        `..
                             `-._
 +---------------+               `._   +-----------+
 | Identity      |                  `- | Relying   |
 | Provider      | ------------------  | Party Foo |
 | Example-B.org |                 _.- +-----------+
 +---------------+             _,-'
                            ,,'
 +---------------+      _.-'           o
 | Identity      |  _,-'              \|/
 | Provider      | '                   |
 | Example-C.org |                    / \
 +---------------+                  Subject
]]> 
	  </artwork>
	</figure>
      </t>      
      <t>
	When an RP receives a request to access a protected resource
	(or requires authentication and authorization for other
	purposes) the request includes a realm name that indicates the
	IdP the Subject has selected for this exchange. Offering the
	Subject the ability to choose among many different IdPs is
	necessary because a Subject may have, and want to maintain,
	uncorrelated identities in several different realms within a
	single federation (i.e. work, school, social networking,
	etc.).  However, this also places a burden on the RPs to
	establish and maintain business agreements and exchange
	security credentials with a potentially large number of
	Identity Providers.
      </t>
      <t>
	In order for a single-hop federation to function, each IdP
	needs to maintain business agreements and exchange credentials
	with every RP that its Subjects are authorized to access.
	<xref target="mesh"/>, shows the likely outcome, which is that
	a single-hop federation will come to resemble a dense mesh
	topology.
      </t>
      <t>
	<figure anchor="mesh" title="Mesh Federation Example">
	  <artwork> 
<![CDATA[ 
  +---------------+
  | Identity      |   
  | Provider      |-.._
  | Example-A.org |`.  ``-.._
  +---------------+  `-.     ``-..__    +-----------+
                        `.          `--.| Relying   |
  +---------------+       `.      __..--| Party Foo |
  | Identity      |       __:.--''   .-'+-----------+
  | Provider      |_..--''     `. .-'
  | Example-B.org |          .-'.
  +---------------+         .'   '.     +-----------+
                         .-'       -.   | Relying   |
  +---------------+   .-'            `-.| Party Bar |
  | Identity      |.-'     ____....---''+-----------+
  | Provider      |.----'''
  | Example-C.org |
  +---------------+            o
                              \|/
                               |
                              / \
                            Subject
]]> 
	  </artwork>
	</figure>
      </t>      
      <t>
	As discussed in section 2.1.1 of
	<xref target="I-D.lear-abfab-arch"/>, as the number of
	organizations involved in a ABFAB federation increase, static
	configuration may not scale sufficiently.  Also, using a Trust
	Broker to establish keys between entities near the RP and
	entities near the IDP with improve the security and privacy of
	an ABFAB federation.  <xref target="trust-broker"/> shows the
	structure of a federation where each IdP and RP has a single
	connection to the Trust Router infrastructure.
      </t>
      <t>
	<figure anchor="trust-broker" title="Federation Broker">
	  <artwork> 
<![CDATA[ 
  +---------------+ 
  | Identity      | 
  | Provider      |\
  | Example-A.org | `.
  +---------------+   \                             +-----------+
                       \                         .-'| Relying   |
  +---------------+     `. +---------------+   .'   | Party Foo |
  | Identity      |       \|    Trust      |.-'     +-----------+
  | Provider      |........|    Broker     |
  | Example-B.org |       /|               |`-.
  +---------------+     .' +---------------+   `.   +-----------+
                       /                         `-.| Relying   |
  +---------------+   /                             | Party Bar |
  | Identity      | .'                              +-----------+
  | Provider      |/                O
  | Example-C.org |                \|/
  +---------------+                 |
                                   / \
                                 Subject
]]> 
	  </artwork>
	</figure>
      </t>      
      <t>
	To improve the operational scalability and security of large
	ABFAB federations, this document proposes a Trust Broker
	solution consisting of of a set of Trust Routers, as described
	in this document, and the Key Negotiation Protocol (KNP), as
	described in <xref target="I-D.howlett-radsec-knp"/>.
      </t>
    </section>
      <section title="Multihop Federation Example">
        <t>
	  The diagram below shows an example of a successful exchange
	  in a multihop federation using the Trust Router Protocol and
	  KNP:
        </t>
	<t>
	  <figure>
	    <artwork> 
<![CDATA[                  
     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---------------------------------+
   |          |  |                |                |
   +----------+  
                 |                |                |
]]> 
</artwork>
</figure>
	</t>
	<t>
	  A multihop federation exchange matching the above diagram can
	  be summarized as follows:
	  <list style="numbers">
            <t>
              We start with a single federation including four realms,
              each containing a single Trust Router.  The Trust
              Routers are peered, such that their interconnections
              form a multihop federation.
            </t>
            <t>
              A Subject (with an identity in Realm D) attempts to
              access a service provided by a Relying Party in Realm A.
            </t>
            <t>
              The Relying Party does not have direct access to a AAA
              Server in Realm D that it can use to authenticate the
              Subject, 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 AAA Server in
              Realm D, which could then be used to authenticate the
              Subject.
            </t>
            <t>
	      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.
            </t>
	    <t>
	      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.
            </t>
            <t>
	      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 AAA Server
              in Realm D (which is part of Realm D's Identity
              Provider).
	   </t>
           <t>
             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
             <xref target="I-D.lear-abfab-arch"/>.
            </t>
          </list>
        </t>
      </section>

    <!-- ****************************************************** -->

    <section anchor="TrustRouter" title="Trust Router Protocol">
    <t>
      Trust Routers use the Trust Router Protocol to exchange information
      about available Trust Links, and Trust Paths across a federation.
    </t>
    <t>
      The Trust Router Protocol differs from an Internet Routing
      Protocol in a couple of important ways:
      <list style="symbols"> 
	<t>
	  Trust Links are unidirectional.  It can not be assumed that
	  the fact that a Trust Router in Realm A is authorized to create
	  temporary identities to access a Trust Router in realm B, that
	  the opposite is also true (A -> B(T) does not imply B->A(T)).
	</t>
	<t>
	  Realm names are not necessarily hierarchical.  Although 
	  aggregation might be possible as a later optimization, the
	  ability to aggregate realm names based on shared roots is
	  not currently assumed.
	</t>
      </list>
    </t>
    <t>
      In addition to the existence of the links themselves, Trust
      Links have a set of associated attributes that can be used
      for filtering and tree computation, including:
      <list style="symbols"> 
	<t>
	  The cost of the link.
	</t>
	<t>
	  Any security and privacy characteristics associated with the link.
	</t>
	<t>
	  Information indicating how/if the link should be
	  propagated across the federation.  
	</t>
      </list> 
    </t>
    <t>
      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 communicate a similar set of information between Trust
      Routers as would be communicated between Internet Routers
      running BGP.
    </t>
    </section>

    <!-- ******************************************************* -->
    
    <section anchor="TrustPathQuery" title="Trust Path Query">
      <t>
        A Trust Path Query is generated by a RP to request a Trust
        Path to reach a specific realm within a given Community of
        Interest.  If possible, the Trust Router will reply with a
        Trust Path that consists of zero or more Trust Router steps
        and ends with a AAA Server (or a path of multiple AAA Servers)
        within the IdP for the indicated realm.
      </t>
      <t>
	The Trust Path Query is initiated by the RP, and
	the initial query message will contain the destination realm
	and Community of Interest.  
      </t>
      <t>
	When a Trust Path Query is received by a Trust Router, the 
	router will first authenticate the RP, and check
	local policy information to determine whether or not to reply.
      </t>
      <t>
	Assuming that the RP 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 Community of Interest.  If so, the shortest/best
	Trust Path will be returned to the Relying Party.
      </t>
      <t>
	A Trust Path will consist of a list of steps, each of which
	will contain: The type of the step (Trust Router or
	AAA Server), the Community of Interest 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.
      </t>
    </section>
    
    <!-- ********************************************************** -->

    <section anchor="IdentityRequest" title="Temporary Identity Request">
      <t>
	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 AAA infrastructure that can be used by the Relying Party
        to communicate with the Trust Router or AAA Server that
        represents the next step in the Trust Path.  Current thinking
        is that KNP will be used as the protocol mechanism for these
        requests.
      </t>
      <t>
        These Temporary Identities will have a finite lifetime and,
        when authenticated, will include a Radius Attribute/Diameter
        AVP 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.
      </t>
      <t>
	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:
        <list style="numbers">
	  <t>
	    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 Community of Interest 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).
	  </t>
	  <t>
	    The Trust Router will authenticate the Relying Party.  
	  </t>
	  <t>
	    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).
	  </t>
	  <t>
	    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 AAA Server in
	    the Trust Path.
	  </t>
	</list>
      </t>
    </section>
    
    <!-- ********************************************************* -->
    
    <section title="Security Considerations">
      <t>
	This document describes an architecture for the establishment
	of transitive trust across an ABFAB federation.  It describes,
	at a high level, the entities and protocols that will be used
	to establish transitive trust, but it does not describe the 
	actual protocols that will be used in detail.  Those details,
	and the detailed Security Considerations associated with them
	are described in separate documents.
      </t>
      <t>
	It is important to note that the trust established using a 
	transitive trust mechanism described in this document will
	only be as good as the weakest link in the transitive trust
	chain.  To service the needs of a highly sensitive Community
	of Interest, stringent criteria must be applied to join the
	Community, sites must be monitored to ensure that they are
	adhering to the Community's standards, and local policy may
	be required to ensure that the chain of trust does not 
	traverse any untrusted, or insufficiently trusted, realms.
      </t>
    </section>

    <!-- ********************************************************* -->

    <section title="IANA Considerations">
      <t>
	There are no IANA actions required for this document.
      </t>
    </section>
    
    <!-- ********************************************************* -->

    <section title="Acknowledgements">
      <t>
	This document was written using the xml2rfc tool described in
	RFC 2629 <xref target="RFC2629"/>.
      </t>
    </section> 

    <!-- ********************************************************* -->

    <section title="Change Log">
      <section title="Changes from -01 to -02">
	<t>
	  <list style="symbols">
	    <t>Changed the term "Policy Regime" to "Community of
	      Interest" throughout the document.</t>
	    <t>Replaced explicit references to RADIUS and Diameter
	      servers with more generic references to AAA Servers.</t>
	    <t>Minor editorial changes.</t>
	  </list>
	</t>
      </section>
      <section title="Changes from -00 to -01">
	<t>
	  <list style="symbols">
	    <t>Editorial changes, and additional text throughout 
	      document.</t>
	  </list>
	</t>
      </section>
    </section>
  </middle>
  
  <back>
    <references title="Normative References">
      &rfc2119;
      &I-D.lear-abfab-arch; 
      &I-D.howlett-radsec-knp; 
      &I-D.mrw-abfab-trust-router;
    </references>
      
    <references title="Informative References">
      &rfc2629;
    </references>
  </back>
</rfc>
