Kerberos is an authentication system that allows clients to prove their identity to servers in an open distributed system without sending passwords over the network. It uses tickets and authenticators to allow clients to request services from servers. Kerberos Version 5 improves upon Version 4 by allowing for stronger encryption, longer ticket lifetimes, support for multiple protocols, and easier authentication across multiple realms.

1. Module 1
Module-1 (Authentication Protocols)
Authentication Protocols – Mutual authentication, One
way authentication.
Kerberos –Kerberos Version 4, Kerberos Version 5. X.509
Authentication service. Public Key Infrastructure (PKI) –
Trust models, Revocation.

2. • CO1: Explain authentication protocols, X.509
authentication service and Public Key Infrastructure
(PKI).(Cognitive Knowledge Level: Understand)

10. 10
KERBEROS
In Greek mythology, a many headed dog, the
guardian of the entrance of Hades

11. KERBEROS
• Is an authentication service
• Used in an open distributed environment in
which users at workstation access services on
servers distributed over the network
• Only restricted access is allowed
11

12. 12
KERBEROS
• Users wish to access services on servers.
• Three threats exist:
– User pretend to be another user.
– User alter the network address of a workstation.
– User eavesdrop on exchanges and use a replay
attack.

13. 13
KERBEROS
• a centralized authentication server (Kerberos) which
authenticates
– Users to servers
– Servers to users
• Relies on conventional encryption, making no use of
public-key encryption
• Two versions: version 4 and 5
• Version 4 makes use of DES
• Version 5 corrects some of the security deficiencies of
Version 4

14. Why KERBEROS?
• If a set of users is provided with dedicated personal
computers that have no network connections, then a
users resources can be protected by securing each
computer
• But now we use distributed architecture consisting
of dedicated user workstation (clients) and
distributed or centralized servers
14

15. Kerberos Requirements
• first published report identified its requirements
as:
– secure-an eavesdropper shouldn’t be able to get enough
information to impersonate the user
– reliable- services using Kerberos would be unusable if
Kerberos isn’t available
– transparent-users should be unaware of its presence,
beyond the requirement to enter a password
– scalable- should support large number of users

16. 16
Kerberos Version 4
• Terms:
– C = Client
– AS = authentication server
– V = server
– IDc = identifier of user on C
– IDv = identifier of V
– Pc = password of user on C
– ADc = network address of C
– Kv = secret encryption key shared by AS and V
– TS = timestamp
– || = concatenation

17. 17
A Simple Authentication Dialogue
(1) C  AS: IDc || Pc || IDv
(2) AS  C: Ticket
(3) C  V: IDc || Ticket
Ticket = E(Kv,[IDc || ADc || IDv])
Since the ticket is encrypted it cannot be altered by C or
by any opponent
• C  V: V decrypts the ticket and verifies that the
user ID in the ticket is the same as the unencrypted
user ID in the message
• Ticket is valid only if it is transmitted from same
workstation.thats why ADc is included

18. Kerberos Version 4: Dialog 1- Simple
1- IDc + Pc+IDv
2- Ticket
3- IDc +Ticket
Ticket=Ekv[IDc,ADc,IDv]
kv=Secret Key between AS and V (Server)
Pc=password of client

19. Kerberos
• A more Secure Authentication Dialogue
– Simple authentication dialogue’s problem
• Too many times that user has to enter a password
– User need a new ticket for every different service
• Plaintext transmission of the password(in msg 1)
• M1: C  AS: IDc || Pc || Idv
Solution-a new server
→TGS(Ticket Granting Server)-issues ticket to users
who have been authenticated to AS

20. • sending usernames and passwords in the clear
jeopardizes the security of the network.
• each time a password is sent in the clear, there is a
chance for interception.
20

21. Kerberos Version 4 : Dialog 2-More
Secure
1- IDc + IDtgs
2- EKc [TicketTGS]
3- TicketTGS+IDc+IDv
4-TicketV
Once per user
logon session
Once per type of
service
ticketTGS=EKtgs[IDc,ADc,
IDtgs,TS1,LifeTime1 ]

22. Kerberos Version 4 : Dialog 2
- More Secure
Cont.
5- TicketV+ IDc
Once per service session
TicketV=EKv[IDc,ADc,IDv,Ts2,Lifetime2]

23. Kerberos
• A more Secure Authentication Dialogue
– Once per user logon session
1.C  AS : IDC , IDtgs( request to use TGS service)
2.AS  C : Ekc [Tickettgs] (responds with a ticket
encrypted with a key derived from users password)
Tickettgs = E(ktgs [IDC,ADC,IDtgs, TS1,Lifetime1])
• Client module asks user for the password to decrypt the
Tickettgs
• If password is correct the ticket is successfully recovered
• This method avoids transmitting the password as plaintext

24. A more Secure Authentication
Dialogue
• Client request ticket granting ticket[Tickettgs] from the
AS which is saved for later use
• Tickettgs = E(ktgs [IDC,ADC,IDtgs, TS1,Lifetime1])
• Ticket consists of ID and the network address of the user
and the ID of TGS
• Each time when user requires access to new service, the
client applies to the TGS using the ticket [Tickettgs ] to
authenticate itself

25. – Once per type of service
3.C  TGS : IDC , IDV , Tickettgs
• TGS decrypts the ticket and verifies the ID. It also checks the
lifetime of ticket. If ID and n/w address matches, the user is
authenticted.
• If user is permitted to access the server V,TGS issues Ticketv to
access the server V
4.TGS  C : Ticketv
Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]
A more Secure Authentication Dialogue

26. – Once per service session
5.C  V : IDC , Ticketv
• Cleint module request service on behalf of user.
• For this client transmits a message to the server containing
user ID and service granting ticket
• Server authenticates by using the contents of the ticket
– Tickettgs = Ektgs [IDC,ADC,IDtgs, TS1,Lifetime1]
– Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]
26
A more Secure Authentication Dialogue

27. – Once per user logon session
1.C  AS : IDC , IDtgs( request to use TGS
service)
2.AS  C : Ekc [Tickettgs] (responds with a ticket
encrypted with a key derived from users
password)
– Once per type of service
3.C  TGS : IDC , IDV , Tickettgs
4.TGS  C : Ticketv
– Once per service session
5.C  V : IDC , Ticketv
– Tickettgs = Ektgs [IDC,ADC,IDtgs, TS1,Lifetime1]
– Ticketv = EKv[IDC,ADC,IDV,TS2,Lifetime2]
27

28. 28
Version 4 Authentication Dialogue
• Problems:
– Lifetime associated with the ticket-granting ticket
– If too short  repeatedly asked for password
– If too long  greater opportunity to replay
• The threat is that an opponent will steal the ticket and use
it before it expires
• TGS or an application service must be able to prove that the person
using a ticket is the same person to whom that ticket was issued

29. Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
(1) C  AS: IDc || IDtgs ||TS1
(2) AS  C: E(Kc ,[Kc,tgs|| IDtgs || TS2 || Lifetime2 ||
Tickettgs])
Tickettgs = E(Ktgs,[Kc,tgs,IDC,ADC,IDtgs,TS2, Lifetime2])
• Opponent will steal the ticket and use before it expires
• Let AS provide both the client and TGS with a secret
information in a secure manner
• Referred to as session key
• AS responds with message encrypted with key derived
from users password that contains Tickettgs
• Encrypted message also contains a copy of session key
kc,tgs(Session key for C and TGS)

30. • Since session key is inside the message encrypted
with kc only users client can read it
• Now C is ready to approach TGS
Ticket-Granting Service Echange: To obtain Service-Granting Ticket
(3) C  TGS: IDv || Ticket
tgs
|| aunthenticator
c
(4) TGS  C: E(Kc,tgs [Kc,v|| IDv || TS4 || Ticket
v
])
Ticket
v
= Ek
v,
[K
c,v
,ID
C
,AD
C
,ID
v
,TS
4
,L-time
4
]
Authenticator
c
= E
Kc,tgs
[ID
C
,AD
C
,TS
3
]
Ticket says anyone who uses Kc,tgs must be C. TGS uses session key to decrypt
authenticator

31. (4)TGS  C:
E(Kc,tgs [Kc,v|| IDv || TS4 || Ticketv])
• Message is encrypted with session key shared by
TGS and C
• includes a session key to be shared between C and
the server V
• Id of V and TS
• Ticket for V
31

32. • C presents the ticket and the authenticator
• Server decrypt the ticket, recover the session key
and decrypt the authenticator
• Authenticatorc = EKc,v[IDC,ADC,TS5]
• Ticketv = E(Kv,[Kc,v,IDC,ADC,IDv,TS4,L-time4])
• Server returns the value of timestamp from the
authenticator incremented by 1 and encrypted with
session key
Client/Server Authentication Exhange: To Obtain Service
(5) C  V: Ticketv || Aunthenticator
c
(6) V  C: E(Kc,v[TS5 +1])

34. Kerberos
• The version4 Authentication Dialogue
1. Client requests ticket-granting ticket
2. AS returns ticket-granting ticket
3. Client requests service-granting ticket
4. TGS returns service-granting ticket
5. Client requests service
6. Service granted

35. Kerberos: The Version 4
Authentication Dialog
1- IDc + IDtgs +TS1
2- E(Kc ,[Kc,tgs,IDtgs,Ts2,
Lifetime2,TicketTGS]
KERBEROS
Once per user logon session
ticketTGS=E(Ktgs, [Kc,tgs,
IDc,ADc,IDtgs,TS2, LifeTime2 ]

36. Kerberos: The Version 4 Authentication
Dialog Cont.
KERBEROS
3- TicketTGS + AuthenticatorC
+ IDv
4-E(kc,tgs[kc,v,IDv,Ts4,Ticketv])
Once per type of service
ticketTGS=E(Ktgs [Kc,tgs,IDc,ADc,IDtgs,
TS2, LifeTime2 ])
AuthenticatorC=E(Kc,tgs[IDc,ADc,TS3]
ticketV=E(K
v
[K
c,v,Idc,ADc,IDv, TS4,
LifeTime4 ])

37. Kerberos: The Version 4
Authentication Dialog Cont.
5- TicketV+ AuthenticatorC
Once per service session
TicketV=E(Kv [Kv,c, IDc, ADc, IDv, TS4, Lifetime4])
AuthenticatorC=Ekc,v [IDc,ADc,TS5]
6- E(kc,v[TS5+1])

38. 38
The version4 Authentication
Dialogue

39. 39
Tickets:
• Contains information which must be considered
private to the user
• Allows user to use a service or to access TGS
• Reusable for a period of particular time
• Used for distribution of keys securely

40. 40
Authenticators
• Proves the client’s identity
• Proves that user knows the session key
• Prevents replay attack
• Used only once and has a very short life time
• One authenticator is typically built per session
of use of a service

41. Kerberos Realms and Multiple
Kerberi
• A single administrative domain includes:
– a Kerberos server
– a number of clients, all registered with server
– application servers, sharing keys with server
• What will happen when users in one realm need
access to service from other realms?:
– Kerberos provide inter-realm authentication

42. • The Kerberos server must have the user ID (UID)
and hashed password of all participating users in
its database. All users are registered with the
Kerberos server.
• The Kerberos server must share a secret with each
server. All servers are registered with the Kerberos
server.
• Such an environment is referred to as realm.
42

43. 43
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

44. 44
Request for Service in Another
Realm

45. Request for Service in another realm:
1-Request ticket for
local TGS
2-Ticket for local TGS
5-Request ticket for remote server
6-Ticket for remote server
3-Request ticket for remote TGS
4-Ticket for remote TGS
7-request for remote service

46. Kerberos Realms and Multiple
Kerberi
46
1. Request ticket for local TGS
2. Ticket for local TGS
3. Request ticket for remote TGS
4. Ticket for remote TGS
5. Request ticket for remote server
6. Ticket for remote server
7. Request remote service

47. • 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

48. 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]

49. 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]

50. 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# ]

51. KERBEROS Version 5 versus Version4
• Environmental shortcomings of Version 4:
– Encryption system dependence: DES
• Any encryption algorithms can be used in v5 but only DES
is possible in v4
– Internet protocol dependence
• Only IP is possible → to use any internet protocol
– Ticket lifetime
• 1280 minutes (maximum time) →any length of time

52. – Authentication forwarding
• V4 does not allow credentials issued to one client to be
forwarded to some other host and used by some other
client. V5 provides this capability.
• i.e server can forward authentication to another server
– Inter-realm authentication
• Technical deficiencies
– Double encryption in V4.
– PCBC encryption
– In v5, Standard CBC is used
– Password attack
– Session Keys- each ticket includes a session key
that is used by the client.

53. 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 ]

54. 54
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 has been scrutinized by many of the top
programmers, cryptologists and security experts in
the industry

55. Kerberos - in practice
• Currently have two Kerberos versions:
• 4 : restricted to a single realm
• 5 : allows inter-realm authentication
• Kerberos v5 is an Internet standard
• specified in RFC1510, and used by many utilities
• To use Kerberos:
• need to have a KDC on your network
• need to have Kerberised applications running on all participating systems
• major problem - US export restrictions
• Kerberos cannot be directly distributed outside the US in source format
• else crypto libraries must be re-implemented locally

56. PUBLIC KEY
INFRASTRUCTURE (PKI)
o distribute public keys securely
• Requires
- Certificates and Certification Authorities
- Method for retrieving certificates
- Method for revoking certificates
- Method for evaluating certificates from
trust anchors

57. 57
Certificate:
• Electronic counterparts to driver licenses,
passports
• Verifies authenticity of the public key
• Prevents impersonation
• Enables individuals and organizations to
secure business and personal transactions

58. 58
Certificate Authorities:
• Trusted entity which issue and manage
certificates for a population of public-private
key-pair holders.
• A digital certificate is issued by a CA and is
signed with CA’s private key.

59. Certificate Issuance Process:
• Generate public/private key pair
• Sends public key to CA
• Proves identity to CA - verify
• CA signs and issues certificate
• CA e-mails certificate or Requestor
retrieves certificate from secure websites
• Requestor uses certificate to demonstrate
legitimacy of their public key

60. Types of Digital Certificates
• E-Mail Certificates
• Browser Certificates
• Server (SSL) Certificates
• Software Signing Certificates

61. • A certificate is a document that contains both an
identity and a public key, binding them together
by a digital signature.
• This digital signature is created by an
organisation called a Certification Authority
(CA).
• This organisation guarantees that upon creating
the digital signature it has checked the identity
of the public key owner (e.g. by verifying a
passport) and that is has checked that this public
key owner is in possession of the corresponding
private key. 61

62. • Anybody in possession of the CA's public key
can verify the CA's signature on the certificate.
In this way the CA guarantees that the public key
in the certificate belongs to the individual whose
identity is in the same certificate.
62

63. 63
What a certificate includes:
• Name of Entity being Certified
• Public Key
• Name of Certificate Authority
• Serial Number
• Expiration Date
• Digital signature of the issuer
• Other information (optional)

64. Who are the Certificate Authorities?
VeriSign
GTE CyberTrust
Entrust
CertCo
USPS / Cylink

65. Block Diagrams of
Certification Process
Certificate
Authority
CA
Repository
Dbase
Subscriber
Receiving
Party
1 2
3
4
5 6

66. 66
X.509 Authentication Service
• Distributed set of servers that maintains a
database about users.
• Each certificate contains the public key of a
user and is signed with the private key of a
CA.
• Is used in S/MIME, IP Security, SSL and
SET.
• RSA is recommended to use.

67. 67

68. X.509 Formats

69. X.509 Certificate format
Version
Serial number
Algorithm
Parameters
Issuer
Not before
Not after
Subject
Algorithm
Parameter
Key
Signature
Algorithm
identifier
Period of
validity
Subject’s
public key
Notation to define a certificate:
CA<<A>>=CA{V,SN,AI,CA,Ta,A,Ap}
where
Y<<X>>= the certificate of user X issued by
certification authority Y
Y{I}=the signing of I by Y. It consists of I with
an enciphered hash code appended.

70. X.509 Certificates
• issued by a Certification Authority (CA), containing:
– version (1, 2, or 3)
– serial number (unique within CA) identifying certificate
– signature algorithm identifier –algorithm used to sign
the certificate
– issuer X.500 name (CA)
– period of validity (from - to dates)
– subject X.500 name (name of owner-public key holder)
– subject public-key info (algorithm, parameters, key)
– issuer unique identifier (v2+)
– subject unique identifier (v2+)
– extension fields (v3)
– signature (of hash of all fields in certificate encypted
with CA’s private key)
• notation CA<<A>> denotes certificate for A signed by CA

71. Obtaining a Certificate
• any user with access to CA can get any
certificate from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be
placed in a public directory

72. CA Hierarchy
• if both users share a common CA then they are assumed
to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to validate
other CA's
– each CA has certificates for clients (forward) and parent
(backward)
• each client trusts parents certificates
• enable verification of any certificate from one CA by
users of all other CAs in hierarchy
72

73. 73

74. Securely Obtain a Public Key
• Scenario:
– A has obtain a certificate from the CA X1
– B has obtain a certificate from the CA X2
– A can read the B’s certificate but cannot verify it.

75. X.509 CA Hierarchy
A acquires B certificate
using chain:
X<<W>>W<<V>>V<<Y>
>Y<<Z>> Z<<B>>
B acquires A certificate
using chain:
Z<<Y>>Y<<V>>V<<W>>
W<<X>> X<<A>>

76. 76
Forward Certificate: Certificate of X generated by other
CAs
Reverse Certificates: Certificates generated by X for
another CA

77. 77

78. Certificate Revocation
• certificates have a period of validity
• may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
• CA’s maintain list of revoked certificates
– the Certificate Revocation List (CRL)
• users should check certificates with CA’s CRL
78

79. Authentication Procedures
• X.509 includes three alternative
authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures
79

80. 80
Authentication Procedures:
• Three alternative authentication procedures:
– One-Way Authentication
– Two-Way Authentication
– Three-Way Authentication
• All use public-key signatures

81. One-Way Authentication:
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– message must include timestamp, nonce, B's
identity and is signed by A
– integrity & originality of message
A B
1-A {ta,ra, IDb,sgnData, E[PUb,Kab]}
Ta-timestamp rA=nonce IDb =identity
sgnData=signed with A’s private key
nonce is an abbreviation of number used once

82. 82
Two-Way Authentication
• 2 messages (A->B, B->A) which also
establishes in addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
A B
1-A {ta,ra,B,sgnData,E[PUb,Kab]}
2-B {tb,rb,A,sgnData, E[PUa,Kab]}

83. 83
Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which
enables above authentication without
synchronized clocks
A B
1- A {ta,ra,B,sgnData, E[PUb,Kab]}
2 -B {tb,rb,A,sgnData, E[PUa,Kab]}
3- A{rb}