Moonshot Project
Trust Router Functional Specification
Revision History:
0.1
Margaret Wasserman
0.9
Margaret Wasserman
1.0
Margaret Wasserman
29-May-2012
1-June-2012
3-June-2012
First Draft for Review
Reflects feedback on First Draft
More updates based on feedback/discussion
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
1
TABLE OF CONTENTS
1.
Trust Router Overview .................................................................................................... 4
1.1
1.2
1.3
Introduction ................................................................................................................................................................... 4
Related IETF Work ...................................................................................................................................................... 4
Terminology ................................................................................................................................................................... 5
2.
Trust Router Operations ................................................................................................. 6
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.1.9
3.
Trust Router Protocol Operational Overview...................................................................................................6
Trust Path Query Operational Overview ............................................................................................................9
Step 0: Trust Router Protocol ..................................................................................................................................9
Step 1: Trust Path Query Request ..........................................................................................................................9
Step 2 & 3: Trust Path Traversal ........................................................................................................................ 10
Step 4: Temporary Identity Provisioned .......................................................................................................... 10
Step 5: Trust Path Query Response..................................................................................................................... 10
Step 6: AAA Authentication .................................................................................................................................... 10
Step 7: Temporary Identity Look-Up ................................................................................................................. 10
Trust Router Protocol Details ........................................................................................ 11
3.1 Trust Router Messages ............................................................................................................................................ 11
3.1.1 Hello Message ............................................................................................................................................................... 11
3.1.2 Trust Link Database Message ............................................................................................................................... 11
3.1.3 Trust Link Update Message.................................................................................................................................... 11
3.1.4 Serial Numbers ............................................................................................................................................................ 12
3.1.5 TCP Connection Handling ....................................................................................................................................... 12
3.2 Communities of Interest.......................................................................................................................................... 13
3.2.1 Communities of Registration................................................................................................................................. 13
3.2.2 COIs Managed by a COR........................................................................................................................................... 13
3.2.3 COIs Independent from CORs ................................................................................................................................ 13
4.
Trust Path Query Details ............................................................................................... 14
4.1 Trust Path Query Messages ................................................................................................................................... 14
4.1.1 Trust Path Query Request ....................................................................................................................................... 14
4.1.2 Trust Path Query Response .................................................................................................................................... 14
4.1.3 Trust Path Forwarding Request .......................................................................................................................... 14
4.1.4 Trust Path Forwarding Response ....................................................................................................................... 14
4.1.5 Temporary Identity Request.................................................................................................................................. 14
4.1.6 Temporary Identity Response ............................................................................................................................... 15
5.
High-Level Architecture................................................................................................. 16
5.1 Conceptual Datastructures .................................................................................................................................... 16
5.1.1 Peer Table ...................................................................................................................................................................... 16
5.1.2 Trust Link Database .................................................................................................................................................. 16
5.2 Architectural Elements ............................................................................................................................................ 16
5.2.1 Peer Table Manager .................................................................................................................................................. 16
5.2.2 Trust Link Database Manager.............................................................................................................................. 16
5.2.3 Trust Path Query Client ........................................................................................................................................... 16
5.2.4 Trust Path Query Server .......................................................................................................................................... 16
5.2.5 Trust Path Forwarding Client ............................................................................................................................... 16
5.2.6 Trust Path Forwarding Server ............................................................................................................................. 16
5.2.7 Temporary Identity Client ...................................................................................................................................... 16
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
2
5.2.8 Temporary Identity Server ..................................................................................................................................... 16
5.3 Functional Elements ................................................................................................................................................. 16
5.3.1 Trust Router .................................................................................................................................................................. 16
5.3.2 Relying Party ................................................................................................................................................................ 16
5.3.3 Identity Provider ......................................................................................................................................................... 16
5.4 Naming ........................................................................................................................................................................... 17
Message Representation ..................................................................................................... 18
5.5 Common Message Encoding .................................................................................................................................. 18
5.6 Trust Router Protocol message Encoding ....................................................................................................... 18
5.6.1 Hello Message Representation.............................................................................................................................. 18
5.6.2 Trust Link Database/Update Representation ............................................................................................... 18
5.6.3 Trust Link Database Update Message............................................................................................................... 20
5.7 Trust Path Query Message Representation..................................................................................................... 21
5.7.1 Trust Path Query Request ....................................................................................................................................... 21
5.7.2 Trust Path Query Response .................................................................................................................................... 21
5.7.3 Temporary Identity Request.................................................................................................................................. 21
5.7.4 Temporary Identity Response ............................................................................................................................... 21
5.7.5 Credential Provisioning Request ......................................................................................................................... 21
5.7.6 Credential Provisioning Response....................................................................................................................... 21
6.
Configuration and Management ................................................................................... 22
6.1 Configuration Information ..................................................................................................................................... 22
6.1.1 Static vs. Runtime Configuration......................................................................................................................... 22
6.1.2 Persistence ..................................................................................................................................................................... 22
6.2 Operational State........................................................................................................................................................ 22
6.2.1 Monitoring ..................................................................................................................................................................... 22
6.2.2 Persistence ..................................................................................................................................................................... 22
7.
Implementation Notes .................................................................................................. 23
7.1 Datastructure Implementation ............................................................................................................................ 23
7.2 Integration with Existing Moonshot Elements .............................................................................................. 23
7.2.1 Trust Path Query Client ........................................................................................................................................... 23
7.2.2 Temporary Identity Server ..................................................................................................................................... 23
7.2.3 All Other Architectural Elements ........................................................................................................................ 23
7.3 Staged Implementation/Deployment................................................................................................................ 23
7.3.1 Initial Deployment ..................................................................................................................................................... 23
7.3.2 Limited COI Support .................................................................................................................................................. 24
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
3
1. Trust Router Overview
1.1 Introduction
A Trust Router is a proposed element in an ABFAB Federation that allows information
about how a Relying Party (RP) can reach a AAA Server for a specified Identity
Provider (IdP) realm to be dynamically propagated throughout an ABFAB Federation.
Trust Routers also provide a mechanism for dynamic key generation between a Relying
Party’s AAA client and an Identity Provider’s AAA Server, over a transitive Trust Path
across the Federation.
This document is intended to be a living document, which will be maintained and
updated throughout the Trust Router implementation to reflect the actual functionality of
Trust Routers and related elements. At this point, the document is intended to describe
the functionality of a Trust Router and related elements well enough to support scoping
and planning of the detailed design and implementation of those elements.
1.2 Related IETF Work
Development of a Trust Router Protocol is under discussion in the IETF. The following
document describes the problems that an ABFAB Trust Router is expected to address:
draft-howlett-abfab-trust-router-ps-02
The following IETF documents describe an earlier version of Multihop ABFAB
Federations, including an earlier version of the Trust Router protocol:
draft-mrw-abfab-multihop-fed-02
draft-mrw-abfab-trust-router-01
It is expected that the Multihop Federations and Trust Router documents above will be
updated in the future to match the contents of this document.
This document assumes that the reader is already familiar with ABFAB Federations and
how they work. In particular, people should have read and understood the following
IETF documents:
draft-ietf-abfab-arch-02
draft-ietf-abfab-usecases-02
draft-ietf-abfab-gss-eap-07
draft-ietf-abfab-aaa-saml-03
draft-ietf-abfab-gss-eap-naming-02
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
4
1.3 Terminology
A Trust Link asserts that one Trust Router is willing and able to forward Trust Path
Requests to another Trust Router or AAA Server. Each Trust Link includes a list of
Communities-of-Interest (COIs) to which the link applies. Trust Routers build trees,
one tree per COI, of Trust Links that can be used to determine the best path to reach a
AAA server for a specified realm.
Trust Links can be represented as a starting realm and a target realm, connected by an
arrow. The type of each entity is included in parenthesis after the real name. So, for
example, a Trust Link between two Trust Routers for realsm A and B can be
represented as: A(T) -> B(T). A Trust Link between a Trust Router in the example.net
realm, and a RADIUS server in the same realm would be representaed as:
example.net(T) -> example.net (R).
A Trust Path is a set of Trust Links that can be used by a specific Relying Party (RP)
to reach a AAA Server in the domain of a specific Identity Provider (IdP).
A Community of Interest (COI) represents a group of IdPs and RPs that share a set of
resources. [Open question: How is membership within a Community of Interest
securely determined – a GSS-API exchange between members?]
A Community of Registration (COR) represents a group of IdPs and RPs that use a
common registration provider for authentication. A COR is a specialized form of COI.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
5
2. Trust Router Operations
The functionality of a Trust Router can be broken into two major pieces: the Trust
Router Protocol, and the Trust Path Query mechanism.
The Trust Router Protocol is used between Trust Routers to propagate information
about available Trust Links within a federation. It runs on an ongoing basis between
Trust Routers, with updates being flooded across the Trust Router network, as
necessary.
The Trust Path Query mechanism is used when an RP needs to reach a AAA Server for
a specified IdP. The RP sends a request to a local Trust Router. The local Trust
Router then sets up a transitive Trust Path across the federation, and facilitates a DiffieHellman key exchange between the RP’s AAA Client and the IdP’s AAA Server, across
the transitive Trust Path. After the keys have been exchanged, the AAA Client
communicates directly with the AAA Server for user authentication.
2.1.1 Trust Router Protocol Operational Overview
Trust Router Protocol
B(T) -> C(T)
C(T) -> C(A)
B(T) -> E(T)
E(T) -> F(T)
F(T) -> F(A)
A
D(T) -> E(T)
E(T) -> F(T)
F(T) -> F(A)
D
C
C(T) -> C(A)
Realm C
AAA
B
E(T) -> F(T)
F(T) -> F(A)
E(T) -> F(T)
F(T) -> F(A)
E
F(T) -> F(A)
Trust Links (administra vely established)
F
Realm F
AAA
Trust Path propaga on via Trust Router messages
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
6
The Trust Router Protocol is used to exchange information about available Trust Links
within an ABFAB Federation. This information is used by Trust Routers to determine
the best Trust Path to use for transitive trust establishment across the federation.
The Trust Router Protocol runs between pairs of Trust Routers. Each Trust Router will
have one or more peers with whom it exchanges information about it’s own Trust Link
Database, including it’s locally-configured Trust Links, and Trust Link information that
the local Trust Router has received from other peers.
Each Trust Router uses the information that it has received from peers to create trees of
all of the available transitive Trust Paths, rooted at the local Trust Router. A Trust
Router will, at least conceptually, maintain one tree of Trust Paths per COI.
The diagram above shows a portion of the Trust Link information that might be
propagated between 6 Trust Routers for 2 AAA Servers, all within a single COI. The
dashed red arrows represented administratively configured, unidirectional or
bidirectional Trust Links between realms. The Blue arrows represent the flow of Trust
Link Database information for the two AAA Servers shown in the diagram – the Realm
C AAA Server, and the Realm F AAA Server. The Trust Router in realm A receives two
Trust Link Databases, one from Trust Router B, and one from Trust Router D. Trust
Router A can build a tree from this information that shows two possible paths from Trust
Router A to a AAA Server in Realm F:
A(T) -> B(T) -> E(T) -> F(T) -> F(A)
A(T) -> D(T) -> E(T) -> F(T) -> F(A)
The Trust Link between Realm B and Realm E is unidirectional, so there is only one
Trust Path between Realm A and the AAA Server in Realm C:
A(T) -> B(T) -> C(T) -> C(A)
2.1.1.1 Local Configuration
Before a Trust Router starts running the Trust Router Protocol, it will need to be
configured with a set of information about its own Trust Links, and a list of peers with
whom it should share Trust Link information. This list will include:
Trust Links for locally-attached AAA Servers, including credentials to
communicate with those servers;
Trust Links to realms for which this Trust Router can provide temporary
identities
A list of Trust Router peers, including credentials to authenticate with
those peers.
2.1.1.2 Trust Router Start-Up
When a Trust Router first comes up on the network, it will attempt to establish an
authenticated connection with each of its peers.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
7
When a peering connection is established, the Trust Router will send a Hello message
containing a previously unused sequence number, and requesting a Link Database
Download from each peer.
The new sequence number should result in the peer requesting a Trust Link Database
upload, as well. When a new Trust Router with several peers comes up on the network,
multiple Trust Link Database uploads and updates may be needed before the Trust Link
Databases settle into their new configuration.
2.1.1.3 Normal Operation
During normal operation, a Trust Router will maintain open TCP connections with its
peers, and will send regular Hello messages to each of its peers to ensure that the TCP
connections are up and that the current Trust Link Database information is up-to-date.
When there is a change to the Trust Link Database (typically initiated by a configuration
change on one or more Trust Routers), the new information will be propagated
throughout the network of Trust Routers using Trust Link Database Update messages.
When a Trust Router sends a Trust Link Database Message or a Trust Link Database
Update Message to another Trust Router, it will not include information about Trust
Paths that flow through the receiving Trust Router. This will avoid loops from forming in
the Trust Link Database on the receiving Trust Router.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
8
2.1.2 Trust Path Query Operational Overview
Trust Path Query
Relying party
domain
Trust Router
Trust Router Trust Router
0
0
2
3
1
Iden ty Provider
domain
4
5
7
AAA
client
0: Trust Router Protocol
1: Trust Path Query Request
2: Trust Path Traversal (first hop)
3: Trust Path Traversal (subsequent hop)
AAA
server
6
4: Temporary Iden ty Provisioned
5: Trust Path Query Response
6: AAA Authen ca on
7: Temporary Iden ty Look-up
2.1.3 Step 0: Trust Router Protocol
Before authentication begins, the Trust Routers have exchanged information about
available Trust Links via the Trust Router Protocol, as described above.
2.1.4 Step 1: Trust Path Query Request
A Relying Party (RP) sends a Trust Path Query Request to its local Trust Router find a
AAA server for a specific realm and COI.
Trust Path Query responses may be cached on the RP for an indicated lifetime. RPs
that implement a cache will check the cache for matching entries before sending a Trust
Path Query Request.
The Trust Path Query Request and Response messages each contain half of a DiffieHellman exchange. This information is used to generate keys that will be used for a
direct AAA connection between a AAA Client (or Proxy) in the RP and a AAA Server in
the IdP realm.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
9
2.1.5 Step 2 & 3: Trust Path Traversal
Upon receiving an authorized Trust Path Query Request, the RP’s local Trust Router
traverses the Trust Path between itself and a Trust Router local to the AAA server for
the target realm. To do this, the local Trust Router builds a Trust Path Forwarding
Request containing the full desired path, and forwards the request to the next Trust
Router in the chosen path. Successive Trust Routers will forward the request along the
chosen path, until the request reaches a Trust Router that serves the IdP realm. After a
temporary identity is provisioned (see below) a Trust Path Forwarding Response is
forwarded back over the reverse path.
Trust Path Query Request messages also contain constraints about the RP, and
Response messages contain constraints about the IdP – what hostnames/realms they
are allowed to claim, etc.
2.1.6 Step 4: Temporary Identity Provisioned
When a Trust Path has been determined, the Trust Router local to the AAA server for
the target realm will provision a temporary identity on the AAA Server(s) in the target
realm. This will be accomplished by issuing a Temporary Identity Request to the target
AAA server, based on information from the Trust Path Forwarding Request.
Information from the Temporary Identity Response will be used to construct the Trust
Path Forwarding Response, which is then forwarded back over the Trust Router
network toward the RP.
2.1.7 Step 5: Trust Path Query Response
The RP’s local Trust Router will respond to the Trust Path Query Request with
information about how to reach a AAA server for the target realm. This will include
temporary credentials that can be used to authenticate with the target AAA server.
Trust Path Query Responses also contain a lifetime that indicates the maximum amount
of time that an RP can cache information received in the response.
2.1.8 Step 6: AAA Authentication
The RP then performs AAA Authentication, as usual, using the provided credentials.
2.1.9 Step 7: Temporary Identity Look-Up
During AAA Authentication, the AAA Server will check the credentials that were
provisioned via the Temporary Identity Request, in order to authenticate the RP’s AAA
Client.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
10
3. Trust Router Protocol Details
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.
When a Trust Router advertises a Trust Link, such as A(T) -> B(T), it is making an
assertion that a Trust Router in realm A is able, and willing, to forward Trust Path
Forwarding Requests to a Trust Router in realm B.
Trust Routers use the information they receive about available Trust Links to construct
Trust Paths that can be used to reach a AAA Server (i.e. a RADIUS or DIAMETER
server) for a target IdP.
Trust Routers mediate a Diffie-Hellman exchange between a AAA Client in the RP and
a AAA Server in the IdP realm, to generate keys that can be used for the subsequent
AAA user authentication.
[Note: Need more information about how a D-H exchange works, to understand exactly
what needs to be included in these messages.]
3.1 Trust Router Messages
3.1.1 Hello Message
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 TCP
connections remain active, to ensure that database information remains synchronized,
and/or to trigger a full Trust Link Database download when a Trust Link Database is
lost.
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 between two
Trust Routers.
3.1.2 Trust Link Database Message
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.
3.1.3 Trust Link Update Message
Trust Routers send Trust Link Update messages to their peers 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 will be
needed.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
11
3.1.4 Serial Numbers
A Serial Number is used as an epoch for a Trust Router’s Trust Link Database. When a
Trust Router boots for the first time it will choose a pseudo-random serial number.
From that time forward, the serial number will be incremented every time the information
in the Trust Link Database is lost, reset or modified. A Trust Router sends its current
Serial Number in each Hello Message, Trust Link Database Message or Trust Link
Database Update.
When a Trust Router syncs its database with a peer, it keeps track of the current serial
number in use by that peer. A Trust Router will not apply any Trust Link Database
Updates received from a peer unless they include the next expected serial number (1
more than the last Serial Number synced). If a Trust Router receives any message
from a peer with an unexpected serial number, the receiving Trust Router will discard
the Trust Link Database entries associated with that peer, and request a complete Trust
Link Database download from the peer. This is most likely to happen if a Trust Router
is off-line for some time, or if a TCP connection between two Trust Router peers goes
down for an extended period.
3.1.5 TCP Connection Handling
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.
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 attempts to
reestablish a TCP connection to that Trust Router reset or time out for a configurable
period of time.
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.
When Trust Links are marked as deprecated, they will not be used if another, nondeprecated 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.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
12
3.2 Communities of Interest
3.2.1 Communities of Registration
3.2.2 COIs Managed by a COR
3.2.3 COIs Independent from CORs
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
13
4. Trust Path Query Details
4.1 Trust Path Query Messages
4.1.1 Trust Path Query Request
The Trust Path Query Request is sent from an RP to a local Trust Router, asking the
Trust Router to traverse the Trust Path and return a AAA Server and credentials that the
RP can use to authenticate a user in the target realm.
4.1.2 Trust Path Query Response
The Trust Path Response is sent from a local Trust Router to the RP in response to a
Trust Path Query Request. It primarily contains contact information for a AAA Server
(or a list of AAA Servers?) in the target realm, and the credentials that the RP can use
to contact the AAA Server. A lifetime is included, and an RP can cache the results for
the indicated lifetime.
4.1.3 Trust Path Forwarding Request
A Trust Path Forwarding Request is sent from one Trust Router to another. Although
the two Trust Routers do not need to be peers in the context of the Trust Router
protocol, the sending Trust Router does need credentials to establish a secure
connection with the receiving Trust Router.
A Trust Path Forwarding Request is used to forge a transitive chain of trust between an
RP and a target IdP.
Intermediate Trust Routers do not perform Trust Link Database lookups before
forwarding the Trust Path Forwarding Request along the path – they use the Trust Path
included in the Trust Path Forwarding Request to determine the next hop in the chain.
4.1.4 Trust Path Forwarding Response
A Trust Path Forwarding Response is returned after a Trust Router in the target IdP has
provisioned a temporary identity for use in a subsequent AAA authentication. It is
forwarded back along the Trust Path that was used for the Trust Path Query Request. It
contains contact information for a AAA Server in the target realm, and a set of security
credentials that can be used to talk to that AAA Server.
4.1.5 Temporary Identity Request
A Temporary Identity Request is sent from a Trust Router that serves the target IdP to a
AAA Server (or a configuration database used by the AAA server?) within the target
IdP. It is a request to provision temporary credentials that can be used by the indicated
RP to access a AAA Server.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
14
4.1.6 Temporary Identity Response
A Temporary Identity Response is returned in response to a Temporary Identify
Request, and contains the credentials that the indicated RP should use to access the
indicated AAA Server.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
15
5. High-Level Architecture
5.1 Conceptual Datastructures
5.1.1 Peer Table
5.1.2 Trust Link Database
5.2 Architectural Elements
5.2.1 Peer Table Manager
5.2.2 Trust Link Database Manager
5.2.3 Trust Path Query Client
5.2.4 Trust Path Query Server
5.2.5 Trust Path Forwarding Client
5.2.6 Trust Path Forwarding Server
5.2.7 Temporary Identity Client
5.2.8 Temporary Identity Server
5.3 Functional Elements
5.3.1 Trust Router
A Trust Router is an infrastructure element in an ABFAB Federation that consists of a
Peer Table Manager, a Trust Link Database Manager, a Trust Path Query Server, a
Trust Path Forwarding Client, a Trust Path Forwarding Server, and a Temporary Identity
Client.
5.3.2 Relying Party
A node in the Relying Party realm, typically a AAA Proxy, will implement a Trust Path
Query Client. All of the Trust Path lookups and Temporary Identity requests performed
by Trust Routers begin with a Trust Path Query Client sending an authenticated Trust
Path Query Request to a local Trust Router.
5.3.3 Identity Provider
For each Identity Provider with an ABFAB Federation, there will be at least one AAA
Server that implements a Temporary Identity Server.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
16
5.4 Naming
Within the Trust Router protocol, strings are used to identify Realms and COIs. This
section describes how those names are assigned and formatted.
Current thinking is that Realms will be derived from DNS domains, e.g. the Janet Realm
might be ‘ja.net’. COI names will scoped to the Realm that is responsible for
authenticating COI membership, e.g. ‘ja.net: three-physics-researchers’.
[More thought/specification is needed in this area as part of the detailed design
process.]
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
17
Message Representation
This section provides details about the contents and encoding of both Trust Router
Protocol messages and Trust Path Query messages.
5.5 Common Message Encoding
The Trust Router Protocol and Trust Path Query messages are encoded in JavaScript
Object Notation (JSON) [RFC4627].
5.6 Trust Router Protocol message Encoding
5.6.1 Hello Message Representation
A Hello Message consists of the following fields:
Name
Realm
Authentication-Information
Database-Serial-Number
Database-Request
The 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.
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.
5.6.2 Trust Link Database/Update Representation
In the Trust Router Protocol, a Trust Router will send a (potentially filtered) set of Trust
Links to each of 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.
Conceptually, a Trust Link consists of:
A Trust Router that is willing to provide a temporary identity.
The Trust Router or AAA Server for which the identity can be provided
The COIs to whom the link is available.
A lifetime for this link, in seconds.
A list of attributes associated with the link
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
18
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 entry with an Index value of 0.
5.6.2.1 Entity Identity
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:
Name
Type
Realm
Attribute-List
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").
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).
The Realm field contains the security realm associated with the entity (e.g.
"example.net").
The Attribute-List, which may be empty, contains any other attributes associated with
this entity.
5.6.2.2 Trust Link Entry
As transmitted in the Trust Router Protocol, a Trust Link entry will have the following
fields:
Index
Target-Entity
COI-List
Lifetime
Attribute-List
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.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
19
The Target-Entity field contains the target of this link – a Trust Router to which Trust
Path Forwarding Requests can be sent, or a AAA Server on which Temporary Identities
can be provisioned.
The COI-List field contains an array of strings, each containing a Community-of-Interest
for which this link is available.
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.
The Attribute-List, which may be empty, contains a list of attributes associated with this
Trust Link.
5.6.2.3 Trust Link Database Message
A Trust Link Databases will consist two fields:
Serial-Number
Trust-Links
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).
The Trust-Links field contains a list of Trust Link Entries.
5.6.3 Trust Link Database Update Message
A Trust Link Database Update will consist three fields:
Serial-Number
Starting-Point
Trust-Links
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).
The Starting-Point field will indicate the portion of the tree previously received from this
Trust Router that should be replaced by the Trust Links contained in this message.
The Trust-Links field contains a list of Trust Link Entries.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
20
5.7 Trust Path Query Message Representation
5.7.1 Trust Path Query Request
5.7.2 Trust Path Query Response
5.7.3 Temporary Identity Request
5.7.4 Temporary Identity Response
5.7.5 Credential Provisioning Request
5.7.6 Credential Provisioning Response
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
21
6. Configuration and Management
6.1 Configuration Information
6.1.1 Static vs. Runtime Configuration
6.1.2 Persistence
6.2 Operational State
6.2.1 Monitoring
6.2.2 Persistence
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
22
7. Implementation Notes
7.1 Datastructure Implementation
7.2 Integration with Existing Moonshot Elements
7.2.1 Trust Path Query Client
It is expected that the Trust Path Query Client will co-reside with a AAA Proxy near the
RP. For our initial implementation, it is expected that the Trust Path Query Client will be
integrated with a FreeRADIUS AAA Proxy.
7.2.2 Temporary Identity Server
The Temporary Identity Server will either co-reside with a AAA Server for the IdP, or it
will have access to the data that is used by the AAA Server when performing
authentication. In our initial implementation it is expected that the Temporary Identity
Server will be integrated with a FreeRADIUS AAA Server.
7.2.3 All Other Architectural Elements
All other Architectural Elements (a Peer Table Manager, a Trust Link Database
Manager, a Trust Path Query Server, a Trust Path Forwarding Client, a Trust Path
Forwarding Server, and a Temporary Identity Client) will run as a standalone Trust
Router software implementation. It is expected that our initial implementation will MIT
Kerberos GSS-API Library and the Moonshot mech_eap GSS-API mechanism.
7.3 Staged Implementation/Deployment
7.3.1 Initial Deployment
As Moonshot deployment becomes more widespread, we anticipate a need for Trust
Routers to reduce the effort involved in adding new members to CORs or COIs.
In order to make it possible to incrementally deploy Trust Routers in a way that is
transparent to federation members, it may be desirable to deploy a system, as soon as
possible, that includes a Trust Path Query Client in the RP and a Temporary Identity
Server in the IdP, even though we do not yet have a full Trust Router implementation
capable of running the Trust Router Protocol between Trust Routers.
This system would involve a single “Trust Router” that has been administratively
configured with a Trust Link Database that includes direct connections to all of the RPs
and IdPs that it serves. This box would facilitate a Diffie-Hellman key exchange
between the RP and IdP, just as a full Trust Router would, thus allowing later
deployment of a full Trust Router infrastructure in a way that is transparent to existing
federation members (the RPs and IdPs).
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
23
In order to accomplish this, it is recommended that our Trust Router implementation
schedule be structured to make the following elements available well in advance of a full
Trust Router implementation:
A Trust Path Query Client (for the RP AAA Proxy)
A Temporary Identity Server (for the IdP)
A “Trust Router” that only includes a Trust Path Query Server, a
Temporary Identity Client and a statically configured Trust Link
Database where all links are terminal (i.e. point directly to AAA Servers
in a target IdP).
After these elements are deployed, the full Trust Router infrastructure can be
implemented and rolled out on an incremental basis.
7.3.2 Limited COI Support
Another possible implementation and deployment plateau would be a fully functional
Trust Router implementation that only handles COIs that are managed by CORs.
Support could be added, later, for COIs that are independently managed.
Moonshot Project: Trust Router Functional Specification
Copyright Janet(UK). All Rights Reserved.
24
