1. Overview

Overview

2. Detail

• Phase 1 - RP asks Trust Router to establish keys with @idp.
• Phase 2 - Authentication between TR and IdP
  • Phase 2a - TR authenticates to IdP
    • Phase 3 - IdP asks Trust Router to establish keys with @apc.
    • Phase 4 - Authentication between TR and APC
    • Phase 5 - Key exchange between IdP and APC, mediated by TR 
    • Phase 6 - IdP and APC connect
  • Phase 2b - IdP authenticates to TR.
• Phase 7 - Key Exchange between RP and IdP, mediated by TR.
• Phase 8 - RP and IdP connect

Preamble:

• 1. TR client on RP wants to send a TP request to the Trust Router (more specifically, the TIDS part of TR) asking for @idp. But first, it needs to authenticate to the TR. So it becomes a moonshot client, and establishes a GSS-EAP session to the moonshot enabled-service - TIDS on the TR.
• 2. TIDS on the TR, 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.
• 3. The RP Proxy knows how to contact the APC (the small set of APCs will be hard coded by the APC 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 client on the RP and the @apc IdP, through the TR FreeRADIUS server.
• 4. The TR client on the RP authenticates to the @apc IdP through the TLS tunnel.
• 5. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on TR.
• 6. The RP Proxy forwards the Access Accept to the TIDS on TR that initiated this process.
• 7. Having successfully authenticated, TIDS on the TR now gives an application session to TR client on RP.
• 8. The TR client on RP now uses this session to issue a TP request for @rp. This also includes the first half of a diffie helman key exchange.
• 9. TIDS on the TR forwards this to the TR. At this point, the TR will add constraints to the TID message and apply any necessary filters on it.

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

Phase 3 - IdP asks Trust Router to establish keys with @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 TR client on the IdP wants to send a TP request to the Trust Router (more specifically, the TIDS part of TR) asking for @apc. But first, it needs to authenticate to the TR. So it becomes a moonshot client, and establishes a GSS-EAP session to the moonshot enabled-service - TIDS on the TR.
    • 14. TIDS on the TR, 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.
    • 15. The RP Proxy knows how to contact the APC (the small set of APCs will be hard coded by the APC 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 client on the IdP and the @apc IdP, through the TR FreeRADIUS server.
    • 16. The TR client on the IdP authenticates to the @apc IdP through the TLS tunnel.
    • 17. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on TR.
    • 18. The RP Proxy forwards the Access Accept to the TIDS on TR that initiated this process.
    • 19. Having successfully authenticated, TIDS on the TR now gives an application session to TR client on the IdP.
    • 20. The TR 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 key exchange.
    • 21. TIDS on the TR forwards this to the TR. At this point, the TR will add constraints to the TID message and apply any necessary filters on it.
       

Phase 4 Authentication between TR and APC
Description

• • • 22. The TR wants to authenticate to TIDS on the APC, so it asks its TR component to connect to TIDS on the APC.
    • 23. The TR 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 TR) and the @apc IdP.
    • 25. The TR client on the TR sends its credentials to the @apc IdP through the TLS tunnel.
    • 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 client on the TR.
    • 28. This session is passed onto the TR..

Phase 5 Key exchange between IdP and APC
Description 

• • • 29. The TR gives DH stuff to TIDS on APC
    • 30. TIDS on APC gives DH stuff to TR
    • 31. TR give DH stuff to TIDS on 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 TR) and @apc IdP.
    • 33. TR client on RP sends credentials to @apc IdP thru the TLS tunnel.
    • 34. @apc IdP sends Access Accept to FR on IdP over RadSec.
    • 35.  FR on IdP sends 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, 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.
  • 38. The RP Proxy knows how to contact the APC (the small set of APCs will be hard coded by the APC 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 client on the IdP and the @apc IdP, through the TR FreeRADIUS server.
  • 39. The TR client on the IdP authenticates to the @apc IdP through the TLS tunnel.
  • 40. The @apc IdP sends a RADIUS Access Accept to the RP Proxy on TR.
  • 41. The RP Proxy forwards the Access Accept to the TIDS on TR that initiated this process.
  • 42. TIDS on the TR forwards this to the TR. At this point, the TR will add constraints to the TID message and apply any necessary filters on it.