One document matched: draft-mrw-abfab-trust-router-01.xml

<?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'>
]>

<?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-trust-router-01.txt">
  <front>
    <title abbrev="Trust Router Protocol">Application Bridging for Federation Beyond the Web (ABFAB) Trust Router Protocol</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="S." surname="Hartman" fullname="Sam Hartman">
      <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>
	<email>hartmans@painless-security.com</email>
	<uri>http://www.painless-security.com</uri>
      </address>
    </author>
    <author initials="J." surname="Howlett" fullname="Josh Howlett">
      <organization>JANET(UK)</organization>
      <address>
	<postal>
          <street></street>
          <city></city> <region></region>
          <code></code>
          <country></country>
	</postal>
	<email></email>
	<uri>josh.howlett@ja.net</uri>
      </address>
    </author>
    <date month="October" year="2011" />
    <area>Security</area>

    <abstract>
      <t>
	A Trust Router is an infrastucture element used to construct
	multihop Application Bridging for Federated Authentication
	Beyond the Web (ABFAB) federations, as discussed in
	draft-mrw-abfab-multihop-fed-01.txt.  This document defines
	both the Trust Router Protocol and the Trust Path Query, as
	discussed in the multihop federation document.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
	A Trust Router is an infrastucture element used to construct
	multihop Application Bridging for Federated Authentication
	Beyond the Web (ABFAB) federations, as discussed in
	draft-mrw-abfab-multihop-fed-01.txt.  This document defines
	both the Trust Router Protocol and the Trust Path Query, as
	discussed in the multihop federation document.
      </t>
      <t>
	This document defines the protocol used between Trust Routers
	to exchange information about Trust Paths available within an
	ABFAB federation.  It also defines the messages that a
	federated service will use to obtain Trust Path information
	from its local Trust Router, so that it can use the ABFAB Key
	Negotiation Protocol (KNP) to forge a Chain of Trust across a
	federation.  The Chain of Trust will lead to an
	Authentication, Authorization and Accounting (AAA) Server for
	a user's Identity Provider, which will then be used to
	authenticate and authorize the user.
      </t>
    </section>
    <section title="Requirements 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>
    </section>
    <section title="Trust Router Protocol">
      <t>
	The Trust Router protocol is a TCP-based protocol that is used
	to exchange information between Trust Routers about available
	Trust Links within an ABFAB Federation.
      </t>
      <t>
	As discussed in the multihop federation document, When a Trust
	Router advertises a Trust Link, such as A(T) -> B(T), it is
	making an assertion that Trust Router A is able, and willing,
	to provide temporary identities (via KNP) that can be used to
	reach Trust Router B.  
      </t>
      <t>
	Trust Routers use the information they receive about available
	Trust Links to construct Trust Paths that can be used to reach 
	AAA Servers (i.e. RADIUS or DIAMETER servers) for a set of 
	Identity Providers (IDPs) within a ABFAB federation.  They then
	return the shortest path to a specific IDP in response to Trust
	Path Queries.
      </t>
    </section>
    <section title="Trust Router Messages">
      <section title="Hello Message">
	<t>
	  Hello Messages are the first messages exchanged by Trust
	  Routers when they bring up a new TCP connection, and they
	  may be exchanged at other times to ensure that database
	  information is synchronized, or to trigger a full Trust Link
	  Database download.  The first Hello messages exchanged over
	  a new TCP connection are also used as the vehicle to 
	  establish an authenticated and encrypted GSS-API session.
	</t>
	<t>
	  TBD:  We need to discuss how GSS-API will be used with this
	  protocol.  Maybe we need separate authentication messages
	  before the Hello messages are exchanged?
	</t>
      </section>
      <section title="Trust Link Database Message">
	<t>
	  A Trust Link Database Message contains a full (potentially
	  filtered) set of Trust Links that can be reached through the
	  sending Trust Router.  This message may be quite large, and
	  is only sent when solicited by the receiver.  
	</t>
      </section>
      <section title="Trust Link Update Message">
	<t>
	  Trust Routers send Trust Link Update messages to other
	  Trust Routers to whom they are connected whenever their
	  Trust Link Database is updated.  Trust Link Update messages
	  contain the portions of the Trust Link Database 
	  that have changed since the last update.  They also contain
	  a serial number that can be used by the receiving Trust
	  Router to determine if any updates have been missed, in
	  which case a full Trust Router Database download is needed.
	</t>
      </section>
    </section>
    <section title="Trust Router Operation">
      <t>
	This section describes how Trust Routers work, in general.  Detailed
	message formats are described in later sections of the document.
      </t>
      <section title="Hello Message Exchange">
      </section>
      <section title="Exchanging Initial Trust Link Databases">
      </section>
      <section title="Trust Link Updates">
      </section>
      <section title="Serial Numbers">
	<t>
	</t>
      </section>
      <section title="TCP Connection Handling">
	<t>
	  Trust Routers communicate by exchanging full JSON-encoded
	  messages over a TCP connection.  If incomplete messages
	  are received, or if the TCP connection is interrupted before
	  a complete message is received, the incomplete messages will
	  be discarded, and no protocol actions will be taken based on
	  the contents of the incomplete message.
	</t>
	<t>
	  In the Trust Router Protocol, no information about the
	  availability of Trust Links is inferred from a TCP reset,
	  or a retransmission timeout on the TCP connection to another
	  Trust Router.  A Trust Router is only considered unreachable
	  after an attempt to reestablish a TCP connection to that
	  Trust Router is reset or times out.  
	</t>
	<t>
	  When a Trust Router is found to be unreachable, the Trust
	  Links supplied by that Trust Router are not removed from the
	  local Trust Link Database.  They will however, be marked as
	  deprecated until a connection can be reestablished with the
	  Trust Router that sent them, and it can be verified that the
	  sequence number of that Trust Router's Database still
	  matches the sequence number of the most recent Trust Link
	  information received.
	</t>
	<t>
	  When Trust Links are marked as deprecated, they will not be used
	  if another, non-deprecated path exists to reach the target
	  Identity Provider.  If there are no paths to the target
	  Identity Provider that traverse only non-deprecated Trust
	  Links, a path containing a deprecated Trust Link will be
	  used.
	</t>
      </section>
      <section title="Conceptual Data Structures">
	<section title="Peer Table">
	  <t>
	  </t>
	</section>
	<section title="Trust Link Database">
	  <t>
	  </t>
	</section>
      </section>
    </section>
    <section title="Trust Path Query">
      <section title="Trust Path Query Messages">
	<section title="Trust Path Query Request">
	</section>
	<section title="Trust Path Query Response">
	</section>
      </section>
      <section title="Trust Path Query Operation">
      </section>
    </section>
    <section title="Message Representation">
      <t>
	This section provides details about the contents and encoding of both
	Trust Router Protocol messages and Trust Path Query messages.
      </t>
      <section title="Message Encoding">
	<t>
	  The Trust Router Protocol and Trust Path Query messages are
	  encoded in JavaScript Object Notation (JSON) [RFC4627].
	</t>
      </section>
      <section title="Hello Message Representation">
	<t>
	  Name or Realm (??)
	  Auth-Token (??)
	  Database-Serial-Number
	  Database-Request
	</t>
	<t>
	  TBD: It is unclear what sort of authentication information
	  needs to be in this message for GSS-API authentication.
	</t>
	<t>
	  Database-Serial-Number field contains the current serial
	  number of the sending Trust Router's Trust Link Database.
	  This information may be used by a receiving Trust Router to
	  determine whether it should request a full Trust Link
	  Database download.
	</t>
	<t>
	  The Database-Request field indicates whether the
	  receiving Trust Router should respond to this message with
	  a Trust Link Database message, to share its full Trust
	  Link Database with the sending Trust Router.  If this field
	  has a value of "true", a download is requested.  If it is 
	  "false", a download is not requested.
	</t>
      </section>
      <section title="Trust Link Database/Update Representation">
	<t>
	  In the Trust Router Protocol, each Trust Router will send a 
	  (potentially filtered) set of Trust Links to its neighboring
	  Trust Routers.  The representation of these Trust Links is
	  designed for efficient encoding, and to allow easy population
	  of a conceptual Trust Link Table  on the receiving Trust 
	  Router.  Each Trust Router will only distribute a set of 
	  Trust Links that form a connected tree rooted at the sending
	  Trust Router.
	</t>
	<t>
	  Conceptually, a Trust Link consists: 
	  <list style="symbols">
	    <t>A Trust Router that is willing to provide a temporary identity.</t>
	    <t>The Trust Router or AAA Server which the identity can be provided </t>
	    <t>The Communities-of-Interest to whom the link is available.</t>
	    <t>A lifetime for this link, in seconds.</t>
	  </list>
	  However, the actual Trust Links passed in the Trust Router
	  protocol rely on inference and ordering to eliminate the need
	  to include the first Trust Router identity in each distributed
	  link.  Instead, we use an Index variable, which indicates each
	  Trust Link's level in a conceptual tree, and we order the
	  Trust Links, so that a Trust Link with an Index of N
	  is subordinate to the closest previous Trust Link with an
	  index of N-1 that applies to the same Community-of-Interest.
	  Each conceptual tree is rooted at the sending Trust Router, 
	  which is represented by an an entry with an Index value of 0.
	</t>
	<section title="Trust Link Ordering">
	  <t>
	  </t>
	</section>
	<section title="Entity Identity">
	  <t>
	    When we send Trust Router or AAA Server identities in the 
	    Trust Router Protocol, that information will be sent in an
	    Entity Identity structure containing the following fields:
	    <list style="symbols">
	      <t>Name</t>
	      <t>Type</t>
	      <t>Realm</t>
	    </list>
	  </t>
	  <t>
	    The Name field will typically contain a fully-qualified domain
	    name (FQDN) that can be used to reach the indicated entity (e.g.
	    "tr-A.example.net").
	  </t>
	  <t>
	    The Type field indicates that the entity is a Trust Router
	    (Type = "T") or a AAA Server (Type = "R", "D", or "S" for
	    a RADIUS Server, DIAMETER Server or RADSEC Server,
	    respectively).
	  </t>
	  <t>
	    The Realm field contains the security realm associated with the
	    entity (e.g. "example.net").
	  </t>
	</section>
	<section title="Trust Link Entry">
	  <t>
	    As transmitted in the Trust Router Protocol, a Trust Link
	    entry will have the following fields:
	    <list style="symbols">
	      <t>Index</t>
	      <t>Target-Entity</t>
	      <t>Communities-of-Interest</t>
	      <t>Lifetime</t>
	    </list>
	  </t>
	  <t>
	    The Index field contains a non-zero integer value,
	    indicating the depth of this Trust Link in a conceptual tree
	    of links rooted at the sending Trust Router.  The maximum
	    value of this field is 255.
	  </t>
	  <t>
	    The Target-Entity field contains a the Trust Router or AAA
	    Server for which temporary identities can be generated.
	    This also represents the Trust Router that can generate
	    identities for any directly subordinate nodes in the
	    conceptual tree.
	  </t>
	  <t>
	    The Communities-of-Interest field contains an array of
	    strings, each containing a Community-of-Interest for which
	    this link is available.
	  </t>
	  <t>
	    The Lifetime field contains an integer that indicates the
	    lifetime of this Trust Link in seconds.  Links are removed
	    from the the conceptual Trust Link Table if their lifetime
	    expires.
	  </t>
	</section>
	<section title="Trust Link Database Message">
	  <t>
	    A Trust Link Databases will consist two fields:
	    <list style="symbols">
	      <t>Serial-Number</t>
	      <t>Trust-Links</t>
	    </list>
	  </t>
	  <t>
	    The Serial-Number field contains an integer indicating the
	    version of the information contained in this database.  The
	    maximum value for this field is (2^32 - 1).
	  </t>
	  <t>
	    The Trust-Links field contains an array of Trust Link 
	    Entries.
	  </t>
	</section>
	<section title="Trust Link Update Message">
	  <t>
	  </t>
	</section>
      </section>
      <section title="Trust Path Query Representation">
	<section title="Trust Link Query Request">
	  <t>
	    TBD: Pending resolution of open architectural questions
	    regarding what will be queried/returned in these
	    messages.
	  </t>
	</section>
	<section title="Trust Link Query Response">
	  <t>
	    TBD: Pending resolution of open architectural questions
	    regarding what will be queried/returned in these
	    messages.
	  </t>
	</section>
      </section>
      <section title="Message Examples">
	<t>
	  This section contains example of Trust Router Protocol and Trust
	  Query messages encoded in JSON, as they will be sent over the
	  nework.
	</t>
	<section title="Hello Message Example">
	  <t>
	  </t>
	</section>
	<section title="Trust Link Database Example">
	  <t>
	  </t>
	</section>
	<section title="Trust Link Update Example">
	  <t>
	  </t>
	</section>
	<section title="Trust Path Query Request Example">
	  <t>
	    TBD: Pending resolution of open architectural questions
	    regarding what will be queried/returned in these
	    messages.
	  </t>
	</section>
	<section title="Trust Path Query Response Example">
	  <t>
	    TBD: Pending resolution of open architectural questions
	    regarding what will be queried/returned in these
	    messages.
	  </t>
	</section>
      </section>
    </section>
    <section title="Security Considerations">
      <t>
	[TBD]
      </t>
    </section>
    <section title="IANA Considerations">
      <t>
	IANA has allocated the following TCP port numbers for use by 
	protocols described in this document:
      </t>
      <t>
	[TBD]
      </t>
    </section>
    <section title="Acknowledgements">
      <t>
	This document was written using the xml2rfc tool described in RFC 2629
	<xref target="RFC2629"/>.
      </t>
      <t>
	The following people provided useful comments or feedback on this 
	document: Daniel Kouril, Linus Nordberg, Rhys Smith, Kevin Wasserman.
      </t>
    </section> 
    <section title="Change Log">
      <section title="Changes between -00 and -01">
	<t>
	  <list style="symbols">
	    <t>Minor revisions, added authors.</t>
	  </list>
	</t>
      </section>
    </section>
</middle>
  
  <back>
    <references title="Normative References">
      &rfc2119;
    </references>
      
    <references title="Informative References">
      &rfc2629;
    </references>
  </back>
</rfc>