1. IIIT Security Workshop1 Chapter Authentication Applications ADAPTED FROM THE PRESENTATION by Henric Johnson Blekinge Institute of Technology,Sweden http://www.its.bth.se/staff/hjo/ henric.johnson@bth.se ATUL NEGI Dept. of CIS, University of Hyderabad

2. IIIT Security Workshop2 Outline Security Concerns Kerberos X.509 Authentication Service Recommended reading and Web Sites

3. IIIT Security Workshop3 Security Concerns key concerns are confidentiality and timeliness to provide confidentiality must encrypt identification and session key info which requires the use of previously shared private or public keys need timeliness to prevent replay attacks provided by using sequence numbers or timestamps or challenge/response

4. IIIT Security Workshop4 KERBEROS In Greek mythology, a many headed dog, the guardian of the entrance of Hades

5. IIIT Security Workshop5 KERBEROS Users wish to access services on servers. Three threats exist: –User pretend to be another user. –User alter the network address of a workstation. –User eavesdrop on exchanges and use a replay attack.

6. IIIT Security Workshop6 Quick View on “What is Kerberos?” Network authentication protocol, software allow OSs(Windows, Mac, etc.) to authenticate users and servers, and manage session-level security and encryption. IP-based service. Uses secret-key crytography to provide strong authentication for client/server applications. Kerberos is available in several commercial products and is also available as free implementation from MIT.

7. IIIT Security Workshop7 KERBEROS Provides a centralized authentication server to authenticate users to servers and servers to users. Relies on conventional encryption, making no use of public-key encryption Two versions: version 4 and 5 Version 4 makes use of DES

8. IIIT Security Workshop8 More on KERBEROS More on KERBEROS Mutual authentication: identifies principals (users and services) by requiring them to present proof of identity. Not only do users of a service identify themselves to the service, but users can challenge the service to prove its identity. Mechanism: "trusted third-party authentication". This means that the Kerberos server must know who all the parties are and how they prove their identity (their passwords).

9. IIIT Security Workshop9 More on KERBEROS More on KERBEROS Key Distribution Center This concentration of secret information makes the Kerberos server (more technically known as the or KDC) Assumption: Kerberos protocol assumes that all network traffic is vulnerable to capture, examination and substitution. It also assumes that it needs to work correctly even in the face of these challenging assumptions.

10. IIIT Security Workshop10 Summary KERBEROS on GNU/Linux Summary KERBEROS on GNU/Linux KDC server two important Kerberos daemons : Kadmind: administrative daemon for the Kerberos server. –kadmind is used by kadmin maintain database of principals and policy configuration. –kadmin allow remotely administer the Kerberos components of the server, (disallow remote logins via ssh) krb5kdc responsible for performing the role of the trusted third party arbitrator in Kerberos authentication. – When a user wants to authenticate himself to a system or service, the user requests a ticket from the KDC. A ticket is a datagram consisting of the client's identity, a session key, a timestamp, and some other information. The datagram is encrypted with the server's secret key.

11. IIIT Security Workshop11 Summary KERBEROS on GNU/Linux Client Side Summary KERBEROS on GNU/Linux Client Side Fedora derived GNU/Linux, package is krb5-workstation Configuration involves editing the /etc/krb5.conf file. In this file, specify the realm, KDC's, administrative server, logging, default domain, and KDC information. Modify the kdc.conf file, specify a location for in the krb5.conf file. The default location is /var/Kerberos/krb5kdc/kdc.conf. The kdc.conf file contains information about the encryption algorithm policy of the realm. More details refer to GNU/Linux FAQ Kerberos Infrastructure HOWTO by V. Alex Brennen

12. IIIT Security Workshop12 Kerberos Version 4 Terms: –C = Client –AS = authentication server –V = server –ID c = identifier of user on C –ID v = identifier of V –P c = password of user on C –ADc = network address of C – K v = secret encryption key shared by AS an V –TS = timestamp –|| = concatenation

13. IIIT Security Workshop13 A Simple Authentication Dialogue (1)C  AS: ID c || P c || ID v (2)AS  C:Ticket (3)C  V: ID c || Ticket Ticket = E K v [ ID c || P c || ID v]

14. IIIT Security Workshop14 Version 4 Authentication Dialogue Problems: –Lifetime associated with the ticket-granting ticket –If to short  repeatedly asked for password –If to long  greater opportunity to replay The threat is that an opponent will steal the ticket and use it before it expires

15. IIIT Security Workshop15 Version 4 Authentication Dialogue Authentication Service Exhange: To obtain Ticket-Granting Ticket (1)C  AS: IDc || IDtgs ||TS 1 (2)AS  C: E Kc [K c,tgs || ID tgs || TS 2 || Lifetime 2 || Ticket tgs ] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C  TGS: IDv ||Ticket tgs ||Authenticatorc (4) TGS  C: E Kc [K c,¨v || IDv || TS 4 || Ticket v ] Client/Server Authentication Exhange: To Obtain Service (5) C  V: Ticket v || Authenticator c (6) V  C: EKc,v[TS5 +1]

16. IIIT Security Workshop16 Overview of Kerberos

17. IIIT Security Workshop17 Request for Service in Another Realm

18. IIIT Security Workshop18 Difference Between Version 4 and 5 Encryption system dependence (V.4 DES) Internet protocol dependence Message byte ordering Ticket lifetime Authentication forwarding Interrealm authentication

19. IIIT Security Workshop19 Kerberos Encryption Techniques

20. IIIT Security Workshop20 PCBC Mode

21. IIIT Security Workshop21 Kerberos - in practise Kerberos - in practise Currently have two Kerberos versions: 4 : restricted to a single realm 5 : allows inter-realm authentication, in beta test Kerberos v5 is an Internet standard specified in RFC1510, and used by many utilities To use Kerberos: need to have a KDC on your network need to have Kerberised applications running on all participating systems major problem - US export restrictions Kerberos cannot be directly distributed outside the US in source format (& binary versions must obscure crypto routine entry points and have no encryption) else crypto libraries must be reimplemented locally

22. IIIT Security Workshop22 Where Kerberos Doesn’t Help "Denial of service" attacks are not solved with Kerberos. System Adminstrators must deal with such problems Principals must keep their secret keys secret. If an intruder somehow steals a principal's key, it will be able to masquerade as that principal or impersonate any server to the legitimate principal. "Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, Each host on the network must have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers. Principal identifiers are not recycled on a short-term basis. A typical mode of access control will use access control lists (ACLs) to grant permissions to particular principals. If a Kohl & Neuman [Page 8] RFC 1510 Kerberos September 1993 stale ACL entry remains for a deleted principal and the principal identifier is reused, the new principal will inherit rights specified in the stale ACL entry. By not re-using principal identifiers, the danger of inadvertent access is removed.

23. IIIT Security Workshop23 X.509 Authentication Service Distributed set of servers that maintains a database about users. Each certificate contains the public key of a user and is signed with the private key of a CA. Is used in S/MIME, IP Security, SSL/TLS and SET. RSA is recommended to use.

24. IIIT Security Workshop24 X.509 Formats

25. IIIT Security Workshop25 Typical Digital Signature Approach

26. IIIT Security Workshop26 Obtaining a User’s Certificate Characteristics of certificates generated by CA: –Any user with access to the public key of the CA can recover the user public key that was certified. –No part other than the CA can modify the certificate without this being detected.

27. IIIT Security Workshop27 X.509 CA Hierarchy

28. IIIT Security Workshop28 Revocation of Certificates Reasons for revocation: –The users secret key is assumed to be compromised. –The user is no longer certified by this CA. –The CA’s certificate is assumed to be compromised.

29. IIIT Security Workshop29 Authentication Procedures

30. IIIT Security Workshop30 Recommended Reading and WEB Sites www.whatis.com (search for kerberos) Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes. http://web.mit.edu/kerberos/www/dialogue.html Kohl, J.; Neuman, B. “The Evolotion of the Kerberos Authentication Service” http://web.mit.edu/kerberos/www/papers.html http://www.isi.edu/gost/info/kerberos/