Chapter 14 – Authentication

Applications

Fourth Edition
by William Stallings

Lecture slides by Lawrie Brown

(modified by Prof. M. Singhal, U of
Kentucky)
1
 Authentication Applications
• developed to support application-level
authentication & digital signatures
• will discuss Kerberos – a private-key
authentication service
• discuss X.509 - a public-key directory
authentication service

2
 Kerberos
• Authentication service developed as a part
of MIT’s Athena project
• provides centralized 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
3
 Athena
• An open distributed environment
• Any user can access services from any
workstation
• Several security threats exists in such an
environment:
– A user impersonate another user
– A user may change the network address of a w/s and
may make it look as another w/s
– A user may eavesdrop on a session and mount a
replay attak later
4
 Kerberos Requirements
• its first report identified requirements as:
– secure
– reliable
– transparent
– scalable
• implemented using an authentication
protocol based on Needham-Schroeder

5
 Kerberos v4 Overview
• a basic third-party authentication scheme
• have an Authentication Server (AS)
– users initially negotiate with AS to identify self
– AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)
– users subsequently request access to other
services from TGS on basis of users TGT

6
 Kerberos v4 Dialogue
1. obtain ticket granting ticket from AS
• once per session
2. obtain service granting ticket from TGT
• for each distinct service required
3. client/server exchange to obtain service
• on every service request

7
Kerberos 4 Overview

8
 Kerberos Realms
• a Kerberos environment consists of:
– a Kerberos server
– a number of clients, all registered with server
– application servers, sharing keys with server
• this is termed a realm
– typically a single administrative domain
• if have multiple realms, Kerberos servers
must share keys and trust each other
9
Kerberos Realms

10
 Kerberos Version 5
• developed in mid 1990’s to address the
deficiencies of v4
• provides improvements over v4
• encryption algorithm: DES is weak and vulnerable
to attacks. V5 allows a suit of encryption
algorithms.
• V5 breaks away from IP only networks
• V4 uses 8bit ticket lifetime.V5 uses start time and
end time.
•
•
11
 X.509 Authentication Service
• part of CCITT X.500 directory service standards
– distributed servers maintaining user info database
• defines framework for authentication services
– directory may store public-key certificates
– with public key of user signed by certification authority
• also defines authentication protocols
• uses public-key crypto & digital signatures
– algorithms not standardised, but RSA recommended
• X.509 certificates are widely used
12
 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 X.500 name (CA)
– period of validity (from - to dates)
– subject X.500 name (name of owner)
– 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)
• notation CA<<A>> denotes certificate for A signed by CA
13
X.509 Certificates

14
 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
• If there are a large number of users, one
CA may not be able to handle the load
• Also it is difficult to propagate the public
key of the CA securely.
15
 Certificate Chaining

• if both users share a common CA then they are

assumed to know its public key
• What if both users have their certificates issued
by two different CAs? (and one does not know
the public key of the other CA)
• Suppose A’s certificate is issued by X1 and B’s
by X2
• And A does not know the public key of X2.
(A can not verify the public key of B).
16
 Certificate chaining
• Suppose X1 and X2 have securely exchanged
their public keys.
• X1 can prepare a certificate for X2 and sends it
to A.
• A can request this certificate from X1, obtain the
public key of X2, and then verify B’s certificate.
• Notationally,
X1<<X2>>X2<<B>>
--Chain of two certficates.
--need not be limited to two certificates. 17
 CA Hierarchy
• CAs can certify each other.
• CAs are linked by this relation.
• CAs can be organized in several structures
• X.509 suggests 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
18
A CA Hierarchy

19
 CA Hierarchy
• A can verify B’s certificate using the following
certificate chain:
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
-- There is chain of trust also.
• Likewise, B can verify A’s public key using the
following certificate chain:
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
--can obtain these certificates from the directory.

20
 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)
– CRL is advertised widely through directory.
• users should check certificates with CA’s CRL

21
 Authentication Procedures
• X.509 includes three alternative
authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures
• It is assumed that the two parties know
each other’s public key.
22
 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
– integrity & originality of message
• message must include timestamp, nonce,
B's identity and is signed by A
• may include additional info for B
– E.g., session key
23
 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
• reply includes original nonce from A, also
timestamp and nonce from B
• may include additional info for A

24
 Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which
enables above authentication without
synchronized clocks
• has reply from A back to B containing
signed copy of nonce from B
• means that timestamps need not be
checked or relied upon

25
 Summary
• have considered:
– Kerberos trusted key server system
– X.509 authentication and certificates

26