Key Management & Certification

Objectives of this Lecture:

❖ To explain the need for a key-distribution center.

❖ To show how a KDC can create a session key between two parties.
❖ To show how two parties can use a symmetric-key agreement
protocol to create a session key between themselves without using
the service of a KDC.
❖ To describe Kerberos as a KDC and an authentication protocol.

Slide-1
Introduction

Trusted Intermediaries:

Symmetric key problem: Public key problem:

How do two entities establish When Alice obtains Bob’s public
shared secret key over key (from web site, e-mail,
network? diskette), how does she know it is
Bob’s public key, not Trudy’s?
Solution:
Trusted key distribution Solution:
center (KDC) acting as Trusted certification authority (CA)
intermediary between entities.

Slide-2
Key-Distribution Center: KDC
In symmetric-key cryptography, a shared secret key is needed to be
exchanged between two parties involved in a communication.
If Alice and Bob want to communicate, they need a way to exchange a
secret key between them; if Alice wants to communicate with one million
people, how can she exchange one million keys with one million people?
Using the Internet is definitely not a secure method. It is obvious that we
need an efficient way to maintain and distribute secret keys.
A practical solution to maintain and distribute secret keys is the use of a
trusted third party, referred to as a key-distribution center (KDC). To
reduce the number of keys, each person establishes a shared secret key
with the KDC, as shown in the figure below.
❖ A secret key is
established
between the KDC
and each member.
❖ Alice has a secret
key KAlice with the
KDC; Bob has a
secret key KBob with
the KDC; and so
on.
❖ They communicate
with each other via
Slide-3
the KDC. Figure: Key-distribution center (KDC)
Key-Distribution Center: KDC
Q: How can Alice send a confidential message to Bob using the KDC?
The process is as follows:
1. Alice sends a request to the KDC stating that she needs a session
(temporary) secret key between herself and Bob.
2. The KDC informs Bob about Alice’s request.
3. If Bob agrees, a session key is created between the two parties.
The established session key between Alice and Bob with the KDC is
used to authenticate Alice and Bob to the KDC which prevents Eve from
impersonating either of them.

Slide-4 Figure: Key-distribution center (KDC)

Key-Distribution Center: KDC
Session Key:
The KDC creates a secret key for each member which can be used only
between the member and the KDC to authenticate each member with
the KDC, not between two members .
If Alice needs to communicate secretly with Bob, she needs a secret key
between herself and Bob.
The KDC can create a session key between Alice and Bob, using their
keys with the center. The session key is used to authenticate Alice and
Bob to each other. After authentication, they can exchange message.
After communication is terminated, the session key is no longer useful.
If Alice and Bob again need to communicate, another session key is
established between them.
Therefore, a session symmetric key between two parties is used only
once.

Slide-5
Key-Distribution Center: KDC
Q: How is a session key established between Alice and Bob for
communication?
The KDC creates a temporary secret key for each member which can
be used only once between the member and the KDC, not between two
members . The process is as follows:
1. Alice sends a request to the KDC stating that she needs a session
(temporary) secret key between herself and Bob.
2. The KDC informs Bob about Alice’s request.
3. If Bob agrees, a session key is created between the two parties.
The established session key between Alice and Bob with the KDC is
used to authenticate Alice and Bob to the KDC which prevents Eve from
impersonating either of them.

Figure:
Key-distribution
center (KDC)

Slide-6
Protocols for Creating Session Key using KDCs
There are several different approaches to create the session key.
Approach-1: Creating Session key using a KDC

Slide-7 Figure: Creating session key using KDC

Protocols for Creating Session Key using KDCs
The steps for creating session key using the first approach is summarized
below:
1. Alice sends an unencrypted plaintext message to the KDC to obtain a symmetric
session key between Bob and herself.
❖ The message contains Alice’s registered identity (Alice in this case) and the
identity of Bob (Bob in this case).
2. After receiving the message from Alice, the KDC creates a ticket which contains
the identities of Alice and Bob, and the session key (K AB). The KDC then encrypts
the ticket using Bob’s key (KB).
The session key along with the encrypted ticket is again encrypted using Alice’s
key KA. Then it is sent to Alice. Alice receives the message. Decrypts it, and
extracts the session key.
❖ Alice can not decrypt the ticket, which is only for Bob.
❖ In this message, Alice is actually authenticated to the KDC, because only she can
open the whole message using her secret key with the KDC.
3. After getting the session key, Alice sends the encrypted ticket to Bob. Bob
decrypts the ticket using his key KB and knows that Alice needs to send message
to him using KAB as the session key.
❖ In this message, Bob is authenticated to the KDC, because only he can open the
ticket.
❖ Since Bob is authenticated to the KDC, he is also authenticated to Alice, who trusts
the KDC. In the same way, Alice is also authenticated to Bob, Bob trusts the KDC
and the KDC has sent Bob the ticket that includes the identity of Alice.
Note: Unfortunately, this protocol has a flaw. Eve can use the replay attack. That is, she can save the message in step 3 and replay it later.
Slide-8
Protocols for Creating Session Key using KDCs
Approach-2: Needham-Schroeder Protocol

This protocol is a
foundation for many
other protocols that
uses multiple
challenge-response
interactions between
parties to achieve a
flawless protocol.
Needham and
Schroeder uses two
nonce: RA and RB.
Figure below shows
the five steps used in
this protocol.

Slide-9 Figure: Needham-Schroeder protocol

Protocols for Creating Session Key using KDCs
Approach-2: Needham-Schroeder Protocol (continue…)
The steps for creating session key using Needham-Schroeder protocol
is summarized below:
1. Alice sends a message to the KDC that includes her nonce (R A), her identity,
and Bob’s identity.
2. After receiving the message from Alice, the KDC creates a ticket which
contains the identities of Alice, and the session key K AB between Alice and
Bob. The KDC then encrypts the ticket using Bob’s key (K B).
Alice’s nonce RA, Bob’s identity, the session key KAB, and the encrypted
ticket for Bob is again encrypted using Alice’s key K A. Then it is sent to
Alice. Alice receives the message. Decrypts it, and extracts the session key.
❖ Alice can not decrypt the ticket, which is only for Bob.
❖ In this message, Alice is actually authenticated to the KDC, because only she
can open the whole message using her secret key with the KDC.
1. After getting the session key, Alice sends the encrypted ticket to Bob. Bob
decrypts the ticket using his key KB and comes to know the session key.
2. Bob encrypts his challenge RB with the session key KAB and sends the
encrypted challenge to Alice.
3. Alice decrypts Bob’s encrypted challenge and extracts it. She then decrease
Bob’s challenge by 1 (i.e. RB-1), encrypts it using the session key and finally
sends it back to Bob.
Slide-10
Note: The response carries RB — 1 instead of RB.
Protocols for Creating Session Key using KDCs
Approach-3: Otway-Rees Protocol
The steps for creating
session key using this
approach is given below:
1. Alice sends a message to Bob
that includes a common nonce
R, the identities of Alice and
Bob, and an encrypted ticket
for KDC that includes Alice’s
nonce RA (a challenge for the
KDC to use), a copy of the
common nonce R, and the
identities of Alice and Bob.
2. Bob creates the same type of
ticket, but with his own nonce
RB. Both tickets are sent to the
KDC.
3. The KDC creates a message
that contains the common
nonce R, a ticket for Alice and a
ticket for Bob; the message is
sent to Bob. The tickets contain
the corresponding nonce RA or
RB, and the session key KAB.
4. Bob sends Alice her ticket.
5. Alice sends a short message
encrypted with her session key
KAB to show that she has the
Slide-11
session key. Figure: Otway-Rees protocol
Using Multiple KDCs:

When the number of people using a KDC increases, the system

becomes unmanageable and a bottleneck can result.
Using multiple KDCs can solve this problem.
There are two approaches to use multiple KDCs:
1. Flat multiple KDCs
2. Hierarchical multiple KDCs

Slide-12
Using Multiple KDCs:
Flat Multiple KDCs:
In this approach, the world is divided into domains where each domain
can have one or more KDCs.
❑ If Alice want to send a confidential message to Bob, who belongs to
another domain, Alice contacts her KDC, which in turn contacts the KDC
in Bob’s domain.
❑ The two KDCs can create a secret key between Alice and Bob.
Figure below shows the flat multiple KDCs.

Figure: Flat multiple KDCs

Slide-13
Using Multiple KDCs:
Hierarchical Multiple KDCs:
In hierarchical multiple KDC system, the concept of flat multiple KDCs
can be extended with one or more KDCs at the top of the hierarchy.
For example, there can be local, national and international KDCs.
❑ When Alice needs to communicate with Bob, who lives in another country, she needs
her request to a local KDC, the local KDC relays the request to the national KDC, the
national KDC relays the request to an international KDC.
❑ The request is then relayed all the way
down to the local KDC where Bob lives.

Figure below shows a

configuration of hierarchical
multiple KDCs.

Slide-14 Figure: Hierarchical multiple KDCs

Kerberos

Kerberos is an authentication protocol, and at the same time a

KDC, that has become very popular.

Several systems, including Windows 2000, use Kerberos.

It is named so after the three-headed dog in Greek mythology that

guards the gates of Hades.

Originally designed at MIT, it has gone through several versions.

Slide-15
Servers Involved in Kerberos:
Three servers are involved in the Kerberos protocol:
1. Authentication Server (AS):
❖ The authentication server (AS) is the KDC in the Kerberos protocol.
❖ Each user registers with the AS and is granted a user identity and a
password.
❖ The AS has a database with these identities and the corresponding
passwords.
❖ The AS -
✔ verifies the user,
✔ issues a session key (KA-TGS) to be used between Alice and the TGS, and
✔ sends a ticket for the TGS.
2. Ticket-Granting Server (TGS):
❖ The TGS –
✔ issues a ticket for the real server (Bob).
✔ provides the session key (KA-B) between Alice and Bob.
3. Real Server:
❖ The real server (Bob) provides services for the user (Alice).
❖ Kerberos is designed for a client-server program, such as FTP, in
which a user uses the client process to access the server process.
❖ Kerberos is not used for person-to-person authentication.

Slide-16
Servers Involved in Kerberos:
Figure below shows the relationship between these three servers.
In our examples and figures, Bob is the real server and Alice is the
user requesting service.

Slide-17
Figure: Kerberos servers
Operation of Kerberos:
In Kerberos, a client process (Alice) can access a process running on the
real server (Bob) in six steps, which are summarized below:
1. Alice sends her request to the AS in plain text using her registered identity.
2. The AS sends a message encrypted with Alice’s permanent symmetric key, KA-AS.
❖ The message contains two items:
− a session key KA-TGS, that is used by Alice to contact the TGS.
− a ticket for TGS that is encrypted with the TGS symmetric key KAS-TGS.
❖ Alice does not know KA-AS, but when the message arrives, she types her symmetric
password. The password and the appropriate algorithm together create K A-AS if the
password is correct. The password is then immediately destroyed; it is not sent to the
network and it does not stay in the terminal. It is used only for a moment to create K A-AS.
❖ The process now uses KA-AS to decrypt the message sent. KA-TGS and the ticket are
extracted.
3. Alice now sends three items to the TGS:
− The first is the ticket received from the AS.
− The second is the name of the real server (Bob).
− The third is a timestamp that is encrypted by KA-TGS. The timestamp prevents a replay by
Eve.
4. Now, the TGS sends two tickets, each containing the session key K A-B between Alice
and Bob:
− One ticket for Alice is encrypted with KA-TGS;
− Another ticket for Bob is encrypted with Bob’s key, K TGS-B.
❖ Note that Eve cannot extract KA-B because she does not know KA-TGS or KTGS-B. She cannot
replay step 3 because she cannot replace the timestamp with a new one (she does not
know KA-TGS). Even if she is very quick and sends the step 3 message before the
timestamp has expired, she still receives the same two tickets that she cannot decipher.
5. Alice sends Bob’s ticket with the timestamp encrypted by K A-B.
6. Bob confirms the receipt by adding 1 to the timestamp. The message is encrypted
with KA-B and sent to Alice.
Slide-18
Operation of Kerberos:
The above six steps are shown in the figure below:

Slide-19 Figure: Kerberos example

Kerberos Version 5:
After its inception, Kerberos has gone through several versions.
Among them, version 4 is the most popular.
The minor differences between version 4 and version 5 of Kerberos
are briefly listed below:
1) Version 5 has a longer ticket lifetime.
2) Version 5 allows tickets to be renewed.

3) Version 5 can accept any symmetric-key algorithm.

4) Version 5 uses a different protocol for describing data types.

5) Version 5 has more overhead than version 4.

Slide-20