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 [Data encryption standard].
 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
ke t f o r
remote
TG S
4. Tick
e t fo r r
emote
T GS
(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 algortihm, network protocol, byte order, ticket lifetime,
authentication forwarding, interrealm authentication
 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 ID
Key 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