The krb5_mk_req() function creates a Kerberos AP_REQ
message. The checksum of the input data is included in the authenticator that
is part of the AP_REQ message. This message is then sent to the partner
application, which calls the krb5_rd_req() routine to extract
the application data after validating the authenticity of the message. The
checksum method set in the authentication context is used to generate the
checksum.
Authorities
No authorities are required.
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.
ap_req_options (Input)
The request options as follows:
AP_OPTS_USE_SESSION_KEY
(x'40000000')
Use session key instead of server key. The
credentials must include a ticket that is encrypted in the session key.
AP_OPTS_MUTUAL_REQUIRED
(x'20000000')
Mutual authentication required.
AP_OPTS_USE_SUBKEY (x'00000001')
Generate a subsession key from the current
session key obtained from the credentials.
service (Input)
The name of the service.
hostname (Input)
The host name that identifies the desired service instance.
in_data (Input)
The application data's checksum that is to be included in the
authenticator. Specify NULL for this parameter if no checksum
is to be included in the authenticator.
ccache (Input)
The credentials cache that is to be used to obtain credentials to the
desired service.
out_data (Output)
The AP_REQ message. The krb5_free_data_contents() routine
should be called to release the storage pointed to by the data field
of the krb5_data structure when it is no longer needed.
Return Value
If no errors occur, the return value is 0. Otherwise, a Kerberos error code
is returned.
The krb5_sname_to_principal() routine is called to convert
the service and hostname parameters to a Kerberos principal.
The krb5_get_host_realm() routine is called to convert the
hostname parameter to a Kerberos realm. If the credentials cache does
not already contain a service ticket for the target server, the Kerberos
protocol runtime issues a default TGS request to obtain the credentials and
store them in the cache.
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.