Cryptography: Module 4

MODULE 4:
X.509 CERTIFICATES
• 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

ud
directory to its users. The directory may serve as a repository of public-key certificates

• Eachcertificate contains the public key of a user and is signed with the private key of a
trusted certification authority. 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.

lo
• The X.509 certificate format is widely used, in for example S/MIME, IP Security and
SSL/TLS and SET. X.509 was initially issued in 1988. The standard was ubsequently
revisedto address some of the security concerns; a revised recommendation was issued in
C
1993. A third version was issued in 1995 and revised in 2000.
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 1

 Cryptography: Module 4

Certificates

The heart of the X.509 scheme is the public-key certificate associated with each user.
These user certificates are assumed to be created by some trusted certification authority (CA)
and placed in the directory by the CA or by the user. The directory server itself is not responsible
for the creation of public keys or for the certification function; it merely providesan easily
accessible location for users to obtain certificates.

ud
The standard uses the notation for a certificate of:

CA<<A>> where the CA signs the certificate for user A with its private key. In more
detail CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}.

If the corresponding public key is known to a user, then that user can verify that a
certificate signed by the CA is valid.

lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 2

 Cryptography: Module 4

Version: Differentiates among successive versions of the certificate format; the default isversion
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 unambiguouslyassociated
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

ud
the certificate, this field has little, if any, utility.
Issuer name: X.500 is the 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 isvalid.
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

lo
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 theissuing 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 thesubject
C
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 3and
are discussed later in this section.
Signature: Covers all of the other fields of the certificate; it contains the hash code of theother
tu

fields encrypted with the CA’s private key. This field includes the signature algorithm identifier.

The unique identifier fields were added in version 2 to handle the possible reuse of subject
and/or issuer names over time. These fields are rarely used. The standard uses the following notation
to define a certificate:
V

CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}

where
Y<< X >> = the certificate of user X issued by certification authority Y
Y {I} = the signing of I by Y. It consists of I with an encrypted hash
code appended
V = version of the certificate

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 3

 Cryptography: Module 4

SN = serial number of the certificate

AI = identifier of the algorithm used to sign the certificate
CA = name of certificate authority
UCA = optional unique identifier of the
CAA = name of user A
UA = optional unique identifier of the user
AAp = public key of user A

ud
TA = period of validity of the certificate

Obtaining a Certificate
User certificates generated by a CA have the following characteristics:
• Any user with access to the public key of the CA can verify the user public keythat was certified.
• No party other than the certification authority can modify the certificate without this being
detected.
lo
Because certificates are unforgeable, they can be placed in a directory without the need for the
directory to make special efforts to protect them.
If all users subscribe to the same CA, then there is a common trust of that CA. All user
C
certificates can be placed in the directory for access by all users. In addition, a user can transmit his
or her certificate directly to other users. In either case, once B is in possession ofA’s certificate, B has
confidence that messages it encrypts with A’s public key will be securefrom eavesdropping and that
messages signed with A’s private key are unforgeable.
tu

CA Hierarchy:

If both parties use the same CA, they know its public key and can verify others certificates. If
V

there is a large community of users, it may not be practical for all users to subscribe to the same CA.
Hence there has to be some means to form a chain of certificationsbetween the CA's used by the two
parties, by the use of client and parent certificates. All these certificates of CAs by CAs need to appear
in the directory, and the user needs to know how they are linked to follow a path to another user's
public-key certificate. X.509 suggests that CAs be arranged in a hierarchy so that navigation is
straightforward. It is assumed that each client trusts its parent’s certificates.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 4

 Cryptography: Module 4

ud
lo
C
Above Figure illustrates the use of an X.509 hierarchy to mutually verify clients
certificates. The connected circles indicate the hierarchical relationship among the CAs; the

associated boxes indicate certificates maintained in the directory for each CA entry. Thedirectory
tu

entry for each CA includes two types of certificates:

Forward certificates: Certificates of X generated by other CAs,

Reverse certificates: Certificates generated by X that are the certificates of other CAs.
V

In this example, we can track chains of certificates as follows:

A acquires B certificate using chain
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
B acquires A certificate using chain:
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 5

 Cryptography: Module 4

Certificate Revocation:
A certificate includes a period of validity. Typically a new certificate is issued just
before the expiration of the old one.
In addition, it may be desirable on occasion to revoke a certificate before it expires, for
one of a range of following reasons:
1. The user’s private key is assumed to be compromised.
2. The user is no longer certified by this CA. Reasons for this include that the subject’s

ud
name has changed, the certificate is superseded, or the certificate was not issued in
conformance with the CA’s policies.
3. The CA’s certificate is assumed to be compromised.
To support this, each CA must maintain a list consisting of all revoked but not expired
certificates issued by that CA, known as the certificate revocation list (CRL). Each certificate

lo
revocation list (CRL) posted to the directory is signed by the issuer and includes the issuer's
name, the date the listwas created, the date the next CRL is scheduled to be issued, and an entry
for each revoked certificate. Each entry consists of the serial number of a certificate and
revocation date for that certificate. Because serial numbers are unique within a CA, the serial
number is sufficient to identify the certificate.
C
When a user receives a certificate in a message, the user must determine whether the
certificate has been revoked, by checking the directory CRL each time a certificate is received,
this often does not happen in practice.
tu

X.509 Version 3
The X.509 version 2 format does not convey all of the information. Rather than continue
to add fields to a fixed format, standards developers felt that a more flexible approach was
V

needed. X.509 version 3 includes a number of optional extensions that may be added to the
version 2 format. Each extension consists of an extension identifier, a criticality indicator, and
an extension value. The criticality indicatorindicates whether an extension can be safely ignored
or not.

Certificate Extensions
The certificate extensions fall into three main categories:

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 6

 Cryptography: Module 4

• Key and policy information - convey additional information about the subject andissuer
keys, plus indicators of certificate policy. A certificate policy is a named set of rules that
indicates the applicability of a certificate to a particular community and/or class of
application with common security requirements.
• Subject and issuer attributes - support alternative names, in alternative formats, for a
certificate subject or certificate issuer and can convey additional information about the
certificate subject; eg. postal address, email address, or picture image

ud
• Certification path constraints - allow constraint specifications to be included in
certificates issued for CA’s by other CA’s that may restrict the types of certificates that can
be issued by the subject CA or that may occur subsequently in a certification chain.

lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 7

 Cryptography: Module 4

USER AUTHENTICATION

An authentication process consists of two steps:

• Identification step: Presenting an identifier to the security system. (Identifiersshould be

assigned carefully, because authenticated identities are the basis for other security services,
such as access control service.)

ud
• Verification step: Presenting or generating authentication information thatcorroborates the
binding between the entity and the identifier.”

In essence, identification is the means by which a user provides a claimed identity to the
system; user authentication is the means of establishing the validity of the claim. Note that user
authentication is distinct from message authentication.

or in combination:
lo
There are four general means of authenticating a user's identity, which can be usedalone

• Something the individual knows: Examples includes a password, a personalidentification

C
number (PIN), or answers to a prearranged set of questions.

• Something the individual possesses: Examples include electronic keycards, smartcards,

and physical keys. This type of authenticator is referred to as a token.
tu

• Something the individual is (static biometrics): Examples include recognition by

fingerprint, retina, and face.

• Something the individual does (dynamic biometrics): Examples include recognitionby

V

voice pattern, handwriting characteristics, and typing rhythm.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 8

 Cryptography: Module 4

All of these methods, properly implemented and used, can provide secure user
authentication. However, each method has problems. An adversary may be able to guess or steal
a password. Similarly, an adversary may be able to forge or steal a token. A user may forget a
password or lose a token. Further, there is a significant administrative overhead for managing
password and token information on systems and securing such information on systems. With
respect to biometric authenticators, there are a variety of problems, including dealing with false
positives and false negatives, user acceptance,cost, and convenience.

ud
Authentication Protocols

• An important application area is that of mutual authentication protocols. Such protocols

enable communicating parties to satisfy themselves mutually about each other'sidentity and to
exchange session keys. There, the focus was key distribution.
• Central to the problem of authenticated key exchange are two issues: confidentiality and

•
timeliness. lo
To prevent masquerade and to preventcompromise of session keys, essential identification and
session key information must be communicated in encrypted form. The second issue,
timeliness, is important because of the threat of message replays.
C
Replay Attacks: are where a valid signed message is copied and later resent. Such replays, at
worst, could allow an opponent to compromise a session key or successfully impersonate another
tu

party. At minimum, a successful replay can disrupt operations by presenting parties with messages
that appear genuine but are not.

Examples of replay attacks:

Simple replay: The opponent simply copies a message and replays it later.
V

Repetition that can be logged: An opponent can replay a timestamped message withinthe 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 thereplay message
arrives.

Backward replay without modification: This is a replay back to the message sender.This attack
Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 9
 Cryptography: Module 4

is possible if symmetric encryption is used and the sender cannot easily recognize the difference
between messages sent and messages received on the basis ofcontent.

Possible countermeasures include the use of:

• Sequence numbers (generally impractical since must remember last number used with every
communicating party)

• Timestamps (needs synchronized clocks amongst all parties involved, which can beproblematic)

ud
• Challenge/response (using unique, random, unpredictable nonce, but not suitable for
connectionless applications because of handshake overhead)

One-Way Authentication

One application for which encryption is growing in popularity is electronic mail (e-mail).

lo
The very nature of electronic mail, and its chief benefit, is that it is not necessary for the sender
and receiver to be online at the same time. Instead, the e-mail message is forwarded to the
receiver’s electronic mailbox, where it is buffered until the receiver is available to read it.
Accordingly, the e-mail message should be encrypted suchthat the mail- handling system is not in
C
possession of the decryption key. A second requirement is that of authentication. Typically, the
recipient wants some assurance that the message is from the alleged sender.
tu

REMOTE USER-AUTHENTICATION USING SYMMETRICENCRYPTION

Mutual Authentication

As discussed earlier, A two-level hierarchy of symmetric encryption keys can be used to

V

provide confidentiality for communication in a distributed environment. Usually involves the use
of a trusted key distribution center (KDC). Each party in the network shares a secret master key
with the KDC.

The KDC is responsible for generating session keys, and for distributing those keys to the
parties involved, using the master keys to protect these session keys.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 10

 Cryptography: Module 4

Needham-Schroeder Protocol

The Needham-Schroeder Protocol is the original, basic key exchange protocol. Used
by 2 parties who both trusted a common key server, it gives one party the info needed to
establish a session key with the other.

Note that all communications is between A&KDC and A&B, B&KDC don't talk

ud
directly (though indirectly a message passes from KDC via A to B, encrypted in B's key
so that A is unable to read or alter it). Other variations of key distribution protocols can
involve direct communications between B&KDC.

1. A→KDC: IDA || IDB || N1

3. A → B:
lo
2. KDC → A: E(Ka,[Ks || IDB||N1|| E(Kb,[Ks||IDA])])

E(Kb, [Ks||IDA])
C
4. B → A: E(Ks, [N2])

5. A → B: E(Ks, [f(N2)])
tu

Secret keys Ka and Kb are shared between A and the KDC and B and the KDC, respectively.
The purpose of the protocol is to distribute securely a session key Ks to A and B.

There is a critical flaw in the protocol, as shown. The message in step 3 can be
decrypted, and hence understood only by B. But if an opponent, X, has been able to
V

compromise an old session key, then X can impersonate A and trick B into using the old
key by simply replaying step 3. Admittedly, this is a much more unlikely occurrence than
that an opponent has simply observed and recorded step 3.

Denning proposes to overcome this weakness by a modification to the

Needham/Schroeder protocol that includes the addition of a timestamp to steps 2 and 3.
Her proposal assumes that the master keys, Ka and Kb are secure, and it consists of the
Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 11
 Cryptography: Module 4

following steps.

1. A→ KDC: IDA|| IDB

2. KDC→ A: E(Ka, [Ks || IDB || T || E(Kb, [Ks || IDA||T])])

3. A→ B: E(Kb, [Ks || IDA || T])

ud
4. B→A: E(Ks, N1)

5. A→B: E(Ks, f(N1))

T is a timestamp that assures A and B that the session key has only just been
generated. Thus, both A and B know that the key distribution is a fresh exchange.

lo
The Denning protocol seems to provide an increased degree of security compared
to the Needham/Schroeder protocol. However, a new concern is raised: namely, that this
new scheme requires reliance on clocks that are synchronized throughout the network. It
C
points out a risk involved. The risk is based on the fact that the distributed clocks can

become unsynchronized as a result of faults in the clocks or the synchronization

mechanism.
tu

The problem occurs when a sender’s clock is ahead of the intended recipient’s
clock. In this case, an opponent can intercept a message from the sender and replay it
later when the timestamp in the message becomes current at the recipient’s site. This replay
could cause unexpected results. Gong refers to such attacks as suppress-replay attacks.
V

REMOTE USER AUTHENTICATION USING ASYMMETRICENCRYPTION

Mutual Authentication

This protocol assumes that each ofthe two parties is in possession of the current

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 12

 Cryptography: Module 4

public key of the other. It may not be practical to require this assumption.

ud
A protocol using timestamps is provided in that uses a central system, referred to
as an authentication server (AS), because it is not actually responsible for secret key
distribution. Rather, the AS provides public-key certificates. The session key is chosen and
encrypted by A; hence, there is no risk of exposure by the AS. The timestampsprotect
against replays of compromised keys. See text for details. This protocol is compact but, as

lo
before, requires synchronization of clocks. Another approach, proposed by Woo and Lam,
makes use of nonces.
C
tu

Note the authors themselves spotted a flaw in it and submitted a revised version of
the algorithm in. In both this example and the protocols described earlier, protocols that
V

appeared secure were revised after additional analysis. These examples highlight the
difficulty of getting things right in the area of authentication.

One-Way Authentication

We have already presented public-key encryption approaches that are suited to

electronic mail, including the straightforward encryption of the entire message for

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 13

 Cryptography: Module 4

confidentiality, authentication, or both. These approaches require that either the sender
know the recipient's public key (confidentiality) or the recipient know the sender's public
key (authentication) or both (confidentiality plus authentication).

If confidentiality is the primary concern, then better to encrypt the message with a
one-time secret key, and also encrypt this one-time key with B's public key. If
authentication is the primary concern, then a digital signature may suffice (but could be

ud
replaced by an opponent). To counter such a scheme, both the message and signature can
be encrypted with the recipient's public key. The latter two schemes require that B know
A's public key and be convinced that it is timely. An effective way to provide this assurance
is the digital certificate.

KERBEROS (Important Topic) lo

Kerberos is an authentication service developed as part of Project Athena at MIT,
and is one of the best known and most widely implemented trusted third party key
C
distribution systems.

Kerberos provides a centralized authentication server whose function is to

authenticate users to servers and servers to users. Unlike most other authentication
tu

schemes, Kerberos relies exclusively on symmetric encryption, making no use of public-

key encryption. Two versions of Kerberos are in common use: v4 & v5.

In a more open environment, in which network connections to other machines are

V

supported, an approach that requires the user to prove his or her identity for each service
invoked, and also require that servers prove their identity to clients, is needed to protect
user information and resources housed at the server. Kerberos supports this approach, and
assumes a distributed client/server architecture that employs one or more Kerberos servers
to provide an authentication service. The first published report on Kerberos[STEI88] listed
the following requirements:

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 14

 Cryptography: Module 4

• Secure: A network eavesdropper should not be able to obtain the necessary information
to impersonate a user.

• Reliable: For all services that rely on Kerberos for access control, lack of availability of
the Kerberos service means lack of availability of the supported services. Hence,
Kerberos should be highly reliable and should employ a distributed server architecture,
with one system able to back up another.

ud
• Transparent: Ideally, the user should not be aware that authentication is taking place,
beyond the requirement to enter a password.

• Scalable: The system should be capable of supporting large numbers of clients and
servers. This suggests a modular, distributed architecture.

lo
To support these requirements, Kerberos is a trusted third-party authentication
service that uses a protocol based on that proposed by Needham and Schroeder which
was discussed earlier in this chapter.

The Version 4 Authentication Dialogue

C
➢ Kerberos V4 is a basic third-party authentication scheme.

➢ The core of Kerberos is the Authentication server (AS) and Ticket Granting
tu

Servers (TGS) – these are trusted by all users and servers and must be securely
administered.

➢ The protocol includes a sequence of interactions between the client, AS, TGT and
desired server. Version 4 of Kerberos makes use of DES, in a rather elaborate
V

protocol, to provide the authentication service

The heart of the first problem is the lifetime associated with the ticket-granting
ticket. If this lifetime is very short (e.g., minutes), then the user will be repeatedly asked for
a password. If the lifetime is long (e.g., hours), then an opponent has a greateropportunity
for replay. Similarly, if an opponent captures a service-granting ticket and uses it before it

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 15

 Cryptography: Module 4

expires, the opponent has access to the corresponding service.

The second problem is that there may be a requirement for servers to authenticate
themselves to users.

First, consider the problem of captured ticket-granting tickets and the need to
determine that the ticket presenter is the same as the client for whom the ticket was issued.
An efficient way of doing this is to use a session encryption key to secure information.

ud
Table 15.1a shows the technique for distributing the session key.

lo
C
tu
V

Table a shows the technique for distributing the session key. As before, the client
sends a message to the AS requesting access to the TGS. The AS responds with a message,

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 16

 Cryptography: Module 4

encrypted with a key derived from the user’s password (Kc) that contains the ticket. The
encrypted message also contains a copy of the session key,( Kc,tgs), where the subscripts
indicate that this is a session key for C and TGS. Because this session key is inside the
message encrypted with (Kc), only the user’s client can read it.The same session key is
included in the ticket, which can be read only by the TGS. Thus, the session key has been
securely delivered to both C and the TGS.

ud
Note that several additional pieces of information have been added to this first phase
of the dialogue. Message (1) includes a timestamp, so that the AS knows that the message
is timely. Message (2) includes several elements of the ticket in a form accessible to C.
This enables C to confirm that this ticket is for the TGS and to learn its expiration time.
Note that the ticket does not prove anyone's identity but is a way to distribute keys securely.
It is the authenticator that proves the client's identity.
lo
C sends the TGS a message that includes the ticket plus the ID of the requested
service (message (3) in Table b). In addition, C transmits an authenticator, which includes
the ID and address of C’s user and a timestamp. Unlike the ticket, which is reusable, the
C
authenticator is intended for use only once and has a very short lifetime. The TGS can
decrypt the ticket with the key that it shares with the AS. This ticket indicates that user C
has been provided with the session key Kc,tgs. In effect, the ticket says,“Anyone who uses
tu

Kc,tgs must be C.”The TGS uses the session key to decrypt the authenticator.

The reply from the TGS, in message (4), follows the form of message (2). C now
has a reusable service-granting ticket for V. When C presents this ticket, as shown in
message (5), it also sends an authenticator. The server can decrypt the ticket, recover the
V

session key, and decrypt the authenticator. If mutual authentication is required, the server
can reply as shown in message (6).

Finally, at the conclusion of this process, the client and server share a secret key.
This key can be used to encrypt future messages between the two or to exchange a new
random session key for that purpose.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 17

 Cryptography: Module 4

ud
lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 18

 Cryptography: Module 4

ud
lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 19

 Cryptography: Module 4

ud
lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 20

 Cryptography: Module 4

ud
KERBEROS REALMS:

A full-service Kerberos environment consisting of a Kerberos server, a number of

lo
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.
C
2. The Kerberos server must share a secret key with each server.All servers are registered
with the Kerberos server.

3. The Kerberos server in each interoperating realm shares a secret key with the server
tu

in the other realm. The two Kerberos servers are registered with each other.

A full-service Kerberos environment consisting of a Kerberos server, a number of

clients, and a number of application servers is referred to as a Kerberos realm. A Kerberos
realm is a set of managed nodes that share the same Kerberos database, and are part of the
V

same administrative domain. If have multiple realms, their Kerberos servers must share
keys and trust each other.

The details of the exchanges illustrated in below Figure are as follows

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 21

 Cryptography: Module 4

ud
lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 22

 Cryptography: Module 4

The Version 5 Authentication Dialogue

ud
lo
C
tu
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 23

 Cryptography: Module 4

• Message (1) is a client request for a ticket-granting ticket. As before, it includes the ID of the user
and the TGS. The following new elements are added:
• Realm: Indicates realm of user
• Options: Used to request that certain flags be set in the returned ticket
• Times: Used by the client to request the following time settings in the ticket:
—from: the desired start time for the requested ticket
—till: the requested expiration time for the requested ticket

ud
—rtime: requested renew-till time
• Nonce: A random value to be repeated in message (2) to assure that the response is fresh and
has not been replayed by an opponent.
• Message (2) returns a ticket-granting ticket, identifying information for the client, and a block
encrypted using the encryption key based on the user’s password. This block includes the session
key to be used between the client and the TGS, times specified in message (1), the nonce from

lo
message (1), and TGS identifying information. The ticket itself includes the session key,
identifying information for the client, the requested time values, and flags that reflect the status of
this ticket and the requested options. These flags introduce significant new functionality to version
5.
C
• Message (3) for both versions includes an authenticator, a ticket, and the name of the requested
service. In addition, version 5 includes requested times and options for the ticket and a nonce—
all with functions similar to those of message 1).
tu

• Message (4) has the same structure as message (2). It returns a ticket plus information needed by
the client, with the information encrypted using the session key now shared by the client and the
TGS.
• Finally, for the client/server authentication exchange, several new features appear in version 5. In
message (5), the client may request as an option that mutual authentication is required. The
V

authenticator includes several new fields:

• Subkey: The client’s choice for an encryption key to be used to protect this specific
application session. If this field is omitted, the session key from the ticket (Kc,v) is used.
• Sequence number: An optional field that specifies the starting sequence number to be used
by the server for messages sent to the client during this session. Messages may be sequence
numbered to detect replays.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 24

 Cryptography: Module 4

DIFFERENCES BETWEEN VERSIONS 4 AND 5

Version 5 is intended to address the limitations of version 4 in two areas: environmental

shortcomings and technical deficiencies.

Environmental shortcomings.

1. Encryption system dependence: Version 4 requires the use of DES. Export restrictionon DES
as well as doubts about the strength of DES were thus of concern. In version 5, ciphertext is tagged

ud
with an encryption-type identifier so that any encryption technique may be used.

2. Internet protocol dependence: Version 4 requires the use of Internet Protocol (IP) addresses.
Other address types, such as the ISO network address, are not accommodated. Version 5 network
addresses are tagged with type and length, allowing any network address type to be used.

3. Message byte ordering: In version 4, the sender of a message employs a byte orderingof its

lo
own choosing and tags the message to indicate least significant byte in lowest address or most
significant byte in lowest address. This techniques works but does not follow established
conventions. In version 5, all message structures are defined using Abstract Syntax Notation One
(ASN.1) andBasic Encoding Rules (BER), which provide an unambiguous byte ordering.
C
4. Ticket lifetime: Lifetime values in version 4 are encoded in an 8-bit quantity in units of five
minutes. Thus, the maximum lifetime that can be expressed is 28 * 5 = 1280 minutes (a little over
21 hours).This may be inadequate for some applications. In version 5, tickets include an explicit
tu

start time and end time, allowing tickets with arbitrary lifetimes.

5. Authentication forwarding: Version 4 does not allow credentials issued to one client to be
forwarded to some other host and used by some other client. This capability would enable a client
to access a server and have that server access another server on behalf of the client. For example,
V

a client issues a request to a print server that then accesses the client’s file from a file server, using
the client’s credentials for access. Version 5 providesthis capability.

6. Interrealm authentication: In version 4, interoperability among N realms requires on the order

of N2 Kerberos-to-Kerberos relationships, as described earlier. Version 5 supports a method that
requires fewer relationships, as described shortly.

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 25

 Cryptography: Module 4

Technical deficiencies:

1. Double encryption: Note in Table 15.1 [messages (2) and (4)] that tickets provided to clients
are encrypted twice - once with the secret key of the target server and then again with a secret key
known to the client. The second encryption is not necessary and is computationally wasteful.

2. PCBC encryption: Encryption in version 4 makes use of a nonstandard mode of DES known
as propagating cipher block chaining (PCBC).It has been demonstrated that this mode is vulnerable

ud
to an attack involving the interchange of ciphertext blocks. Version 5 provides explicit integrity
mechanisms, a checksum or hash code is attached to themessage prior to encryption using
CBC.

3. Session keys: Each ticket includes a session key that is used by the client to encryptthe
authenticator sent to the service associated with that ticket. In addition, the session key may

lo
subsequently be used by the client and the server to protect messages passed during that session.
However, because the same ticket may be used repeatedly to gain service from a particular server,
there is the risk that an opponent will replay messages from an old session to the client or the
server. In version 5, it is possible for a client and server to negotiate a subsession key, which is to
be used only for that one connection.
C
4. Password attacks: Both versions are vulnerable to a password attack. The message from the
AS to the client includes material encrypted with a key based on the client’s password. An
tu

opponent can capture this message and attempt to decrypt it by trying various passwords. If the
result of a test decryption is of the proper form, then the opponent has discovered the client’s
password and may subsequently use it to gain authentication credentials from Kerberos. Version
5 does provide a mechanism known as pre authentication, which should make password attacks
more difficult, but it does not prevent them.
V

Prof. Vidya H A, Dept. of ISE, SVIT, Bengaluru Page : 26