Unit 5

Transport Level Security

Or

Transport Layer Security

 Introduction

(1) In the original Internet protocols, security features have not built into. This is
a security weakness of the protocol. The security weakness of such web
services have been exploited by the attackers to gain access to the private
data.
(2) Now-a-days web applications are being extensively used in Financial
organizations, e-commerce, Government services, Private organization
services, and so on. Various types of threats arise for web services and
Internet applications.
(3) The security problems are prevailing at Client, Server, and the traffic
between client & server.
 What are the possible web security threats ?

(1) The web system may have both passive and active attacks.

(2) Passive attacks include eavesdropping between browser and server, and

active attack include altering the message during transmission.

(3) The web security threats involve attack on browser, web server, and the
network traffic between browser and server.

(4) Web threats pose a broad range of risks, including financial damages, loss of
confidential information, theft of network resources, damage brand and
personal reputation, and erosion of consumer confidence in e-commerce
business and online banking system.
The table give the summary of types of security threats face when using web
 Web traffic security approaches
(1) We can secure IP layer, or Transport layer, or application layer.
(2) The advantage of doing IPSec is, all transport layer protocols and all application layer
protocols are secured in addition to the network layer protocols.
(3) The advantage of doing transport layer security is, transport protocols and all
application layer protocols are covered under security.
(4) The advantage of doing application layer security is specific to individual application
and does not cover other applications. For example, a mail security can not provide
security for web browsing applications.
(6) In some sense IPSec is better, but there are several problems of implementation. So,
providing security at Transport layer and Application layer are widely used.
 (1) IP Security (Network level Security)
(2) IPSec include selection of the packets based on IP address. Through this,
only selected traffic can be allowed to flow in to the private network.
(2) It provide data authentication, and confidentiality.
(3) In IPSec, data encryption is made on per-packet rather than per-flow basis.
(4) Per-packet encryption greatly enhances the IP security.
(5) Disadvantage is with Implementation and performance in Internet.
 (2) Transport layer security (TLS)
(1) The Transport Layer Security protocol adds a layer of security on top of the
TCP protocol.
(2) TLS use both symmetric key encryption & Asymmetric key encryption for
secure transmission of data.
(3) TLS protocol provide communication security between client/server
applications that communicate with each other over the Internet.
(4) TLS provide Confidentiality & integrity for the data transmitted between
different nodes on the Internet.
 (3) Application level Security

 Application level security  is only for individual application, to protect from
malicious attacks.
 Transport Layer Security
Secure Socket Layer (SSL)
(1) SSL is a most widely used security protocol.
(2) SSL protocols relay upon TCP.
(3) The latest version of secure socket layer is SSLv3.
 SSL
(1) SSL was designed to coordinate with TCP to provide a reliable, end-to-end
secure service.
(2) SSL is a two layered architecture.
(3) SSL, sitting at the transport layer, provide service to its higher layers.
(4) In web services, it provide service to HTTP, present in application layer.
(5) HTTP sits on the top of SSL.
(6) For the purpose of security management, SSL use three protocols- SSL
Handshake Protocol, SSL Change Cipher spec Protocol, and SSL Alert protocol.
 TLS Vs SSL
(1) SSLv1 was developed by Netscape in 1994 and deployed in their web
browser. SSLv3 is most commonly deployed protocol.
(2) In 1999, IETF upgraded SSLV3 and named as Transport layer security (TLS)
v1.
(3) The standards of TLSv1 are defined in RFC2246.
(4) The difference between SSLv3 & TLSv1 is very small but do not
interoperable.
(5) SSL provides security services to application layer protocols using TCP during
data transmission.
 SSL Architecture
SSL has 4 protocols presented in two layers.
(1) Handshake protocol- It negotiates which type of crypto algorithm to be used, type of
hash algorithm, Sharing public key certificate, and other parameters required for a SSL
session connection.
(2) Change cipher spec protocol – Implement negotiated crypto algorithms, and
parameters during connection & session.
(3) SSL Alert protocol – Any error occurs during crypto communication, all those error
messages are communicated to the end users.
(4) SSL Record protocol – Protocols (1), (2) & (3) run on record protocol. It is a main
protocol in SSL. It provides confidentiality through encryption & authentication using
MAC code.
SSL Architecture (contd..)
 HTTP Vs HTTPS

(1) Many applications use TCP. TCP is a part of OS. Application interact with TCP
by using a concept called Socket. What an application developer do is, he write
an API program to call TCP for a connection setup & send packet. That is called
Socket API.
(2) Netscape developers wanted to add security through some encryption
during communication between web browser & web server. So, they developed
a layer between application & TCP called as SSL. Open SSL provide a set of C
libraries.
 Transport layer security (contd…)
SSL/TLS Negotiation services

 SSL/TLS use a secure connection & a secure session for data transfer.

 SSL/TLS establish a secure connection using TCP & then establish a session
between client/server using handshake protocol.

 When connection is established information like- Nonce, MAC secret,

encryption keys, IV, & sequence number etc. are exchanged.

 When session is established then session information like- session Id,

certificate, compression method, cypher Spec (encryption algo & hash algo),
Master secret key, etc. are exchanged.
 i) SSL connection parameters
SSL establish a connection by using TCP. It is a process-to-process connection
established for one session. A connection state is defined by the following
parameters.
(1) Server and client random
It is a block size selection between the server and the client for the session.
(2) Server write MAC secret
The secret key used in MAC operations on data sent by the server.
(3) Client write MAC secret
The secret key used in MAC operations on data sent by the client.
(4) Server write key
The secret encryption key for data encrypted by the server and decrypted by
the client.
(5) Client write key
The symmetric encryption key for data encrypted by the client and
decrypted by the server.
 i) SSL connection parameters (contd..)
(6) Initialization vectors
An initialization vector is a random number used in combination with a secret
key as a means to encrypt data.
(7) Sequence numbers
Each sender maintains separate sequence numbers for transmitted data
and received data for each connection.
 (ii) SSL session parameters
Sessions are created by using SSL Handshake protocol. Session phase defines a set of
cryptographic security parameters which can be shared by client & Server.
SSL session parameters are:
(1) Session identifier: A unique number generated by the server to identify a session.
(2) Peer certificate: The sessions are between a client and a server. The identity of
the peer is established as part of session setup. It is identified by X509.v3 certificate.
(3) Compression method: The type algorithm used to compress data prior to encryption.
(4) Cipher spec : Specifies the bulk data encryption algorithm ( AES, etc.) and a hash
algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic
attributes such as the hash size.
(5) Master secret: 48-byte secret key shared between the client and the server.
(6) Is resumable: A flag indicating whether the session can be used to initiate new
connection.
 SSL Record Protocol

The SSL Record Protocol provides two important services.

(1) Confidentiality: The Handshake Protocol share a secret key that is used for
encryption. By encrypting the data, it provide confidentiality.
(2) Integrity: The Handshake Protocol also share secret key that is used to form a
message authentication code (MAC). Using MAC, perform authentication.
SSL Record Protocol Operation
 SSL Record Protocol Operation

(1) The Record Protocol takes an application message to be transmitted of

some size 500 bytes or less.
(2) Fragments the data into blocks.
(3) compresses the data by applying a lossless compression technique. It save
communication cost. Apply MAC over the compressed data by using a
shared secret key. The compressed message is appended with MAC.
(3) The compressed message is appended with MAC is encrypted using
symmetric encryption. The encrypted packet size can not be more than
1024 Bytes.
(4) For the encrypted message, add SSL record header , and transmits the
data unit as a TCP segment.
(5) Received TCP segments are decrypted, verified, decompressed, and
reassembled and delivered to the higher level layers.
SSL record header fields (SSL record frame format)
 SSL record header fields (SSL record frame format)

(1) Content Type (8 bits): The higher-layer protocol (AES,DES) used to process
the enclosed fragment.
(2) Major Version (8 bits): Indicates major version of SSL in use. For SSLv3, the
value is 3.
(3) Minor Version (8 bits): Indicates minor version in use. For SSLv3, the value is
0.
(4) Compressed Length (16 bits): The size of the compressed fragment in bytes.
 1. SSL Change Cipher Spec Protocol field (Cipher spec frame format)
(1) It is a simple protocol.
(2) This protocol consists of a single message of 1- byte with the value 1.
(3) When the value is 1, It updates the cipher protocol along with the session
parameters which are to be used during that session.
 2. Alert Protocol field (Alert protocol frame format)
(1) The alert protocol convey alert messages to the peer entities.
(2) It uses SSL record protocol, So the alert messages are compressed and
encrypted.
(3) Message field consists of 2-bytes. If, the level byte take value 1, it is
warning. & if the level value is 2, it is fatal (failure or disaster). The value 2
convey the severity of the message. If the level is fatal, SSL immediately
terminate the connection.
 What are the Warning messages (when level=1)?
(1) close-notify: It notifies the recipient that the sender will not send any more message
on this connection. So, each party has to exchange close-notify message.
(2) no_cirtificate: If no certificate is available during SSL handshake, it send this
message.
(3) bad_certificate: A received certificate but is corrupted digitally.
(4) unsupported_certificate: The type of certificate received is not supported.
(5) certificate_revoked: Certificate has been revoked by the authority.
(6) certificate_expired: The certificate has expired.
(7) certificate_unknown: A certificate is unacceptable.
 What are the fatal messages (when level=2) ?
(1) unexpected_message: An inappropriate message was receive.
(2) bad_record_mac: An incorrect MAC received.
(3) decompression_failue: Unable to decompress or segment size is greater
than 1024 bytes.
(4) hand_shake failure: Sender was unable to negotiate by using an acceptable
set of security parameters.
(5) illegal_parameters: A field in the handshake message was out of range or
inconsistent with other field.
 3. SSL Handshake protocol
It allows the server and client to authenticate each other and negotiate which
type of crypto algorithm to be used, type of hash algorithm, Sharing public key
certificate, and other parameters required for a SSL session connection.
The handshake protocol consists of a series of messages exchanged between
client and server.
Each message has three fields.
Type (1 byte): Indicate type of message.
Length(3 bytes): The length of the message type.
Content(>=0):The parameters associated with this message.
 Handshake protocol action
The figure shows the exchange of messages needed to establish a session
between client and server.
The exchange involves 4- Phases.
Phase 1: Establish security capabilities.
Phase 2: Server authentication & Key exchange.
Phase 3: Client authentication & key exchange.
Phase 4: Finish.
Handshake protocol action (contd..)
 Handshake protocol action (contd..)

Phase 1: Establish security capabilities

This phase is used to initiate a session and to establish security capabilities.
The exchange of message is initiated by client.
The client send client_hello message along with the following parameters_
Version, Random, Session Id, Cipher suit (cryptographic algorithms),
compression method.
After sending the message, client wait for server_hello message which contain
the same message.

hash(ClientHello.random || ServerHello.random || ServerParams)

 Handshake protocol action (contd..)

Phase 2: Server authentication & Key exchange

Server send, certificate, server key exchange, certificate request, server hello
done.

CertificateVerify.signature.md5_hash
MD5(master_secret || pad_2 || MD5(handshake_messages ||
master_secret || pad_1));

Certificate.signature.sha_hash
SHA(master_secret || pad_2 || SHA(handshake_messages ||
master_secret || pad_1));
 Handshake protocol action (contd..)
Phase 3: Client authentication &key exchange
Client send – certificate, client key exchange, certificate verify.
Phase 4: Finish
Client send - Change cipher spec, finished message.
Server send - Change cipher spec, finished message.
The key exchange and authentication process were successful.
 Cryptographic Computation
How to generate Master Key?
Generating a shared Master key consists of two stages.
(1) Client generate a 48-byte ( 384-bits ) pre-master key. Client apply RSA
algorithm to encrypt the pre-master- key using Server Public key and sent to
server. Server decrypt by using its Private key & recover the pre-master- key .
(2) To generate the Maser key at both the sides, the 384 bit pre-master- key is
divided into 3 groups of size 128-bits. To compute Master key using pre-
master- key , the following algorithms are applied:
master_secret = MD5( pre_master_secret || SHA('A' || pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5( pre_master_secret || SHA(‘BB' || pre_master_secret ||
ClientHello.random || ServerHello.random)) ||
MD5( pre_master_secret || SHA(‘CCC' || pre_master_secret ||
ClientHello.random || ServerHello.random))
where, ClientHello.random & ServerHello.random are nonce values exchanged during
hello messages.
 TLS Protocol Stack

1) The TLS record format is same as SSL record format.

2) The fields in the header have the same meaning.
 (1) TLS record header fields (TLS record frame format)

(1) Content Type (8 bits): The higher-layer protocol (AES,DES) used to process
the enclosed fragment.
(2) Major Version (8 bits): Indicates major version of TLS in use. For TLS, the
value is 3.
(3) Minor Version (8 bits): Indicates minor version in use. For TLS , the value is
1.
(4) Compressed Length (16 bits): The size of the compressed fragment in bytes.
TLS record header fields
TLS handshake operations
 There is difference in MAC calculation in TLS & SSL
TLS MAC Scheme
TLS makes use of the HMAC algorithm as defined in RFC 2104.

Ipad = inner padding – fixed Hexadecimal 36

opad = outer padding – fixed Hexadecimal 5C

How TLS differs with SSL in using MAC scheme ?.

(1) In TLS, the padding bits are concatenated on the left and XORed with Secret-key.
(2) In SSLv3, the padding bits are concatenated on left of the Secret-key
 Pseudorandom Function
(1) During session handshake, both Client & Server generate a secure random
number called as Nonce. These nonce values are exchanged for validation.
(2) In SSL, the random number (nonce) size is 28-bytes.
(3) In TLS, generates a random number of size 28-bytes or less, but enhances
that nonce into a longer block, to secure the nonce from the attackers.
 Generating Pseudorandom value in TLS

HMAC( secret , seed ||HMAC[secret, A(0)]) || HMAC( secret , seed ||HMAC[secret, A(1)]) ||

HMAC( secret , seed ||HMAC[secret, A(2)]) || HMAC( secret , seed ||HMAC[secret, A(3)]) || …..

A(0)=seed value. A(i) = HMAC(secret, A(i-1)) , i=2,3,4,…

(i) PRF takes input , a secret value, a label, & a seed to produce an output of arbitrary length pseudorandom value.

(ii) Iterating many times produce large quantity of data. Out of which, required size data can be retained and other
data can be discarded.
 Alert Codes

TLS support all alert messages listed in SSL, in addition to that it support,

The first byte take value 1, it is warning

(1) user_canceled
(2) no_renegotiation

The first byte take value 2, it is fatal (failure or disaster)

(3) record_overflow
(4) unknown_ca
(5) access_denied
(6) decode_error
(7) protocol_version
(8) insufficient_security
(9) unsupported_extension
(10) internal_error
(11) decrypt_error
 What are the Warning messages (when level=1)?
(1) close-notify: Notifies the recipient that the sender will not send any more
message on this connection. So, each party has to send close-notify alert.
(2) no_cirtificate: If no certificate is available during SSL handshake, it send this
message.
(3) bad_certificate: A received certificate is corrupted.
(4) unsupported_certificate: Type of certificate received is not supported.
(5) certificate_revoked: Certificate has been revoked by the authority.
(6) certificate_expired: A certificate has expired.
(7) certificate_unknown: A certificate is unacceptable.
 What are the fatal messages (when level=2) ?
(1) unexpected_message: An inappropriate message was receive.
(2) bad_record_mac: An incorrect MAC received.
(3) decompression_failue: Unable to decompress or segment size is greater
than 1024 bytes.
(4) hand_shake failure: Sender was unable to negotiate by using an acceptable
set of security parameters.
(5) illegal_parameters: A field in the handshake message was out of range or
inconsistent with other field.
 Client Certificate type

(1) In TLS, the certificate –request message types are:

(i) rsa_sign,
(ii) dsa_sign
(iii) rsa_fixed_dh,
(iv) dss_fixed_dh
(2) In SSLv3, in addition to the above, include:
(v) rsa_ephemeral_dh
(vi) Dss_ephemeral_dh
 (6) Finished Message
(1) In SSLV3;
(i) MD5(master_secret|| pad2|| MD5[handshake_message|| sender ||
master_secret|| pad1])
OR
(ii) SHA(master_secret|| pad2|| SHA[handshake_message|| sender ||
master_secret|| pad1])
(2) In TLS;

PRF(master_secret, finished_label1, MD5(handshake_message) ||

SHA1(hansshake_message))
Where, finished_label1= “Client finished” OR “Server finished”
 Electronic Mail Security
E-mail is the most heavily used network based application. Hence, there is need
for proving security for email-services. For secure e-mail services, the mail
application must be incorporated with Confidentiality & Authentication features.

There are two popular schemes that provide secure e-mail services.
(1) Pretty Good Privacy (PGP)
(2) Secure Multipurpose Internet Mail Extension (S/MIME).
 (1) Pretty Good Privacy (PGP)

(2) PGP is the first secure e-mail service, developed by Phil Zimmermann, who
is a well known Cryptographer. It provide both Confidentiality &
Authentication for e-mail services.

(2) Phil Zimmermann did not develop any new encryption algorithms, instead he
selected the best available encryption algorithms (for confidentiality) & best

hash schemes (for authentication) and put them into a single package that
any body can use on any system, anywhere in the world.

(3) The PGP became so popular that people wanted to develop PGP products.
Till now it was an individuals proprietary, manufactures approached IETF to
set up standards. Then, IETF developed standards and named it as Open
PGP.

(4) Open PGP provide standards for commercial version of PGP. Currently the
rights are owned by MCCafee.
 PGP Services

PGP provides 4 services- Authentication, Confidentiality, Compression, & e-mail

compatibility.
 (i) Authentication

Authentication is achieved through digital signature.

(1) A hash code of the message is created using SHA1. This is called message
digest.
(2) This message digest is encrypted by using either DSS or RSA by using senders
private key.
(3) The encrypted message digest is concatenated with the original message and
send to the destination.
(4) At the receiver side, the encrypted message digest is decrypted by using
sender public key and message digest is recovered.
(5) the original message is hashed by using SHA1 & created message digest.
(6) The created message digest is compared with the recovered message digest,
found correct, authenticated.
 (ii) Confidentiality
(1) The confidentiality is achieved by applying message encryption algorithms.
(2) In PGP, the popular message encryption algorithms like CAST-128 (Carlisle
Adams & Stafford Tavares) OR IDEA (International Data Encryption
Algorithm) OR 3DES (Data Encryption algorithm) are used by applying one
time session key. The session key is shared with the receiver by using DH or
RSA algorithms, using receiver public key.

(iii) Compression

In PGP, the encrypted message is compressed by applying ZIP compression

algorithm and then transmitted.
 (iv) E-mail compatibility

(1) PGP use Radix-64 algorithm for conversion of 8-bit ASCII characters into 6-bit
non-ASCII characters.
(2) This technique is also called as converting binary text into mailable text.
(3) Using this technique, text, pictures , audio & video files can transmitted
using mail.
(4) Radix-64 uses – a to z (lowercase alphabets), A to Z (uppercase alphabets), 0
to 9 (decimals), and +,/ (symbols). Total 64.
(5) It will convert binary into Radix-64 before going into wire.
 (4) E-mail compatibility (contd…)

(1) Example: Convert binary text “ Man” into mailable text.

It will take a block of 3-characters of 8-bit each. Total 24-bits. Group into 6-bits
each. The output will be 4-characters of 6-bit each.
 PGP Operation - Authentication

H = hash function (SHA-1)

EP = public-key encryption (DSS/RSA)
PRA = private key of user A
|| = concatenation
Z = compression using ZIP algorithm
 PGP Operation – Authentication (contd…)
Authentication is achieved through digital signature.
(1) A hash code of the message is created using SHA1. This is called message
digest.
(2) This message digest is encrypted by using either DSS or RSA by using senders
private key.
(3) The encrypted message digest is concatenated with the original message,
zipped and the zipped file is send to the destination.
(4) At the receiver side, the file is unzipped, the encrypted message digest is
decrypted by using sender public key and message digest is recovered.
(5) the original message is hashed by using SHA1 & created message digest.
(6) The created message digest is compared with the recovered message digest,
found correct, authenticated.
 PGP Operation - Confidentiality

Z = compression using ZIP algorithm

Ks = session key used in symmetric encryption scheme
EC = symmetric encryption (CAST-128/ IDEA/3DES)
PUa = public key of user A, used in public-key encryption scheme
EP = public-key encryption (DH/RSA)
DP = public-key decryption
DC = symmetric decryption
 Confidentiality
(1) The confidentiality is achieved by applying message encryption algorithms.
(2) In PGP, the popular message encryption algorithms like CAST-128 (Carlisle
Adams & Stafford Tavares) OR IDEA (International Data Encryption
Algorithm) OR 3DES (Data Encryption algorithm) by using one time session
key (Ks). The session key is shared with the receiver by in an encrypted way
using DH or RSA algorithm, by using receiver public key.

Compression

In PGP, the encrypted message is compressed by applying ZIP compression

algorithm and then transmitted.
PGP Operation – Confidentiality & Authentication
Transmission & Reception of PGP messages
 Secure Multipurpose Internet Mail Extension (S/MIME)
Introduction to S/MIME
S/MIME defines the standard for secure e-mail service.
In the beginning, e-mail was designed only for text message transmission (RFC
5322). When the developers thought of sending non-text information such as
picture, voice and video using e-mail, then they developed Multipurpose
Internet Mail Extension (MIME). These e-mail transmission facilities became
more popular in the business field, then, the security issues come up (1990s),
which lead to the development of S/MIME.
The S/MIME is added with 4 more enhanced functionalities. It support in
sending (i) Envelop data, (ii) Signed data, (iii) Clear signed data, and (iv)
Signed and enveloped data.
 Evolution of MIME
RFC 5322
(1) This defines a format for sending text messages using e-mail.
(2) The format is associated with two entities, (i) Content & (ii) Envelop.
Content – It composes of general information on the message to be delivered
to the recipient. The content include header fields.
Envelop – It contains the actual message to be delivered to the recipient.
 Multipurpose Internet Mail Extension (MIME)
MIME is an extension of RFC 5322. MIME is designed to address some of the
problems and limitations of the use of Simple Mail Transfer Protocol (SMTP).
The limitations of SMTP are:
(1) SMTP can not transmit executable files.
(2) SMTP can not transmit other national language characters.
(3) SMTP server reject mail message over a certain size, and so on.

MIME intended to resolve all these problems.

(1) MIME header fields: Five new message header fields are defined. These
fields provide information about the body of the message.

(2) MIME content types: A number of content formats are defined to support
multimedia electronic mail.

(3) MIME transfer encoding: Transfer encodings are defined that enable the
conversion of content format into a mailable format.
 MIME header fields

To resolve these SMTP problems, MIME include the following features in its
header fields. The MIME header fields are,

(i) MIME-Version
(ii) Content-Type
(iii) Content-Transfer-Encoding
(iv) Content-ID
 (i) MIME Version
MIME version: 1.0
(ii) MIME content types
A number of content formats are defined to support multimedia electronic mail. It is
consisting of a type and subtype, for example, Content-Type: text/plain
 (iii) Content-Transfer-Encoding
Transfer encodings are defined that enable the conversion of content format into a
mailable format. MIME allows different encodings.
(i) 7 – bit ASCII
(ii) 8 – bit ASCII
(iii) Non-ASCII characters
(iv) Quoted-printable : It is an encoding method defined in MIME standard. It is used
primarily to encode 8-bit text (English & foreign characters)into 7-bit ASCII. The
encoded document is in readable form. i.e you can put alphanumeric as it is. A is
translated into A, a is translated into a. and so on.
(v) Base – 64: which is Similar to Radix-64.
ASCII files are plane text files. They have the extension .txt.
Binary files are program files like .c, compressed files, and other non-text files.
Content-transfer-encoding define whether or not a binary to text encoding scheme has
been used. These encoding are necessary when channel does not allow 8-bit
representation.
 (iv) Content Id
The content Id is an optional field. The content-Id of MIME is a unique number. However in
many systems where the messages are stored, does not indexed independently.
 S/MIME Functions
S/MIME is a standard for public key encryption and signing of MIME data.
(i) Envelop data – This consists of encrypted content of any data and encrypted keys for one or more
recipients.
(ii) Signed data- A digital signature is formed by taking the message digest and then encrypted using
private key of the sender. The content plus the signature are then encoded using Radix-64 algorithm.
A digitally signed message can only be viewed by a recipient with S/MIME capability.
(iii) Clear signed data- Here, digital signature is encoded using Radix-64. As a result the recipient
without S/MIME capability can view the message content but without verification of message.
(iv) Signed and enveloped data – Signed only and encrypted only entities may be nested, so that
encrypted data may be signed and signed data and clear – signed data may be encrypted.
 Kerberos
Assume an open distributed environment, in which users at workstations wish to access
services. The servers distributed throughout the network. We would like the restrict the
server access to authorised users and to be able to authenticate requests for service. In this
environment, a workstation cannot be trusted to identify its users correctly for network
services.
In particular, the following three threats exist:
(i) A user may gain access to a particular workstation and pretend to be a user operating
from that workstation.
(ii) A user may alter the network address of a workstation so that the requests sent from
the altered workstation appear to come from the impersonated(pretended to be
another person) workstation.
(iii) A user may eavesdrop on exchanges and use a replay attack to gain entrance to a
server or to disrupt operations.

In any of these cases, an unauthorized user may be able to gain access to services and he
can access the data.

How to overcome this problem?

 Kerberos Version 4
In an unprotected network environment, any client can request to any server for service.
The security risk is that of impersonation. An opponent can pretend to be an authorized
client and obtain authorized privilege on the server machines. To counter this threat
server must be able to authenticate the client. But in an open environment this is
substantial burden on each server.
Ticket Granting Server (TGS)
 If a client wishes to check the mail several times in a day, each time he has to enter the
password.
 An eavesdropper can steal the password and can use it for mail reading.

To solve these problems, the developers introduced a scheme called Ticket-Granting

Server (TGS).
Ticket Granting Server (TGS) contd…
1) User logs on to the workstation and send a request to authenticate server for ticket –
granting –ticket.
2) The authenticate server of verify users access rights from its database, create ticket –
granting –ticket , encrypted by a key generated from users password.
3) Client receive ticket – granting –ticket decrypt using his password and recover ticket –
granting –ticket.
4) The client encrypt the ticket – granting –ticket and send a request to TGS.
5) TGS verify the request, create a ticket and sent to the client. Thus, client receive a
ticket from the Kerberos server.
6) Using the ticket, client send a request to server. Server verify the ticket, authenticate,
and grant access to server.
For different servers user is necessary to get new tickets.
Secure Authentication Dialogue
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 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
 Differences between Kerberos Versions 4 and 5
Kerberos 4 was developed by a group of researchers as a part of project Athena. So, in
Kerberos version 4 did not fully address the needs of general purpose.
In version -5, developers tried to address the limitations of version -4 in two areas.
(1) Environmental short comings, and (2) Technical deficiencies.
(1) Environmental short comings
(i) Encryption system dependence
(ii) Internet protocol dependence
(iii) Message byte ordering
(iv) Ticket lifetime
(v) Authentication forwarding
(2) Technical deficiencies
(vi) Double encryption
(vii) Session keys
(i) Encryption system dependence
Kerberos version 4 uses DES algorithm. There was export restrictions on DES products, and by
that time doubts were raised on the security of DES.
In Kerberos version 5 the flexibility was introduced such that any encryption technique may be
used.
(ii) Internet protocol dependence
In Kerberos version 4, the use of internet protocol addressing scheme was used. In Kerberos
version 5, ISO networking addressing where subfields or subnetting can be used.
(iii) Message byte ordering
In Kerberos version 4, the message was stored by using byte ordering. A byte has a limit of
256 values. When the value is greater than 255, it is to be stored in multiple bytes. This
caused conversion problem.
In Kerberos version 5, the message was stored using abstract syntax notation which is
standard for data representation, encoding, decoding and transmission.
(iv) Ticket Lifetime
In Kerberos version 4, the ticket lifetime was 1280 minutes or 21 hours.
In Kerberos version 5, the ticket include start and end time, with arbitrary life period.
(v) Authentication forwarding
Kerberos version 4, does not allow credentials issued to one client to be forwarded to some
other host. For example, a client issues a request for print server that then access file server
for printing. The same credentials can not used for file server.
In Kerberos version 5, this problem has been resolved and provided with capabilities.
(2) Technical deficiencies.
(i) Double encryption
In Kerberos version 4, the ticket provided to client is encrypted twice, once with secret key of
the target server and again with client secret key.
In Kerberos version 5, the second encryption was found unnecessary.
(ii) Session key
In Kerberos version 4, session key is used repeatedly, client uses the session key to encrypt
the authenticator. Also client use the same key for message encryption during the session.
This is a risk. In Kerberos version 5, client-server negotiate using one secret key, and another
secret key is used for message transfer.