Architecture

The overall architecture of Moonshot is based on the following:

• A client tries to access a service, and the service delegates authentication to an identity provider for the credentials that were previously issued to the user using the client.
• EAP is used to enable authentication to happen between the client and the IdP.
• The EAP is transported over the GSS-API / SSPI between client and service, and over RadSec/RADIUS between the service, its RP Proxy, and the IdP. 

Protocol Flows

The full protocol flow for Moonshot is described in full technical detail in the ABFAB Architecture document, but an overview of the process is presented in this section.

Beforehand

A few steps need to be completed beforehand to support the Moonshot authentication flow. These are:

• The user needs to have a set of credentials issued from a Moonshot Identity Provider that has a trust relationship with a Moonshot Relying Party that is fronted by the service the user wishes to connect to.  
• The client device needs to be configured with identity information, have the Moonshot GSS-API/SSPI mechanism installed. The client application also might need configuring to use the Moonshot mechanism.
• The server on which the service is running needs to have the Moonshot GSS-API/SSPI mechanism installed, and this must be configured to talk to its local Moonshot RP Proxy. The server application also might need configuring to use the Moonshot mechanism.

Flow

The steps of the protocol flow are as follows:

1. The application client attempts to connect to the application server, using the application's standard protocol(s). (for example, OpenSSH client tries to connect to OpenSSH server using the SSH protocol).
2. The application client and application server negotiate the use of the GSS-API for authentication, and GSS-EAP is called on the client device.
3. GSS-EAP prompts for credentials to use on this particular service. This will make a call to the identity selector mechanism; this will (somehow) end up with an identity to use, comprising an NAI. Since GSS-EAP has successfully found an identity, then GSS-EAP is offered as an available GSS mechanism.
4. GSS-EAP is negotiated as the GSS-API mechanism to use for this authentication.
5. GSS-EAP on the application client creates an EAP request containing the anonymous version of the NAI (i.e. simply @REALM). This EAP message is sent over the established GSS channel to the application server.
6. GSS-EAP on the application server opens a RadSec/RADIUS connection to its configured RP Proxy. A RADIUS Access-Request message, with the EAP message it received from the client encapsulated, is sent down this channel.
   1. GSS-EAP on the application server could also at this point create a SAML authentication request, and add it to the RADIUS Access-Request.

7. The RP Proxy receives this request. It looks at the realm that was a part of the EAP message, and finds the Identity Provider associated with that realm - how it finds it is out of scope for this protocol flow - see the Trust Infrastructure section for the options. Whatever method is used, the RP Proxy will end up with an IP address that it can contact the IdP on, and the keying material necessary to open a secure connection to it. The RP Proxy uses this information to open a RadSec/RADIUS connection, through which it forwards the RADIUS Access-Request containing the encapsulated EAP message. It will also include a GSS name that it claims to be.

   At this point, the RP Proxy and IdP now have a secure tunnel established between themselves, and there is a path between the client and its IdP (consisting of GSS-EAP between application client to application server, RadSec/RADIUS between application server and its RP Proxy, and RadSec/RADIUS between the RP Proxy and the IdP.
8. The client and IdP now being an EAP conversation through the established path - the outer tunnel. This consists of the client and IdP choosing an EAP method to use. EAP-TTLS is chosen, which creates a secure inner tunnel between the client and IdP so that the two can communicate securely in such a way that the intermediate RP cannot see the traffic (it just passes back and forth encrypted data).
9. The client and IdP negotiate an inner EAP method, which in turn is used to verify the credentials being used. Additionally, the client sends a channel bindings message which contains the GSS name of the RP that it is trying to connect to.
10. The IdP authenticates the client credentials. It also checks that the GSS name that the client told it that it is trying to connect to matches the names that the RP claims to have, to check they match. Assuming the credentials verify correct (e.g. if the username/password was correct), then EAP messages are exchanged, resulting in the client and the IdP both ending up with a copy of the EAP Master Session Key (EAP MSK) and EAP Extended Master Session Key (EAP EMSK).
11. The IdP responds to the RP Proxy by sending it a RADIUS Access-Accept message, which contains an encapsulated EAP success message, the EAP MSK, and possibly a SAML assertion (either unsolicited or in response to a SAML request, if one was present).
12. The RP Proxy decides whether this authenticated user should be allowed to use the service, based on local policy and/or information provided by the IdP in the form of RADIUS or SAML attribute information. If the decision is positive, then the RP Proxy forwards the Access-Accept with EAP success message, EAP MSK, and possibly SAML assertion (these may be sent unmodified or be modified by the RP Proxy before forwarding) to the application server over the RadSec/RADIUS connection between the two.
13. GSS-EAP on the application server checks that the EAP MSK claimed by the RP matches that given to it by its IdP (to authenticate the RP). It then makes a decision about whether the user should be allowed to use the service, based on policy custom to the application in question, possibly informed by the content of the RADIUS/SAML attribute information provided to it. If the decision is positive, then the application server provides a session to the application client of whatever form that application/service uses.

Further Information

Channel bindings

• (Under construction)