krb5_rd_req — Parse a KRB_AP_REQ message
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
|
|
|
| context (input/output) | The context structure. | |
| auth_context (input/output) | Authentication context. A new authentication context will be returned if NULL is specified. | |
| inbuf (input) | Contains the KRB_AP_REQ message to be parsed. | |
| server (input) | Specifies the expected server’s principal name for the ticket. | |
| keytab (input) | Specifies a keytab containing a decryption key. If NULL, krb5_kt_default will be used to find the default keytab and the key taken from there. | |
| ap_req_options (input/output) | If nonNULL on input, this field will be set to contain the application request flags on output. | |
| ticket (output) | Returns the ticket from the AP_REQ message. The caller is responsible for deallocating this space by using krb5_free_ticket. If no ticket is desired, specify NULL. |
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 information.
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 criterion.
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 client.
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 use.
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.