When the APC and IdP already share a valid key (it was establish via Trust Router at an earlier point), but the RP and IdP don't yet share a key, then the protocol flow that enables an RP and an IdP to securely establish a connection is a simple 27 step process (!) that ultimately ends up with the RP and IdP having a shared set of keys each to be used for secure communications. This page details this protocol flow.

Contents

1. Overview

This protocol flow represents the intermediate level of difficultly for Trust Router - the RP and IdP don't yet share a key and want to establish one, but the APC and IdP do. This means a one step Trust Router transaction is required, instead of the recursive two step process when no keys at all exist (see Trust Router Protocol Flows with No Established Keys).

2. Detail

The steps of the protocol flow for Trust Router in this case are split into the following phases:

Phase 1 - The Moonshot RP asks the Trust Router to establish keys with the Moonshot IdP that is responsible for the realm "@idp"
Phase 2 - Mutual Authentication between Trust Router and IdP
- Phase 2a - Trust Router authenticates to IdP
- Phase 2b - IdP authenticates to Trust Router.
Phase 3 - Key Exchange between RP and IdP, mediated by Trust Router.
Phase 4 - RP and IdP connect

Step by step detail for each of these phases is detailed below.

If you don't know what "TIDC", "TIDS", and other such acronyms used below, then a detailed description of each of the components of Trust Router is available which should explain it all.

Trust Router protocol flow where APC and IdP already share a key

Preamble:

A Moonshot client has attempted to connect to a Moonshot enabled-service on a RP. To enable the authentication to happen, the RP must facilitate the establishment of a secure tunnel from the Moonshot Client to the relevant IdP, via its RP Proxy (go read the Moonshot introductory documentation if you’re unsure how Moonshot in general works).

For the RP Proxy and IdP to communicate, they need to know each other's IP addresses and have a shared key for encrypting traffic to each other. Where this information is pre-configured in both components, great. But pre-configuring this for all instances of RPs and IdPs does not scale well. So, enter Trust Router. Trust Router can assist RPs and IdPs to securely negotiate this information in a just-in-time manner.

Phase 1 - The Moonshot RP asks the Trust Router to establish keys with the Moonshot IdP that is responsible for the realm "@idp"

Firstly, the RP asks its Trust Router to help it establish keys with the IdP responsible for the realm specified by the user attempting to access the Moonshot-enabled service. We'll call this "@idp".

1. The TR client on the RP wants to send a Trust Path request to the Trust Router (more specifically, to the TIDS part of Trust Router) asking for @idp. But first, it needs to authenticate to the Trust Router. To do so, it becomes a moonshot client, and as such, it establishes a GSS-EAP session to the moonshot enabled-service - TIDS on the Trust Router.
2. TIDS on the Trust Router, as any normal moonshot-enabled service would do, next connects to its configured RP Proxy, over RadSec, saying that the IdP in question is @apc (since the IdP for this community of Moonshot services is the APC). Here, the RP Proxy is co-located on the same server as the Trust Router.
3. The RP Proxy knows how to contact the APC (the small set of APCs will be pre-configured by the Trust Router adminstrator), so it forwards the request for @apc, over RadSec, to FreeRadius on the APC. Since the APC *is* @apc, it doesn’t need to send the request on any further, and a TLS tunnel is established between the Trust Router client (i.e. the moonshot client) on the RP and the @apc IdP, through the Trust Router's FreeRADIUS server.
4. The TR client on the RP authenticates to the @apc IdP through the TLS tunnel (using the credential issued to it by the APC).
5. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on Trust Router.
6. The RP Proxy forwards the Access Accept to the TIDS on Trust Router that initiated this process.
7. Having successfully authenticated, TIDS on the Trust Router now gives an application session to Trust Router client on the RP.
8. The Trust Router client on the RP now uses this session to issue a Trust Path request for @rp. This also includes the first half of a Diffie Helman (DH) key exchange.
9. TIDS on the Trust Router forwards this to the Trust Router process. At this point, the Trust Router will add constraints to the Temporary Identity (TID) message and apply any necessary filters on it.

Phase 2 - Mutual Authentication between TR and IdP

The Trust Router now needs to connect to the TIDS on the IdP in order to perform the next step of the DH key exchange. Of course, TIDS on the IdP won’t accept connections from anyone, so the TR and the IdP must now mutually authenticate.

Phase 2a - TR authenticates itself to IdP

First, the Trust Router authenticates itself via the APC.

- 10. The Trust Router wants to authenticate to TIDS on the IdP, so it asks its Trust Router component to connect to TIDS on the IdP.
- 11. The TR client is a moonshot client and establishes a GSS-EAP session between itself and the moonshot enabled-service - TIDS on the IdP, telling TIDS that the IdP that will authenticate it is @apc.
- 12. TIDS on the IdP passes it to its RP Proxy over RadSec, co-located on the same box, telling it that the IdP is @apc. The RP Proxy on the IdP next wants establish a TLS tunnel between the client (TIDC on the Trust Router) and @apc IdP. Luckily, a shared key for the IdP and APC has been previously established, and so this is now used.
- 13. The RP Proxy on the IdP and the APC now have a shared key, so the RP Proxy on the IdP connects to the APC over RadSec and a TLS tunnel is established between the client (the Trust Router process on Trust Router) and the @apc IdP.
- 14. The Trust Router client on the RP sends its credentials to the @apc IdP through the TLS tunnel.
- 15. The @apc IdP sends ab Access Accept to FreeRADIUS on the IdP over RadSec.
- 16. FreeRADIUS on the IdP sends an Access Accept to TIDS over RadSec.

Phase 2b - IdP authenticates to TR
Now that the TR has authenticated to the IdP, the IdP in turn authenticates itself to the TR.

- 17. The TR client on the IdP is a moonshot client and establishes a GSS-EAP session between itself and the moonshot enabled-service - TIDS on the APC, telling TIDS that the IdP that will authenticate it is @apc.
- 18. TIDS on the Trust Router, as a normal moonshot-enabled service would do, next connects to its configured RP Proxy, over RadSec, saying that the IdP in question is @apc. Here, the RP Proxy is co-located on the same server as the Trust Router.
- 19. The RP Proxy knows how to contact the APC (the small set of APCs will be pre-configured by the Trust Router administrator), so it forwards the request for @apc, over RadSec, to FreeRadius on the APC. Since the APC *is* @apc, it doesn’t need to send the request on any further, and a TLS tunnel is established between the Trust Router client on the IdP and the @apc IdP, through the Trust Router's FreeRADIUS server.
- 20. The Trust Router client on the IdP authenticates to the @apc IdP through the TLS tunnel (using the credential issued to it by the APC).
- 21. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on the Trust Router.
- 22. The RP Proxy forwards the Access Accept to the TIDS on the Trust Router that initiated this process.
- 23. TIDS on the Trust Router forwards this to the Trust Router process. At this point, the Trust Router will add constraints to the TID message and apply any necessary filters on it.

Phase 7 - Key exchange between RP and IdP
The RP and IdP are now able to establish keys with each other by using the Trust Router to mediate the DH process.

24. The Trust Router gives the first half ot he DH key exchange that it received way back in step 8 to TIDS on the IdP

25. TIDS on the IdP responds to the Trsut Router with the next step of the DH exchange.
26. The Trust Router passes this on to TIDS on the RP.

Phase 8 - RP and IdP communicate
Now that the RP and the IdP have a shared set of keys, they can communicate. The job of Trust Router is done!

27. The RP and IdP can now set up a direct RadSec connection, enabling the Moonshot client that initiated the whole process to authenticate through a TLS tunnel to its IdP.

Trust Router

Trust Router Protocol Flows with Existing APC/IdP Key

Analytics

1. Overview

2. Detail

Related content