4 Protocol Examples

Figure 3: Protocol sequence example

The previous figure gives a simple example of handshake, data transfer, and closing of the connection when the client and server negotiate a security mechanism that authenticates both the client and server and provides data integrity and confidentiality protections.

1. To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message and sent to the server.

2. Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is not yet complete.

   The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeInProgress message, and sends this message to the client.

3. The client receives the HandshakeInProgress message, and passes the token in the AuthPayload to GSS_Init_sec_context. The number of HandshakeInProgress messages exchanged between the client and server is dependent on the authentication level selected by the client and the authentication protocol that was negotiated between the client and server. In this example, the return code of GSS_Init_sec_context indicates that the handshake is not complete. The client takes the token returned from GSS_Init_sec_context, and places it in the AuthPayload field of a HandshakeInProgress message.

   The client sends the HandshakeInProgress message to the server.

4. After the server receives the HandshakeInProgress message from the client, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is complete. The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeDone message, and sends this message to the client. The server now enters the data transfer phase.

5. When the client receives the HandshakeDone message from the server, it also transitions to the data transfer phase. In this example, the client chooses to send a single message to the server. The client creates this message as specified in section 2.2.2, using the negotiated security context from the handshake phase. The client then sends this message to the server.

6. The server receives the message, and in this example chooses to end the connection at this time. The server closes the underlying TCP connection to the client.

7. The client application is notified that the server has closed the connection.

Figure 4: Protocol sequence example

The previous figure gives another simple example of handshake, data transfer, and closing of the connection when the client and server negotiate a security mechanism that authenticates only the client and does not provide data integrity or confidentiality protections.

1. To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message, which is sent to the server.

2. Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is not yet complete.

   The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeInProgress message, and sends this message to the client.

3. The client receives the HandshakeInProgress message, and passes the token in the AuthPayload to GSS_Init_sec_context. In this example, the return code of GSS_Init_sec_context indicates that the handshake is complete. The client takes the token returned from GSS_Init_sec_context, and places it in the AuthPayload field of a HandshakeDone message.

   The client sends the HandshakeDone message to the server.

4. After the server receives the HandshakeDone message from the client, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function indicates that the security context negotiation is complete as well. No token is returned, so the server sends a HandshakeDone message with no AuthPayload to the client. The server now enters the data transfer phase.

5. In this example, the server chooses to send a single message to the client. No data integrity or confidentiality protections have been negotiated, so the data is sent directly over the underlying TCP connection.

6. The client receives the message and in this example chooses to end the connection at this time. The client closes the underlying TCP connection to the server.

7. The server application is notified that the client has closed the connection.

Figure 5: Protocol sequence example

The previous figure gives a final simple example of handshake in which the server rejects the client's credentials.

1. To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message, which is sent to the server.

2. Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an error indicating that the client's credentials have been rejected.

   The server constructs a HandshakeError message containing the HRESULT SEC_E_LOGON_DENIED (0x8009030C) and sends it to the client to indicate the failure.

3. The client receives the HandshakeError message, notifies the application that the provided credentials have been rejected, and closes the underlying TCP connection.

4. The server application is notified that the client has closed the connection.