Presentation of Kerberos as per ECE scheme

Presentation of Kerberos as per ECE scheme

• 1.
  KERBEROS
• 2.
  KERBEROS  Authentication servicedesigned for use in a distributed environment.  Developed as part of project Athena at MIT.
• 3.
  ATTACKS ON OPENDISTRIBUTED ENVIRONMENT  Impersonation  Altering of address of workstation  Entrance into the network
• 4.
  FUNDAMENTAL REQUIREMENT INAN AUTHENTICATION SERVICE  Secure  Reliable  Transparent  Scalable
• 5.
  TWO VERSIONS OFKERBEROS  Kerberos v4 (developed in 1988) is still in common use  Kerberos v5 (1994) corrects some security deficiencies of version 4 and has been issued a draft internet standard (RFC 1510)
• 6.
  KERBEROS 4  Ituses DES  An authentication server (AS) is used which stores the passwords of all users and also shares a unique secret key with each user.
• 7.
  SIMPLE AUTHENTICATION DIALOGUE 1.C → AS: IDC|| PC || IDV 2. AS→ C: Ticket 3. C→V : IDC || Ticket Ticket = E(Kv,[IDC|| ADC || IDV]) 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 KV= secret encryption key shared by AS and V
• 8.
  DRAWBACKS  Users passwordis unprotected.  User has to login every time he request for service. These can be removed by using a more secure scheme. It uses a new server TGS.
• 9.
  TICKET GRANTING SERVER Issues ticket to users authenticated to AS.  Ticket granting ticket is issued by AS.  Each time the user require access to a new service, the client applies to the TGS, using the ticket.  Then TGS grants a ticket for a particular service.
• 10.
  A MORE SECUREAUTHENTICATION DIALOGUE Once per service session: (1) C → AS: IDC || IDtgs (2) AS→ C:E(KC,[Tickettgs]) Once per type of service: (3) C→TGS: IDC || ID´V || Tickettgs (4) TGS→C: TicketV Once per service session: (5) C→V: TicketV || ID´C Tickettgs = E(Ktgs ,[IDC|| ADC || IDtgs || TS1 || Lifetime1 ]) TicketV = E(Kv, [IDC|| ADC || IDV || TS2 || Lifetime2 ])
• 11.
  THE VERSION 4AUTHENTICATION DIALOGUE:  Two additional problems remain in the second scenario: 1. Lifetime associated with the ticket-granting ticket: Short Lifetime: User is repeatedly asked for password Long Lifetime: Greater opportunity for replay 2. Requirement for servers to authenticate themselves to users
• 12.
  ELEMENTS OF KERBEROSVERSION 4 PROTOCOL
• 13.
  1. Authentication ServiceExchange: to obtain ticket- granting ticket 2. Ticket-Granting Service Exchange: to obtain service- granting ticket 3. Client/Server Authentication Exchange: to obtain service
• 14.
  AUTHENTICATION SERVICE EXCHANGE 1.C → AS IDc||IDtgs||TS1 Client requests ticket-granting ticket 2. AS → C E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs]) Ticket tgs=E(Ktgs, [Kc,tgs||IDc||ADc||IDtgs||TS2||Lifetime2]) AS returns ticket-granting ticket
• 15.
  TICKET-GRANTING SERVICE EXCHANGE 3.C → TGS IDv||Tickettgs||Authenticatorc Authenticatorc=E(Kc,tgs,[IDc||ADc||TS3]) Client requests service-granting ticket 4. TGS → C E(Kc,tgs, [Kc,v||IDv||TS4||Ticketv]) Ticketv= E(Kv,[Kc,v||IDc||ADc||IDv||TS4||Lifetime4]) TGS returns service-granting ticket
• 16.
  CLIENT/SERVER AUTHENTICATION EXCHANGE 5. C→ V Ticketv||Authenticatorc Ticketv=E(Kv,[Kc,v||IDc||ADc||IDv||TS4||Lifetime4]) Authenticatorc=E(Kc,v,[IDc||ADc||TS5]) Client requests service 6. V → C E(Kc,v,[TS5+1]) Optional authentication of server to client
• 17.
  KERBEROS REALMS  Requirementsof a full-service Kerberos environment: All users registered with the Kerberos server All servers registered with the Kerberos server The two Kerberos servers registered with each other (to support interrealm authentication)
• 18.
  REQUEST FOR SERVICEIN ANOTHER REALM
• 19.
  1. Request ticketfor local TGS C → AS IDc||IDtgs||TS1 2. Ticket for local TGS AS → C E(Kc,[Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs]) 3. Request ticket for remote TGS C → TGS IDtgsrem||Tickettgs||Authenticatorc 4. Ticket for remote TGS TGS → C E(Kc,tgs,[Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])
• 20.
  5. Request ticketfor remote server C → TGSrem IDvrem||Tickettgsrem||Authenticatorc 6. Ticket for remote server TGSrem → C E(Kc,tgsrem,[Kc,vrem||IDvrem||TS6||Ticketvrem]) 7. Request remote service C → Vrem Ticketvrem||Authenticatorc  However, this approach does not scale well to many realms. For N realms, there must be N(N-1)/2 secure key exchanges between realms
• 21.
  KERBEROS V5  Generalpurpose authentication service  Specified in RFC-4120  Overcome the shortcomings of v4
• 22.
  SHORTCOMING OF V4 Environmental Shortcomings -Related to the architecture of network  Technical Shortcomings : - Deficiencies in the v4 itself
• 23.
  KERBEROS V4 ENVIRONMENTAL SHORTCOMINGS Encryption System Dependence  Internet Protocol Dependence  Message by ordering  Ticket Lifetime  Authentication Forwarding  Inter-realm Authentication
• 24.
  KERBEROS V4 TECHNICAL SHORTCOMINGS Double Encryption  Propagation Cipher Block Chaining Encryption  Session Keys  Password Attacks
• 25.
  KERBEROS V5 EXCHANGES
• 26.
  KERBEROS V5 FLAGS
• 27.
  CONCLUSION  Version 5of Kerberos is a step toward the design of an authentication system that is widely applicable.  We believe the framework is flexible enough to accommodate future requirements like 1. Smart Cards 2. Remote Administration