1. Overview

The Client consists of parts of the software that exists on the user’s device (e.g., laptop) that make up both the start and end points of a Moonshot transaction.  A request starts with the Client sending a session request to the Service (Relying Party) and includes an identity selection mechanism that enables the user to choose which identity to use at the Service.

2. Requirements

2.1. Moonshot mechanism

The Client must have the Moonshot mechanism installed and configured within the operating system. This will either be:

• The GSS-EAP mechanism configured in the GSS stack.
• or, on Windows only, the Moonshot SSP (EAP-SSP) mechanism configured as a SSPI provider.

These mechanisms enable client software (such as an SSH client) to make use of Moonshot as a potential GSS-API/SSPI mechanism for authentication.

2.2. Application needs to be configured to use GSS

The client application needs to be configured to use the GSS-API/SSPI for authentication. How this is done is highly application specific - see the wiki section on configuring clients for instructions for particular clients.

2.3. Identity Selection mechanism

When the Client starts the process of Moonshot authentication, it must specify which credentials should be used to authenticate to the relevant Service. The job of managing sets of credentials and credential to service mappings, and interacting with the user (if appropriate), is performed by the Identity Selection mechanism. See the wiki section on Identity Selection for further information.

3. How Moonshot is used on the client.

In general terms, the Moonshot-enabled client application triggers the whole Moonshot process by trying to connect to a Moonshot-enabled service; it negotiates the use of Moonshot as an authentication mechanism with the Service; it interacts with an IdP to prove that it has a valid set of credentials; and finally a session is opened between the Client and the Service.

More specifically:

1. The Moonshot-enabled client application tries to connect to a Moonshot-enabled service using that specific service's own protocols.
2. This connection negotiates GSS/SSP as the authentication method of choice.
3. This triggers the identity selection process and, if credentials for a particular Service are found, then GSS-EAP is offered by the client as a potential mechanism to use.
4. The client then receives an EAP request from the server over the GSS/SSP layer, to which it responds with an EAP response containing the realm of the credential to be used.
5. A secure TLS tunnel is subsequently established to the Identity Provider for the chosen credentials that flows via the Service.
6. The credentials are sent down this secure tunnel for the Identity Provider to verify. Also, the client sends channel binding information in the form of the name of the Relying Party that it is trying to connect to.
7. If the Identity Provider is happy with these credentials; the channel bindings match (the name of the Relying Party the client is trying to connect to matches the name the Relying Party has claimed); and the Service is subsequently happy to grant access, then finally the Service establishes a session with the Client.