UNIT II KEY MANAGEMENT AND AUTHENTICATION

Key Management and Distribution: Symmetric Key Distribution, Distribution of Public Keys,
X.509 Certificates, Public-Key Infrastructure. User Authentication: Remote User-Authentication
Principles, Remote User-Authentication Using Symmetric Encryption, Kerberos Systems,
Remote User Authentication Using Asymmetric Encryption.

2. KEY MANAGEMENT AND DISTRIBUTION

2.1 SYMMETRIC KEY DISTRIBUTION

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 deliver- ing 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.

CS354 NETWORK SECURITY 1 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 A Key Distribution Scenario

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, K, known only to itself and the KDC; similarly, B shares the
a 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.
2. The KDC responds with a message encrypted using Ka .

In addition, the message includes two items intended for B:

• The one-time session key, Ks, to be used for the session

• An identifier of A (e.g., its network address), IDA

CS354 NETWORK SECURITY 2 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 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.

Using the newly minted session key for encryption, B sends a nonce, N2, to A.

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 Transparent Key Control Scheme

The approach assumes that communication makes use of a connection-ori-

ented end-to-end protocol, such as TCP.

CS354 NETWORK SECURITY 3 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 2.1.1 SYMMETRIC KEY DISTRIBUTION USING ASYMMETRIC ENCRYPTION

One of the most important uses of a public-key cryptosystem is to encrypt

secret keys for distribution.

A Simple Secret key Distribution

K
E
Y

M
A
N
A
G
E
M
E
N
T
:

3.1 K
e

CS354 NETWORK SECURITY 4 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 KEY MANAGEMENT:

Key management refers to management of cryptographic keys in a cryptosystem. This

includes dealing with the generation, exchange, storage, use and replacement of keys. Once
keys are inventoried, key management typically consists of three steps: exchange, storage and
use. Key exchange (also key establishment) is any method in cryptography by which
cryptographic keys are exchanged between two parties, allowing use of a cryptographic
algorithm. If the cipher is a symmetric key cipher, both will need a copy of the same key. If
an asymmetric key cipher with the public/private key property, both will need the other's
public key.

2.2 Distribution of public Keys:

Several techniques have been proposed for the distribution of public keys.

Virtually all these proposals can be grouped into the following general schemes:

• Public announcement

• Publicly available directory

• Public-key authority.

• Public-key certificates

Public Announcement Of Public Keys:

On the face of it, the point of public-key encryption is that the public key is public. Thus, if
there is some broadly accepted public-key algorithm, such as RSA, any participant can send
his or her public key to any other participant or broadcast the key to the community at large
(Refer fig be

Fig 3.4: Uncontrolled public key distribution

CS354 NETWORK SECURITY 5 UNIT II KEY MANAGEMENT AND AUTHENTICATION
 Publicly Available Directory

A greater degree of security can be achieved by maintaining a publicly available dynamic

directory of public keys. Maintenance and distribution of the public directory would have to
be the responsibility of some trusted entity or organization (Figure below). Such a scheme
would include the following elements:

Fig 3.5: Public-Key Publication

1. The authority maintains a directory with a {name, public key} entry for each participant.

2. Each participant registers a public key with the directory authority. Registration would
have to be in person or by some form of secure authenticated communication.
3.A participant may replace the existing key with a new one at any time, either because of
the desire to replace a public key that has already been used for a large amount of data, or
because the corresponding private key has been compromised in some way.

4. Participants could also access the directory electronically. For this purpose, secure,
authenticated communication from the authority to the participant is mandatory.

Public-Key Authority:

Stronger security for public-key distribution can be achieved by providing tighter

control over the distribution of public keys from the directory. A typical scenario is illustrated
in Figure below.

CS354 NETWORK SECURITY 6 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 Fig 3.6: Public Key Distribution Scenario
1. A sends a time stamped message to the public-key authority containing a request for the

current public key of B.

2. The authority responds with a message that is encrypted using the authority’s

Private key, PR Thus, A is able to decrypt the message using the authority’s public key.

Therefore, A is assured that the message originated with the authority. The message includes

the following:

• B’s public key, PUb, which A can use to encrypt messages destined for B

• The original request used to enable A to match this response with the corresponding

earlier request and to verify that the original request was not altered before reception by the

authority

• The original timestamp given so A can determine that this is not an old message from
CS354 NETWORK SECURITY 7 UNIT II KEY MANAGEMENT AND AUTHENTICATION
 the authority containing a key other than B’s current public key

3. A stores B’s public key and also uses it to encrypt a message to B containing an identifier

of A (IDA) and a nonce (N), which is used to identify this transaction uniquely.

4, 5. B retrieves A’s public key from the authority in the same manner as A retrieved B’s

public key. At this point, public keys have been securely delivered to A and B, and they may

begin their protected exchange. However, two additional steps are desirable:

7. A returns N2, which is encrypted using B’s public key, to assure B that its correspondent

is A. Thus, a total of seven messages are required.

Public-Key Certificates:

The public key certificate relies on certificates that can be used by participants to
exchange keys without contacting a public-key authority, in a way that is as reliable as if the
keys were obtained directly from a public-key authority. In essence, a certificate consists of a
public key, an identifier of the key owner, and the whole block signed by a trusted third party.

We can place the following requirements on this scheme:

1. Any participant can read a certificate to determine the name and public key of the
certificate’s owner.

2. Any participant can verify that the certificate originated from the certificate authority and
is not counterfeit.

3. Only the certificate authority can create and update certificates.

4. Any participant can verify the currency of the certificate.

CS354 NETWORK SECURITY 8 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 Fig 3.7: Exchange of public key exchange

A certificate scheme is illustrated in Figure above. Each participant applies to the certificate
authority, supplying a public key and requesting a certificate. Application must be in person
or by some form of secure authenticated communication.
For participant A, the authority provides a certificate of the form

where PRauth is the private key used by the authority and T is a timestamp. A may
then pass this certificate on to any other participant, who reads and verifies the certificate
as follows:

The recipient uses the authority’s public key, PUauth, to decrypt the certificate. Because the
certificate is readable only using the authority’s public key, this verifies that the certificate
came from the certificate authority. The elements IDA and PUa provide the recipient with the
name and public key of the certificate’s holder. The timestamp T validates the currency of the
certificate.

One scheme has become universally accepted for formatting public-key certificates: the
X.509 standard. X.509 certificates are used in most network security applications, including
IP security, transport layer security (TLS), and S/MIME.

CS354 NETWORK SECURITY 9 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 2.3 X.509 CERTIFICATES
X.509 defines a framework for the provision of authentication services by the X.500
directory to its users. The directory may serve as a repository of public-key certificates. Each
certificate 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 an important standard because the certificate
structure and authentication protocols defined in X.509 are used in a variety of contexts. For
example, the X.509 certificate format is used in S/MIME, IP Security, and SSL/TLS
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 provides
an easily accessible location for users to obtain certificates

CS354 NETWORK SECURITY 10 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 Fig 3.20: General form of a certificate

CS354 NETWORK SECURITY 11 UNIT II KEY MANAGEMENT AND AUTHENTICATION

 The above figure shows the general format of a certificate, which includes the following
elements.

• 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 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.

• Subject’s 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.

• Signature: Covers all of the other fields of the certificate; it contains the hash code of the
other fields encrypted with the CA’s private key. This field includes the signature algorithm
identifier.

CS354 NETWORK SECURITY 12 UNIT II KEY MANAGEMENT AND AUTHENTICATION

CS354 NETWORK SECURITY 13 UNIT II KEY MANAGEMENT AND AUTHENTICATION
 2.4 PUBLIC-KEY INFRASTRUCTURE:

Public-key infrastructure (PKI) is the set of hardware, software, people,

policies, and procedures needed to create, manage, store, distribute, and revoke digital
certificates based on asymmetric cryptography. 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. This section describes
the PKIX model.

• 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.

Fig. 3.21: PKIX Architectural Model

CS354 NETWORK SECURITY 14 UNIT II KEY MANAGEMENT AND AUTHENTICATION
 Figure 3.21 shows the interrelationship among the key elements of the PKIX
model. These elements are

• Repository: A generic term used to denote any method for storing

certificates and CRLs so that they can be retrieved by end entities.

PKIX Management Functions

PKIX identifies a number of management functions that potentially need

to be supported by management protocols. These are indicated in Figure 3
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 off- line 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

user’s public key and returns that certificate to the user’s client system and/or
posts that certificate in arepository.

• 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
CS354 NETWORK SECURITY 15 UNIT II KEY MANAGEMENT AND
AUTHENTICATION
 will not be possible to recover the encrypted data. Loss of access to the
decryption key can result from forgotten passwords/PINs, corrupted disk
drives, damage to hardware tokens, and so on. Key pair recovery allows end
entities to restore their encryption/decryption key pair from an authorized key
backup facility (typically, the CA that issued the end entity’s certificate).

• Key pair update: All key pairs need to be updated regularly (i.e.,

replaced with a new keypair) 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

private key 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 c o n t a i n s a CA

signature key used for issuing certificates.

2.5 REMOTE USER-AUTHENTICATION PRINCIPLES

There are four general means of authenticating a user’s 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
CS354 NETWORK SECURITY 16 UNIT II KEY MANAGEMENT AND
AUTHENTICATION
 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.

2.6 REMOTE USER-AUTHENTICATION USING SYMMETRIC ENCRYPTION

2.7 KERBEROS
Kerberos is an authentication service developed as part of Project Athena at MIT.

 Kerberos provides a centralized authentication server whose function is to authenticate users to

servers and servers to users.

 Kerberos relies exclusively on symmetric encryption, making no use of public-key encryption.

Two versions of Kerberos are in common use.

1. Version 4

2. Version 5
CS354 NETWORK SECURITY 17 UNIT II KEY MANAGEMENT AND
AUTHENTICATION
The first published report on Kerberos listed the following requirements:
1. Secure

2. Reliable

3. Transparent

4. Scalable

Kerberos Version 4:
Version 4 of Kerberos makes use of DES to provide authentication service.
More Secure Authentication Dialogue:
Two problems remain in the above scenario.
1. First, we would like to minimize the number of times that a user has to enter a password.

2. The second problem is that the earlier scenario involved a plaintext transmission of the password.
An eavesdropper could capture the password and use any service accessible to the victim.

To solve these problems, a new scheme has been introduced for avoiding plaintext passwords and a new
server, known as the ticket-granting server (TGS).

Once per user logon session:

(1) C AS: ID C || ID tgs

(2) AS C: EKc [Ticket tgs ]

Once per type of service:

(3) C TGS: ID C || ID V|| Ticket tgs

(4) TGS C: Ticket v

Once per service session:

(5) C V: ID C || Ticket v

Ticket tgs = EKtgs [ ID C || AD C || ID tgs || TS 1 || Lifetime 1 ]

CS354 NETWORK SECURITY 18 UNIT II KEY MANAGEMENT AND

AUTHENTICATION
 Ticket v = EKv [ ID C || AD C || ID v || TS 2 || Lifetime 2 ]

TGS:
 The new service, TGS, issues tickets to users who have been authenticated to AS.

 Thus, the user first requests a ticket-granting ticket (Ticket tgs) from the AS.

 The client module in the user workstation saves this ticket.

 The TGS then grants a ticket for the particular service.

 The client saves each service-granting ticket and uses it to authenticate its user to a server each time
a particular service is requested.

The authentication steps are as follows:

1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID and
password to the AS, together with the TGS ID, indicating a request to use the TGS service.
2. The AS responds with a ticket that is encrypted with a key that is derived from the user's
password.
3. The client requests the TGS for a service-granting ticket on behalf of the user.
4. The TGS decrypts the incoming ticket and verifies the success of the decryption by the presence
of its ID. Then after verification by the TGS, the TGS issues a ticket to grant access to the
requested service.
5. The client requests the server for accessing a service on behalf of the user. The server
authenticates by using the contents of the ticket.
The Version 4 Authentication Dialogue:
Two additional problems remain in the above scenario.
1. The first problem is the lifetime associated with the ticket-granting ticket.

 If this lifetime is very short, then the user will be repeatedly asked for a password.

 If the lifetime is long, then an opponent has a greater opportunity for replay.

CS354 NETWORK SECURITY 19 UNIT II KEY MANAGEMENT AND

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

The above problems have been addressed in the following protocol.

Kerberos Version 4 Message Exchanges

(1) C AS ID c ||ID tgs ||TS 1

(2) AS C E( K c ,[ K c,tgs ||ID tgs ||TS 2 ||Lifetime 2 ||Ticket tgs ])

Ticket tgs = E(K tgs , [K c,tgs ||ID c ||AD c ||ID tgs ||TS 2|| Lifetime 2 ])

(a) Authentication Service Exchange to obtain ticket-granting ticket

(3) C TGS ID v Ticket tgs Authenticator c

(4) TGS C E( K c,tgs , [ K c,v|| ID v ||TS 4 ||Ticket v ])

Ticket tgs = E(K tgs , [K c,tgs ||ID C|| AD C|| ID tgs|| TS 2 ||Lifetime 2])
Ticket v = E(K v , [K c,v|| ID C ||AD C|| ID v ||TS 4||Lifetime 4 ])

CS354 NETWORK SECURITY 20 UNIT II KEY MANAGEMENT AND

AUTHENTICATION
 Authenticator c = E(K c,tgs , [ID C ||ADC ||TS 3 ])

(b) Ticket-Granting Service Exchange to obtain service-granting ticket

(5) C V Ticket v ||Authenticator c

(6) V C E( K c,v , [ TS 5 + 1]) (for mutual authentication)

Ticket v = E(K v , [K c,v|| ID c ||AD c ||ID v ||TS 4|| Lifetime 4 ])

Authenticator c = E(K c,v ,[ID c ||AD C ||TS 5 ])

(c) Client/Server Authentication Exchange to obtain service

1. The client sends a message to the AS requesting access to the TGS.

2. The AS responds with a message, encrypted with a key derived from the user's password ( K c ) that
contains the ticket.

3. C sends the TGS a message that includes the ticket plus the ID of the requested service.

4. The reply from the TGS follows the form of message (2).

5. C now has a reusable service-granting ticket for V. When C presents this ticket it also sends an
authenticator.

6. The server can reply as shown in message (6). The server returns the value of the timestamp from
the authenticator, incremented by 1, and encrypted in the session key.

Finally, at the conclusion of this process, the client and server share a secret key.
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.
CS354 NETWORK SECURITY 21 UNIT II KEY MANAGEMENT AND
AUTHENTICATION
Such an environment is referred to as a Kerberos realm.
Realm:
 A Kerberos realm is a set of managed nodes that share the same Kerberos database.

 The read only copy of the Kerberos database resides on the Kerberos master computer system,
which should be kept in a physically secure room.

 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.

 Kerberos provides a mechanism for supporting such interrealm authentication. For two realms to
support interrealm authentication, a third requirement is added:

o 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.

The mechanism is as follows:

1. A user wishing service on a server in another realm needs a ticket for that server.

2. The user's client follows the usual procedures to gain access to the local TGS and then requests a
ticket-granting ticket for a remote TGS.

3. 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.

Request for Service in Another Realm

(1) C AS: ID c || ID tgs|| TS 1

(2) AS C: E( K c , [ K c,tgs|| ID tgs ||TS 2 ||Lifetime 2 ||Ticket tgs ])

(3) C TGS: ID tgsrem ||Ticket tgs ||Authenticator c

(4) TGS C: E( K c,tgs , [ K c,tgsrem ||ID tgsrem ||TS 4|| Ticket tgsrem ])

(5) C TGS rem : ID vrem ||Ticket tgsrem ||Authenticator c

CS354 NETWORK SECURITY 22 UNIT II KEY MANAGEMENT AND

AUTHENTICATION
 (6) TGS rem C: E( K c,tgsrem , [ K c,vrem ||ID vrem ||TS 6 ||Ticket vrem ])

(7) C V rem : Ticket vrem ||Authenticator c

 The ticket presented to the remote server (Vrem ) indicates the realm in which the user was originally
authenticated. The server chooses whether to honor the remote request.

Kerberos Version 5:
 Kerberos Version 5 provides a number of improvements over version 4.

Differences between Versions 4 and 5:

Version 5 is intended to address the limitations of version 4 in two areas:
1. Environmental shortcomings

2. Technical deficiencies

Environmental shortcomings:
1. Encryption system dependence

2. Internet protocol dependence

3. Message byte ordering

CS354 NETWORK SECURITY 23 UNIT II KEY MANAGEMENT AND

AUTHENTICATION
 4. Ticket lifetime

5. Authentication forwarding

6. Inter realm authentication

Technical deficiencies
1. Double encryption

2. PCBC (Propagating cipher block chaining) encryption

3. Session keys

4. Password attacks

The Version 5 Authentication Dialogue:

Kerberos Version 5 Message Exchanges

(1) C AS Options ID c ||Realm c ||ID tgs ||Times ||Nonce 1

(2) AS C Realm c ||ID C ||Ticket tgs|| E( K c , [ K c,tgs ||Times ||Nonce 1 ||Realm tgs|| ID tgs ])

Ticket tgs = E( K tgs , [ Flags ||K c,tgs|| Realm c|| ID c|| AD c|| Times])

(a) Authentication Service Exchange to obtain ticket-granting ticket

(3) C TGS Options ID v ||Times ||Nonce 2 ||Ticket tgs ||Authenticator c

(4) TGS C Realm c ||ID c ||Ticket v ||E( K c,tgs , [ K c,v ||Times ||Nonce 2 ||Realmv ||ID v ])
Ticket tgs = E(K tgs , [ Flags ||K C,tgs ||Realm c|| ID C|| AD C ||Times])

Ticket v = E(K v , [Flags||K c,v ||Realm c ||ID C ||AD c ||Times])

Authenticator c = E( K c,tgs , [ ID C ||Realm c|| TS 1])

(b) Ticket-Granting Service Exchange to obtain service-granting ticket

(5) C V Options||Ticket v ||Authenticator c

(6) V C E K c,v [TS 2|| Subkey|| Seq#]

CS354 NETWORK SECURITY 24 UNIT II KEY MANAGEMENT AND

AUTHENTICATION
 Ticket v = E(K v , [Flags||K c,v ||Realm c ||ID C ||AD C ||Times])
Authenticator c = E( K c,v ,[ ID C ||Realm c ||TS 2 ||Subkey ||Seq #])

(c) Client/Server Authentication Exchange to obtain service

First, consider the authentication service exchange.

1. First message is a client request for a ticket-granting ticket. It includes the ID of the user and the
TGS. The following new elements are added:

Realm, Options, Time and Nonce

2. 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.

3. Message (3) includes an authenticator, a ticket, and the name of the requested service.

4. Message (4) has the same structure as message (2), returning a ticket plus information needed by
the client, the latter encrypted with the session key now shared by the client and the TGS.

5. Message (5), the client may request as an option that mutual authentication is required. The
authenticator includes several new fields as follows:

 Subkey

 Sequence numbers

Ticket Flags
The flags field included in tickets in version 5 supports expanded functionality compared to that available
in version 4. Table 14.4 summarizes the flags that may be included in a ticket.
Kerberos Version 5 Flags
1. INITIAL

2. PRE-AUTHENT

3. HW-AUTHENT

4. RENEWABLE
CS354 NETWORK SECURITY 25 UNIT II KEY MANAGEMENT AND
AUTHENTICATION
 5. MAY-POSTDATE

6. POSTDATED

7. INVALID

8. PROXIABLE

9. PROXY

10. FORWARDABLE

2.8 REMOTE USER-AUTHENTICATION USING ASYMMETRIC ENCRYPTION.

CS354 NETWORK SECURITY 26 UNIT II KEY MANAGEMENT AND

AUTHENTICATION