Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

x2

VIEWS: 10 PAGES: 20

									  The Authentication Service
‘Kerberos’ and It’s Limitations
OUTLINE
  What is Kerberos ?
  How does it work ?
  Kerberos infrastructure and Cross-realm
   Authentication
  Kerberos Encryption
  Attacks on Kerberos ?
  Limitations of Kerberos
  Future Work
1. What Is Kerberos ?

Definition :
In Greek mythology, Kerberos was “ a three headed
dog that guards the entrance to Hades.
An authentication service developed as part of Project
Athena at MIT to enable network applications to
securely identify their peers.
It was intended to have three components to guard a
network’s gate: authentication, accounting, and audit.
The last two were never implemented.
Versions 1 through 3 were internal development
versions. Version 4 is the original Kerberos.

Motivation :
In an open environment, in which network connections
to other machines are supported, there is a need to
protect user information and resources stored at the
server. To do this :
Require the user to prove identity for each service
invoked. Also require that servers prove their identity
to clients.
These are supported by Kerberos.
It should be :
Secure: opponent does not find it to be the weak link
Reliable: it should employ a distributed server architecture,
           with one system able to back up another.
Transparent : user should not be aware that authentication
                is taking place.
Scalable : supporting large numbers of clients and servers.
       Once per                                        (2)
       user logon                                     Kerberos
       session
                                                          Authentication
                                                              Server
    (1)

                    Request service-granting ticket      Ticket - granting
                                                           Server (TGS)
                          Ticket+session key
                                                                                (4)
    (3)
                                                                     Once per type of
                                                                     service

Once per
service
session
            (5)                                                    (6)
1. User logs on to workstation and request service on host.
2. AS verifies user’s access rights in database, creates TGT
   and session key. Results are encrypted using key derived
   from user’s password.
3. Workstation prompts user for password and uses pass-
   word to decrypt incoming message, then sends ticket and
   authenticator that contains user’s name, network address,
   and time to TGS.
4. TGS decrypts ticket and authenticator, verifies request,
   then creates ticket for requested server.
5. Workstation sends ticket and authenticator to server.
6. Server verifies that ticket and authenticator match, then
   grants access to service. If mutual authentication is
   required, server returns an authenticator.
How does it work ?
 1.   C -----> AS : IDC , PC , IDV
 2.   AS----> C : Ticket
 3.   C------> IDC, Ticket
      Ticket = EKv [ IDC , ADC , IDV ]

 Where
 C = Client
 AS = Authentication Server
 V = Server
 IDC = Identifier of user on C
 IDV = Identifier of V
 PC = Password of user on C
 ADC = Network address of C
 K   = Secret encrytion key shared by AS and V
A more secure Authentication
The first scenario does not solve the followings:
1. The number of times that a user has to enter a password.
2. It involved a plaintext transmission of the password (mess1)

To solve these problems, we introduce ticket-granting server.
The new scenario:

Once per user logon session :
1. C -----> AS : IDC , IDtgs
2. AS----> C : Ekc[ Tickettgs]

Once per type of service:
3. C------> TGS : IDC , IDV , Tickettgs
4. TGS--> C : TicketV
Once per service session :
5. C------>V : IDC , TicketV

Tickettgs = EKtgs[IDC , ADC , IDtgs , TS1, Lifetime1]
TicketV = EKv[ IDC , ADC , IDV , TS2 , Lifetime2]
TS = Timestamp

This new scenario satisfies the two requirements of only one
password query per user session and protection of the user
password.

We still have two additional problems :
1. The lifetime associated with the ticket-granting ticket.
   If it is short (e.g., minutes), the user will be repeatedly
   asked for a password. If it is long, then an opponent has a
   greater opportunity for replay.
2. There might be a need for server to authenticate itself to
    users.

Solution : Session Keys
The threat : Opponent will steal the ticket and use it before it
               expires.
The solution : AS provide both the C and TGS with a secret
               piece of information in a secure manner. Then,
               C can prove its ID to the TGS by revealing the
               secret. An encryption key ise used as the secure
               info., this is referred to as a session key.
So the actual Kerberos protocol :
Summary of Kerberos Version 4
Message Exchanges
----------------------------------------------------------------------------------
a) Authentication Service Exchange : to obtain TGT
----------------------------------------------------------------------------------
1. C-------> AS : IDC , IDtgs ,TS1
2. AS-----> C : EKc[ KC,tgs, IDtgs,TS2, Lifetime2, Tickettgs]
Tickettgs = EKtgs[ KC,tgs, IDC, ADC, IDtgs,TS2, Lifetime2]
----------------------------------------------------------------------------------
b) Ticket-Granting Service Exchange : to obtain service-
   granting ticket
----------------------------------------------------------------------------------
3. C-------> TGS : IDV , Tickettgs ,AuthenticatorC
4. TGS---> C : EKc[ KC,V, IDV,TS4, TicketV]
Tickettgs = EKtgs[ KC,tgs, IDC, ADC, IDtgs,TS2, Lifetime2]
TicketV = EKv[ KC,V, IDC, ADC, IDV,TS4, Lifetime4]
AuthenticatorC = EKc,tgs[IDC, ADC, TS3]
-----------------------------------------------------------------------------------
c) Client/Server Authentication Exchange : to obtain service
-----------------------------------------------------------------------------------
5. C------> TGS : TicketV, AuthenticatorC
6. K------> C          : EKc,v [ TS5 +1] (for mutual authentication)
TicketV = EKv[ KC,V, IDC, ADC, IDV,TS4, Lifetime4]
AuthenticatorC = EKc,v[IDC, ADC, TS5]
-----------------------------------------------------------------------------------
Kerberos Realms
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 UID and hashed pass-
   word 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.
For inter-realm authentication;
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.
This means that the Kerberos server in one realm trust the
Kerberos server in the other realm to authenticate its users
                 Kerberos
Client
         1          AS
             2                     1. Request ticket for local
         3         TGS
             4                        TGS
                                   2. Ticket for local TGS
                      Realm A
                                   3. Request ticket for
 7                                    remote TGS
         5                         4. Ticket for remote TGS
                 Kerberos          5. Request ticket for
         6
                                      remote server
                    AS             6. Ticket for remote server
Server                             7. Request remote service
                   TGS
                         Realm B
     Encryption for Privacy and
              Integrity
The data structures that Kerberos encrypts need to be
protected from both disclosure and modification.
Kerberos uses DES algorithm for encryption. For a long
message CBC (Cipher Block Chaining) could be used and
it does a good job on privacy.
Problem :However, there is no integrity
check. If an intruder were to modify block cn,then mn and mn+1
would be garbage. No way for kerberos to detect this.
Solution: Plaintext Cipher Block Chaining (PCBC).
It has the property that modifying any ci will result in garbling
plaintext blocks starting with mi all the way to the end. There
is a recognizable data at the end of a message so that it will
decrypt to see whether the final block is proper.
Question: What if we swap two adjacent blocks of ciphertext?
Plaintext Cipher Block Chaining




        m1    m2    m3     m4

  IV

                                  Encrypt
        E     E      E     E      with
                                  secret key

        c1    c2     c3    c4
Attacks on Kerberos
1. Replay Attacks
2. Secure Time Services
3. Password-Guessing Attacks
4. Spoofing Login
5. Inter-Session Chosen Plaintext attacks
6. Exposure of Session Keys
7. The Scope of Tickets
        Limitations of Version 4
Environmental Shortcomings :
1. Encryption system dependence (it uses only DES)
2. Internet protocol dependence (requires the use of IP addr.
3. Message byte ordering
4. Ticket Lifetimes (a maximum lifetime of 211/4 hours).
5. Authentication Forwarding ( an intermediate server may
   need to accsess some resource with the rights of the client
   for example a print server)
6. Principal naming. ( principals are named with three compo-
   nents: name, instance, and realm, each of which may be up
   to 39 charactres long which are too short for some applicati-
   ons and installation environments
7. Inter-realm authentication. (The pairwise key exchange
   requires a lot of key exchanges for n realms).
Technical Deficiencies :

1. Double Encryption: The ticket is encrypted twice when
   transmitted to the client, and only once when sent to the
   application server. If encryption is computationally intensive
   this is unneccesary use of processing time.
2. PCBC encryption:This mode was an attempt to provide data
   encryption and integrity protection in one operation. But, an
   intruder can modify a message with a special block-
   exchange attack which may not be detected by the receiver.
3. Authenticators and replay detection
4. Password attacks
5. Session keys
6. Cryptographic checksum : The MIT implementation does
   not perform this algorithm as described; the suitability of the
   modified version as a CCF is unknown.
Future Work
Version 5 of Kerberos is a step toward the design of an
authentication system that is widely applicable.The framework
is flexible enough to accommodate future requirements.Some
items expected to add to Kerberos in the near future include:
1.Public-key cryptosystems: It will give the ability to interope-
   rate with the Privacy Enhanced Mail (PEM) infrastructure.
2.Smartcards: Hand-held devices can be used to augment
   normal password security methods.
3.Remote administration : Remote extraction of server key
   tables, password “quality checks”, and a provision for
   servers to change their secret keys automatically often.
4.Validation suites: To verify that the protocol is properly imp-
    lemented. It could prevent future problems.
5. Applications : E-mail, Usenet, distributed file systems.

								
To top