Kerberos Pre-authentication

Posted on by
Authenticating using Kerberos
Authenticating using Kerberos (Source: OMAL PERERA)

Kerberos comprises three architectural elements: client, server (aka AP, application server), and Key Distribution Center (KDC). The KDC comprises two servers: Authentication Server (AS) and Ticket-Granting Server (TGS). Kerberos uses a request/response model that defines the messages exchanged between the client, server, and KDC. Major Kerberos messages are listed as follows:

  • Client and AS: KRB_AS_REQ (1) and KRB_AS_REP (2)
  • Client and TGS: KRB_TGS_REQ (3) and KRB_TGS_REP (4)
  • Client and AP: KRB_AP_REQ (5) and KRB_AP_REP (6)

Client Identity In Cleartext

When a client wishes to obtain authentication credentials for a given server but currently holds no credentials, it sends a KRB_AS_REQ message that contains its identity in cleartext to the AS.

“In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials, other information about the credentials it is requesting, and a randomly generated nonce, which can be used to detect replays and to associate replies with the matching requests.” (RFC 4120)

Pre-authentication

Pre-authentication is an optional Kerberos feature. According to RFC 4120, the Kerberos protocol (V5) supports myriad options. Among these are:

  • multiple encryption and checksum types;
  • alternative encoding schemes for the transited field;
  • optional mechanisms for pre-authentication;
  • the handling of tickets with no addresses;
  • options for mutual authentication;
  • user-to-user authentication;
  • support for proxies;
  • the format of realm names;
  • the handling of authorization data; and
  • forwarding, postdating, and renewing tickets.

Since Kerberos doesn’t require the AS to perform pre-authentication, it depends on the vendor’s implementation and configurations. When pre-authentication is not performed, a client doesn’t submit its password or any other authenticators, so the AS cannot validate the client’s identity and doesn’t provide any assurance of the identity.

“Without pre-authentication, 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.” (RFC 4120)

If pre-authentication is performed, the client sends a KRB_AS_REQ message that contains its identity in cleartext along with a timestamp encrypted in its secret key, typically using symmetric ciphers, such as RC4, DES, or AES.

Microsoft Kerberos Support
Microsoft Kerberos Support

Cryptography

Kerberos builds on symmetric-key cryptography, but it may optionally use public-key cryptography during certain phases of authentication. (Wikipedia) A cipher suite (encryption type) will be negotiated and selected to support encryption, hashing, and other cryptographic operations. The following are commonly supported encryption types:

  • des-cbc-md5
  • des-cbc-crc
  • des3-cbc-sha1-kd
  • arcfour-hmac-md5
  • arcfour-hmac-md5-exp
  • aes128-cts-hmac-sha1-96
  • aes256-cts-hmac-sha1-96
Kerberos Pre-authentication
Kerberos Pre-authentication

References

Leave a Reply