krb5_rd_req()--Process Kerberos AP_REQ Message

 #include <krb5.h>

 krb5_error_code krb5_rd_req(
     krb5_context       context,
     krb5_auth_context *    auth_context,  
     krb5_const krb5_data *   in_data,
     krb5_const_principal   server,
     krb5_keytab      keytab,
     krb5_flags *     ap_req_options,   
     krb5_ticket **     ticket);

The krb5_rd_req() function processes a Kerberos AP_REQ message generated by the partner application. 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 protocol runtime creates a replay cache and stores the cache handle in the authentication context.

Parameters

context  (Input)

The Kerberos context.

auth_context  (Input/Output)

The authentication context. A new authentication context is created and returned in this parameter if the value is NULL.

in_data  (Input)

The buffer containing the AP_REQ message.

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 that contains the server key. The default key table is used if NULL is specified for this parameter.

ap_req_options  (Output)

The options from the AP_REQ message. Specify NULL for this parameter if the options are not needed.

ticket  (Output)

The ticket 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.

Authorities

No authorities are required.

Error Messages

Usage Notes

1. If the authentication context contains a keyblock, it is 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 is used to obtain the decryption key.
   
   
2. 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.
   
   
3. If no errors are detected, the authenticator, subsession key, and remote sequence number are stored in the authentication context. If AP_OPTS_MUTUAL_REQUIRED (x'20000000') is specified in the AP_REQ message, the local sequence number is XORed with the remote sequence number.
   
   
4. The Kerberos protocol runtime provides no concurrency control for the authentication context. If the application wants to use the same authentication context in multiple threads, it is the responsibility of the application to serialize access to the authentication context so that only a single thread is accessing the authentication context at any time. Because message sequence numbers are contained in the authentication context, this serialization needs to be extended to encompass the message exchange between the two applications. Otherwise, message sequence errors are liable to occur if the messages are delivered out of sequence.

[ Back to top | Security APIs | UNIX-Type APIs | APIs by category ]