UNIT-IV

CNS NOTES

UNIT IV :
Key Management and distribution: Symmetric key distribution using Symmetric Encryption,
Symmetric key distribution using Asymmetric, Distribution of Public keys, X.509 Certificates,
Public key Infrastructure. User Authentication: Remote user Authentication Principles, Remote
user Authentication using Symmetric Encryption, Kerberos, Remote user Authentication using
Asymmetric Encryption, Federated Identity Management
Electronic mail security: Pretty Good Privacy (PGP), S/MIME
KEY MANAGEMENT AND DISTRIBUTION:
The topics of cryptographic key management and cryptographic key distribution are
complex, involving cryptographic, protocol, and management considerations.
SYMMETRIC KEY DISTRIBUTION USING SYMMETRIC ENCRYPTION:

For symmetric encryption to work, the two parties to an exchange must share the same
key, and that key must be protected from access by others. Furthermore, frequent key changes
are usually desirable to limit the amount of data compromised if an attacker learns the key.
Therefore, the strength of any cryptographic system rests with the key distribution
technique, a term that refers to the means of delivering a key to two parties who wish to
exchange data without allowing others to see the key. For two parties A and B, key distribution
can be achieved in a number of ways, as follows:
1. A can select a key and physically deliver it to B.
2. A third party can select the key and physically deliver it to A and B.
3. If A and B have previously and recently used a key, one party can transmit the
new key to the other, encrypted using the old key.
4. If A and B each has an encrypted connection to a third party C, C can deliver a key on the
encrypted links to A and B.
However, for end-to-end encryption over a network, manual delivery is awkward. In a
distributed system, any given host or terminal may need to engage in exchanges with many other
hosts and terminals over time. Thus, each device needs a number of keys supplied dynamically.
If encryption is done at the application level, then a key is needed for every pair of users or
processes that require communication.
For each end system or user, there is a unique master key that it shares with the key
distribution center. Of course, these master keys must be distributed in some fashion.

Dept. Of CSE, MeRITS

Page 1

UNIT-IV

CNS NOTES

A Key Distribution Scenario:

The key distribution concept can be deployed in a number of ways. A typical scenario is
illustrated in the following Figure which is based on a figure the scenario assumes that each user
shares a unique master key with the key distribution center (KDC).

Let us assume that user A wishes to establish a logical connection with B and requires a
one-time session key to protect the data transmitted over the connection. A has a master key Ka ,
known only to itself and the KDC; similarly, B shares the master key Kb with the KDC.The
following steps occur.
1.A issues a request to the KDC for a session key to protect a logical connection to B.The
message includes the identity of A and B and a unique identifier,N1 , for this transaction, which
we refer to as a nonce. The nonce may be a timestamp, a counter, or a random number; the
minimum requirement is that it differs with each request. Also, to prevent masquerade, it should
be difficult for an opponent to guess the nonce. Thus, a random number is a good choice for a
nonce.
2. The KDC responds with a message encrypted using Ka. Thus, A is the only one who can
successfully read the message, and A knows that it originated at the KDC.
The message includes two items intended for A:
The one-time session key,Ks , to be used for the session
The original request message, including the nonce, to enable A to match this response with the
appropriate request. Thus, A can verify that its original request was not altered before reception
by the KDC and, because of the nonce, that this is not a replay of some previous request.
3. A stores the session key for use in the upcoming session and forwards to B the information
that originated at the KDC for B, namely E(Kb,[Ks IDA]). Because this information is
encrypted with Kb it is protected from eavesdropping. B now knows the session key (Ks) knows
that the other party is A (from IDA), and knows that the information originated at the KDC
(because it is encrypted using Kb).
Dept. Of CSE, MeRITS

Page 2

UNIT-IV

CNS NOTES

Hierarchical Key Control:

It is not necessary to limit the key distribution function to a single KDC. Indeed, for very
large networks, it may not be practical to do so.As an alternative, a hierarchy of KDCs can be
established. For example, there can be local KDCs, each responsible for a small domain of the
overall internetwork, such as a single LAN or a single building.
A hierarchical scheme minimizes the effort involved in master key distribution, because
most master keys are those shared by a local KDC with its local entities. Furthermore, such a
scheme limits the damage of a faulty or subverted KDC to its local area only.
Session Key Lifetime:
The more frequently session keys are exchanged, the more secure they are, because the
opponent has less cipher text to work with for any given session key. On the other hand, the
distribution of session keys delays the start of any exchange and places a burden on network
capacity.
A security manager must try to balance these competing considerations in determining
the lifetime of a particular session key. If a logical connection has a very long lifetime, then it
would be prudent to change the session key periodically. For a connectionless protocol, such as a
transaction-oriented protocol, there is no explicit connection initiation or termination.
A Transparent Key Control Scheme:
The scheme is useful for providing end-to end encryption at a network or transport level
in a way that is transparent to the end users. The approach assumes that communication makes
use of a connection-oriented end-to-end protocol, such as TCP. The noteworthy element of this
approach is a session security module (SSM), which may consist of functionality at one protocol
layer , that performs end-to-end encryption and obtains session keys on behalf of its host or
terminal.

Dept. Of CSE, MeRITS

Page 3

UNIT-IV

CNS NOTES

The steps involved in establishing a connection are shown in the following fig: When
one host wishes to set up a connection to another host, it transmits a connection- request packet
The SSM saves that packet and applies to the KDC for permission to establish the connection.
The communication between the SSM and the KDC is encrypted using a master key shared only
by this SSM and the KDC. If the KDC approves the connection request,
It generates the session key and delivers it to the two appropriate SSMs, using a unique
permanent key for each SSM. The requesting SSM can now release the connection request
packet, and a connection is set up between the two end systems .All user data exchanged
between the two end systems are encrypted by their respective SSMs using the onetime session
key.
Decentralized Key Control:
The use of a key distribution center imposes the requirement that the KDC be trusted and
be protected from subversion. This requirement can be avoided if key distribution is fully
decentralized. Although full decentralization is not practical for larger networks using symmetric
encryption only, it may be useful within a local context.
A session key may be established with the following sequence of steps:
1. A issues a request to B for a session key and includes a nonce, N1 .
2. B responds with a message that is encrypted using the shared master key. The response
includes the session key selected by B, an identifier of B, the value f(N1) and another nonce,
N2. 3. Using the new session key,A returns f(N2) to B.

X.509 CERTIFICATES:
Dept. Of CSE, MeRITS

Page 4

UNIT-IV

CNS NOTES

ITU-T recommendation X.509 is part of the X.500 series of recommendations that

define a directory service. The directory is, in effect, a server or distributed set of servers that
maintains a database of information about users. The information includes a mapping from user
name to network address, as well as other attributes and information about the users.
X.509 defines a framework for the provision of authentication services by the X.500
directory to its users. X.509 defines alternative authentication protocols based on the use of
public-key certificates. X.509 is an important standard because the certificate structure and
authentication protocols defined in X.509 are used in a variety of contexts

X.509 is based on the use of public-key cryptography and digital signatures. The standard
does not dictate the use of a specific algorithm but recommends RSA.The digital signature
scheme is assumed to require the use of a hash function. Again, the standard does not dictate a
specific hash algorithm.
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.
The following fig: shows the general format of a certificate, which includes the
following elements

Dept. Of CSE, MeRITS

Page 5

UNIT-IV

CNS NOTES

Version: Differentiates among successive versions of the certificate format; the default is
version 1. If the issuer unique identifier or subject unique identifier are present, the value must
be version 2. If one or more extensions are present, the version must be version 3.
Serial number: An integer value unique within the issuing CA that is unambiguously
associated with this certificate.
Signature algorithm identifier: The algorithm used to sign the certificate together with any
associated parameters. Because this information is repeated in the signature field at the end of the
certificate, this field has little, if any, utility.
Issuer name: X.500 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 is valid.
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.
Subjects public-key information: The public key of the subject, plus an identifier of the
algorithm for which this key is to be used, together with any associated parameters.
Issuer unique identifier: An optional-bit string field used to identify uniquely the issuing CA
in the event the X.500 name has been reused for different entities.
Subject unique identifier: An optional-bit string field used to identify uniquely the subject in
the event the X.500 name has been reused for different entities.
Extensions: A set of one or more extension fields. Extensions were added in version 3 and are
discussed later in this section.
Dept. Of CSE, MeRITS

Page 6

UNIT-IV

CNS NOTES

Signature: Covers all of the other fields of the certificate; it contains the hash code of the other
fields encrypted with the CAs 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:
CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}

OBTAINING A USERS 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 key that was
certified.
No party other than the certification authority can modify the certificate without this being
detected. If all users subscribe to the same CA, then there is a common trust of that CA. All user
certificates can be placed in the directory for access by all users.
X.509 Version 3:
The X.509 version 2 format does not convey all of the information that recent design and
implementation experience has shown to be needed. [FORD95] lists the following requirements
not satisfied by version 2.
1. The subject field is inadequate to convey the identity of a key owner to a public-key user.
X.509 names may be relatively short and lacking in obvious identification details that may be
needed by the user.
2. The subject field is also inadequate for many applications, which typically recognize entities
by an Internet e-mail address, a URL,or some other Internet-related identification.
3. There is a need to indicate security policy information.This enables a security application or
function, such as IPSec, to relate an X.509 certificate to a given policy.
4. There is a need to limit the damage that can result from a faulty or malicious CA by setting
constraints on the applicability of a particular certificate.
5. It is important to be able to identify different keys used by the same owner at different times.
This feature supports key lifecycle management: in particular, the ability to update key pairs for
users and CAs on a regular basis or under exceptional circumstances.
Dept. Of CSE, MeRITS

Page 7

UNIT-IV

CNS NOTES

PUBLIC-KEY INFRASTRUCTURE:
The principal objective for developing a PKI is to enable secure, convenient, and
efficient acquisition of public keys. The Internet Engineering Task Force (IETF) Public Key
Infrastructure X.509 (PKIX) working group has been the driving force behind setting up a formal
(and generic) model based on X.509 that is suitable for deploying a certificate-based architecture
on the Internet.
The following figure shows the interrelationship among the key elements of the PKIX
model.These elements are:
End entity: A generic term used to denote end users, devices (e.g., servers, routers), or any
other entity that can be identified in the subject field of a public key certificate. End entities
typically consume and/or support PKI-related services.
Certification authority (CA): The issuer of certificates and (usually) certificate revocation
lists (CRLs). It may also support a variety of administrative functions, although these are often
delegated to one or more Registration Authorities.
Registration authority (RA): An optional component that can assume a number of
administrative functions from the CA.The RA is often associated with the end entity registration
process but can assist in a number of other areas as well.
CRL issuer: An optional component that a CA can delegate to publish CRLs.
Repository: A generic term used to denote any method for storing certificates and CRLs so
that they can be retrieved by end entities.

Dept. Of CSE, MeRITS

Page 8

UNIT-IV

CNS NOTES

PKIX Management Functions:

PKIX identifies a number of management functions that potentially need to be supported
by management protocols. These are indicated in Figure 14.16 and include the following:
Registration: This is the process whereby a user first makes itself known to a CA (directly or
through an RA), prior to that CA issuing a certificate or certificates for that user.
Registration begins the process of enrolling in a PKI. Registration usually involves some
offline or online procedure for mutual authentication. Typically, the end entity is issued one or
more shared secret keys used for subsequent authentication.
Initialization: Before a client system can operate securely, it is necessary to install key
materials that have the appropriate relationship with keys stored elsewhere in the infrastructure.
For example, the client needs to be securely initialized with the public key and other assured
information of the trusted CA(s), to be used in validating certificate paths.
Certification: This is the process in which a CA issues a certificate for a users public key,
returns that certificate to the users client system, and/or posts that certificate in a repository.
Key pair recovery: Key pairs can be used to support digital signature creation and verification,
encryption and decryption, or both.When a key pair is used for encryption/decryption, it is
important to provide a mechanism to recover the necessary decryption keys when normal access
to the keying material is no longer possible, otherwise it will not be possible to recover the
encrypted data
Key pair update: All key pairs need to be updated regularly (i.e., replaced with a new key
pair) and new certificates issued. Update is required when the certificate lifetime expires and as a
result of certificate revocation.
Revocation request: An authorized person advises a CA of an abnormal situation requiring
certificate revocation. Reasons for revocation include privatekey compromise, change in
affiliation, and name change.
Cross certification: Two CAs exchange information used in establishing a cross-certificate.A
cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key
used for issuing certificates.
PKIX Management Protocols:
The PKIX working group has defines two alternative management protocols between
PKIX entities that support the management functions listed in the preceding subsection. RFC
2510 defines the certificate management protocols (CMP). Within CMP, each of the management
functions is explicitly identified by specific protocol exchanges. CMP is designed to be a flexible
protocol able to accommodate a variety of technical, operational, and business models.
REMOTE USER-AUTHENTICATION PRINCIPLES:
Dept. Of CSE, MeRITS

Page 9

UNIT-IV

CNS NOTES

This topic is concerned solely with user authentication.

There are four general means of authenticating a users identity, which can be used alone or in
combination:
Something the individual knows: Examples include a password, a personal identification
number (PIN), or answers to a prearranged set of questions.
Something the individual possesses: Examples include cryptographic keys, electronic
keycards, smart cards, and physical keys. This type of authenticator is referred to as a token.
Something the individual is (static biometrics): Examples include recognition by fingerprint,
retina, and face.
Something the individual does (dynamic biometrics): Examples include recognition by voice
pattern, handwriting characteristics, and typing rhythm. 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.
Mutual Authentication:
An important application area is that of mutual authentication protocols. Such protocols
enable communicating parties to satisfy themselves mutually about each others identity and to
exchange session keys. Central to the problem of authenticated key exchange are two issues:
confidentiality and timeliness.
To prevent masquerade and to prevent compromise of session keys, essential
identification and session-key information must be communicated in encrypted form. This
requires the prior existence of secret or public keys that can be used for this purpose.The second
issue, timeliness, is important because of the threat of message replays.
The following are the examples of replay attacks:
Simple replay: The opponent simply copies a message and replays it later.
Repetition that can be logged: An opponent can replay a timestamped message within the
valid time window.
Repetition that cannot be detected: This situation could arise because the original message
could have been suppressed and thus did not arrive at its destination; only the replay message
arrives.
Backward replay without modification: This is a replay back to the message sender. This
attack is possible if symmetric encryption is used and the sender cannot easily recognize the
difference between messages sent and messages received on the basis of content.
One of the following two general approaches is used:
Timestamps: Party A accepts a message as fresh only if the message contains a
timestamp that, in As judgment, is close enough to As knowledge of current time. This
approach requires that clocks among the various participants be synchronized.
Challenge/response: Party A, expecting a fresh message from B, first sends B a
nonce (challenge) and requires that the subsequent message (response) received from B contain
the correct nonce value.

One-Way Authentication:
Dept. Of CSE, MeRITS

Page 10

UNIT-IV

CNS NOTES

One application for which encryption is growing in popularity is electronic mail (e-mail).
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
receivers electronic mailbox, where it is buffered until the receiver is available to read it.
The envelope or header of the e-mail message must be in the clear, so that the message
can be handled by the store-and-forward e-mail protocol, such as the Simple Mail Transfer
Protocol (SMTP) or X.400. However, it is often desirable that the mail-handling protocol not
require access to the plaintext form of the message, because that would require trusting the mailhandling mechanism.
Accordingly, the e-mail message should be encrypted such that the mail-handling system
is not in 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.
REMOTE USER-AUTHENTICATION USING SYMMETRIC ENCRYPTION:
Mutual Authentication:
It includes authentication features. The protocol can be summarized as follows:

The master keys Ka and Kb, are secure, and it consists of the following steps:

Dept. Of CSE, MeRITS

Page 11

UNIT-IV

CNS NOTES

An opponent can intercept a message from the sender and replay it later when the
timestamp in the message becomes current at the recipients site.This replay could cause
unexpected results. Gong refers to such attacks as suppress-replay attacks.
One way to counter suppress-replay attacks is to enforce the requirement that parties
regularly check their clocks against the KDCs clock. The other alternative, which avoids the
need for clock synchronization, is to rely on handshaking protocols using nonces.
In an attempt is made to respond to the concerns about suppress replay attacks and at the same
time fix the problems in the Needham/Schroeder protocol.

Let us follow this exchange step by step:

1. A initiates the authentication exchange by generating a nonce,Na , and sending that plus its
identifier to B in plaintext. This nonce will be returned to A in an encrypted message that
includes the session key, assuring A of its timeliness.
2. B alerts the KDC that a session key is needed. Its message to the KDC includes its identifier
and a nonce,Nb . This nonce will be returned to B in an encrypted message that includes the
session key, assuring B of its timeliness.Bs message to the KDC also includes a block
encrypted with the secret key shared by B and the KDC.This block is used to instruct the KDC
to issue credentials to A; the block specifies the intended recipient of the credentials, a suggested
expiration time for the credentials, and the nonce received from A.
3. The KDC passes on to A Bs nonce and a block encrypted with the secret key that B shares
with the KDC.The block serves as a ticket that can be used by A for subsequent
authentications, as will be seen.The KDC also sends to A a block encrypted with the secret key
shared by A and the KDC.This block verifies that B has received As initial message ( IDb) and
that this is a timely message and not a replay ( Na), and it provides A with a session key (Ks )
and the time limit on its use (Tb ).
4. A transmits the ticket to B, together with the Bs nonce, the latter encrypted with the session
key. The ticket provides B with the secret key that is used to decrypt E(Ks, Nb) to recover the
nonce. The fact that Bs nonce is encrypted with the session key authenticates that the message
came from A and is not a replay.

Dept. Of CSE, MeRITS

Page 12

UNIT-IV

CNS NOTES

One-Way Authentication:
Using symmetric encryption, the decentralized key distribution scenario illustrated in
Figure is impractical. This scheme requires the sender to issue a request to the intended recipient,
await a response that includes a session key, and only then send the message. With some
refinement, the KDC strategy illustrated in Figure is a candidate for encrypted electronic mail.
Because we wish to avoid requiring that the recipient (B) be on line at the same time as the
sender (A), steps 4 and 5 must be eliminated. For a message with M content , the sequence is as
follows:

This approach guarantees that only the intended recipient of a message will be able to
read it. It also provides a level of authentication that the sender is A. As specified, the protocol
does not protect against replays.

KERBEROS:
Kerberos is an authentication service developed as part of Project Athena at MIT. The
problem that Kerberos addresses is this: Assume an open distributed environment in which users
at workstations wish to access services on servers distributed throughout the network.
In this environment, a workstation cannot be trusted to identify its users correctly to network
services. In particular, the following three threats exist:
1. A user may gain access to a particular workstation and pretend to be another user operating
from that workstation.
2. 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 workstation.
3. 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
data that he or she is not authorized to access. Rather than building in elaborate authentication
protocols at each server, Kerberos provides a centralized authentication server whose function is
to authenticate users to servers and servers to users. Unlike most other authentication schemes
described in this book,
Kerberos relies exclusively on symmetric encryption, making no use of public-key encryption.
Two versions of Kerberos are in common use. Version 4 implementations still exist.
Version 5 corrects some of the security deficiencies of version 4 and has been issued as a
proposed Internet Standard.

Dept. Of CSE, MeRITS

Page 13

UNIT-IV

CNS NOTES

Motivation:
If a set of users is provided with dedicated personal computers that have no network
connections, then a users resources and files can be protected by physically securing each
personal computer.
When these users instead are served by a centralized timesharing system, the timesharing operating system must provide the security. The operating system can enforce accesscontrol policies based on user identity and use the logon procedure to identify users.
In this environment, three approaches to security can be envisioned.
1. Rely on each individual client workstation to assure the identity of its user or users and rely on
each server to enforce a security policy based on user identification (ID).
2. Require that client systems authenticate themselves to servers, but trust the client system
concerning the identity of its user.
3. Require the user to prove his or her identity for each service invoked. Also require that servers
prove their identity to clients.
Kerberos assumes a distributed client/server architecture and employs one or more
Kerberos servers to provide an authentication service.
The first published report on Kerberos listed the following requirements:
Secure: A network eavesdropper should not be able to obtain the necessary information to
impersonate a user. More generally,Kerberos should be strong enough that a potential opponent
does not find it to be the weak link.
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.
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.
Kerberos Version 4:
Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide the
authentication service.
A SIMPLE AUTHENTICATION DIALOGUE:
In an unprotected network environment, any client can apply to any server for service.
The obvious security risk is that of impersonation. An opponent can pretend to be another client
and obtain unauthorized privileges on server machines. To counter this threat, servers must be
able to confirm the identities of clients who request service.
An alternative is to use an authentication server (AS) that knows the passwords of all
users and stores these in a centralized database.

Dept. Of CSE, MeRITS

Page 14

UNIT-IV

CNS NOTES

where
C
= client
AS = authentication server
V = server
IDC = identifier of user on C

In this scenario, the user logs on to a workstation and requests access to server V. The
client module C in the users workstation requests the users password and then sends a message
to the AS that includes the users ID, the servers ID, and the users password. The AS checks its
database to see if the user has supplied the proper password for this user ID and whether this user
is permitted access to server V. If both tests are passed, the AS accepts the user as authentic and
must now convince the server that this user is authentic.To do so, the AS creates a ticket that
contains the users ID and network address and the servers ID. This ticket is encrypted using the
secret key shared by the AS and this server.This ticket is then sent back to C. Because the ticket
is encrypted, it cannot be altered by C or by an opponent.
The second problem is that the earlier scenario involved a plaintext transmission of the
password [message (1)]. An eavesdropper could capture the password and use any service
accessible to the victim. To solve these additional problems, we introduce a scheme for avoiding
plaintext passwords and a new server, known as the ticket-granting server (TGS). The new (but
still hypothetical) scenario is as follows.

Dept. Of CSE, MeRITS

Page 15

UNIT-IV

CNS NOTES

The client saves each service-granting ticket and uses it to authenticate its user to a server
each time a particular service is requested. Let us look at the details of this scheme:
1. The client requests a ticket-granting ticket on behalf of the user by sending its users ID 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 users
password ( ), which is already stored at the AS.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.
Now that the client has a ticket-granting ticket, access to any server can be obtained with steps
3 and 4:
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 users ID, the ID of the desired service, and the
ticket-granting ticket.
4. The TGS decrypts the incoming ticket using a key shared only by the AS and the TGS ( ) 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.
Finally, with a particular service-granting ticket, the client can gain access to the
corresponding service with step 5.
5. The client requests access to a service on behalf of the user. For this purpose, the client
transmits a message to the server containing the users ID and the service-granting ticket. The
server authenticates by using the contents of the ticket.
THE VERSION 4 AUTHENTICATION DIALOGUE:
Although the foregoing scenario enhances security compared to the first attempt, two
additional problems remain. 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 greater
opportunity for replay.
An opponent could eavesdrop on the network and capture a copy of the ticket-granting
ticket and then wait for the legitimate user to log out. Then the opponent could forge the
legitimate users network address and send the message of step (3) to the TGS. This would give
the opponent unlimited access to the resources and files available to the legitimate user.
Similarly, if an opponent captures a service-granting ticket and uses it before it expires,
the opponent has access to the corresponding service.

Dept. Of CSE, MeRITS

Page 16

UNIT-IV

CNS NOTES

The second problem is that there may be a requirement for servers to authenticate
themselves to users.Without such authentication, an opponent could sabotage the configuration
so that messages to a server were directed to another location.The false server would
then be in a position to act as a real server and capture any information from the user and deny
the true service to the user.

Dept. Of CSE, MeRITS

Page 17

UNIT-IV

Dept. Of CSE, MeRITS

CNS NOTES

Page 18

UNIT-IV

Dept. Of CSE, MeRITS

CNS NOTES

Page 19

UNIT-IV

CNS NOTES

KERBEROS REALMS AND MULTIPLE KERBERI:

A full-service Kerberos environment consisting of a Kerberos server, a number of
clients, and a number of application servers requires the following:
1. The Kerberos server must have the user ID and hashed passwords of all participating
users in its database. All users are registered with the Kerberos server.
2. The Kerberos server must share a secret key with each server.All servers are registered with
the Kerberos server.
Such an environment is referred to as a Kerberos realm. The concept of realm can be
explained as follows.
Dept. Of CSE, MeRITS

Page 20

UNIT-IV

CNS NOTES

A Kerberos realm is a set of managed nodes that share the same Kerberos database. The
Kerberos database resides on the Kerberos master computer system, which should be kept in a
physically secure room. A read-only copy of the Kerberos database might also reside on other
Kerberos computer systems.
However, all changes to the database must be made on the master computer system.
Changing or accessing the contents of a Kerberos database requires the Kerberos master
password. A related concept is that of a Kerberos principal, which is a service or user that is
known to the Kerberos system. Each Kerberos principal is identified by its principal name.
Principal names consist of three parts: a service or user name, an instance name, and a realm
name.

Kerberos provides a mechanism for supporting such interrealm authentication. For two
realms to support interrealm authentication, a third requirement is added:
3. The Kerberos server in each interoperating realm shares a secret key with the server in the
other realm.The two Kerberos servers are registered with each other

Dept. Of CSE, MeRITS

Page 21

UNIT-IV

CNS NOTES

A user wishing service on a server in another realm needs a ticket for that server.The
users client follows the usual procedures to gain access to the local TGS and then requests a
ticket-granting ticket for a remote TGS (TGS in another realm).The client can then apply to the
remote TGS for a service-granting ticket for the desired server in the realm of the remote TGS.

Dept. Of CSE, MeRITS

Page 22

UNIT-IV

CNS NOTES

Kerberos Version 5:
Kerberos version 5 is specified in RFC 4120 and provides a number of improvements
over version 4 To begin, we provide an overview of the changes from version 4 to version 5 and
then look at the version 5 protocol.
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. Let
us briefly summarize the improvements in each area.
This led to the following environmental shortcomings:
1.Encryption system dependence: Version 4 requires the use of DES. Export restriction on
DES as well as doubts about the strength of DES were thus of concern. In version 5, ciphertext is
tagged 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 ordering of its
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) and Basic
Encoding Rules (BER), which provide an unambiguous byte ordering.
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 minutes (a little over 21 hours).
This may be inadequate for some applications (e.g., a long-running simulation that
requires valid Kerberos credentials throughout execution). In version 5, tickets include an
explicit 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, a client issues a request to a print server that then accesses the clients file
from a file server, using the clients credentials for access.Version 5 provides this capability.
6. Interrealm authentication: In version 4, interoperability among realms requires on the order
of Kerberos-to-Kerberos relationships, as described earlier.

Dept. Of CSE, MeRITS

Page 23

UNIT-IV

CNS NOTES

First, consider the authentication service exchange. 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
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
Let us now compare the ticket-granting service exchange for versions 4 and 5.We see
that 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
nonceall with functions similar to those of message (1).

Dept. Of CSE, MeRITS

Page 24

UNIT-IV

CNS NOTES

The authenticator itself is essentially the same as the one used in version 4. 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 authenticator includes several new fields:
Subkey: The clients 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 (K c,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.

Dept. Of CSE, MeRITS

Page 25

UNIT-IV

CNS NOTES

REMOTE USER AUTHENTICATION USING ASYMMETRIC ENCRYPTION:

Mutual Authentication:
we used one approach to the use of public-key encryption for the purpose of session-key
distribution.. This protocol assumes that each of the two parties is in possession of the current
public key of the other. It may not be practical to require this assumption.
A protocol using timestamps is provided as follows:

In this case, the central system is 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 timestamps protect against replays of compromised keys.
The protocol consists of the following steps.

Dept. Of CSE, MeRITS

Page 26

UNIT-IV

CNS NOTES

One-Way Authentication:
public-key encryption approaches that are suited to electronic mail, including the
straightforward encryption of the entire message for confidentiality authentication or both.
If confidentiality is the primary concern, then the following may be more efficient:

This method guarantees that A cannot later deny having sent the message. However, this
technique is open to another kind of fraud. Bob composes a message to his boss Alice that
contains an idea that will save the company money. He appends his digital signature and sends it
into the e-mail system. Eventually, the message will get delivered to Alices mailbox. But
suppose that Max has heard of Bobs idea and gains access to the mail queue before delivery. He
finds Bobs message, strips off his signature, appends his, and requeues the message to be
delivered to Alice. Max gets credit for Bobs idea.
Dept. Of CSE, MeRITS

Page 27

UNIT-IV

CNS NOTES

FEDERATED IDENTITY MANAGEMENT:

Federated identity management is a relatively new concept dealing with the use of a
common identity management scheme across multiple enterprises and numerous applications and
supporting many thousands, even millions, of users
Identity Management:
Identity management is a centralized, automated approach to provide enterprise wide
access to resources by employees and other authorized individuals. The focus of identity
management is defining an identity for each user (human or process), associating attributes with
the identity, and enforcing a means by which a user can verify identity. The central concept of an
identity management system is the use of single sign-on (SSO). SSO enables a user to access all
network resources after a single authentication.
It lists the following as the principal elements of an identity management system:
Authentication: Confirmation that a user corresponds to the user name provided.
Authorization: Granting access to specific services and/or resources based on the
authentication.
Accounting: A process for logging access and authorization.
Provisioning: The enrollment of users in the system.
Workflow automation: Movement of data in a business process.
Delegated administration: The use of role-based access control to grant permissions.
Password synchronization: Creating a process for single sign-on (SSO) or reduced sign-on
(RSO). Single sign-on enables a user to access all network resources after a single authentication.
RSO may involve multiple sign-ons but requires less user effort than if each resource and service
maintained its own authentication facility.
Self-service password reset: Enables the user to modify his or her password.
Federation: A process where authentication and permission will be passed on from one system
to anotherusually across multiple enterprises, thereby reducing the number of authentications
needed by the user.
A principal is an identity holder: Typically, this is a human user that seeks access to
resources and services on the network
User devices, agent processes, and server systems may also function as principals.
Principals authenticate themselves to an identity provider. The identity provider associates
authentication information with a principal, as well as attributes and one or more identifiers.
An attribute service manages the creation and maintenance of such attributes. For
example, a user needs to provide a shipping address each time an order is placed at a new Web
merchant, and this information needs to be revised when the user moves.

Dept. Of CSE, MeRITS

Page 28

UNIT-IV

CNS NOTES

Data consumers are entities that obtain and employ data maintained and provided by
identity and attribute providers, which are often used to support authorization decisions and to
collect audit information.
Administrators may also assign attributes to users, such as roles, access permissions,
and employee information.
The following fig: illustrates entities and data flows in a generic identity management
architecture.

Identity Federation:
Identity federation is, in essence, an extension of identity management to multiple
security domains. Such domains include autonomous internal business units, external business
partners, and other third-party applications and services.The goal is to provide the sharing of
digital identities so that a user can be authenticated a single time and then access applications and
resources across multiple domains. Because these domains are relatively autonomous or
independent, no centralized control is possible.
Federated identity management refers to the agreements, standards, and technologies that
enable the portability of identities, identity attributes, and entitlements across multiple
enterprises and numerous applications and supporting many thousands, even millions, of users.
Another key function of federated identity management is identity mapping. Different
security domains may represent identities and attributes differently.
The following Figure illustrates entities and data flows in a generic federated identity
management architecture.

Dept. Of CSE, MeRITS

Page 29

UNIT-IV

CNS NOTES

The identity provider acquires attribute information through dialogue and protocolex
changes with users and administrators. For example, a user needs to provide a shipping address
each time an order is placed at a new Web merchant, and this information needs to be revised
when the user moves. Identity management enables the user to provide this information once, so
that it is maintained in a single place and released to data consumers in accordance with
authorization and privacy policies.
Service providers are entities that obtain and employ data maintained and provided by
identity providers, often to support authorization decisions and to collect audit information.
STANDARDS :
Federated identity management uses a number of standards as the building blocks for
secure identity exchange across different domains or heterogeneous systems. In essence,
organizations issue some form of security tickets for their users that can be processed by
cooperating partners.
Identity federation standards are thus concerned with defining these tickets, in terms of
content and format, providing protocols for exchanging tickets and performing a number of
management tasks. These tasks include configuring systems to perform attribute transfers and
identity mapping, and performing logging and auditing functions.

Dept. Of CSE, MeRITS

Page 30

UNIT-IV

CNS NOTES

PRETTY GOOD PRIVACY:

PGP is a remarkable phenomenon. Largely the effort of a single person, Phil
Zimmermann, PGP provides a confidentiality and authentication service that can be used for
electronic mail and file storage applications.
In essence, Zimmermann has done the following:
1. Selected the best available cryptographic algorithms as building blocks.
2. Integrated these algorithms into a general-purpose application that is independent
of operating system and processor and that is based on a small set of
easy-to-use commands.
3. Made the package and its documentation, including the source code, freely
available via the Internet, bulletin boards, and commercial networks such as
AOL (America On Line).
4. Entered into an agreement with a company (Viacrypt, now Network Associates) to provide a
fully compatible, low-cost commercial version of PGP.

Dept. Of CSE, MeRITS

Page 31

UNIT-IV

CNS NOTES

Operational Description:
The actual operation of PGP, as opposed to the management of keys, consists of four
services: authentication, confidentiality, compression, and e-mail compatibility.
AUTHENTICATION : The following figure illustrates the digital signature service provided by
PGP. The sequence is as follows
1. The sender creates a message.
2. SHA-1 is used to generate a 160-bit hash code of the message.
3. The hash code is encrypted with RSA using the senders private key, and the result is
prepended to the message. 4. The receiver uses RSA with the senders public key to
decrypt and recover the hash code. 5. The receiver generates a new hash code for the
message and compares it with the decrypted hash code. If the two match, the message is
accepted as authentic.

Dept. Of CSE, MeRITS

Page 32

UNIT-IV

Dept. Of CSE, MeRITS

CNS NOTES

Page 33

UNIT-IV

CNS NOTES

To protect the key, it is encrypted with the receivers public key. Figure 18.1b illustrates
the sequence, which can be described as follows:
1. The sender generates a message and a random 128-bit number to be used as
a session key for this message only. 2. The message is encrypted using CAST-128 (or IDEA or
3DES) with the session key. 3. The session key is encrypted with RSA using the recipients
public key and is
prepended to the message. 4. The receiver uses RSA with its private key to decrypt and recover
the session key. 5. The session key is used to decrypt the message. As an alternative to the use of
RSA for key encryption, PGP provides option referred to as Diffie-Hellman
CONFIDENTIALITY AND AUTHENTICATION : As Figure 18.1c illustrates, both services
may be used for the same message. First, a signature is generated for the plaintext message and
prepended to the message.Then the plaintext message plus signature is encrypted using CAST128 (or IDEA or 3DES), and the session key is encrypted using RSA .
COMPRESSION: As a default, PGP compresses the message after applying the signature but
before encryption.This has the benefit of saving space both for e-mail transmission and for file
storage.
E-MAIL COMPATIBILITY: When PGP is used, at least part of the block to be transmitted is
encrypted. If only the signature service is used, then the message digest is encrypted (with the
senders private key). If the confidentiality service is used, the message plus signature (if
present) are encrypted (with a one-time symmetric key).
Figure 18.2 shows the relationship among the four services so far discussed. On
transmission (if it is required), a signature is generated using a hash code of the uncompressed
plaintext. Then the plaintext (plus signature if present) is compressed. Next, if confidentiality is
required, the block (compressed plaintext or compressed signature plus plaintext) is encrypted
and prepended with the public-key encrypted symmetric encryption key. Finally, the entire block
is converted to radix-64 format.
Cryptographic Keys and Key Rings:
PGP makes use of four types of keys: one-time session symmetric keys, public keys,
private keys, and passphrase-based symmetric keys (explained subsequently).Three separate
requirements can be identified with respect to these key.
.
1. A means of generating unpredictable session keys is needed.
2. We would like to allow a user to have multiple public-key/private-key pairs. One reason is that
the user may wish to change his or her key pair from time to time. When this happens, any
messages in the pipeline will be constructed with an obsolete key. Furthermore, recipients will
know only the old public key until an update reaches them.
3. Each PGP entity must maintain a file of its own public/private key pairs as well as a file of
public keys of correspondents.
Dept. Of CSE, MeRITS

Page 34

UNIT-IV

CNS NOTES

SESSION KEY GENERATION :

Each session key is associated with a single message and is used only for the purpose of
encrypting and decrypting that message. Recall that message encryption/decryption is done with
a symmetric encryption algorithm. CAST-128 and IDEA use 128-bit keys; 3DES uses a 168-bit
key.
A message consists of three components: the message component, a signature (optional),
and a session key component (optional). The message component includes the actual data to be
stored or transmitted, as well as a filename and a timestamp that specifies the time of creation.
The signature component includes the following.
Timestamp: The time at which the signature was made.
Message digest: The 160-bit SHA-1 digest encrypted with the senders private signature key.
The digest is calculated over the signature timestamp concatenated with the data portion of the
message component. The inclusion of the signature timestamp in the digest insures against replay
types of attacks

Dept. Of CSE, MeRITS

Page 35

UNIT-IV

CNS NOTES

Figure 18.4 shows the general structure of a private-key ring.We can view the ring as a
table in which each row represents one of the public/private key pairs owned by this user. Each
row contains the entries:
Timestamp: The date/time when this key pair was generated.
Key ID: The least significant 64 bits of the public key for this entry.
Public key: The public-key portion of the pair.
Private key: The private-key portion of the pair; this field is encrypted.
User ID: Typically, this will be the users e-mail address (e.g., stallings@acm.org).
However, the user may choose to associate a different name with each pair.

Dept. Of CSE, MeRITS

Page 36

UNIT-IV

CNS NOTES

Figure 18.4 also shows the general structure of a public-key ring. This data structure is
used to store public keys of other users that are known to this user. For the moment, let us ignore
some fields shown in the figure and describe the following fields.
Timestamp: The date/time when this entry was generated.
Key ID: The least significant 64 bits of the public key for this entry.
Public Key: The public key for this entry.
User ID: Identifies the owner of this key. Multiple user IDs may be associated with a single
public key.
1. Signing the message:
a. PGP retrieves the senders private key from the private-key ring using your_userid as
an index. If your_userid was not provided in the command, the first private key on the ring is
retrieved.
b. PGP prompts the user for the passphrase to recover the unencrypted private key.
c. The signature component of the message is constructed.
2. Encrypting the message:
a. PGP generates a session key and encrypts the message.
b. PGP retrieves the recipients public key from the public-key ring using her_userid as
an index.
c. The session key component of the message is constructed.
The receiving PGP entity performs the following steps (Figure 18.6).
Dept. Of CSE, MeRITS

Page 37

UNIT-IV

CNS NOTES

1. Decrypting the message:

a. PGP retrieves the receivers private key from the private-key ring using the Key ID
field in the session key component of the message as an index.
b. PGP prompts the user for the passphrase to recover the unencrypted
private key.
c. PGP then recovers the session key and decrypts the message..
2. Authenticating the message:
a. PGP retrieves the senders public key from the public-key ring using the Key ID field
in the signature key component of the message as an index.
b. PGP recovers the transmitted message digest.
c. PGP computes the message digest for the received message and compares it to the
transmitted message digest to authenticate.

Dept. Of CSE, MeRITS

Page 38

UNIT-IV

CNS NOTES

S/MIME:
Secure/Multipurpose Internet Mail Extension (S/MIME) is a security enhancement to the
MIME Internet e-mail format standard based on technology from RSA Data Security.
To understand S/MIME, we need first to have a general understanding of the underlying
e-mail format that it uses, namely MIME. But to understand the significance of MIME, we
need to go back to the traditional e-mail format standard.

RFC 5322:
RFC 5322 defines a format for text messages that are sent using electronic mail. It has
been the standard for Internet-based text mail messages and remains in common use. In the RFC
5322 context, messages are viewed as having an envelope and contents.The envelope contains
whatever information is needed to accomplish transmission and delivery. The contents compose
the object to be delivered to the recipient.
The overall structure of a message that conforms to RFC 5322 is very simple. A message
consists of some number of header lines (the header) followed by unrestricted text (the body).
The header is separated from the body by a blank line.
A header line usually consists of a keyword, followed by a colon, followed by the
keywords arguments; the format allows a long line to be broken up into several lines.The most
frequently used keywords are From, To, Subject, and Date.
Dept. Of CSE, MeRITS

Page 39

UNIT-IV

CNS NOTES

Multipurpose Internet Mail Extensions:

Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322
framework that is intended to address some of the problems and limitations of the use of Simple
Mail Transfer Protocol (SMTP), defined in RFC 821, or some other mail transfer protocol and
RFC 5322 for electronic mail. [PARZ06] lists the following limitations of the SMTP/5322
scheme.
1. SMTP cannot transmit executable files or other binary objects.A number of schemes are in use
for converting binary files into a text form that can be used by SMTP mail systems, including the
Dept. Of CSE, MeRITS

Page 40

UNIT-IV

CNS NOTES

popular UNIX UUencode/Uudecode scheme. However, none of these is a standard or even a de

facto standard.
2. SMTP cannot transmit text data that includes national language characters, because these are
represented by 8-bit codes with values of 128 decimal or higher, and SMTP is limited to 7-bit
ASCII.
3. SMTP servers may reject mail message over a certain size.
4. SMTP gateways that translate between ASCII and the character code EBCDIC do not use a
consistent set of mappings, resulting in translation problems.
5. SMTP gateways to X.400 electronic mail networks cannot handle nontextual data included in
X.400 messages.
6. Some SMTP implementations do not adhere completely to the SMTP standards defined in
RFC 821. Common problems include:
Deletion, addition, or reordering of carriage return and linefeed
Truncating or wrapping lines longer than 76 characters
Removal of trailing white space (tab and space characters)
Padding of lines in a message to the same length
Conversion of tab characters into multiple space characters
OVERVIEW: The MIME specification includes the following elements.
1. Five new message header fields are defined, which may be included in an RFC 5322
header.These fields provide information about the body of the message.
2. A number of content formats are defined, thus standardizing representations that support
multimedia electronic mail.
3. Transfer encodings are defined that enable the conversion of any content format into a form
that is protected from alteration by the mail system. In this subsection, we introduce the five
message header fields. The next two subsections deal with content formats and transfer
encodings.
The five header fields defined in MIME are:
MIME-Version: Must have the parameter value 1.0. This field indicates that the message
conforms to RFCs 2045 and 2046.
Content-Type: Describes the data contained in the body with sufficient detail that the receiving
user agent can pick an appropriate agent or mechanism to represent the data to the user or
otherwise deal with the data in an appropriate manner.
Content-Transfer-Encoding: Indicates the type of transformation that has been used to
represent the body of the message in a way that is acceptable for mail transport.
Content-ID: Used to identify MIME entities uniquely in multiple contexts.
Content-Description: A text description of the object with the body; this is useful when the
object is not readable (e.g., audio data).
MIME CONTENT TYPES :
The bulk of the MIME specification is concerned with the definition of a variety of
content types. This reflects the need to provide standardized ways of dealing with a wide variety
of information representations in a multimedia environment.
Dept. Of CSE, MeRITS

Page 41

UNIT-IV

Dept. Of CSE, MeRITS

CNS NOTES

Page 42