1. AUTHENTICATION APPLICATIONS - Chapter 14 Kerberos X.509 Directory Authentication (S/MIME)

2. SERVER ATTACKS B[A] : Pretend B  A: Impersonate B(A  Server): Eavesdrop/Replay Server W/station Server W/station

3. CENTRALISED AUTHENTICATION Symmetric Key - YES Public Key - NO Central Auth. K W/stationServerW/station

4. KERBEROS Two Versions Version 4. Version 5. – Draft Internet Standard

5. KERBEROS Secure no eavesdropper / user impersonation Reliable backup / critical Transparent user unaware / password Scalable large number of clients

6. KERBEROS Trusted Third-Party Authentication Uses Needham/Schroeder scheme Fig 7.9

7. KERBEROS V4 Uses DES Complicated! To analyse: Simple More Secure V4 Auth. Dialogue  Dialogue  Dialogue

8. SIMPLE DIALOGUE Impersonations: Server Confirms Client ID Authentication Server (AS) contains User Passwords (centralised) Unique Server Keys

9. SIMPLE DIALOGUE 1. C  ID C || P C || ID V AS 2. AS  Ticket C 3. C  ID C || Ticket V Ticket = E K V [ ID C || AD C || ID V ] C : client AS : authentication server V : server AD C : client address (ticket only valid if from C) P C : client password

10. MORE SECURE DIALOGUE Re-usable Tickets? But different tickets for every server Solution: Use Ticket Granting Server (TGS)

11. MORE SECURE DIALOGUE Once/Logon 1. C  ID C || ID TGS AS 2. AS  E K C [Ticket TGS ] C (K C from users password) Once/Service 3. C  ID C || ID V || Ticket TGS TGS 4. TGS  Ticket V C Once/Service Session 5. C  ID C || Ticket V V Ticket TGS = E K TGS [ID C || AD C || ID TGS || TS 1 || lifetime 1 ] Ticket V = E K V [ID C || AD C || ID V || TS 2 || lifetime 2 ]

12. ADVANTGAGES of MORE SECURE DIALOGUE Password NOT plaintext instead, pwd confirmed via K C Uses Multiple Service-Granting Tickets One Problem: Ticket TGS could be captured Solution: Ticket TGS includes timestamp T S and lifetime

13. MORE SECURE DIALOGUE WEAKNESSES 1. Short lifetime  too many password requests Long lifetime  replay attacks 2. False servers

14. VERSION 4. AUTHENTICATION DIALOGUE Table 14.1 – Protocol Table 14.2 – Rationale 1. Protect from Captured Tickets: AS  key Client Client  key TGS  key TGS prove ID key is K c, TGS

15. VERSION 4. Note: (1) TS 1 (2) TS 2, lifetime 2 (3) Authenticator – use once – short life (authenticates ticket sender as owner) After complete dialogue, Client : Server share secret key

16. KERBEROS SERVER REQUIRES User IDs Hashed Passwords Symmetric Server Keys (registered servers)

17. KERBEROS OVERVIEW

18. INTER-REALM AUTHENTICATION Two realms share secret key (mutually registered) - needs mutual trust (Fig 14.2) Problem: Does not scale well to many realms N realms  N(N-1) secure key 2 exhanges

19. INTER-REALM AUTHENTICATION

20. KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS 1.Encryption System Dependence V4: (DES,export) V5: Ciphertext tagged with encryption id - keys tagged with type/length 2. Internet Protocol Dependence V4: requires IP addresses V5: addresses tagged with type/length (IP/ISO) 3. Message Byte Ordering V4: tagged message with ordering V5: Abstract Syntax Notation One Basis Encoding Rules

21. KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS 4. Ticket Lifetime V4: 8-bit, 5 minute units, Max = 1280 minutes V5: Start time/End time – arbitrary 5. Authentication Forwarding V4: NO Credential Forwarding V5: Credential Forwarding 6. Inter-Realm Authentication V4: O(N 2 ) keys V5: Fewer keys

22. KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (Tech) 1.Double Encryption ((2), (4) of Table 14.1) V4: Yes V5: Second encryption omitted 2. PCBC Encryption V4: Nonstandard DES mode, PCBC (vulnerable), for integrity check V5: Explicit, separate integrity + CBC mode 3. Session Keys V4: Replay risk using repeated ticket V5: Subsession key. Once only

23. KERBEROS 4 PROBLEMS, KERBEROS 5 SOLUTIONS (tech) 4. Password Attacks V4: Vulnerable Key password  Decrypt by guessing passwords V5: Vulnerable Pre-authentication makes attacks more difficult

24. KERBEROS 5 AUTHENTICATION DIALOGUE Compare Tables 14.1 and 14.3 (1),(3) new: Realm, Options (flags), Times, Nonce Times are client requests for ticket time settings (5) new: Optional Mutual Authentication (6) new: No timestamp needed - use keys instead

25. X.509 AUTHENTICATION Directory – database : network adddress, certificate,…etc Certificate: CA = E KR auth [T,ID A,KU A ] (RSA recommended) Used for S/MIME, IPSec, SSL/TLS, and SET

26. CERTIFICATE DIRECTORY CA or user  (trusted) Directory Certificate Fig 14.3a - formats Certificates unforgeable Directory of certificates used to distribute authentic user public keys

27. CERTIFICATE DIRECTORY

28. TWO CAs A B Cert X 2 Cert B E KR 1 [T,ID 1,KU 2 ] E KR 2 [T,ID B,KU B ] CA 2 (KU 2 ) CA 1 (KU 1 )  X 1 >X 2 > A wishes to obtain B’s public securely via two accesses to the directory. A initially has cert. from X 1 B initially has cert. from X 2 Having X 1 ’s pub. key gives access to X 2 ’s pub. key Having X 2 ’s pub. key gives access to B’s pub. key

29. X.509 CA HIERARCHY

30. CHAIN OF CERTIFICATES Hierarchy : Fig 14.4 Forward Certificates : e.g. W > cert of X generated by W Reverse Certificates : e.g. X > cert of W generated by X e.g. X >W >V>>Y>>Y >Z > result: A recovers B’s public key

31. CERTIFICATE REVOCATION 1.User secret key compromised 2. User no longer certified 3. CA’s certificate compromised each CA has Certificate Revocation List (CRL)

32. X.509 AUTHENTICATION Three alternatives : a) One-Way Auth. – ID A, message from A, message is for B, integrity/originality of message b) Two-Way Auth. – a) plus ID B, reply from B, integrity/originality of reply c) Three-Way Auth. – b) plus signed nonce – to avoid t/stamps - used when clocks not synchronised

33. X.509 AUTHENTICATION

34. ENCRYPTION KEY FROM PASSWORD

35. PCBC MODE