The krb5_rd_req_verify() function processes an AP_REQ
message generated by the partner application and verifies the application data
checksum contained in the authenticator. The authenticator is extracted,
validated, and stored in the authentication context. If the server parameter is
not NULL and no replay cache is associated with the authentication context, the
Kerberos runtime will create a replay cache and store the cache handle in the
authentication context.
Authorities
None.
Parameters
context (Input)
The Kerberos context.
auth_context (Input/Output)
The authentication context. A new authentication context will be created
and returned if this parameter is NULL.
in_data (Input)
The buffer containing the AP_REQ message.
appl_data (Input)
The application data to be verified. The checksum is computed for the
supplied data and compared to the checksum obtained from the authenticator.
Specify NULL if the checksum is not to be verified.
server (Input)
The server name. The server principal in the AP_REQ must be the same as the
principal specified by this parameter. Specify NULL if any server principal is
acceptable.
keytab (Input)
The key table which contains the server key. The default key table will be
used if NULL is specified for this parameter.
ap_req_options (Output)
The options returned from the AP_REQ message. Specify NULL for this
parameter if the options are not needed.
ticket (Output)
The ticket returned from the AP_REQ message. Specify NULL for this
parameter if the ticket is not needed. The krb5_free_ticket()
routine should be called to release the ticket when it is no longer needed.
Return Value
If no errors occur, the return value is 0. Otherwise, a Kerberos error code
is returned.
If the authentication context contains a keyblock, it will be used to
decrypt the ticket in the AP_REQ message. This is useful for user-to-user
authentication. If the authentication context does not contain a keyblock, the
key table specified on the function call will be used to obtain the decryption
key.
The client in the authenticator must match the client in the ticket. If the
remote address has been set in the authentication context, the request must
have come from that address. If a replay cache handle is stored in the
authentication context, the new authenticator is stored in the cache after
checking for replay.
If no errors are detected, the authenticator, subsession key, and remote
sequence number are stored in the authentication context. If
AP_OPTS_MUTUAL_REQUIRED is specified in the AP_REQ message, the local sequence
number is XORed with the remote sequence number