1. 1 Authentication Applications Behzad Akbari Fall 2010 In the Name of the Most High

2. 2 Outline Introduction Kerberos X.509 Authentication Service Recommended reading and Web Sites

3. 3 Authentication Applications Authentication functions  developed to support application-level authentication & digital signatures Kerberos  a secret-key authentication service X.509  a public-key directory authentication service

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

5. 5 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. 6 KERBEROS A centralized authentication server  From MIT  To authenticate users to servers and servers to users  Relies on conventional encryption Making no use of public-key encryption  Allows users to access services distributed in network Without needing to trust all workstations All trust a central authentication server Two versions: version 4 and 5  Version 4 makes use of DES

7. 7 Kerberos v4 Overview a basic 3rd-party authentication scheme have an Authentication Server (AS)  users initially negotiate with AS to identify self  AS provides a non-corruptible authentication credential ticket granting ticket (TGT) have a Ticket Granting server (TGS)  users subsequently request access to other services from TGS based on users’ TGT

8. 8 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 and V  TS = timestamp  || = concatenation

9. 9 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] Kv shared by AS and Sever (V) Ticket can be decrypted by Server

10. 10 Kerberos v4 Dialogue 1. obtain ticket granting ticket from AS once per session 2. obtain service granting ticket from TGS for each distinct service required 3. client/server exchange to obtain service on every service request

11. 11 Version 4 Authentication Dialogue Threat  An opponent will steal the ticket-granting ticket and use it before it expires Countermeasure  How to decide the lifetime associated with the ticket- granting ticket? If too short  repeatedly asked for password If too long  greater opportunity to replay

12. 12 Version 4 Authentication Dialogue (1) C  AS IDc || ID tgs || TS 1 (2) AS  C E(K c,[K c, tgs ll ID tgs ll TS 2 ll Lifetime 2 ll Ticket tgs ]) Ticket tgs = E (K tgs, [K c, tgs ll ID c ll AD c ll ID tgs ll TS 2 ||Lifetime 2 ]) Summary of Kerberos Version 4 Message Exchanges (a) Authentication Service Exchange to obtain ticket-granting ticket (3)C  TGS ID v || Ticket tgs || Authenticator c (4)TGS  C E(K c, tgs [K c,v ll ID v ll TS 4 ll Ticket v ]) Ticket tgs = E(K tgs,[K c, tgs ll ID c ll AD c ll ID tgs ll TS 2 ll Lifetime 2 ]) Ticket v = E(K v,[K c, v ll ID c ll AD c ll ID v ll TS 4 ll Lifetime 4 ]) Authenticator c = E(K c, tgs [ID c ll AD c ll TS 3 ]) (b) Ticket-Granting Service Exchange to obtain service-granting ticket (5)C  V Ticket v || Authenticator c (6)V  C E(K c,v, [TS 5 + 1]) (for mutual authentication) Ticket v = E (K v, [K c, v ll ID c ll AD c ll ID v ll TS 4 ll Lifetime 4 ]) Authenticator c = E (K c,v, [ID c ll AD c ll TS 5 ]) (c) Client/Server Authentication Exchange to obtain service

13. 13 Version 4 Authentication Dialogue The client requests a TGT to AS with message(1) To handle the problem of captured TGT and the genuiness of ticket presenter, –the AS provides both the TGS and the client with a secret information, called a session key, in a secure manner through message(2) –then the key is used to prove the identity of the client to TGS (1) C  AS IDc || ID tgs || TS 1 (2) AS  C E(K c,[K c, tgs ll ID tgs ll TS 2 ll Lifetime 2 ll Ticket tgs ]) Ticket tgs = E(K tgs, [K c, tgs ll ID c ll AD c ll ID tgs ll TS 2 || Lifetime 2 ]) (a) Authentication Service Exchange to obtain ticket-granting ticket

14. 14 Version 4 Authentication Dialogue C transmits an authenticator (A) used only once with very short lifetime in message(3) –Replay attack is encountered. The TGS decrypts the A and the ticket with keys, - The contents from the both are checked if those match - The ticket is a way to distribute keys securely - The A proves the client’s identity. Reply from TGS includes a session key shared b/w C and V. –It says that the key can be used by only C and V for authentication. (3) C  TGS ID v || Ticket tgs || Authenticator c (4) TGS  C E(K c, tgs [K c,v ll ID v ll TS 4 ll Ticket v ]) Ticket tgs = E(K tgs,[K c, tgs ll ID c ll AD c ll ID tgs ll TS 2 ll Lifetime 2 ]) Ticket v = E(K v,[K c, v ll ID c ll AD c ll ID v ll TS 4 ll Lifetime 4 ]) Authenticator c = E(K c, tgs [ID c ll AD c ll TS 3 ]) (b) Ticket-Granting Service Exchange to obtain SGT

15. 15 Version 4 Authentication Dialogue The message(5) is similar to message(3) –V examines the contents of A and the ticket if the ticket presenter is genuine The mutual authentication is done with message(6) –The value of timestamp from the A is incremented by 1 and encrypted by the session key. –The contents of the message assures C that this is not a replay –The session key is used to encrypt future messages b/w the two or to exchange a new random session key for that purpose (5) C  V Ticket v || Authenticator c (6) V  C E(K c,v, [TS 5 + 1]) (for mutual authentication) Ticket v = E(K v,[K c, v ll ID c ll AD c ll ID v ll TS 4 ll Lifetime 4 ]) Authenticator c = E(K c,v, [ID c ll AD c ll TS 5 ]) (c) Client/Server Authentication Exchange to obtain service

16. 16 Version 4 Authentication Dialogue

17. 17 Kerberos Realm A Kerberos realms is a set of managed nodes that share the same Kerberos DB. A Kerberos realm consists of : –A Kerberos server, with all user IDs and their passwords in its DB –A number of clients, registered with the Kerberos server –A number of application servers, sharing a key and registered with the Kerberos server Networks of clients and servers under different administrative organizations constitute typically different realms.

18. 18 Kerberos Realms with Multiple Kerberi For two realms to support interrealm auth, –The Kerberos server in one realm shares a secret key with the sever in the other realm. The two Kerberos servers are registered with each other –The participating servers in the second realm must trust the Kerberos server in the first realm One problem with above approach : –It does not scale well to many realms –It requires N(N-1)/2 secure key exchanges for interoperation of all realms

19. 19 Request for Service in Another Realm

20. 20 Password-to-key Transformation

21. 21 PCBC Mode

22. 22 Kerberos - in practice currently have two Kerberos versions: v4  restricted to a single realm v5  allows inter-realm authentication  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

23. 23 X.509 Authentication Service A 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.  used in S/MIME, IP Security, SSL/TLS and SET.  RSA is recommended to use.

24. 24 X.509 Certificates issued by a Certification Authority (CA), containing:  version (1, 2, or 3)  serial number (unique within CA) identifying certificate  signature algorithm identifier  issuer X.500 name (CA)  period of validity (from - to dates)  subject X.500 name (name of owner)  subject public-key info (algorithm, parameters, key)  issuer unique identifier (v2+)  subject unique identifier (v2+)  extension fields (v3)  signature (of hash of all fields in certificate) notation CA >  denotes certificate for A signed by CA

25. 25 X.509 Formats

26. 26 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.  Nobody other than the CA can modify the certificate without this being detected.

27. 27 CA Hierarchy both users share a common CA  they are assumed to know its public key If X > and X >, then A has B’s certificate (public key)  otherwise CA's must form a hierarchy A signed by X1, B signed by X2  If A doesn’t know X2’s public key  B’s certificate is useless to A  A can obtain X2’s public key from X1 if X2 is also signed by X1  X1 >X2 > -- certification path use certificates linking members of hierarchy to validate other CA's  each CA has certificates for clients (forward) and parent (backward)  each client trusts parents certificates  enable verification of any certificate from one CA by users of all other CAs in hierarchy

28. 28 X.509 CA Hierarchy A establishes a certification path to B: X >W >V >Y >Z > B establishes a certification path to A: Z >Y >V >W >X > If X >, then (i) A knows X’s public key and (ii) A can get all the public keys signed by X.

29. 29 Revocation of Certificates Reasons for revocation:  The users private key is assumed to be compromised.  The user is no longer certified by this CA.  The CA’s certificate is assumed to be compromised.

30. 30 Authentication Procedures X.509 includes three alternative authentication procedures –intended for use across a variety of applications –to use public-key signature –assumed for the two parties to know each other’s KU The three procedures : –One-way authentication –Two-way authentication –Three-way authentication

31. 31 One-Way Authentication A single transfer of information from A to B Verification of the followings: 1. A’s identity and the message generated by A 2. the message intended for B 3. the integrity and originality of the message At minimum : TS t A, nonce r A, B’s identity, A’s signature AB 1. A{t A,r A,ID B,sgnData,E[PU b,K ab ]}

32. 32 Two-Way Authentication Verification of the followings: 4. B’s identity and the message generated by B 5. the message intended for A 6. the integrity and originality of the reply Permission of verification for both parties Reply includes A’s nonce, TS and nonce from B AB 1. A{t A,r A,ID B,sgnData,E[PU b,K ab ]} 2. B{t B,r B,ID A,r A,sgnData,E[PU a,K ba ]}

33. 33 Three-Way Authentication The signed copy of the nonce r B in the final MSG –TS need not to be checked –Replay attack can be detected by nonces echoed to each other AB 1. A{t A,r A,ID B,sgnData,E[PU b,K ab ]} 2. B{t B,r B,ID A,r A,sgnData,E[PU a,K ba ]} 3. A{r B }

34. 34 X.509 Version 3 Has been recognized that additional information is needed in a certificate –e-mail/URL, policy details, usage constraints Include a number of optional extensions added to version 2 format –rather than continue to add fields to a fixed format Each extension consists of extension identifier, criticality indicator, extension value

35. 35 Public Key Infrastructure PKI – the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography. based on X.509

36. 36 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/