Docstoc

Kerberos and PKIs

Document Sample
Kerberos and PKIs Powered By Docstoc
					              ITEC4621
Kerberos and Public-key
          Infrastructure
            Dr. Supakorn Kungpisdan

                                 MUT, THAILAND



    ITEC4621: Network Security                   1
Outline

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   2
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   3
Kerberos

 Kerberos provides centralized authentication
  service to authenticate users to servers and
  servers to users.
 Rely heavily on conventional encryption, making
  no use of public-key encryption
 Two versions of Kerberos: version 4 and 5.
  Version 5 corrects some of the security
  deficiencies of version 4.


                   ITEC4621: Network Security       4
Motivations
   Approaches to enhance security of distributed systems:
    1. Rely on each client workstation to assure identities of its
       users and rely on each server to enforce policy based on
       user identification
    2. Clients need to authenticate themselves to the server, but
       trust the client system concerning the identity of its user
    3. Require user to prove identity for each service invoked.
       Require server to prove their identity to clients
   Small organization may require only 1 and 2, but open
    system needs 3 too
   Kerberos provides #3


                           ITEC4621: Network Security                5
Requirements for Kerberos

 Secure: eavesdroppers are not able to obtain
  information for impersonation
 Reliable: should be highly reliable and based on
  distributed server architecture
 Transparent: beyond entering a password, it
  should be transparent to users
 Scalable: capable of supporting large no. of
  clients and servers


                    ITEC4621: Network Security       6
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   7
Kerberos Version 4

 A Simple Authentication Dialogue
  Authentication Server (AS) contains user passwords
   stored in centralized database.
  AS shares a unique key with each server. The key have
   been distributed in a secure manner.
                                          Password of C
  (1) CAS:         IDC||PC||IDV
  (2) ASC:         Ticket
  (3) CV:          IDC||Ticket
  Ticket = EKv[IDC||ADC||IDV]
  Kv is shared btw AS and V          IP address of C
                              ITEC4621: Network Security   8
Problems
 A user have to contact AS to issue a new ticket every
  time he/she wants to connect to a server
    Solved by storing the ticket in the client during a logon
     session.
 A user still needs many tickets for different services
 Password is sent in cleartext in message (1)




                           ITEC4621: Network Security            9
A More Secure Authentication Dialogue

 Ticket-granting server (TGS) is introduced.

                                                  To authenticate C to TGS

                                                    C supplies a password to
                                                    decrypt the message




                                                 To authenticate C to V




                    ITEC4621: Network Security                                 10
A More Secure Authentication Dialogue
(cont’d)
 Tickettgs can be used to acquire service-granting
  ticket (TicketV) for as many as service during its
  life time
 User can reuse service-granting ticket to access
  service without having to re-enter password
 This technique satisfies 2 requirements:
  One password query per session
  Protection of the user password



                     ITEC4621: Network Security    11
Remaining problems
 2 problems remain:
1. Lifetime associated with ticket-granting ticket (Ticketgs)
    IF too short -> user needs to supply password often
    If too long -> increase a chance for replay
        Steal ticket and use it before expired
        Need the ability to prove that the person using a ticket is the
         same person to whom that the ticket was issued.
2. Server also needs to authenticate itself to users
    Otherwise, user may be redirected to another location
     controlled by attacker



                             ITEC4621: Network Security                    12
Overview of Kerberos 4




               ITEC4621: Network Security   13
    Summary of Kerberos V4 Message
    Exchange

                                 Time when ticket was issued
                                          Lifetime of ticket

Session key


                                               ID, address, timestamp of C



Session key

                                                        To confirm ID of the user
                                                        requesting the service
                                                   Optional

                  ITEC4621: Network Security                                 14
Kerberos Realms
 A full Kerberos service environment (a “realm”) is
  composed of
    Kerberos server, Clients, Application servers
 Requirements
    Kerberos server with registered user IDs and associated
     hashed passwords
    Shared keys between Kerberos server and all registered
     servers
 Users may need to access a server in different realm
  -> additional requirements
    Kerberos servers in each realm must share a secret key
     with server in the other realm. Two Kerberos servers are
     registered with each other.
                         ITEC4621: Network Security             15
 Kerberos
 Realms (cont’d)




Client belongs to realm A.
Server providing service is
in realm B.




                              ITEC4621: Network Security   16
Kerberos Realms and Multiple Kerberi
(cont’d)
                                                   Session keys needed
(1) C->AS: IDC||IDtgs||TS1
(2) AS->C: EKc[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs]
(3) C->TGS: IDtgs-rem||Tickettgs||AuthenticatorC
(4) TGC->C: EKc,tgs[Kc,tgs-rem||IDtgsrem||TS4||Tickettgs-rem]
(5) C->TGSrem: IDv-rem||Tickettgs-rem||AuthenticatorC
(6) TGS->C: EKc,tgs-rem[Kc,v-rem||IDv-rem||TSb||Ticketv-rem]
(7) C->Vrem: Ticketv-rem||AuthenticatorC

     Tickettgs = EKtgs[Kc,tgs||IDC||ADC||IDtgs||TS2||Lifetime2]
     AuthenticatorC = EKc,tgs[IDC||ADC||TS3]
     Tickettgs-rem = ticket of remote TGS
     IDvrem/Ticketv-rem = ID/Ticket of remote server
                              ITEC4621: Network Security                 17
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   18
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



                         ITEC4621: Network Security                 19
Environmental Shortcomings
 Encryption system dependence
    V4 is based on DES, whereas V5 does not stick with any kind of
     encryption -> having “encryption type identifier”
 Internet protocol dependence
    V4 is based only on IP addresses, whereas V5 has tag
     identifying type of network address
 Message byte ordering
    V5 provides unambiguous standard byte ordering by deploying
     Abstract Syntax Notation One (ASN.1), whereas V4 has its own
     byte ordering technique
 Ticket lifetime
    V4 specifies lifetime as 8-bit quantity in units of 5 minutes -> 28 x
     5 mins ≈ 21 hours, whereas V5 explicitly specifies start/stop time
 Authentication forwarding
    V4 does not allow credentials issued to one client to be used by
     other client, whereas V5 does
                             ITEC4621: Network Security                  20
Technical Deficiencies
 Double encryption
    Ticket issued to client is encrypted twice. 2nd encryption in
     message (4) is not necessary
 PCBC encryption
    V4’s non-standard mode of DES called PCBC (propagating
     cipher block chaining) (intended for integrity check) is found
     vulnerable to attacks. V5 deploys standard CBC
 Session keys
    In V4, Session keys Kc,tgs and Kc,v used to generate
     AuthenticatorC can be replayed within ticket lifetime.
    V5 offers an option to generate a subsession key for requesting
     for service.
 Password attacks
    Both V4 and V5 are vulnerable to password attacks. KC is
     generated from client’s password. Attacker can capture message
     (2) and try to recover password.
                            ITEC4621: Network Security                 21
Kerberos Version 5 (cont’d)

 Some of the new elements are introduced:
  Realm: indicates realm of user
  Options: client’s request that certain flags to be set in
   the returned ticket
  Times: used by client to request time settings in the
   ticket:
      from: start time
      till: end time
      rtime: renew time
  Nonce: random value to prevent replay


                           ITEC4621: Network Security          22
Kerberos V5 Message Exchange
                                           Not encrypted
                                           compared to V4




              ITEC4621: Network Security                    23
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   24
X.509 Authentication Service
 X.509 is a framework for provision of authentication
  services by X.500 directory to its users.
 X.500 is directory service -> a server or set of servers
  that maintains database of information about users.
 X.509 defines certificate format for a variety of
  applications e.g. S/MIME (email security), IP Security,
  SSL/TLS and SET (transport-layer security)
 X.509 is based on public-key cryptography




                        ITEC4621: Network Security           25
Digital (or Public-key) Certificates


 User certificates are created by some trusted certification
  authority (CA) and placed in CA’s directory.
 Defining a certificate:               Validity period
                         version          Sig algo Identifier
                                                                 Algo & parameters
         CA<<A>> = CA{V, SN, AI, CA, TA, A, Ap}
                             Serial no.                     Cert holder’s name
                                                CA’s name
Where
Y<<X>> = the certificate of user X issued by Y
Y{I} = the signing of I by Y. It consists of I with an encrypted
  hashed of I appended
                         ITEC4621: Network Security                              26
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Certificate Format
  X.509 Hierarchy
  X.509 Authentication


                   ITEC4621: Network Security   27
   X.509 Certificate Formats




Detailed
information
(optional)



Hash of other fields
signed with the CA’s   ITEC4621: Network Security   28
private key
Obtaining a User’s Certificate
 Certificates have the following characteristics:
    Any user who has CA’s public key can recover a user’s
     certified public key
    No party other than CA can modify certificates without being
     detected
 Basically, user can transmit his/her certificate directly to
  others or place the certificate in a public directory

 In a large community, users may use different CAs.
 User A (not trust CA named X) can obtain B’s certificate
  (issued by X) but cannot verify it.
 X needs to convince A about B’s certificate.


                          ITEC4621: Network Security                29
Obtaining User’s Public Key from Different CA

  Users A and B obtains certificates certA and certB from
   CA X1 and CA X2, respectively.
 X1 and X2 securely exchange their public keys
1. A obtains certX2 signed by X1. So A can verify X2’s
   public key from X1’s signature.
2. A then obtains certB signed by X2. A then can verify
   certB by using X2’s public key.




                       ITEC4621: Network Security            30
Digital Certificates

 certB and certA are written as follows:
                X1<<X2>> X2<<B>>
                X2<<X1>> X1<<A>>
 In general, a chain of certs can be represented
  as follows:
          X1<<X2>> X2<<X3>> … XN<<B>>
 X.509 suggests that CAs should be arranged in
  a hierarchy

                    ITEC4621: Network Security      31
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   32
X.509 Hierarchy

    Reverse certs




    Forward certs




                    ITEC4621: Network Security   33
X.509 Hierarchy (cont’d)
 Each CA (E.g. X) includes two types of certificates:
    Forward certificates: X’s certificate issued by other CAs
    Reverse certificates: other (CAs or users) certificates issued
     by X
 A acquires certB in the following format:
      X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>
 B acquires certA as follows:
      Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>




                           ITEC4621: Network Security                 34
Certificate Revocation
 A new certificate will be issued from the following
  reasons:
    Before expiry date
    User’s private key is compromised
    User is no longer certified by this CA
    CA’s certificate is compromised
 Each CA maintain a list of revoked certs, but not expired
  called certificate revocation list (CRL) and post the CRL
  on the directory.
 CRL is signed by the issuer (CA)
 When a user receives a cert, he/she must check with
  CRL.
                           ITEC4621: Network Security     35
Certificate               Date the list
Revocation List           was created

                         Date next
                         CRL will be
                         issued




                         Revoked
                         certificates




              ITEC4621: Network Security   36
Roadmap

Kerberos
  Kerberos version 4
  Kerberos version 5
X.509 Authentication Service
  X.509 Format
  X.509 Hierarchy
  X.509 Authentication


                  ITEC4621: Network Security   37
X.509 Authentication

One-way Authentication
               timestamp

        EKRa[tA, rA, IDB, Data, EKUb[Kab]]
    A                                            B
                   nonce




                    ITEC4621: Network Security       38
X.509 Authentication (cont’d)

Two-way Authentication

        EKRa[tA, rA, IDB, Data, EKUb[Kab]]

   A                                             B
       EKRb[tB, rB, IDA, rA, Data, EKUa[Kab]]




                    ITEC4621: Network Security       39
X.509 Authentication (cont’d)

Three-way Authentication

         EKRa[tA, rA, IDB, Data, EKUb[Kab]]



   A
        EKRb[tB,rB, IDA, rA, Data, EKUa[Kab]]
                                                  B
                      EKRa[rB]



                     ITEC4621: Network Security       40
Public Key Infrastructure




               ITEC4621: Network Security   41
Questions?
                                Next week
                               IP Security



  ITEC4621: Network Security                 42

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:8/18/2012
language:
pages:42