• Module-1 (Authentication Protocols)

Authentication Protocols – Mutual

authentication,
• One way authentication. Kerberos –
Kerberos Version 4, Kerberos Version 5.
X.509 Authentication service. Public Key
Infrastructure (PKI) – Trust models,
Revocation.
• CO1: Explain authentication protocols, X.509 authentication service
and Public Key Infrastructure (PKI).(Cognitive Knowledge Level:
Understand)
 Authentication Protocols
• used to convince parties of each others
identity and to exchange session keys
• may be one-way or mutual
• key issues are
– confidentiality – to protect session keys
– timeliness – to prevent replay attacks
 Replay Attacks
• where a valid signed message is copied and later
resent
– simple replay:The opponent simply copies a message and
replays it later.
– Repetition that can be logged: An opponent can replay a
timestamped message within the valid time window.
– Repetition that cannot be detected: This situation could arise
because the original message could have been suppressed and
thus did not arrive at its destination; only the replay message
arrives.
– Backward replay without modification: This is a replay back to
the message sender. This attack is possible if symmetric encryption
is used and the sender cannot easily recognize the difference
between messages sent and messages received on the basis of
content.
 Replay Attacks
• countermeasures include
– use of sequence numbers (generally impractical)
– timestamps (needs synchronized clocks)
– challenge/response (using unique nonce)
 Using Symmetric Encryption
• as discussed previously can use a two-
level hierarchy of keys
• usually with a trusted Key Distribution
Center (KDC)
– each party shares own master key with KDC
– KDC generates session keys used for
connections between parties
– master keys used to distribute these to them
 Needham-Schroeder Protocol
• original third-party key distribution protocol
• for session between A B mediated by KDC
• protocol overview is:
1. A→KDC: IDA || IDB || N1
2. KDC→A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A→B: EKb[Ks||IDA]
4. B→A: EKs[N2]
5. A→B: EKs[f(N2)]
 Needham-Schroeder Protocol
• used to securely distribute a new session
key for communications between A & B
• but is vulnerable to a replay attack if an old
session key has been compromised
– then message 3 can be resent convincing B
that is communicating with A
• modifications to address this require:
– timestamps (Denning 81)
– using an extra nonce (Neuman 93)
 Using Public-Key Encryption
• have a range of approaches based on the
use of public-key encryption
• need to ensure have correct public keys
for other parties
• using a central Authentication Server (AS)
• various protocols exist using timestamps
or nonces
 Denning AS Protocol
• Denning 81 presented the following:
1. A→AS: IDA || IDB
2. AS→A: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T]
3. A→B: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] ||
EKUb[EKRas[Ks||T]]
• note session key is chosen by A, hence
AS need not be trusted to protect it
• timestamps prevent replay but require
synchronized clocks
 One-Way Authentication
• required when sender & receiver are not in
communications at same time (eg. email)
• have header in clear so can be delivered
by email system
• may want contents of body protected &
sender authenticated
 Using Symmetric Encryption
• can refine use of KDC but can’t have final
exchange of nonces, vis:
1. A→KDC: IDA || IDB || N1
2. KDC→A: EKa[Ks || IDB || N1 || EKb[Ks||IDA] ]
3. A→B: EKb[Ks||IDA] || EKs[M]
• does not protect against replays
– could rely on timestamp in message, though
email delays make this problematic
 Public-Key Approaches
• have seen some public-key approaches
• if confidentiality is major concern, can use:
A→B: EKUb[Ks] || EKs[M]
– has encrypted session key, encrypted message
• if authentication needed use a digital
signature with a digital certificate:
A→B: M || EKRa[H(M)] || EKRas[T||IDA||KUa]
– with message, signature, certificate
• Module-1 (Authentication Protocols)
Authentication Protocols – Mutual
authentication, One way authentication.
Kerberos – Kerberos Version 4, Kerberos
Version 5.
• X.509 Authentication service. Public Key
Infrastructure (PKI) – Trust models,
Revocation.
• CO1: Explain authentication protocols, X.509 authentication
service and Public Key Infrastructure (PKI).(Cognitive Knowledge
Level: Understand)
 KERBEROS
• Kerberos is an authentication service developed at MIT,
and is one of the best known and most widely
implemented trusted third party key distribution
systems.
• Kerberos provides a centralized authentication server
whose function is to authenticate users to servers and
servers to users. Unlike most other authentication schemes,
Kerberos relies exclusively on symmetric encryption,
making no use of public-key encryption. Two versions of
Kerberos are in common use: v4 & v5.
 KERBEROS
• Users wish to access services on
servers.
• 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.
 Kerberos Requirements
• its first report identified
requirements as:
– Secure
A network eavesdropper should not be able to obtain the
necessary information to impersonate a user.
strong enough such that a potential opponent does not find
it to be the weak link.
– Reliable
– should be highly reliable
– should employ a distributed server architecture,
– one system able to back up another.
 Kerberos Requirements

– Transparent
– user should not be aware that authentication is taking
place beyond the requirement to enter a password.
– Scalable
– capable of supporting large numbers of clients and
servers ▪ modular, distributed architecture.

• implemented using an authentication

protocol based on Needham-
Schroeder
 Kerberos v4 Overview
• In an unprotected network environment, any client can apply
to any server for service. The obvious security risk is that
of impersonation. An opponent can pretend to be another
client and obtain unauthorized privileges on server machines.
To counter this threat, servers must be able to confirm the
identities of clients who request service. Each server can be
required to undertake this task for each client/server
interaction, but in an open environment, this places a
substantial burden on each server .
• An alternative is to use an authentication server (AS) that
knows the passwords of all users and stores these in a
centralized database. In addition, the AS shares a unique
secret key with each server. These keys have been
distributed physically or in some other secure manner.
 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
 Kerberos Version 4
• 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
(1) C  AS: IDc || Pc || IDv
(2) AS  C: Ticket
(3) C  V: IDc || Ticket

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

• In this scenario, the user logs on to a workstation and
requests access to server V. The client module C in the
user's workstation requests the user's password and then
sends a message to the AS that includes the user's ID, the
server's ID, and the user's password. The AS checks its
database to see if the user has supplied the proper
password for this user ID and whether this user is
permitted access to server V. If both tests are passed, the
AS accepts the user as authentic and must now convince the
server that this user is authentic. To do so, the AS creates
a ticket that contains the user's ID and network address
and the server's ID. This ticket is encrypted using the
secret key shared by the AS and this server. This ticket is
then sent back to C. Because the ticket is encrypted, it
cannot be altered by C or by an opponent. With this ticket, C
can now apply to V for service. C sends a message to V
containing C's ID and the ticket. V decrypts the ticket and
verifies that the user ID in the ticket is the same as the
unencrypted user ID in the message. If these two match,
the server considers the user authenticated and grants the
requested service
 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
 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
• The threat is that an opponent will steal
the ticket and use it before it expires
To solve these additional problems, we introduce a
scheme for avoiding plaintext passwords and a new
server, known as the ticket-granting server (TGS).
• 1. The client requests a ticket-granting ticket on behalf of the user
by sending its user's ID and password to the AS, together with the
TGS ID, indicating a request to use the TGS service.

• 2. The AS responds with a ticket that is encrypted with a key that is

derived from the user's password. When this response arrives at the
client, the client prompts the user for his or her password, generates
the key, and attempts to decrypt the incoming message. If the
correct password is supplied, the ticket is successfully recovered .

• 3.The client requests a service-granting ticket on behalf of the user.

For this purpose, the client transmits a message to the TGS
containing the user's ID, the ID of the desired service, and the
ticket-granting ticket.
• 4. The TGS decrypts the incoming ticket and verifies the success of
the decryption by the presence of its ID. It checks to make sure
that the lifetime has not expired. Then it compares the user ID and
network address with the incoming information to authenticate the
user. If the user is permitted access to the server V, the TGS issues
a ticket to grant access to the requested service.

• 5. The client requests access to a service on behalf of the user. For

this purpose, the client transmits a message to the server containing
the user's ID and the service-granting ticket. The server
authenticates by using the contents of the ticket.
Version 4 Authentication Dialogue
Summary of Kerberos Version 4 Message Exchanges

Authentication Service Exhange: To obtain Ticket-Granting Ticket

(1) C  AS: IDc || IDtgs ||TS1
(2) AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]

Ticket-Granting Service Echange: To obtain Service-Granting Ticket

(3) C  TGS: IDv ||Tickettgs ||Authenticatorc
(4) TGS  C: EKc [Kc,¨v|| IDv || TS4 || Ticketv]

Client/Server Authentication Exhange: To Obtain Service

(5) C  V: Ticketv || Authenticatorc
(6) V  C: EKc,v[TS5 +1]
Overview of Kerberos
 Kerberos Realms
• A full-service Kerberos environment consisting of a
Kerberos server, a number of clients, and a number of
application servers requires the following:
• 1. The Kerberos server must have the user ID and hashed
passwords of all participating users in its database. All users
are registered with the Kerberos server.
• 2. The Kerberos server must share a secret key with each
server. All servers are registered with the Kerberos server.
• Such an environment is referred to as a Kerberos realm.
• A Kerberos realm is a set of managed nodes that share the
same Kerberos database. The Kerberos database resides on
the Kerberos master computer system, which should be kept
in a physically secure room. A read-only copy of the
Kerberos database might also reside on other Kerberos
computer systems. However, all changes to the database
must be made on the master computer system. Changing or
accessing the contents of a Kerberos database requires the
Kerberos master password.
• A related concept is that of a Kerberos principal, which is a
service or user that is known to the Kerberos system. Each
Kerberos principal is identified by its principal name.
Principal names consist of three parts: a service or user
name, an instance name, and a realm name
• Networks of clients and servers under different
administrative organizations typically constitute
different realms. That is, it generally is not
practical, or does not conform to administrative
policy, to have users and servers in one
administrative domain registered with a Kerberos
server elsewhere. However, users in one realm may
need access to servers in other realms, and some
servers may be willing to provide service to users
from other realms, provided that those users are
authenticated. Kerberos provides a mechanism for
supporting such interrealm authentication.
• The scheme requires that the Kerberos server in one realm trust
the Kerberos server in the other realm to authenticate its users.
Furthermore, the participating servers in the second realm must
also be willing to trust the Kerberos server in the first realm
Request for Service in
Another Realm
 Difference Between
Version 4 and 5
• Encryption system dependence (V.4 DES)
• Internet protocol dependence
• Message byte ordering
• Ticket lifetime
• Authentication forwarding
• Interrealm authentication
Kerberos Encryption Techniques
PCBC Mode
 Kerberos - in practice
• 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
• 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 reimplemented locally
• Module-1 (Authentication Protocols)
Authentication Protocols – Mutual
authentication,
• One way authentication. Kerberos –
Kerberos Version 4, Kerberos Version 5.
X.509 Authentication service.
• Public Key Infrastructure (PKI) – Trust
models, Revocation.
• CO1: Explain authentication protocols, X.509 authentication
service and Public Key Infrastructure (PKI).(Cognitive Knowledge
Level: Understand)

48
 X.509 Authentication
Service
• X.509 is part of the X.500 series of recommendations that define a
directory service, being a server or distributed set of servers that
maintains a database of information about users.
• X.509 defines a framework for the provision of authentication services
by the X.500 directory to its users. The directory may serve as a
repository of public-key certificates.
• In addition, X.509 defines alternative authentication protocols based
on the use of public-key certificates.
• X.509 is based on the use of public-key cryptography and digital
signatures.
• The standard does not dictate the use of a specific algorithm but
recommends RSA.
• The X.509 certificate format is widely used, in for example S/MIME,
IP Security and SSL/TLS and SET.
49
50
 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
X.509 Formats

52
• Version: Differentiates among successive versions of the
certificate format; the default is version 1. If the Issuer
Unique Identifier or Subject Unique Identifier are present,
the value must be version 2. If one or more extensions are
present, the version must be version 3.
• Serial number: An integer value, unique within the issuing
CA, that is unambiguously associated with this certificate.
• Signature algorithm identifier: The algorithm used to sign
the certificate, together with any associated parameters.
Because this information is repeated in the Signature field
at the end of the certificate, this field has little, if any,
utility.
• Issuer name: X.500 name of the CA that created and
signed this certificate.
• Period of validity: Consists of two dates: the first and last
on which the certificate is valid.

53
• Subject name: The name of the user to whom this certificate
refers. That is, this certificate certifies the public key of the
subject who holds the corresponding private key.
• Subject's public-key information: The public key of the subject,
plus an identifier of the algorithm for which this key is to be used,
together with any associated parameters.
• Issuer unique identifier: An optional bit string field used to
identify uniquely the issuing CA in the event the X.500 name has
been reused for different entities.
• Subject unique identifier: An optional bit string field used to
identify uniquely the subject in the event the X.500 name has been
reused for different entities.
• Extensions: A set of one or more extension fields. Extensions were
added in version 3 .
• Signature: Covers all of the other fields of the certificate; it
contains the hash code of the other fields, encrypted with the
CA's private key. This field includes the signature algorithm
identifier.

54
 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.

55
 CA Hierarchy
• if both 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
X.509 CA Hierarchy

57
 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
Authentication Procedures

59
 Authentication Procedures
• X.509 includes three alternative
authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures
 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
– eg session key
 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
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
 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
 Certificate Extensions
• key and policy information
– convey info about subject & issuer keys,
plus indicators of certificate policy
• certificate subject and issuer
attributes
– support alternative names, in alternative
formats for certificate subject and/or
issuer
• certificate path constraints
– allow constraints on use of certificates
by other CA’s
•Module-1 (Authentication Protocols)
Authentication Protocols – Mutual authentication,
•One way authentication. Kerberos – Kerberos
Version 4, Kerberos Version 5. X.509
Authentication service.
• Public Key Infrastructure (PKI) – Trust models,
Revocation.
•CO1: Explain authentication protocols, X.509 authentication service and Public Key
Infrastructure (PKI).(Cognitive Knowledge Level: Understand)
 Authenticity of Public Keys

?
private key

Bob
Alice
public key

Problem: How does Alice know that the public key

she received is really Bob’s public key?
 Certificate and CA

•Public-key certificate
•Signed statement specifying the key and identity
•sigAlice(“Bob”, PKB)
•Common approach: certificate authority (CA)
•Single agency responsible for certifying public keys
•After generating a private/public key pair, user proves his
identity and knowledge of the private key to obtain CA’s
certificate for the public key (offline)
•Every computer is pre-configured with CA’s public key
Using Public-Key Certificates

Authenticity of public keys is reduced to

authenticity of one key (CA’s public key)
 Public Key Infrastructure Introduction

Introduction

Public key infrastructure is a system to securely distribute public

keys. It consists of:
certificates
➠ X.509 is the specification for a certificate
a repository for retrieving certificates a method of revoking certificates
a method of evaluating a chain of certificates from trust anchors to
the target name

Zhi Wang (FSU)

 Public Key Infrastructure Introduction

Terminology

A certificate is a signed message vouching a name with a public

key
➠ [Bob’s public key is 829248]Alice
➠ Alice is the issuer, and Bob is the subject
A principal is anything that has a public key If Alice wants to find
a path to Bob’s key
➠ Bob is the target, Alice is the verifier
A trust anchor is a public key that is trusted to sign a certificate

Zhi Wang (FSU)

 Public Key Infrastructure X.509 Certificate

X.509 Certificate: Example

A certificate for Bank of America signed by VeriSign

Zhi Wang (FSU)

 Public Key Infrastructure X.509 Certificate

X.509 Certificate: Example

Details for the BOA certificate

Zhi Wang (FSU)

 Public Key Infrastructure X.509 Certificate

X.509 Certificate: Example

Verification path for the BOA certificate

Zhi Wang (FSU)

 Hierarchical Approach

•Single CA certifying every public key is impractical

•Instead, use a trusted root authority
•For example, Verisign
•Everybody must know the public key for verifying root
authority’s signatures
•Root authority signs certificates for lower-level
authorities, lower-level authorities sign certificates for
individual networks, and so on
•Instead of a single certificate, use a certificate chain
•sigVerisign(“UnB”, PKUT), sigUT(“Manoel”, PKV)
•What happens if root authority is ever compromised?
 Alternative: “Web of Trust”

•Used in PGP (Pretty Good Privacy)

•Instead of a single root certificate authority, each person
has a set of keys they “trust”
•If public-key certificate is signed by one of the “trusted”
keys, the public key contained in it will be deemed valid
•Trust can be transitive
•Can use certified keys for further certification
I trust
Alice
sigAlice(“Friend”, Friend’s key)
sigFriend(“FoaF”, FoaF’s key)

Friend of Alice Bob

Alice Friend of friend
 Chain of Trust

•Small World: Any two people in this world can be

connected via “six degrees of separation”

Alice: Ted’s public key is 135790 (Trust anchor)

[Carol’s public key is 123456] Ted

[David’s public key is 789012] Carol

[Bob’s public key is 345678] David

 Public Key Infrastructure PKI Trust Models

PKI Trust Models

PKI trust models defines where to get trust anchors, and how
to evaluate a chain of certificates from trust anchors to the
target
1 Monopoly model Monopoly +
2 RAs Delegated CAs Oligarchy
3 model Anarchy model
4 Top-down with name constraints
5 Bottom-up with name
6
constraints
7

Zhi Wang (FSU)

 Public Key Infrastructure PKI Trust Models

Monopoly Model

One CA is universally trusted by the world

➠ everyone must get certificates from the (only) CA

The CA’s public key is embedded in all software and

hardware
➠ the only trust anchor

Zhi Wan (FSU) 7 / 25

 Public Key Infrastructure PKI Trust Models

Problems of Monopoly Model

There is NO universally trusted organization

Monopoly control →CA can charge whatever it wants for a
certificate Entire security of the world rests on the CA
➠ infeasible to change the CA’s key everywhere if compromised
It is expensive and insecure for the CA to remotely certify a public
key

Zhi Wang (FSU) 8 / 25

 Public Key Infrastructure PKI Trust Models

Monopoly + Registration Authorities (RAs)

The CA chooses and trusts other organizations as RAs RAs check

identities and obtain and vouch for public keys
The CA certifies public keys according to information provided by
RAs

It is more convenient and secure to obtain certificates It is still a

monopoly model and has all of its problems
➠ RA can be incorporated into any of the PKI models

Zhi Wang (FSU) Fall 2014 9 / 25

 Public Key Infrastructure PKI Trust Models

Delegated CAs

Trust anchor issues certificates to other CAs (delegated CAs)

vouching for their keys and their trustworthiness as CAs
User can obtain certificates from a delegate CA
Alice follows a chain of certificates from a trust anchor to the
target to verify a certificate

Delegated CA has security and operational properties similar to

RAs Delegated CAs can be incorporated into any of the PKI
models

Zhi Wang (FSU) 10 / 25

 Public Key Infrastructure PKI Trust Models

Oligarchy Model

Oligarchy model is commonly used in browsers

The products are pre-configured with many trust anchors, a
certificated issued by any one of them is accepted
User may examine and edit the list of trust anchors
➠

Zhi Wang (FSU) 11 / 25

 Public Key Infrastructure PKI Trust Models

Problems of Oligarchy Model

Security of the world is at risk if any trust anchor is compromised

The list of trust anchors is at the discretion of the product vendor
➠ there is no practical ways for users to verify their trustworthiness
➠ some vendors will include any CAs that pay a fee
It might be easy to trick a navie user into adding a bogus trust
anchor
➠ encrypted does not mean secure
Some software (browsers) accept expired certificates
➠ Google Chrome includes a certificate from Microsoft which has
expired since 12/30/1999

Zhi Wang (FSU) 12 / 25

 Public Key Infrastructure PKI Trust Models

Anarchy Model (Web of Trust)

Anarchy model is used by PGP

Anarchy model is fully distributed and has no CAs
➠ anyone can sign certificates for anyone else
A database is maintain (by volunteers) to keep certificates
Each user is responsible to certificate and deposit his trust
anchors
➠ e.g., the public key from someone he met personally
User searches through the database to verify a public key
➠ a path from one of his trust anchors to the target →trusted

Zhi Wang (FSU) 13 / 25

 Public Key Infrastructure PKI Trust Models

Problems of Anarchy Model

Anarchy model is unworkable on a large scale (why?)

The database would be unworkably large if deployed on Internet scale
It’s hard to verify the trustworthiness of every certificate on the chain
➠ no problem for a small community where everyone is trustworthy
➠ can we trust a certificate if there are multiple chains?

Zhi Wang (FSU) 14 / 25

 Public Key Infrastructure PKI Trust Models

Models with Name Constraints

A CA is only trusted for certifying users in his domains

➠ FSU CA certifies FSU students
➠ a certificate for Amazon.com from Nigeria?
Name constraints defines they way to verify (search) a
target
➠ top-down or bottom-up

Zhi Wang (FSU) 15 / 25

 Public Key Infrastructure PKI Trust Models

Top-down with Name Constraints

Everyone agrees upon a root CA, root CA delegates other CAs

➠ similar to the monopoly model with delegate CAs
A delegated CA is only trusted to certify keys in its namespace
Use can verify a target by following the namespace down from
root

It has the other problems of the monopoly model

Zhi Wang (FSU) 16 / 25

 Public Key Infrastructure PKI Trust Models

Bottom-up with Name Constraints

The model assumes a hierarchical namespace (like DNS) Each

organization can create its own PKI and link to others
➠ a parent certifies its children (down-link)
➠ a child also certifies its parent (up-link)
➠ a cross-link connects two nodes neither is an ancestor of the
other
The namespace can be traversed starting from any node
➠ follow up-links and/or one cross-link to an ancestor of the target
➠ follow donw-links (only) from there

Zhi Wang (FSU) 17 / 25

 Public Key Infrastructure PKI Trust Models

Bottom-up with Name Constraints...

How can A/C/Y verify the certificate of B/Y/Z/C?

How can B/Y/Z/C verify the certificate of A/C/Y?

Zhi Wang (FSU) 18 / 25

 Public Key Infrastructure PKI Trust Models

Advantages of Bottom-up with Name Constraints

The model is easy to understand and configure

➠ PKI can be deployed in any organization independent of others
➠ Authentication between users in the same organization stays
within
It is easy to find out if a path exists No monopoly is possible
Replacing any key is reasonably easy

Zhi Wang (FSU) 19 / 25

 Public Key Infrastructure Certificate Revocation

Certificate Revocation

Certificates might need to be revoked

➠ employment is terminated, private key is stolen...
Certificates normally have an expiration time
➠ validity time is months, lots of damage can be done in
between
➠ browsers normally do not enforce expiration time!

Solution: Certificate Revocation List (CRL)

CA maintains and periodically releases a CRL Each transaction is
checked against the CRL

Zhi Wang (FSU) 20 / 25

 Public Key Infrastructure Certificate Revocation

Certificate Revocation List

Why are CRL issued periodically even if no certificates are revoked?

How frequent should CRL be issued?

If a CRL is maintained, why set an expiration time for certificates?

Zhi Wang (FSU) 21 / 25

 Public Key Infrastructure Certificate Revocation

Delta CRL

CRL may be very large and needs to be downloaded

frequently A delta CRL lists changes from the last complete
CRL
➠ not from the last delta CRL
Delta CRLs can be issued very frequently
➠ full CRLs are issued less frequently

Zhi Wang (FSU) 22 / 25

 Public Key Infrastructure Certificate Revocation

On-line Revocation Servers (OLRS)

OLRS is a online system to query the revocation status of

certificates
➠ OLRS maints the full CRL list
➠ OLRS is not as security sensitive as a CA (or a KDC)
OLRS can be a performance bottleneck
➠ Alice can obtain a (timestamped) certificate from OLRS “Alice’s
certificate was not revoked as of ...”
➠ Bob can query OLRS in advance and cache the result

Zhi Wang (FSU) 23 / 25

 Public Key Infrastructure Certificate Revocation

Good-lists vs. Bad-lists

CRL is a black-list of revoked certificates

How about maintaining a list of valid certificates?
➠ Is it more secure than bad-lists?

Problems:
A good-list is likely much larger than the bad list
Organizations might not want its list of valid certificates
public
➠ solution: use hashes of the certificates

Zhi Wang (FSU) 24 / 25