Overview

Overview

Detail

Understanding the subtleties of how Trust Router bootstraps itself when no shared keys exist is not easy; it will take effort, concentration, and probably an hour or two of whiteboarding going through each step one at a time. Jumping straight in to this worst case is probably not the best way to understand it. Instead, understand the simple case first - , then the intermediate case - , and then finally come back here.

Detail

The steps of the protocol flow for Trust Router in the worst case (neither the RP and IdP or the IdP and APC yet share a key) are split into the following phases:

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

Preamble:

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

Preamble:

• 1. The TR client on the RP wants to send a TP Trust Path request to the Trust Router (more specifically, to the TIDS part of TR Trust Router) asking for @idp. But first, it needs to authenticate to the TR. So 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 TR Trust Router.
• 2. TIDS on the TR Trust Router, as a 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 TR Trust Router.
• 3. The RP Proxy knows how to contact the APC (the small set of APCs will be hard coded pre-configured by the APC administrator 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 TR client the Trust Router client (i.e. the moonshot client) on the RP and the @apc IdP, through the TR 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 TR Trust Router.
• 6. The RP Proxy forwards the Access Accept to the TIDS on TR Trust Router that initiated this process.
• 7. Having successfully authenticated, TIDS on the TR Trust Router now gives an application session to TR Trust Router client on the RP.
• 8. The TR Trust Router client on the RP now uses this session to issue a TP Trust Path request for @rp. This also includes the first half of a diffie helman a Diffie Helman (DH) key exchange.
• 9. TIDS on the TR Trust Router forwards this to the TR Trust Router process. At this point, the TR Trust Router will add constraints to the Temporary Identity (TID) message and apply any necessary filters on it.

• • 10. The TR Trust Router wants to authenticate to TIDS on the IdP, so it asks its TR 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-loed 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 TRthe Trust Router) and @apc IdP, but it does't know how to get to @apc IdP yet. So, enter trust router, again!
     

Phase 3 - IdP asks  IdP asks Trust Router to establish keys with @apc.the APC
To enable the authentication to happen, the IdP’s RP Proxy must facilitate the establishment of a secure tunnel from the Moonshot Client to the relevant IdP, via its RP Proxy (see THIS PAGE if you’re unsure how Moonshot in general works).
Where this connection between the RP Proxy and the relevant IdP is pre-configured in FreeRADIUS, great. But that doesn’t scale well. So, enter Trust Router.

.

• • • 13. The Trust Router client on the IdP wants to send a TP Trust Path request to the Trust Router (more specifically, the TIDS part of TR Trust Router) asking for @apc. But first, it needs to authenticate to the TR Trust Router. So it becomes a moonshot client, and establishes a GSS-EAP session to the moonshot enabled-service - TIDS on the TR Trust Router.
    • 14. TIDS on the TR, as a any 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 TR Trust Router.
    • 15. The RP Proxy knows how to contact the APC (the small set of APCs will be hard coded pre-configured by the APC administratorTrust 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 TR Trust Router client on the IdP and the @apc IdP, through the TR Trust Router's FreeRADIUS server.
    • 16. The TR Trust Router client on the IdP authenticates to the @apc IdP through the TLS tunnel(using the credential issued to it by the APC).
    • 17. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on TRthe Trust Router.
    • 18. The RP Proxy forwards the Access Accept to the TIDS on TR Trust Router that initiated this process.
    • 19. Having successfully authenticated, TIDS on the TR Trust Router now gives an application session to TR Trust Router client on the IdP.
    • 20. The TR Trust Router client on the IdP now uses this session to issue a TP request for @apc. This also includes the first half of a diffie helman a DH key exchange.
    • 21. TIDS on the TR Trust Router forwards this to the TR Trust Router process. At this point, the TR Trust Router will add constraints to the TID message and apply any necessary filters on it.
       

Phase 4 - Mutual Authentication between TR the Trust Router and APC
DescriptionThe Trust Router now needs to connect to the TIDS on the APC in order to perform the next step of the DH key exchange. Of course, TIDS on the APC won’t accept connections from anyone, so the Trust Router and the APC must now mutually authenticate.

• • • 22. The TR Trust Router wants to authenticate to TIDS on the APC, so it asks its TR component Trust Router process to connect to TIDS on the APC.
    • 23. The TR Trust Router client 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. 
    • 24. TIDS on the APC passes it to its RP Proxy over RadSec, co-loed on the same box, telling it that the IdP is @apc. The RP Proxy recognises that it *is* the @apc IdP, so it doesn’t need to send the request anywhere else, and so a TLS tunnel is established between the client (TR on TRthe Trust Router process on the Trust Router) and the @apc IdP.
    • 25. The TR client on the TR sends its credentials to the @apc IdP through the TLS tunnel (using the credential issued to it by the APC).
    • 26. The @apc IdP sends a RADIUS Access Accept to TIDS on the same server.
    • 27. Having successfully authenticated, TIDS on the APC now gives an application session to TR the Trust Router client on the TR Trust Router.
    • 28. This session is passed onto the TR. Trust Router process. At this point, the Trust Router will add constraints to the TID message and apply any necessary filters on it.

Phase 5 - Key exchange between IdP and APC
Description Now that the IdP and APC have mutually authenticated, the Trust Router can help negotiate a DH key exchange between the IdP and APC.

• • • 29. The TR gives DH stuff Trust Router gives the first half of the DH key exchange that it received in step 20 to TIDS on APC
    • 30. TIDS on APC gives DH stuff to TR31. TR give DH stuff responds to the Trust Router with the next step of the DH exchange.
    • 31. The Trust Router passes this on to TIDS on the IdP.
      
      

• • • 32. 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 (TR on TRthe Trust Router process on Trust Router) and the @apc IdP.
    • 33. TR The Trust Router client on the RP sends its credentials to the @apc IdP thru through the TLS tunnel.
    • 34. The @apc IdP sends ab Access Accept to FR FreeRADIUS on the IdP over RadSec.
    • 35.  FR  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.

• • 36. 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. 
  • 37. TIDS on the TR 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 TR Trust Router.
  • 38. The RP Proxy knows how to contact the APC  (the small set of APCs will be hard coded pre-configured by the APC 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 TR Trust Router client on the IdP and the @apc IdP, through the TR Trust Router's FreeRADIUS server.
  • 39. The TR Trust Router client on the IdP authenticates to the @apc IdP through the TLS tunnel (using the credential issued to it by the APC).
  • 40. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on TRthe Trust Router.
  • 41. The RP Proxy forwards the Access Accept to the TIDS on TR the Trust Router that initiated this process.
  • 42. TIDS on the TR Trust Router forwards this to the TR Trust Router process. At this point, the TR Trust Router will add constraints to the TID message and apply any necessary filters on it.