Chapter 4

Key Distribution & User Authentication

 Table of Contents
Problem Before Kerberos Kerberos Version 4
01 05

Kerberos Request for Service in Another Realm

02 06

Kerberos Requirements Kerberos Version 5

03 07

Public Key Certificate X-509

A Simple Authentication Dialogue
04 08
 Table of Contents
X.509 Authentication Service Federated Identity Management
09 13

Digital Signatures
10

Certificate Authority
11

Revocation of Certificate
12
PROBLEM BEFORE
KERBEROS
 PROBLEM BEFORE KERBEROS

Users wish to access services on servers.

● Three threats exist in the distributed network:

• User impersonation
• A dishonest user may pretend to be another user from the same
workstation.

• Network address impersonation

• A dishonest user can changes the network address of his/her
workstation to impersonate another workstation.
 PROBLEM BEFORE KERBEROS

Users wish to access services on servers.

● Three threats exist in the distributed network:

• Eavesdropping, replay attack, DOS, and so on.

• Attackers may try their best to access network service by mounting
different attacks.
KERBEROS
 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.
 KERBEROS

o Trusted key server system from MIT

● allows users access to services distributed through network
● without needing to trust all workstations
● rather all trust a central authentication server
 KERBEROS

In Kerberos system, there are three kinds of servers:

● Kerberos authentication server (AS):

• A centralized trusted authentication server for the whole system,
who issues long lifetime tickets.

● Ticket-granting servers (TGS):

• Issue short lifetime tickets.

● Service server (S):

• Provide different service.
 KERBEROS
REQUIREMENTS
 KERBEROS REQUIREMENTS

Its first report identified requirements as:

● secure
● reliable
● transparent
● scalable
Implemented using an authentication protocol based on
Needham-Schroeder.
 A SIMPLE
AUTHENTICATION
DIALOGUE
 A SIMPLE AUTHENTICATION DIALOGUE

• 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
 A SIMPLE AUTHENTICATION DIALOGUE

A simple authentication step flows:

Client’s (ID + Password) + Server’s ID

Step 1 : C AS : IDc || Pc || IDv

Encrypted by secret encryption key shared by AS and V

[ Client’s (ID + Password) + Server’s ID ]
Step 2 : AS C : Ticket = EKv[IDc || Pc || IDv]

Step 3: C V : IDc || Ticket

 A SIMPLE AUTHENTICATION DIALOGUE

Problems:
● Lifetime associated with the ticket-granting ticket
● (1) If too short repeatedly asked for password
● (2) If too long greater opportunity to replay

The threat is that an opponent will steal the ticket and use it before
it expires.
KERBEROS VERSION 4
 Once per user logon session

1. User logs on to computer

and requests service on
host.
Kerberos 3. AS verifies user’s access right in
2. Request T
GS ticket database. Create TGS ticket &
session key. Results are
4. TGS ticke encrypted using key derived from
t + session k
ey user’s password.
Client 5. Computer prompts user for password and uses
password to decrypt incoming message, then sends
ticket and authenticator that contain user’s name,
network address, and time to TGS. Authentication server
(AS)

6. TGS ticket + Authenticator

8. Service ticket + session key Ticket Granting Server

(TGS)

7. TGS decrypts ticket and authenticator,

verifies request, then creates ticket for
requested server.

10. Computer Request Service (Service ticket + Authenticator)

11. Server verifies that ticket &

12. Service authenticator match, then grants access
to service.
Server
 KERBEROS VERSION 4 AUTHENTICATION DIALOGUE

This is similar to the following immigration policy, which allows a

foreigner to enter a country:

Visa (=tickets in Kerberos):

Specifies who is allowed to entry this country for how many days.

Passport (=Authenticators in Kerberos):

Shows your identity, i.e., who are you.
KERBEROS VERSION 4
REQUEST FOR SERVICE
IN ANOTHER REALM
Realm A Kerberos

t for local TGS

1. Request ticke

cal TGS
2. Ticket for lo (AS)
3. Req
Client uest tic
ket for
remote
TGS
4. Tick
et for r
emote
TGS
(TGS)

5. Request ticket for remote server

6. Ticket for remote server
Kerberos

7. Request remote service

(AS)

(TGS)
Server Realm B
 KERBEROS - EXAMPLE

For example, once a user logs on a workstation by providing his/her

identity(ID) and password.

The workstation will get and store a ticket-granting ticket from AS on

behalf of the user.

This ticket-granting ticket could be valid in a relatively long time, such

as one day.

During this period, without repeatedly entering his/her password the

user can access different services, such as checking emails, printing
files, and so on.
 KERBEROS - EXAMPLE

The reason is that when the user wants to access a new service
(within the same logon session), the workstation can get a particular
service ticket from the TGS by using the housed ticket-granting ticket.

Similarly, the service ticket can be also used for multiple times to
access the same service server.

In addition, the codes for getting tickets could be implemented as

transparent procedures, i.e., the user may not notice that
authentication is taking place at all.
KERBEROS VERSION 5
 KERBEROS - EXAMPLE

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, interrealm auth
● and technical deficiencies
• double encryption, non-std mode of use, session keys, password attacks
DIFFERENCE BETWEEN
VERSION 4 & VERSION 5
 DIFFERENCE VERSION 4 & VERSION 5

Encryption system dependence (V.4 DES)

Internet protocol dependence
Message byte ordering
Ticket lifetime
Authentication forwarding
Inter-realm authentication
 DIFFERENCE VERSION 4 & VERSION 5

Currently have two Kerberos versions:

4 : restricted to a single realm

5 : allows inter-realm authentication, in beta test
Kerberos v5 is an Internet standard
specified in RFC1510, and used by many utilities
 KERBEROS – IN PRACTICE

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
(& binary versions must obscure crypto routine entry points and have no
encryption)
else crypto libraries must be reimplementation locally
PUBLIC KEY CERTIFICATE
– X.509
 INTERNET

Public keys are available

openly to anyone
 PUBLIC KEY ENCRYPTION

Bob Alice

Plan to send message to Alice

Plaintext Plaintext
 PUBLIC KEY ENCRYPTION

Bob Alice

Public Private Public Private

Key Key Key Key
Each person have their own
set of public and private key
 PUBLIC KEY ENCRYPTION

Public
Bob Key

STOP!!!!
Plaintext Are you sure that public
Ciphertext key really belong to
ALICE??
 Public
-Alice’s IDKey Encryption
-Alice’s Public Key

Encrypted with CA’s

Private Key
Public
Bob -Alice’s ID Key
-Alice’s Public Key

Encrypted with CA’s

Private Key

CA’s Public Key

Plaintext
compare
CA (e.g. Verisign)
Alice’s Public Key
 Public Alice
Bob Key

Plaintext Ciphertext Plaintext

Alice’s Public Key Alice’s Private Key

X.509 AUTHENTICATION
SERVICE
 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 (Certificate Authority).
Is used in S/MIME, IP Security, SSL/TLS and SET.
RSA is recommended to use.
the term X.509 certificate usually refers to the IETF's PKIX Certificate
(Public Key Infrastructure )
Public-Key Certificate Use

40
Public
Key

Digital
Signature
DIGITAL SIGNATURES
TYPICAL DIGITAL SIGNATURE APPROACH
 DIGITAL SIGNATURE

Have looked at message authentication.

● but does not address issues of lack of trust
Digital signatures provide the ability to:
● verify author, date & time of signature
● authenticate message contents
● be verified by third parties to resolve disputes
Hence include authentication function with additional
capabilities.
DIGITAL SIGNATURE MODEL
DIGITAL SIGNATURE MODEL
CERTIFICATE AUTHORITY
(CA)
 CERTIFICATE AUTHORITY (CA)

Certificate Authority (CA)

● Anyone can be a CA, but must be trusted.
● It is a trusted third party, which trusted by the user
community.
● CA is to proof the user/system public key that claim to be
true.
● Example: VeriSign, GTE, U.S. Postal Service.
 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 part other than the CA can modify the certificate without this
being detected.
REVOCATION OF
CERTIFICATE
 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
 X.509 VERSION 3

Has been recognised that additional information is needed in

a certificate .
● email/URL, policy details, usage constraints
Rather than explicitly naming new fields defined a general
extension method.
Extensions consist of:
● extension identifier
● criticality indicator
● extension value
FEDERATED IDENTITY
MANAGEMENT
 FEDERATED IDENTITY MANAGEMENT

• Federated identity management is a relatively new concept

dealing with the use of a common identity management scheme
across multiple enterprises and numerous applications and
supporting many thousands, even millions, of users.
 IDENTITY MANAGEMENT

• Identity management is a centralized, automated approach to

provide enterprise wide access to resources by employees and
other authorized individuals.
• The focus of identity management is defining an identity for
each user (human or process), associating attributes with the
identity, and enforcing a means by which a user can verify
identity.
 IDENTITY MANAGEMENT

• The central concept of an identity management system is the

use of single sign-on (SSO).
• SSO enables a user to access all network resources after a
single authentication.
• Typical services provided by a federated identity management
system include the following:

■■ Point of contact: Includes authentication that a user

corresponds to the user
 IDENTITY MANAGEMENT

■■ SSO protocol services: Provides a vendor-neutral security

token service for supporting a single sign on to federated services.
■■ Trust services: Federation relationships require a trust
relationship-based federation between business partners. A trust
relationship is represented by the combination of the security
tokens used to exchange information about a user, the
cryptographic information used to protect these security tokens,
and optionally the identity mapping rules applied to the information
contained within this token.
■■ Key services: Management of keys and certificates.
 IDENTITY MANAGEMENT

■■ Identity services: Services that provide the interface to local

data stores, including
user registries and databases, for identity-related information
management.
■■ Authorization: Granting access to specific services and/or
resources based on
the authentication.
 IDENTITY MANAGEMENT

■■ Provisioning: Includes creating an account in each target

system for the user,
enrollment or registration of user in accounts, establishment of
access rights or credentials to ensure the privacy and integrity of
account data.
■■ Management: Services related to runtime configuration and
deployment.
THANK YOU
Insert the Subtitle of Your Presentation