CHAPTER 5:

AUTHENTICATION
APPLICATIONS

UFCEKQ-10-3 Internet Security

UFCEKQ-10-3 Internet Security

PROBLEMS WITH PASSWORD-BASED

AUTHENTICATION
 Problems associated with password based
authentication
 Passwords can be collected by eavesdropping
 Password based authentication is inconvenient
 Enter a password each time a user accesses a network
service
 Stronger authentication methods base on
cryptography are required
 So that 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
2
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

KEY DISTRIBUTION
 Given parties A and B have various key
distribution alternatives:
1. A can select key and physically deliver to B
2. Third party can select & deliver key to A & B
3. If A & B have communicated previously
 Can use previous key to encrypt a new key
4. If A & B have secure communications with a
trusted third party C,
 C can relay key between A & B
 As number of parties grow, some variant of 4 is
the only practical solution to the huge growth
in number of keys potentially needed

3
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

KERBEROS
 Trusted key server system from MIT
 Provides centralised private-key third-party
authentication in a distributed network
 Allows users access to services distributed through
network
 Without needing to trust all workstations
 Rather all trust a central authentication server
 Two versions in use: 4 & 5

4
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

KERBEROS V4 OVERVIEW
 A basic third-party authentication scheme
 Has an Authentication Server (AS)
 Users initially negotiate with AS to identify self
 AS provides a non-corruptible authentication credential
(ticket-granting-ticket TGT)
 Has a Ticket Granting server (TGS)
 Users subsequently request access to other services from
TGS on basis of the user’s TGT
 Using a complex protocol involving DES

5
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

2. AS verifies user's access right in

KERBEROS OVERVIEW
database, creates ticket-granting ticket
and session key. Results are encrypted
using key derived from user's password.

once per
user logon Kerberos
session

Authentication
ket- Server (AS)
es t tic icket
u
req nting t
1. User logs on to g r a
key
workstation and
s e ssion
requests service on host. t+
ticke
s e rv i c e - Ticket-
request g ticket
grantin granting
y Server (TGS)
ession ke
ticket + s

once per
3. Workstation prompts
type of service 4. TGS decrypts ticket and
authenticator, verifies request,
user for password and
uses password to decrypt then creates ticket for requested
req server.
incoming message, then ue
sends ticket and st
se r
authenticator that vi c
contains user's name, e
network address, and pr
time to TGS. au ovid
the e s
nti erv
once per cat er
or 6. Server verifies that
service session ticket and authenticator
5. Workstation sends match, then grants access
ticket and authenticator to service. If mutual
to server. authentication is
required, server returns
an authenticator.
6
Chapter 5: Authentication Applications Figure 4.1 Overview of Kerberos
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL

 User logs on the client machine using username and

password combination
Client Logon

 The client machine performs a one-way hash on the

entered password
 This becomes the secret key of the client/user

 Client sends a cleartext message of the username/ID to

Client Authentication

the AS
 AS generates the secret key by hashing the user
password
 Found at the database e.g. Active Directory in

Windows Server

Client AS
7
Chapter 5: Authentication Applications TGS
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
Message A
 AS sends back the following two
messages
 Message A: Client/TGS Session
Key encrypted using the secret key
Client Authentication

of the client/user Message B

 Message B: Ticket-Granting-
Ticket (TGT) encrypted using the
secret key of the TGS
 TGT includes the client ID, client
network address, ticket validity
period, and the Client/TGS
session key
Client AS
8
Chapter 5: Authentication Applications
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
Message A
 Client receives messages A and B
 Attempts to decrypt message A
 With the secret key generated from the password
entered by the user
 If the user entered password does not match the
Client Authentication

password in the AS database

 The client's secret key will be different and thus
unable to decrypt message A.
 With a valid password and secret key the client
decrypts message A to obtain the Client/TGS
Session Key
 Used for further communications with the TGS
 Client cannot decrypt Message B, as it is Message B
encrypted using TGS's secret key
 At this point, the client has enough
information to authenticate itself to the TGS
9
Chapter 5: Authentication Applications
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
 When requesting services, the client
sends the following two messages to
the TGS:
Client Service Authorisation

 Message C: Composed of the TGT from Message C

message B and the ID of the requested
Message B Service ID

service
 Message D: Authenticator
 composed of the client ID and the
timestamp, encrypted using the
Message D
Client/TGS Session Key
Client ID

Client AS
10
Chapter 5: Authentication Applications TGS
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
Message C
The TGS retrieves message B out
Message B Service ID

of message C
Client Service Authorisation

 Decrypts message B using the TGS

secret key Message B

 Giving it the Client/TGS session

key
 Using the Client/TGS session
key, the TGS decrypts message D
(Authenticator)
Message D
Client ID

11
TGS
Chapter 5: Authentication Applications
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
 Then TGS sends the following two
messages to the client: Message E
Client Service Authorisation

 Message E: Client-to-server ticket Client ID

 Includes the client ID, client

network address, validity period

and Client/Server Session Key
 Encrypted using the Service's
secret key Message F
 Message F: Client/Server Session
Key encrypted with the Client/TGS
Session Key

Client
12
Chapter 5: Authentication Applications TGS
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
 Upon receiving messages E and F from
TGS, the Client has enough
information to authenticate itself to the
Service
Client Service Request

 The Client connects to the Service Message E

and sends the following two messages: Client ID

 Message E from the previous step

 The client-to-server ticket
 Encrypted using service's secret key
Message G
 Message G: a new Authenticator Client ID
 Includes the client ID, timestamp
 Encrypted using Client/Server Session Key

Client
13
Chapter 5: Authentication Applications Service
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
Message E
 The Service decrypts the ticket using Client ID

its own secret key to retrieve the

Client/Server Session Key
Client Service Request

 Using the Client/Server session key, Message G/

the Service decrypts the Authenticator
Authenticator Client ID

 And sends the following message to the

Client to confirm its true identity and
willingness to serve the client: Message H
 Message H: the timestamp found in
Timestamp + 1
client's Authenticator plus 1
 Encrypted using the Client/Server Session
Key
Client
14
Chapter 5: Authentication Applications Service
 UFCEKQ-10-3 Internet Security

KERBEROS PROTOCOL
 The client decrypts the confirmation
using the Client/Server Session Key
Message H
 Checks whether the timestamp is
Timestamp + 1
correctly updated
Client Service Request

 If so, then the client can trust the server

and can start issuing service requests
 The server provides the requested
services to the client
 If mutual authentication was
required, the server would have sent
an Authenticator in the previous
step as well

15
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

KERBEROS VERSION 5
 Developed in mid 1990’s
 Specified as Internet standard RFC 1510

 Provides improvements over v4

 Addresses environmental shortcomings
 Encryption alg, network protocol, byte order, ticket lifetime,
authentication forwarding, inter-realm auth
 And technical deficiencies
 Double encryption, non-std mode of use, session keys,
password attacks
 A nonce, or random number, is added to the
client’s request to the AS
 Prevent reply attack

16
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

X.509 Certificates

17
Chapter 5: Authentication Applications
X.509 CERTIFICATE USE
Unsigned certificate:
 X.509 is based on the use contains user ID,
user's public key Generate hash

of public-key cryptography code of unsigned

certificate

and digital signatures H

 The standard does not

dictate the use of a specific
algorithm but recommends Encrypt hash code
E
RSA
with CA's private key
to form signature

 The digital signature

scheme is assumed to
require the use of a hash Signed certificate:
Recipient can verify

function signature using CA's

public key.

Figure 4.3 Public-Key Certificate Use

18
UFCEKQ-10-3 Internet Security

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
 Issuer (name of CA)
 Period of validity (from - to dates)
 Subject (name of owner)
 Subject public-key info (algorithm, parameters, key)
 Issuer unique identifier (optional)
 Subject unique identifier (optional)
 Extension fields (optional)
 Certificate signature algorithm
 Certificate signature (of hash of all fields in certificate)
 If the corresponding public key is known to a user, then that
user can verify that a certificate signed by the CA is valid

19
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

X.509 CERTIFICATES
Signature
algorithm
Version algorithm
identifier parameters
Certificate
Issuer Name
Serial Number
Signature
algorithm
algorithm This Update Date
identifier parameters

Version 1
Issuer Name Next Update Date

Version 2
Period of not before Revoked user certificate serial #
validity not after certificate revocation date

Version 3
Subject Name •
Subject's algorithms •
public key parameters •
info key
Issuer Unique Revoked user certificate serial #
Identifier certificate revocation date
Subject Unique algorithms
Signature parameters
Identifier encrypted

Extensions (b) Certificate Revocation List

versions

algorithms
Signature parameters
all

encrypted hash

(a) X.509 Certificate

20
Chapter 5: Authentication Applications Figure 4.4 X.509 Formats
UFCEKQ-10-3 Internet Security

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

21
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

22
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

CERTIFICATE REVOCATION
 Certificates have a period of validity
 May need to revoke before expiry, e.g.:
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
23
Chapter 5: Authentication Applications
UFCEKQ-10-3 Internet Security

CA HIERARCHY
 Ifboth 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
24
Chapter 5: Authentication Applications
CERTIFICATE CHAINS

25