Chapter 4

Authentication Applications

1
 Outline
Security Concerns
Kerberos
X.509 Authentication Service
Recommended reading and Web Sites

2
 KERBEROS

In Greek mythology, a many headed dog, the

guardian of the entrance of Hades 3
 KERBEROS: Environment
Users on workstations wish to access services on
servers distributed over network.

Network

Workstations Servers
4
 KERBEROS
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.

5
 KERBEROS
Provides a centralized authentication
server to authenticate users to servers
and 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

6
 KERBEROS: Motivation
Network evolution
 Dedicated PC – no network connection
 Single Centralized Server
 Distributed Servers: 3 security approaches
Workstation-based
Server-based
Service-based -> KERBEROS

7
 KERBEROS: Requirements
Secure
Reliable
Transparent
Scalable
Therefore use

trusted 3rd party authentication service.

8
 KERBEROS 4: Entities

Terms:
 C = Client
 AS = authentication server
 V = server
 IDc = identifier of user on C
 IDv = identifier of server V
 ADc = network address of C
 Pc = password of user on C
 Kv = secret encryption key shared by AS an V
 TS = timestamp
 || = concatenation
9
 KERBEROS 4
Building up the full protocol:
 Simple authentication dialogue
 More secure authentication dialogue
 KERBEROS 4 authentication dialogue

10
 A Simple Authentication Dialogue
Authentication
Server

Network

Workstations Servers

11
Authentication Server - AS

AS knows passwords
of all users

AS shares a unique
secret key with each
server

12
 A Simple Authentication Dialogue
(1) C  AS: IDc || Pc || IDv
(2) AS  C: Ticket
(3) C  V: IDc || Ticket

Ticket = EKv[IDc || ADc || IDv]

13
A Simple Authentication Dialogue
Ticket encrypted to prevent forgery
IDv – for server to verify its decryption
IDc – for verify that this ticket is for C
ADc – to prevent masquerading from
other workstation

14
A Simple Authentication Dialogue
Problems
 Users have to enter password every time
accessing the server/service
 Plaintext transmission of user’s password

15
A More Secure Authentication Dialogue
Authentication
Ticket Granting Server Server

Network

Workstations Servers

16
Ticket Granting Server - TGS

•TGS grants a ticket for a

particular service
(Ticketv)

•First, user must be authenticated at AS

and obtain ticket-granting ticket
(Tickettgs)

•Tickettgs is saved at workstation

17
 A More Secure Authentication Dialogue
Once per user logon session:
(1) C  AS: IDc || IDtgs
(2) AS  C: EK [Tickettgs]
C

Once per type of service:

(3) C  TGS: IDC || IDv ||Tickettgs
(4) TGS  C: Ticketv
Once per service session:
(5) C  V: IDC || Ticketv

18
 A More Secure Authentication Dialogue

Tickettgs = EKtgs [IDC||ADC||IDtgs||TS1||Lifetime1]

Ticketv = EKv[IDC||ADC||IDV||TS2||Lifetime2]

(Ktgs - key known only by AS and TGS)

(Kv - key known only by server and TGS)

19
A More Secure Authentication Dialogue

User’s password is not transmitted.

Tickettgs is encrypted by key derived from
user’s password.
Tickets are reusable but are timestamped
to prevent replay attack.

20
A More Secure Authentication Dialogue

Problems:
 Lifetime associated with the ticket-granting
ticket
If too short  repeatedly asked for password
If too long  greater opportunity to replay
 Similarly for service-granting ticket
 Opponent masquerades as server

21
 Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
(1) C  AS: IDc || IDtgs ||TS1
(2) AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]

Tickettgs = EKtgs[Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2]
To counter replay attack and prove user
identity
 AS provides session key to TGS and user
(Kc,tgs)
 Timestamp is also included
22
 Version 4 Authentication Dialogue
Ticket-Granting Service Echange: To obtain Service-Granting Ticket
(3) C  TGS: IDv ||Tickettgs ||Authenticatorc
(4) TGS  C: EKc [Kc,v|| IDv || TS4 || Ticketv]

Tickettgs = EKtgs[Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2]
Ticketv = EKv[Kc,v||IDc||ADc||IDv||TS4||Lifetime4]
Authenticatorc = EKc,tgs[IDc||ADc||TS3]

Authenticator very short lifetime to prevent replay

Kc,v is session key between user and server
23
 Version 4 Authentication Dialogue
Client/Server Authentication Exhange: To Obtain Service
(5) C  V: Ticketv || Authenticatorc
(6) V  C: EKc,v[TS5 +1]

Ticketv = EKv[Kc,v||IDc||ADc||IDv||TS4||Lifetime4]
Authenticatorc = EKc,v[IDc||ADc||TS5]

If also require server to prove itself to user then

(6) is used.

24
Overview of Kerberos

25
 Realms and Multiple Kerberi
The KERBEROS environment we had just
covered is called a realm.
There can be multiple realms where user
in one realm can access services in
another realm.
KERBEROS server in each realm shares a
secret key with servers in another realm.
KERBEROS servers are registered with one
another.
26
Request for Service in Another Realm

27
KERBEROS 4 Environmental Limitations

Encryption system dependence (V.4 DES)

Internet protocol dependence
Message byte ordering
Ticket lifetime
Authentication forwarding
Interrealm authentication

28
 KERBEROS 4 Technical Limitations

Double encryption – message (2) and (4)

PCBC encryption (propagating block
chaining) – has weakness
Session keys – can be used repeatedly
Password attacks

29
Kerberos Encryption Techniques
Password-to-Key Transformation

30
Kerberos Encryption Techniques
Password-to-Key Transformation

31
PCBC Mode

32
 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 Kerberized applications running on all
participating systems
 major problem - US export restrictions
 Kerberos cannot be directly distributed outside the US in source
format (& binary versions must obscure crypto routine entry
points and have no encryption)
 else crypto libraries must be implemented locally

33
X.509 Authentication Service
X.509 is a part of X.500 directory 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/TLS
and SET.
RSA is recommended for use.

34
35
X.509 Formats

36
Typical Digital Signature Approach

37
Obtaining a User’s Certificate
Characteristics of certificates generated by
CA:
 Any user with access to the public key of the
CA can recover the user public key that was
certified.
 No party other than the CA can modify the
certificate without this being detected.

38
X.509 CA Hierarchy

39
 Revocation of Certificates
Reasons for revocation:
 The users secret key is assumed to be
compromised.
 The user is no longer certified by this CA.
 The CA’s certificate is assumed to be
compromised.

40
Authentication Procedures

41
Recommended Reading and
WEB Sites
www.whatis.com (search for kerberos)
Bryant, W. Designing an Authentication
System: A Dialogue in Four Scenes.
http://web.mit.edu/kerberos/www/dialogue.html
Kohl, J.; Neuman, B. “The Evolotion of
the Kerberos Authentication Service”
http://web.mit.edu/kerberos/www/papers.html
http://www.isi.edu/gost/info/kerberos/

42