Summary
Message direction Message type Section
1. Client to Kerberos KRB_AS_REQ 5.4.1
2. Kerberos to client KRB_AS_REP or 5.4.2
KRB_ERROR 5.9.1
The Authentication Service (AS) Exchange between the client and the
Kerberos Authentication Server is usually initiated by a client when
it wishes to obtain authentication credentials for a given server but
currently holds no credentials. The client's secret key is used for
encryption and decryption. This exchange is typically used at the
initiation of a login session, to obtain credentials for a Ticket-
Granting Server, which will subsequently be used to obtain
credentials for other servers (see section 3.3) without requiring
further use of the client's secret key. This exchange is also used
to request credentials for services which must not be mediated
through the Ticket-Granting Service, but rather require a principal's
secret key, such as the password-changing service. (The password-
changing request must not be honored unless the requester can provide
the old password (the user's current secret key). Otherwise, it
would be possible for someone to walk up to an unattended session and
change another user's password.) This exchange does not by itself
provide any assurance of the the identity of the user. (To
authenticate a user logging on to a local system, the credentials
obtained in the AS exchange may first be used in a TGS exchange to
obtain credentials for a local server. Those credentials must then
be verified by the local server through successful completion of the
Client/Server exchange.)
The exchange consists of two messages: KRB_AS_REQ from the client to
Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these
messages are described in sections 5.4.1, 5.4.2, and 5.9.1.
In the request, the client sends (in cleartext) its own identity and
the identity of the server for which it is requesting credentials.
The response, KRB_AS_REP, contains a ticket for the client to present
to the server, and a session key that will be shared by the client
and the server. The session key and additional information are
encrypted in the client's secret key. The KRB_AS_REP message
contains information which can be used to detect replays, and to
associate it with the message to which it replies. Various errors
can occur; these are indicated by an error response (KRB_ERROR)
instead of the KRB_AS_REP response. The error message is not
encrypted. The KRB_ERROR message also contains information which can
be used to associate it with the message to which it replies. The
lack of encryption in the KRB_ERROR message precludes the ability to
detect replays or fabrications of such messages.
In the normal case the authentication server does not know whether
the client is actually the principal named in the request. It simply
sends a reply without knowing or caring whether they are the same.
This is acceptable because nobody but the principal whose identity
was given in the request will be able to use the reply. Its critical
information is encrypted in that principal's key. The initial
request supports an optional field that can be used to pass
additional information that might be needed for the initial exchange.
This field may be used for preauthentication if desired, but the
mechanism is not currently specified.
