This routine parses a KRB_AP_REQ message, returning its contents.
Upon successful return, if ticket is nonNULL, *ticket will
be modified to point to allocated storage containing the ticket
If auth_context is NULL, one will
be generated and freed internally by the function.
The server argument specifies the
expected server's name for the ticket.
If server is NULL, then any server
name will be accepted if the appropriate key can be found, and the
caller should verify that the server principal matches some trust
If server is not NULL, and a replay detection cache has not
been established with auth_context, one
will be generated.
If a keyblock is present in the auth_context,
it will be used to decrypt the ticket request and the keyblock freed
with krb5_free_keyblock. This is useful
for user-to-user authentication.
If no keyblock is specified, the keytab is
consulted for an entry matching the requested keytype, server, and version
number and used instead.
The authenticator in the request is decrypted and stored in auth_context.
The client specified in the decrypted authenticator is compared
to the client specified in the decoded ticket to ensure that the
compare was performed.
If the remote_addr portion of the auth_context is
set, then this routine checks if the request came from the right
The replay cache is checked to see if the ticket and authenticator
have been seen and, if so, returns an error. If not, the ticket
and authenticator are entered into the cache.
Various other checks are made of the decoded data, including
cross-realm policy, clockskew, and ticket validation times.
The keyblock, subkey, and sequence number of the request are
all stored in the auth_context for future
If the request has the AP_OPTS_MUTUAL_REQUIRED bit set, the
local sequence number, which is stored in the auth_context,
is XORed with the remote sequence number in the request.