Kerberos Version 5

Kerberos Version 5 is developed to replace Kerberos Version 4 to address some of its deficiencies.

Other than that, there are some differences between Version 5 and Version 4#. Firstly, Version 4 depends solely on the use of Data Encryption Standard (DES) whereas Version 5 accepts any kind of encryption scheme or technique. Furthermore, V4 requires the use of IP Address# only whereas V5 allows any type of network address such as Media Access Control Address (MAC)# to be used. In V4, the sender of the message could choose its own message byte ordering, but the message structure is standardised using Abstract Syntax Notation One (ANS.1) and Basic Encoding Rules (BER) in V5. Moreover, the ticket lifetime is now indicated using explicit start and end time in V5, in contrast to the encoded 8-bit lifetimes values (up to 1280 minutes) in V4. Additionally, authentication forwarding is allowed in V5, but it is not in V4. Last but not least, the interopability (the degree of two things could be used together) among $N$ realms requires $O(N^2)$ Kerberos-to-Kerberos relationships in V4. V5 has a method that requires fewer relationships than in V4.

There are several flags that could be requested by the client that will be active for the session:

INITIAL: This ticket should be issued based on AS protocol instead of based on ticket-granting ticket
PRE-AUTHENT: The client was authenticated by the KDC before a ticket was issued during the initial authentication
HW-AUTHENT: The protocol employed for initial authentication requried the use of hardware
RENEWABLE: This ticket can be renewed at a later date
MAY-POSTDATE: A postdated ticket may be issued based on this ticket-granting ticket
POSTDATED: This ticket has been postdated
INVALID: This ticket is invalid
PROXIABLE: A new service-granting ticket with a different network address may be issued based on the presented ticket
PROXY: This ticket is a proxy
FORWARDABLE: A new ticket-granting ticket with a different network address may be issued based on this ticket-granting ticket
FORWARDED: This ticket has been forwarded or was issued based on authentication involving a forwarded ticket-granting ticket

Kerberos Version 5 operations could be summarised by the followings:

$$ \begin{align} C \rightarrow AS:& \text{Options} || ID_C || \text{Realm}_C || ID_{tgs} || \text{Times} || \text{Nonce}_1\\ AS \rightarrow C:& \text{Realm}_C || ID_C || \text{Ticket}_{tgs} || E_{K_C}[K_{c,tgs} || \text{Times} || \text{Nounce}_1 || \text{Realm}_{tgs} || ID_{tgs} ]\\ C \rightarrow TGS:& \text{Options} || ID_V || \text{Times} || \text{Nonce}_2 || \text{Ticket}_{tgs} || \text{Authenticator}_C\\ TGS \rightarrow C:& \text{Realm}_C || ID_C || \text{Ticket}_V || E_{K_C, tgs} [K{c,v} || \text{Times} || \text{Nonce}_2 || \text{Realm}_C || ID_V]\\ C \rightarrow V:& \text{Options} || \text{Ticket}_V || \text{Authenticator}_{C'}\\ V \rightarrow C:& E_{K_{C,V}} [TS_2 || \text{Subkey} || \text{Seq\#}] \end{align} $$

Where:

$C$ is the client
$AS$ is the Authentication Server
$\text{Options}$ is the request from the client that certain flags should be set on the returning $\text{Ticket}$
$ID$ for $C$ is the identity of the client, otherwise it is a request from the client to access a server
$\text{Realm}$ in the realm of user
$\text{Times}$ is the new mechanism that defines the lifetime of the $\text{Ticket} which has the value of from, till and rtime (renew time)
$\text{Nonce}$ is a Nonce#
$tgs$ or $TGS$ stands for Ticket Granting Server
$E$ is the encryption algorithm using the $K$ key
$\text{Lifetime}$ is the lifetime of the issued ticket
$\text{Ticket}_{tgs}$ is a ticket granted to client to access TGS, which is defined as $E_{K_{tgs}} [\text{Flags} || K_{c,tgs} || \text{Realm}_C || ID_C || AD_C || \text{Times}]$
$\text{Flags}$ reflects the ticket’s status and the requested options by $\text{Options}$.
$AD$ contains the device the client used initially produced the request.
$V$ is the server intended to be used by the client
$\text{Authenticator}_C$ is defined as $E_{K_{c,tgs}} [ID_C || \text{Realm}_C || TS_1]$, which is generated by client to validate the $\text{Ticket}_{tgs}$
$TS$ is the timestamp when the client initiated the request
$\text{Ticket}_V$ is a ticket granted to client to access the server, which is defined as $E_{K_V} [\text{Flags} || K_{C,V} || \text{Realm}_C || ID_C || AD_C || \text{Times}]$
$\text{Authenticator}_{C'}$ is defined as $E_{K_{c,v}} [ID_C || \text{Realm}_C || TS_2 || \text{Subkey} || \text{Seq\#} ]$, which is generated by client to validate the $\text{Ticket_{V}$
$\text{Subkey}$ is an encryption key used to protect the application session, by default it uses $K_{c,v}$
$\text{Seq\#}$ is an optional field specifies the starting sequence number in the message sent by the server to the client

Links to this page

Kerberos Version 4

However, Version 4 is not without flaws. There is a double encryption on the tickets provided to the client ($\text{Ticket}_{tgs}$ and $\text{Ticket}_{V}$). The encryption scheme used by V4 is not secure at all (PCBC, which is a non-standard Data Encryption Standard (DES)#). It is vulnerable to an attack which involves the interchange of the ciphertext blocks. (Version 5 prevents it by providing Cipher Block Chaining (CBC)# mode for encryption). In addition, the same ticket could be used by the client to access a server which is at risk of potential Replay Attack using an old session key. (V5 allows the use of a subsession key, which will be invalid after one connection)
Kerberos

Kerberos is a protocol utilising #Symmetric Cryptography to provide Security Service# in Application Layer#. It is done by authenticate the user in order to gain temporary access to internal or remote resources. There are currently two versions of Kerberos implementation: Version 4# and Version 5#. Regardless of the version, three components make up the structure of Kerberos which is used to guard the network: Authentication#, Accounting and Auditing. It has two main ~~components~~ servers: Authentication Server and Ticket Granting Server.