AS Exchange

Overview [1]#

When initially logging onto a Kerberos Realm (or AD DOMAIN), clients must negotiate access by providing a log-in name and password in order to be verified by the Kerberos Authentication Service (AS) within the same Kerberos Realm.

The Key Distribution Center has access to the Kerberos Database (Microsoft Active Directory) user account information and the Kerberos Authentication Service will check if you are in the Kerberos Database. This check is only to see if the entity exist (ie no credentials are checked) the user is granted a Ticket to Get Tickets (Ticket Granting Ticket) that is valid for the Kerberos Realm.

The Ticket Granting Ticket has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The Ticket Granting Ticket ma be put in cache on the local device or in Random Access Memory space and used to request Kerberos sessions with Resources throughout the network.

Example (AS_REQ) Request#

The client send a request to the AS which identifies the client to the KDC in plaintext consisting of:

If Kerberos Pre-Authentication is enabled, a timestamp will be encrypted using the user's password hash as an encryption key.

If the KDC reads a valid time when using the user's password-hash (stored in the Microsoft Active Directory) for decryption of the timestamp, the KDC knows that request isn't a replay attack of a previous request.

The Kerberos Pre-Authentication feature may be disabled for specific users in order to support some applications that don't support the security feature.

Example Kerberos Authentication Service (AS_REP) Response#

When the request arrives, the Kerberos Authentication Service checks whether

Otherwise the AS processes the AS_REP as follows:

It may seem that this message contains redundant information (Service-Principal, timestamp, lifetime and TGS Session Key). However since the information present in the Ticket Granting Ticket is encrypted using the TGS Session Key for the server (KTGS), the TGT cannot be read by the client and needs to be repeated.

At this point, when the client receives the AS_REP message, it will ask the user to enter the password.

The salt is concatenated with the password and then the string2key function is applied: with the resulting key and used for decryption of the part of the message encrypted by the AS using the Secret-key of the user stored in the Kerberos Database. If the user is really who he/she says, and has thus entered the correct password, the decryption operation will be successful and thus the TGS Session Key can be extracted and with the TGT (which remains encrypted) stored in the user's credential cache.

Note lifetime#

The actual lifetime, i.e. which is put in the ticket is the lowest of the following values: the lifetime requested by the client, the one contained in the user's principal and that in the service principal. And in some Kerberos implementations (Microsoft Windows) the lifetime can be set from the configuration of the KDC and applied to any ticket.

Note IP Address list #

IP Address list may also be null. In this case the corresponding ticket can be used by any machine. This resolves the problem of those clients under NAT, since their request would arrive at the service with a source address different from that of the requesting user, but the same as the router making the NAT. Instead, in the case of machines with more than one network card, IP Address list should contain the IP Address of all the cards: in fact it would be difficult to predict beforehand with which connection the server which provides the service would be contacted.

After the AS Exchange #

Only when the TGS Session Key and the Ticket Granting Ticket are obtained can the Client-Principal attempt to access a Relying Party using the TGS Exchange

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!