Authentication Applications: Security Concerns Kerberos

Authentication Applications
Security Concerns
Kerberos
A Simple Authentication
Dialogue
(1) C ----> AS: IDc || Pc || IDv
(2) AS ----> C: Ticket
(3) C -----> V: IDc || Ticket
Data & Network Security By Mohib Ullah

Ticket = EKv[IDc || Pc || IDv]
Version 4 Authentication
Dialogue
• Problems:
• Lifetime associated with the ticket-granting ticket
• If too short ---> repeatedly asked for password

• If too long ----> greater opportunity to replay
• The threat is that an opponent will steal the ticket
and use it before it expires
Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket
(1) C ---> AS: IDc || IDtgs ||TS1
(2) AS ---> C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]
Ticket-Granting Service Echange: To obtain Service-Granting Ticket

(3) C ---> TGS: IDv ||Tickettgs ||Authenticatorc
(4) TGS ---> C: EKc [Kc,¨v|| IDv || TS4 || Ticketv]
Client/Server Authentication Exhange: To Obtain Service

(5) C ---> V: Ticketv || Authenticatorc
(6) V ---> C: EKc,v[TS5 +1]
Overview of Kerberos

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
Kerberos provides a mechanism for supporting 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.
•The scheme requires that the Kerberos server in one realm
trust the Kerberos server in the other realm to authenticate its
users.
•.
• Furthermore, the participating servers in the second realm
must also be willing to trust the Kerberos server in the first
realm.
• A user wishing service on a server in another realm needs a
ticket for that server. 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 (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
Another Realm
Request for Service in

Difference Between Version 4
and 5
• Encryption system dependence (V.4 DES)
Version 4 use DES. DES has some issue about its security an strength.
Therefore version 5 can use any encryption technique with restriction that same key to be used in
different algorithms
• Internet protocol dependence
Version 4 uses only IP addresses. Other types such as ISO network address are not

accommodated. Version 5 network addresses are tagged with type and length, allowing
any network address type to be used.
• Ticket lifetime
In version 4, the maximum lifetime that can be expressed is 1280 minutes, or 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.
Kerberos Version 5
• developed in mid 1990’s
• specified as Internet standard RFC 1510
• provides improvements over v4
• addresses environmental shortcomings

• encryption alg, network protocol, byte order, ticket lifetime,
authentication forwarding, interrealm auth
• and technical deficiencies
• double encryption, non-std mode of use, session keys, password
attacks
Assumption of Kerberos
• Following are the assumption to solve the limitation of Kerberos as
given below.
• The Kerberos protocol does not protect against denial-of-service
attacks. Detection and solution of such attacks are usually best left to
human administrators and users.
• Key sharing or key theft can allow impersonation attacks. To limit this

threat, prohibit users from sharing their keys and document this
policy in your security regulations.
• The Kerberos protocol does not protect against typical password
vulnerabilities, such as password guessing. If a user chooses a poor
password, an attacker might successfully mount an offline dictionary
attack by repeatedly attempting to decrypt messages that are
encrypted under a key derived from the user's password. To ensure
that users choose a secure password, establish password guidelines
and document them in your company's security policy

Authentication Applications: Security Concerns Kerberos

Uploaded by

Copyright:

Available Formats

Authentication Applications: Security Concerns Kerberos

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authentication Applications: Security Concerns Kerberos

Uploaded by

Copyright:

Available Formats

Authentication Applications

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Ticket-Granting Service Echange: To obtain Service-Granting Ticket

Data & Network Security By Mohib Ullah

Client/Server Authentication Exhange: To Obtain Service

Data & Network Security By Mohib Ullah

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

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

Data & Network Security By Mohib Ullah

You might also like