Kerberos Version 5 | Need of Kerberos Version 5 | Message Exchange in Kerberos Version 5

     Kerberos Version 5 | Need of Kerberos Version 5 | Message Exchange in Version 5

What is Kerberos?

Kerberos is a network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

Different Version of Kerberos Protocols

Why Kerberos Version 5.0?

Version 5 is intended to address the limitations of version 4 in two areas: environmental shortcomings and technical deficiencies.

Environmental shortcomings: Encryption System Dependence, Internet Protocol, Dependence, Ticket Lifetime, Authentication Forwarding, Inter Realm Authentication. All the shortcomings are explained as below:

Encryption system dependence

Version 4 requires the use of DES. Export restriction on DES as well as doubts about the strength of DES were thus of concern. In version 5, ciphertext is tagged with an encryption-type identifier so that any encryption technique may be used.

Internet protocol dependence

Version 4 requires the use of Internet Protocol (IP) addresses. Other address types, such as the ISO network address, are not accommodated. Version 5 network addresses are tagged with type and length, allowing any network address type to be used.

Ticket lifetime

Lifetime values in version 4 are encoded in an 8-bit quantity in units of five minutes. Thus, the maximum lifetime that can be expressed is 2⁸ * 5 = 1280 minutes This may be inadequate for some applications. In version 5, tickets include an explicit start time and end time, allowing tickets with arbitrary lifetimes.

Authentication forwarding

Version 4 does not allow credentials issued to one client to be forwarded to some other host and used by some other client. This capability would enable a client to access a server and have that server access another server on behalf of the client. Version 5 provides this capability.

Figure: Authentication Forwarding

Inter Realm Authentication

In version 4, interoperability among realms requires many Kerberos - to - Kerberos relationships but version 5 supports a method that requires fewer relationships.

Figure: Inter Ralm Authentication

Technical Deficiencies: PCBC Encryption, Session Keys, Password attack. All technical deficiencies are explained as below:

PCBC encryption:

Encryption in version 4 makes use of a non-standard mode of DES known as propagating cipher block chaining (PCBC). It has been demonstrated that this mode is vulnerable to an attack involving the interchange of ciphertext blocks. Version 5 allows the standard CBC mode to be used for encryption.

Figure: PCBC Encryption

Figure: CBC Encryption

Session keys:

Each ticket includes a session key used for encrypting messages. However, because the same ticket may be used repeatedly, replay attack is possible. In version 5, it is possible for a client and server to negotiate a sub- session key, which is to be used only for that one connection.

Figure: Session Key & Sub Session key

Password attack:

Both versions are vulnerable to a password attack. The message from the AS to the client includes material encrypted with a key based on the client's password. An opponent can capture this message and attempt to decrypt it by trying various passwords. Thus, the opponent can discover the client's password and may subsequently use it to gain authentication credentials from Kerberos.

Kerberos V 5.0 Message Exchange

Message-1: First, consider the authentication service exchange. Message (1) is a client request for a ticket-granting ticket. As before, it includes the ID of the user and the TGS. The following new elements are added:

Realm: Indicates realm of user

Options: Used to request that certain flags be set in the returned ticket

Times: Used by the client to request the following time settings in the ticket:

from: the desired start time for the requested ticket

till: the requested expiration time for the requested ticket

rtime: requested renew-till time

Nonce: A random value to be repeated in message (2) to assure that the response is fresh and has not been replayed by an opponent

Message-2: Message (2) returns a ticket-granting ticket, identifying information for the client, and a block encrypted using the encryption key based on the user’s password. This block includes the session key to be used between the client and the TGS, times specified in message (1), the nonce from message (1), and TGS identifying information. The ticket itself includes the session key, identifying information for the client, the requested time values, and flags that reflect the status of this ticket and the requested options. These flags introduce significant new functionality to version 5. For now, we defer a discussion of these flags and concentrate on the overall structure of the version 5 protocol.

The following flags are used in Kerberos Version 5 message exchange:

Message-3: Let us now compare the ticket-granting service exchange for versions 4 and5. We see that message (3) for both versions include an authenticator, a ticket, and the name of the requested service. In addition, version 5 includes requested times and options for the ticket and a nonce—all with functions similar to those of message (1). The authenticator itself is essentially the same as the one used in version 4.

Message-4: Message (4) has the same structure as message (2). It returns a ticket plus information needed by the client, with the information encrypted using the session key now shared by the client and the TGS.

Message-5: Finally, for the client/server authentication exchange, several new features appear in version 5. In message (5), the client may request as an option that mutual authentication is required. The authenticator includes several new fields:

Subkey: The client’s choice for an encryption key to be used to protect this specific application session. If this field is omitted, the session key from the ticket (Kc,v) is used.

Sequence number: starting sequence number to be used by the server for messages sent to the client during this session. Messages may be sequence numbered to detect replays.

Message-6: If mutual authentication is required, the server responds with message (6). This message includes the timestamp from the authenticator. Note that in version 4, the timestamp was incremented by one. This is not necessary in version 5, because the nature of the format of messages is such that it is not possible for an opponent to create message (6) without knowledge of the appropriate encryption keys. The subkey field, if present, overrides the subkey field, if present, in message (5). The optional sequence number field specifies the starting sequence number to be used by the client.

To learn more about Socket Programming Functions, Click here

Watch more videos click here.