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:
The initiator tags the message with gss_get_mic().
The initiator sends the message and MIC to the acceptor.
The acceptor verifies the message with gss_verify_mic().
The acceptor sends the MIC back to the initiator.
The initiator verifies the received MIC against the original message with gss_verify_mic().
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:
The initiator wraps the message with gss_wrap().
The initiator sends the wrapped message.
The acceptor unwraps the message with gss_unwrap().
The acceptor calls gss_get_mic() to produce a MIC for the unwrapped message.
The acceptor sends the derived MIC to the initiator.
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).