Notes for Lecture-33,34

MCA 206: Advanced Computer Networks

1. Introduction to Authentication Protocols

Before two participants are likely to establish a secure channel between themselves— that is, use
an algorithm such as DES to encrypt messages they exchange—they will generally wish to
establish that the other participant is who he or she claims to be. This is the problem of
authentication. Authentication protocols are capable of simply authenticating the connecting
party or authenticating the connecting party as well as authenticating itself to the connecting
party. Authentication protocols are based on two approaches – timestamp and nonce. The time
stamp requires distributed clock synchronization and it has certain margin of error. In the usage
of nonce the track of past nonce has to be kept. These drawbacks can be overcome through the
Challenge-Response Protocol.

1.1 Challenge-Response Protocol

In this protocol, Alice send Bob a timestamp, challenging Bob to encrypt it in response or
digitally sign it in a response message. The encrypted timestamp is like an authenticator and also
provides timeliness. Since, timestamp comes from Alice’s own clock therefore, no distributed
clock synchronization is needed.

2. Public key Authentication Protocol

2.1 With Clock Synchronization

1. Alice sends Bob a message with a timestamp T1 and her identity along with digital signature.

2. Bob authenticate the message and verify the freshness using timestamp.

3. Bob sends back a message with timestamp T2 and his identity and a new session key
encrypted using Alice Public key, all digitally signed.

4. Alice can verify authenticity and freshness to trust the new session key.

2.2 Without Clock Synchronization

1. Alice sends Bob a message with a timestamp T1 and her identity along with digital signature.

2. Bob sends back a digitally signed message with T1, his new timestamp T2 and his identity.

3. Alice compares this T1 with original timestamp for freshness check.

4. Alice sends T2 and a new session key encrypted using Bob’s public key.

5. Bob can verify freshness of message to trust new session key.

Note, here timestamp serves the purpose of nonce.

3. Symmetric Key Authentication Protocol

3.1 Needham–Schroeder protocol

The term Needham–Schroeder protocol can refer to one of the two communication protocols
intended for use over an insecure network, both proposed by Roger Needham and Michael
Schroeder. These are:

 The Needham–Schroeder Symmetric Key Protocol is based on a symmetric encryption

algorithm. It forms the basis for the Kerberos protocol. This protocol aims to establish a
session key between two parties on a network, typically to protect further
communication.
 The Needham–Schroeder Public-Key Protocol, based on public-key cryptography. This
protocol is intended to provide mutual authentication between two parties communicating
on a network, but in its proposed form is insecure.

Here, Alice (A) initiates the communication to Bob (B). S is a server trusted by both parties. In
the communication:

 A and B are identities of Alice and Bob respectively

 KAS is a symmetric key known only to A and S
 KBS is a symmetric key known only to B and S
 NA and NB are nonces generated by A and B respectively
 KAB is a symmetric, generated key, which will be the session key of the session between
A and B

The protocol can be specified as follows in security protocol notation:

Alice sends a message to the server identifying herself and Bob, telling the server she
wants to communicate with Bob.

The server generates and sends back to Alice a copy encrypted under for
Alice to forward to Bob and also a copy for Alice. Since Alice may be requesting keys
for several different people, the nonce assures Alice that the message is fresh and that the
server is replying to that particular message and the inclusion of Bob's name tells Alice
who she is to share this key with.
 Alice forwards the key to Bob who can decrypt it with the key he shares with the server,
thus authenticating the data.

Bob sends Alice a nonce encrypted under to show that he has the key.

Alice performs a simple operation on the nonce, re-encrypts it and sends it back verifying
that she is still alive and that she holds the key.

3.2 Kerberos

Kerberos is a computer network authentication protocol which works on the basis of "tickets" to
allow nodes communicating over a non-secure network to prove their identity to one another in a
secure manner. Kerberos authentication was developed at the Massachusetts Institute of
Technology aimed primarily at a client–server model. It provides mutual authentication—both
the user and the server verify each other's identity. Kerberos protocol messages are protected
against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and
requires a trusted third party, and optionally may use public-key cryptography during certain
phases of authentication. Kerberos uses port 88 by default. There are two main components: a
ticket, which is used for user authentication and securing data, and an authenticator that is used
to verify that the user is the same user to whom the ticket was initially granted.
It has three servers: authentication server, ticket granting server and real server.

3.2.1 Operation

When a user logs into a system, the system connects to the Kerberos server where it retrieves a
session key to be used between the user and the ticket granting service (TGS). This is encrypted
with a key based on the user's password. If the user provides the right password the end system is
able to decrypt the session key. After this is done, the user password is erased from memory to
avoid being compromise. The ticket (Ticket granting ticket: TGT) expires after a set amount of
time. When a user wants to connect to a service to which he does not already have a ticket, the
user connects to the TGS and gets a ticket that can only be used to access the particular service
the ticket was granted for. The user can now connect through an encrypted channel to the server.
After the ticket expires, the user must request a new one from the TGS. The major issue with
Kerberos is its scalability. The Kerberos server must store secret keys for each of the users and each
of the TGSs.

The protocol is described in detail below.

User Client-based Logon

1. A user enters a username and password on the client machines.

2. The client performs a one-way function (hash usually) on the entered password, and this
becomes the secret key of the client/user.

Client Authentication

1. The client sends a clear text message of the user ID to the AS requesting services on
behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The
AS generates the secret key by hashing the password of the user found at the database
(e.g. Active Directory in Windows Server).
2. The AS checks to see if the client is in its database. If it is, the AS sends back the
following two messages to the client:
o Message A: Client/TGS Session Key encrypted using the secret key of the
client/user.
o Message B: Ticket-Granting-Ticket (which includes the client ID, client network
address, ticket validity period, and the client/TGS session key) encrypted using the
secret key of the TGS.
3. Once the client receives messages A and B, it attempts to decrypt message A with the
secret key generated from the password entered by the user. If the user entered password
does not match the password in the AS database, the client's secret key will be different
and thus unable to decrypt message A. With a valid password and secret key the client
decrypts message A to obtain the Client/TGS Session Key. This session key is used for
further communications with the TGS. (Note: The client cannot decrypt Message B, as it
is encrypted using TGS's secret key.) At this point, the client has enough information to
authenticate itself to the TGS.

Client Service Authorization

1. When requesting services, the client sends the following two messages to the TGS:
o Message C: Composed of the TGT from message B and the ID of the requested
service.
o Message D: Authenticator (which is composed of the client ID and the
timestamp), encrypted using the Client/TGS Session Key.
 2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It
decrypts message B using the TGS secret key. This gives it the "client/TGS session key".
Using this key, the TGS decrypts message D (Authenticator) and sends the following two
messages to the client:
o Message E: Client-to-server ticket (which includes the client ID, client network
address, validity period and Client/Server Session Key) encrypted using the
service's secret key.
o Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request

1. Upon receiving messages E and F from TGS, the client has enough information to
authenticate itself to the SS. The client connects to the SS and sends the following two
messages:
o Message E from the previous step (the client-to-server ticket, encrypted using
service's secret key).
o Message G: a new Authenticator, which includes the client ID, timestamp and is
encrypted using Client/Server Session Key.
2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session
Key. Using the sessions key, SS decrypts the Authenticator and sends the following
message to the client to confirm its true identity and willingness to serve the client:
o Message H: the timestamp found in client's Authenticator plus 1, encrypted using
the Client/Server Session Key.
3. The client decrypts the confirmation using the Client/Server Session Key and checks
whether the timestamp is correctly updated. If so, then the client can trust the server and
can start issuing service requests to the server.
4. The server provides the requested services to the client.

3.2.2 Drawbacks and Limitations

 Single point of failure: It requires continuous availability of a central server. When the
Kerberos server is down, no one can log in. This can be mitigated by using multiple
Kerberos servers and fallback authentication mechanisms.
 Kerberos has strict time requirements, which means the clocks of the involved hosts must
be synchronized within configured limits. The tickets have a time availability period and
if the host clock is not synchronized with the Kerberos server clock, the authentication
will fail. In practice Network Time Protocol daemons are usually used to keep the host
clocks synchronized.
 The administration protocol is not standardized and differs between server
implementations.
 Since all authentications are controlled by a centralized KDC, compromise of this
authentication infrastructure will allow an attacker to impersonate any user.
 Each network service which requires a different host name will need its own set of
Kerberos keys. This complicates virtual hosting and clusters.
3.3 Diffie-Hellman Exchange Method

Diffie Hellman was the first public key algorithm ever invented; in 1976. Diffie Hellman key
exchange algorithm uses asymmetric key principles for the distribution of symmetric keys to
both parties in a communication network. Key distribution is an important aspect of conventional
algorithm and the entire safety is dependent on the distribution of key using secured channel.
Diffie Hellman utilizes the public& private key of asymmetric key cryptography to exchange the
secret key.

3.3.1 Method

The steps for Diffie Hellman key exchange algorithm are:

Alice and Bob want to be able to generate a key to use for subsequent message exchange. The
key generating exchange can take place over an unsecure channel that allows eavesdropping. The
ingredients to the protocol are: p, a large prime and g, a primitive element of Zn. This means that
all numbers n=1, ... , p-1 can be represented as n = gi. These two numbers do not need to be kept
secret. For example, Alice could send them to Bob in the open. The protocol runs as follows:

 Alice chooses a large random integer x and sends Bob

o X=gx mod p
 Bob chooses a large random integer y and sends Alice
o Y=gy mod p
 Alice computes
o k=Yx mod p
 Bob computes
o k=Xy mod p

k is the key. k is equal to gxy mod p.

3.3.2 An Example

• Alice and Bob get public numbers, P = 23, G = 9

• Alice and Bob compute public values
– X = 94 mod 23 = 6561 mod 23 = 6
– Y = 93 mod 23 = 729 mod 23 = 16
• Alice and Bob exchange public numbers
• Alice and Bob compute symmetric keys
ka = ya mod p = 164 mod 23 = 9
kb = xb mod p = 63 mod 23 = 9
• Alice and Bob now can talk securely!