Confirming Message Transmission in GSS-API

After the recipient has unwrapped or verified the transmitted message, a confirmation can be returned to the sender. This means sending back a MIC for that message. Consider the case of a message that was not wrapped by the sender but only tagged with a MIC with gss_get_mic().

The process, illustrated in Figure 4–9, is as follows:

1. The initiator tags the message with gss_get_mic().

2. The initiator sends the message and MIC to the acceptor.

3. The acceptor verifies the message with gss_verify_mic().

4. The acceptor sends the MIC back to the initiator.

5. The initiator verifies the received MIC against the original message with gss_verify_mic().

Figure 4–9 Confirming MIC Data

In the case of wrapped data, the gss_unwrap() function never produces a separate MIC, so the recipient must generate it from the received and unwrapped message.

The process, illustrated in Figure 4–10, is as follows:

1. The initiator wraps the message with gss_wrap().

2. The initiator sends the wrapped message.

3. The acceptor unwraps the message with gss_unwrap().

4. The acceptor calls gss_get_mic() to produce a MIC for the unwrapped message.

5. The acceptor sends the derived MIC to the initiator.

6. The initiator compares the received MIC against the original message with gss_verify_mic().

Applications should deallocate any data space that has been allocated for GSS-API data. The relevant functions are gss_release_buffer(3GSS), gss_release_cred(3GSS), gss_release_name(3GSS), and gss_release_oid_set(3GSS).

Figure 4–10 Confirming Wrapped Data