MODULE 4 : USER AUTHENTICATION

Remote User Authentication Principles:

➢ In most computer security contexts, user authentication is the fundamental building
block and the primary line of defense.

➢ User authentication is the basis for most types of access control and for user
accountability.

➢ User information needs to be stored on any server or computer system that he/she
wishes to use and could be known to system administrators.

➢ Typical item of authentication information associated with the user ID is password.

➢ User ID and password enables administrators to set up user’s access permissions and
audit their activity.
➢User authentication is distinct from message authentication.
▪ Message authentication is a procedure that allows
communicating parties to verify that the contents of a received
message have not been altered and that the source is authentic.
▪ User authentication is defined as the process of verifying an
identity claimed by or for a system entity.
An authentication process consists of two steps:

• Identification step: Presenting an identifier to the security system.

• Verification step: Presenting or generating authentication information

that confirms the binding between the entity and the identifier.
NIST E-AUTHENTICATION ARCHITECTURE MODEL
➢ Registration Authority (RA). RA is a trusted entity that establishes and vouches for the identity of an applicant to a Credential
Service Provider (CSP)

➢ Identity Proofing. Applicant applies to RA to become subscriber of a CSP. CSP issues some sort of electronic credential to
the subscriber based on verification of credentials by RA.

➢ Credential. It is a data structure that authoritatively binds an entity and additional attributes to a token possessed by the
subscriber and can be verified when presented to the verifier in an authentication transaction. Token can be an encryption key
or password that identifies the subscriber issued by CSP / generated directly by the subscriber / provided by a third party.
Token and credential may be used in subsequent authentication events. Once user is registered as subscriber, actual
authentication process can take place between subscriber and one or more systems that perform authentication and
subsequently authorization.

➢ Claimant & Verifier. Party to be authenticated is called claimant and party verifying that identity is called a verifier. When a
claimant successfully demonstrates possession and control of a token to a verifier through an authentication protocol, the
verifier can verify that claimant is the subscriber named in the corresponding credential.

➢ Relying Party. Uses authenticated information provided by the verifier to make access control or authorization decisions
 MEANS OF AUTHENTICATION
There are four general means of authenticating a user’s identity, which can be used alone or in
combination:

1) Something the individual knows: Examples include a password, a personal identification

number (PIN), or answers to a prearranged set of questions.
2) Something the individual possesses: Examples include cryptographic keys, electronic
keycards, smart cards, and physical keys.
3) Something the individual is (static biometrics): Examples include recognition by fingerprint,
retina, and face.
4) Something the individual does (dynamic biometrics): Examples include recognition by voice
pattern, handwriting characteristics, and typing rhythm.
All of these methods, properly implemented and used, can provide secure User
Authentication.
Mutual Authentication

Mutual authentication protocols enable communicating parties to satisfy themselves

mutually about each other’s identity and to exchange session keys.

Central to the problem of authenticated key exchange are two issues: Confidentiality
and Timeliness

To prevent compromise of session keys, essential identification and session-key

information must be communicated in encrypted form.

Timeliness, is important because of the threat of message replays. It can allow a

opponent to compromise a session key / successfully impersonate another party.
Replay Attacks
Where a valid signed message is copied and later resent
▪ simple replay
▪ repetition that can be logged
▪ repetition that cannot be detected (opponent suppresses original message)
▪ backward replay without modification (replay back to message sender, difficult to
recognize difference between message sent and message received on basis of
content – symmetric encryption is used)

Countermeasures include
a) use of sequence numbers (generally impractical-overheads)
b) timestamps (needs synchronized clocks,. protocol must be both fault tolerant,
to cope with network errors, and secure, to cope with hostile attacks)
c) challenge/response (using unique nonce)
Because of the variable and unpredictable nature of network delays, distributed clocks
cannot be expected to maintain precise synchronization. So, timestamp-based procedure
must allow for a window of time sufficiently large to accommodate network delays yet
sufficiently small to minimize the opportunity for attack

The challenge-response approach is unsuitable for a connectionless type of application,

because it requires the overhead of a handshake before any connectionless transmission,
effectively negating the chief characteristic of a connectionless transaction.
One way authentication :
One application for which encryption is growing in popularity is electronic mail.
The chief benefit of Email is that it is not necessary for the sender and receiver to be online
at the same time.

The e-mail message is forwarded to the receiver’s electronic mailbox, where it is buffered
until the receiver is available to read it.

The message can be handled by the store-and-forward e-mail protocol, such as the Simple
Mail Transfer Protocol (SMTP) or X.400

E-mail message should be encrypted such that the mail-handling system is not in possession
of the decryption key.
Second requirement is that of authentication. The recipient wants some assurance that the
message is from the genuine sender.
Remote user authentication using symmetric encryption :
Mutual Authentication:
Two-level hierarchy of symmetric encryption keys can be used to provide confidentiality for
communication in a distributed environment ( the third party KDC distributes the session key,
encrypting session key using master key to protect the distribution of keys )

Needham and Schroeder [NEED78] for secret key distribution using a KDC . Below is the
protocol. ▪ Secret keys shared between A & KDC, B & KDC
▪ A securely gets new session key in step 2
▪ Message in step 3 can be decrypted & hence understood only by B
▪ Step 4 reflects B’s knowledge of Ks
▪ Step 5 assures B of A’s knowledge of Ks and freshness by using N2

Despite the handshake of steps 4 and 5, the protocol is still vulnerable to a form of replay attack.
Adversary X can impersonate A and trick B into using the old key by simply replaying step 3.
Denning [DENN81, DENN82] proposes to overcome this weakness by a modification to the
Needham/Schroeder protocol that includes the addition of a timestamp to steps 2 and 3.
Her proposal assumes that the master keys, Ka and Kb, are secure, and it consists of the
following steps.

T is a timestamp that assures A and B that the session key has only just been generated.
Thus, both A and B know that the key distribution is a fresh exchange
A and B can verify timeliness by checking that
Δt1 is the estimated normal discrepancy between the KDC’s clock and the
local clock (at A or B)
Δt2 – network delay
Because the Timestamp T is encrypted using secure master keys, an opponent, even with knowledge of an old session key,
cannot succeed because a replay of step 3 will be detected by B as untimely
Steps 4 & 5 confirm receipt of session key at B
The Denning protocol seems to provide an increased degree of security compared to the
Needham/Schroeder protocol.
A new concern in the Denning’s approach is that the clocks must be synchronized throughout
the network.

When a sender’s clock is ahead of the intended recipient’s clock., an opponent can intercept a
message from the sender and replay it later when the timestamp in the message becomes
current at the recipient’s site.

This replay could cause unexpected results. Such attacks are referred as suppress-replay
attacks.

One way to counter suppress-replay attacks is to enforce the requirement that parties
regularly check their clocks against the KDC’s clock.

The other alternative, which avoids the need for clock synchronization, is to rely on
handshaking protocols using nonces
An attempt is made to respond to the concerns about suppress replay attacks and at the
same time fix the problems in the Needham/Schroeder protocol. Subsequently, an
inconsistency in this latter protocol was noted and an improved strategy was presented as
given below. The protocol is as given in the next slide.

Ks - session key
Tb – time limit to use Ks
 PROTOCOL TO OVERCOME SUPPRESS REPLAY ATTACKS

1. A initiates the authentication exchange by generating a nonce, Na, and sending that plus its identifier to B in plaintext. This
nonce will be returned to A in an encrypted message that includes the session key, assuring A of its timeliness.

2. B alerts the KDC that a session key is needed. Its message to the KDC includes its identifier and a nonce, Nb. This nonce
will be returned to B in an encrypted message that includes the session key, assuring B of its timeliness. B’s message to the
KDC also includes a block encrypted with the secret key shared by B and the KDC. This block is used to instruct the KDC to
issue credentials to A; the block specifies the intended recipient of the credentials, a suggested expiration time for the
credentials, and the nonce received from A.

3. The KDC passes on to A B’s nonce and a block encrypted with the secret key that B shares with the KDC. The block serves
as a “ticket” that can be used by A for subsequent authentications, as will be seen. The KDC also sends to A a block encrypted
with the secret key shared by A and the KDC. This block verifies that B has received A’s initial message (IDB) and that this is a
timely message and not a replay (Na), and it provides A with a session key (Ks) and the time limit on its use (Tb).

4. A transmits the ticket to B, together with the B’s nonce, the latter encrypted with the session key. The ticket provides B
with the secret key that is used to decrypt E(Ks, Nb) to recover the nonce. The fact that B’s nonce is encrypted with the
session key authenticates that the message came from A and is not a replay.

5. Protocol : Secure means for A & B to establish session with secure session key. Protocol leaves A in possession of a key
that can be used for subsequent authentication to B without
 Suppose that A and B establish a session using the aforementioned protocol and
then conclude that session.

Subsequently, but within the time limit established by the protocol, A desires a new
session with B. The following protocol ensues:

➢ When B receives the message in step 1, it verifies that ticket has not expired
➢ Newly generated nonces Na’ and Nb’ assures each party that there is no replay attack
➢ Time specified in Tb is a time relative to Bs clock. This timestamp does not require
synchronized clocks because B checks only self generated timestamps
One-Way Authentication

Symmetric encryption with some refinement is used for one way authentication for
Emails.
Following is the protocol for message M

➢ Here, we wish to avoid the requirement that recipient B be online at the same time as
sender A
➢ This approach guarantees that only the intended recipient of a message will be able to
read it
➢ Provides a level of authentication that sender is A
➢ Protocol does not protect against replays. This limitation can be improved by including a
timestamp but because of potential delays in email process, such timestamps may have
limited usefulness
REMOTE AUTHENTICATION USING ASYMMETRIC ENCRYPTION
 Remote User Authentication using Asymmetric Encryption:
➢ Protocol Assumption that each of 2 parties
are in possession of current public key of
other – not practical
➢ Central System – Authentication Server
(AS)
➢ AS – responsible for Public Key certificates
& not key distribution
➢ Timestamps – protect against replays of
compromised keys
AS:Authentication Server

This protocol is compact but, requires the synchronization of clocks

An approach, proposed by Woo and Lam [WOO92a], makes use of nonces. The
protocol consists of the following steps

This protocol seems to be a secure protocol that takes into account the various
attacks.
The authors themselves spotted a flaw and submitted a revised version of the
algorithm in [WOO92b].
Revised version of the algorithm in [WOO92b]
One Way Authentication :
Public-key encryption approaches require that either the sender
know the recipient’s public key (confidentiality), the recipient know
the sender’s public key (authentication), or both (confidentiality plus
authentication).

Public-key encryption approaches are suitable for E-mails.

If confidentiality is the primary concern, then the following is used for
Emails.

The message is encrypted with a one-time secret key

If authentication is the primary concern, then a digital signature may
suffice.

This technique is open to another kind of fraud.

To avoid fraud , both the message and signature can be encrypted
with the recipient’s public key.

Above two schemes require that B know A’s public key and be
convinced that it is timely. An effective way to provide this assurance is
the digital certificate.
KERBEROS

27
Overview

• When using authentication based on cryptography, an attacker listening to the

network gains no information that would enable it to falsely claim another's
identity.
• Kerberos is the most commonly used example of this type of authentication
technology. The authors concentrate on authentication for real-time,
interactive services that are offered on computer networks.

28
 INTRODUCTION

• Literal meaning: In Greek mythology, Kerberos is a multi-headed dog (usually three) which guards the
entrance of Hades.
• Technically Kerberos is an authentication protocol implemented in Project Athena at MIT
• Each user has complete control of its workstation
• But the workstations cannot be trusted completely to identify its users to the network services
• Kerberos acts as a third party authenticator - Helps the user to prove its identity to the various services
and vice versa
• Uses symmetrical cryptographic algorithms –Same key is used for encryption as well as decryption –Uses
DES (Data Encryption Standard)

29
Project Athena was a major computing project at MIT from 1983 to 1991, focused on creating a distributed
computing environment for educational purposes. It aimed to provide students and faculty with easy access to
computing resources and revolutionized educational computing, leading to the development of key technologies
like Kerberos, the X Window System, and the client-server model of distributed computing. Kerberos, in
particular, was a crucial authentication protocol developed within the project.

Key aspects of Project Athena:

Goal: To improve the quality of education by providing students with more accessible and robust computing
resources.
•Distributed Computing: The project focused on a networked, client-server model, where thin clients could access
resources from powerful servers.
•Kerberos: A network authentication protocol developed to secure communication and access control in the
distributed environment.
• X Window System: A software library that manages the appearance of the computer display screen, also
developed as part of the project.
•Legacy: The project's innovations influenced the development of various technologies, including thin computing,
LDAP, and Active Directory.
•Impact: Athena revolutionized educational computing and created the computing environment that many
students and faculty still use today
 THE THREE HEADS :

● Authentication : Confirms that a user who is requesting services is a valid user of the network

● Authorization : Granting of specific types of service to a user, based on their authentication

● Accounting : The tracking of the consumption of network resources by users

31
 HISTORY
Massachusetts Institute of Technology (MIT) developed Kerberos to protect network services provided by
Project Athena. The protocol is based on the earlier Needham–Schroeder symmetric key protocol. Several
versions of the protocol exist; versions 1–3 occurred only internally at MIT.

Kerberos version 4 was primarily designed by Steve Miller and Clifford Neuman. Published in the late
1980s, version 4 was also targeted at Project Athena.

Neuman and John Kohl published version 5 in 1993 with the intention of overcoming existing limitations
and security problems. Version 5 appeared as RFC 1510, which was then made obsolete by RFC 4120 in
2005.

32
 WHY Kerberos?

• Authentication is a key feature in a multi-user environment.

• Sending usernames and passwords over the network is not secure.
• Each time a password is sent in the network, there is a chance for interception.
• Problem: Cannot trust workstation to identify their users correctly in an open distributed environment .
• Solution: – Building elaborate authentication protocols at each server.
– A centralized authentication server (Kerberos) which authenticates users to servers and server
to users.

33
 Kerberos
Trusted authentication server system from MIT
provides centralised authentication server in a distributed network whose
function is to authenticate users to servers and servers to users.
Kerberos relies exclusively on symmetric encryption
Two versions in use: 4 & 5
Requirement : Servers to be able to restrict access to authorized users and to be able to
authenticate requests for service. A workstation cannot be trusted to identify its users
correctly to network services. In particular the following threats exist:-

➢ A user may gain access to a particular workstation and pretend to be another user
operating from that workstation
➢ A user may alter the network address of a workstation so that the requests sent from the
altered workstation appear to come from the impersonated workstation
➢ A user may eavesdrop on exchanges and use a replay attack to gain access to services to a
server or to disrupt operations

➢ In any of these cases, an unauthorized user may be able to gain access to services and
data that he or she is not authorized to access. Rather than building elaborate database
authentication protocols at each server, Kerberos provides a centralized authentication
server whose function is to authenticate users to servers and servers to users
 FIREWALL VS KERBEROS

• Firewall make a risky assumption that attackers are coming from the outside. In reality
attacks frequently come from within.
✓Assume “bad guys” are outside while the really damaging is happening in inside.
✓They even restrict how users can use the internet.

• Kerberos assumes that network connections (rather than servers and workstations) are
the weak link in network security.

36
 TERMINOLOGY

USER: A human being who wishes to use a computer system.

SERVICE: A program or set of programs running on a computer which is accessible over the
network. The service would like to know with certainty that the workstation to which it is
providing the service is really being used by the user who claims to be logged in on the
workstation.
PRINCIPAL: An entity that can both prove its identity and verify the identities of other
principals who wish to communicate with it, each user and each service registered with Kerberos
is thus a principal.
TICKET:A data structure obtained from Kerberos, which is presented to a service or application
to authenticate the ticket holder.

37
K.D.C. (Key Distribution Centre):Kerberos servers plus database of principals is regarded as the Key
Distribution Centre.

KDC consists of:

Ticket Granting Service (TGS):A server that issues tickets for a desired service which are in turn
given to users for access to the service. The TGS usually runs on the same host as the KDC.
Authentication Server(AS):Give reply to initial authentication requests from users.
Ticket Granting Ticket (TGT):A special ticket that allows the client to obtain additional tickets
without applying for them from the KDC
Database: Contains information about Users & Services.

SESSION KEY: The client has its own copy of this session key, which was contained in the credentials that
include this ticket Only the server can decrypt the ticket to receive its copy of the session key. Once this is
done, the server and client share a common secret key. That key is used to complete the authentication
process and may also be employed by client and server to encrypt their entire session.

CREDENTIALS: The combination of a ticket and its session key .The client sends the ticket to the server
in order to distribute the session key and also sends an authenticator which is encrypted in that session key.

38
 MOTIVATION FOR KERBEROS
A distributed architecture consisting of dedicated user workstations
(clients) and distributed or centralized servers.
Following are the three approaches to security in distributed
Environment.
1. Rely on each individual client workstation to assure the identity of its
user or users and rely on each server to enforce a security policy based on
user identification (ID).
2. Require that client systems authenticate themselves to servers, but
trust the client system concerning the identity of its user.
3. Require the user to prove his or her identity for each service invoked.
Also require that servers prove their identity to clients.
For small and closed env – option 1 or 2
For open env – option 3
 Kerberos assumes a distributed client/server architecture and employs one or more
Kerberos servers to provide an authentication service.

Kerberos Requirements
Kerberos first report identified following requirements :
▪ Secure :A N/w eavesdropper should not be able to obtain the necessary info to
impersonate a user.
▪ Reliable : Kerberos should be highly reliable and should employ a distributed server
architecture with one system able to back up other.
▪ Transparent: user should not be aware that authentication is taking place beyond the requirement to
enter a password.
▪ Scalable : support more number of clients and servers.
Kerberos v4:
Version 4 of Kerberos makes use of DES, to provide the authentication
service.
A simple Authentication Dialogue :
➢ In an unprotected network environment, any client can apply to any
server for service.
➢ The obvious security risk is that of impersonation. An opponent can
pretend to be another client and obtain unauthorized privileges on
server machine.
➢ To counter this threat, servers must be able to confirm the identities
of clients who request service.
➢ in an open environment, above way of authentication places a
substantial burden on each server.
An alternative is to use an authentication server (AS) that
knows the passwords of all users and stores these in a
centralized database.

The AS shares a unique secret key with each server

Each of the ingredients ( IDc, ADc, IDv ) of message (3) is

significant.
A more secure Authentication Dialogue:

Two problems of authentication in an open network environment in

previous authentication scheme are:-

1) A user has to enter a password each time he/she request for service
from server.

2) A plaintext transmission of the password [message (1)]. An

eavesdropper could capture the password and use any service accessible
to the victim.
To solve these problems, a scheme for avoiding plaintext
passwords and a new server, known as the ticket-granting
server (TGS) are introduced. The new scenario is as follows.
KERBEROS VERSION 4
MESSAGE EXCHANGE
Kerberos Principal

• A service or user that A service

is known to the An or user
name
Kerberos system instance
name
• Identified by its
A realm
principal name name

Three parts of a principal

name
Kerberos Realms and Multiple Kerberos realm :
A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a
number of application servers requires the following:

1. The Kerberos server must have the user ID and hashed passwords of all participating users in
its database. All users are registered with the Kerberos server.
2. The Kerberos server must share a secret key with each server. All servers are registered with
the Kerberos server
Above environment is referred to as a Kerberos realm typically a single administrative domain

➢ A Kerberos realm is a set of managed nodes that share the same Kerberos database. The
Kerberos database resides on the Kerberos master computer system.
➢ Changing or accessing the contents of a Kerberos database requires the Kerberos master
password
INTER-REALM AUTHENTICATION:
• Kerberos server in each realm shares a secret key with other realms.
• It requires
• Kerberos server in one realm should trust the one in other realm to
authenticate its users
• The second also trusts the Kerberos server in the first realm

KERBEROS
 Step Steps in Inter-Realm Authentication Description
Request for Service in another realm:
The user (from Realm A) logs in and
obtains a Ticket Granting Ticket (TGT)
1. User Login in Home Realm
from their own Authentication Server
(AS).

The user sends a request to their Ticket

Granting Server (TGS-A) to access a
2. Request for Cross-Realm TGT
service in Realm B. TGS-A checks the
trust path to Realm B.

TGS-A provides a TGT for TGS-B,

3. TGS-A Issues a Cross-Realm TGT encrypted with the key shared between
TGS-A and TGS-B (i.e., cross-realm key).

The user sends this cross-realm TGT to

4. Request to TGS-B in Target Realm TGS-B in Realm B to request a service
ticket for the specific service in Realm B.

TGS-B verifies the cross-realm TGT and

5. TGS-B Issues Service Ticket issues a service ticket for the desired
application server in Realm B.

The user presents the service ticket to

6. Access the Service in Realm B the application server in Realm B and
gains access.
Step Protocol Message Purpose

1. C → AS-A: Request TGT in Realm A C → AS-A: {C, TGS-A} Client sends request for TGT from AS of Realm A

AS-A → C: {TGT-A = {C, session key, validity}_K_TGS-A,

2. AS-A → C: TGT for TGS-A AS sends TGT for TGS-A, along with session key
session key}_K_C

3. C → TGS-A: Request Cross-Realm TGT for TGS-B C → TGS-A: {TGT-A, Authenticator}_K_session, {S in Realm B} Client requests a ticket for a server in Realm B

TGS-A → C: {TGT-B = {C, session key, validity}_K_TGS-B, TGS-A responds with a TGT for TGS-B, encrypted with key
4. TGS-A → C: TGT for TGS-B
session key}_K_C shared between TGS-A and TGS-B

5. C → TGS-B: Request service ticket for S in Realm B C → TGS-B: {TGT-B, Authenticator}_K_session, {S} Client contacts TGS-B using TGT-B to get a service ticket

TGS-B → C: {Ticket = {C, session key, validity}_K_S, session

6. TGS-B → C: Service ticket for S TGS-B sends the service ticket for server S in Realm B
key}_K_C

7. C → S: Request service using service ticket C → S: {Ticket, Authenticator}_K_session Client uses the service ticket to access service on S

Server can reply with timestamp+1 for mutual

8. S → C: Optional mutual authentication S → C: {timestamp + 1}_K_session
authentication
 New Elements in Kerberos Version 5

 Realm
 Indicates realm of the user
 Options
 Times
 From: the desired start time for the ticket
 Till: the requested expiration time
 Rtime: requested renew-till time
 Nonce
 A random value to assure the response is fresh

KERBEROS
Differences Between Versions 4 and 5

Version 5 is intended to address the

limitations of version 4 in two areas:

Environmental shortcomings Technical deficiencies

•Encryption system dependence •Double encryption
•Internet protocol dependence •PCBC encryption
•Message byte ordering •Session keys
•Ticket lifetime •Password attacks
•Authentication forwarding
•Interrealm authentication
 Kerberos Version 5 Message Exchange:1
 To obtain ticket-granting ticket:

(1)C → AS : Options || IDc || Realmc || IDtgs ||Times || Nonce1

(2) AS → C : Realmc || IDc || Ticket tgs || EKc [ Kc,tgs || IDtgs || Times || Nonce1 ||| Realm tgs ]

Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c || IDc || ADc || Times]

In the first step, the client sends a request to the Authentication Server (AS) with its identity and the identity of the
Ticket Granting Server (TGS). Nonce1 is used to ensure freshness and prevent replay attacks.

The AS responds with a session key (Kc,tgs) encrypted with the client’s key, and a Ticket-Granting Ticket (TGT)
encrypted with the TGS’s key. The client cannot read the TGT—it’s meant to be used later with the TGS.
 Kerberos Version 5 Message Exchange:2
 To obtain service-granting ticket :

(3)C → TGS : Options || IDv || Times || Nonce2 || Ticket tgs ║ Authenticator c

(4)TGS → C : Realmc || IDc || Ticket v || EK c,tgs [ Kc,v ║Times|| Nonce2 || IDv ║ Realm v]

Ticket tgs= EKtgs [ Flags || Kc,tgs || Realm c || IDc || ADc || Times]

Ticket v : EK v [Kc,,v ║ Realmc || IDc ║ ADc ║ Times ]
Authenticator c : EK c,tgs [IDc ║ Realmc ║ TS1]
Now, the client wants to access a specific service on a server (IDv). It sends the previously obtained TGT to
the TGS, along with an authenticator, which is a timestamped proof of identity encrypted using Kc,tgs.

The TGS validates the TGT and the authenticator, then issues a new service ticket (Ticket_v) and a
session key (Kc,v) for secure communication with the service. This is sent back to the client with Nonce2
to confirm the response corresponds to the request.
 Kerberos Version 5 Message Exchange:3
 To obtain service
(5) C → S : Options || Ticket v|| Authenticator c
(6) S → C : EK c,v [TS2|| Subkey || Seq# ]

 Ticket v : EK v [Flags || Kc,v || Realmc || IDc || ADc || Times ]

 Authenticator c : EK c,v [IDc || Realmc || TS2 || Subkey|| Seq# ]
In this final step, the client presents the service ticket (Ticket_v) and another authenticator to the actual service server.

The server decrypts the ticket and validates the authenticator to ensure the request is legitimate and timely. If valid, it
sends back a confirmation encrypted with the session key (Kc,v), including a timestamp and optionally a subkey and
sequence number for further secure communication. This establishes mutual authentication and a secure channel
between client and server.
Kerberos : Strengths
 User's passwords are never sent across the network, encrypted or in plain text

 Secret keys are only passed across the network in encrypted form

 Client and server systems mutually authenticate

 It limits the duration of their users' authentication.

 Authentications are reusable and durable

KERBEROS
Conclusion
 Kerberos is an authentication service using convention encryption
 Kerberos the solution to network security is a protocol designed to provide
centralized authentication whose function is to authenticate user to server
and server to user.

KERBEROS