Authentication Technology Survey: Kerberos, LDAP, Client-side PKI and Other Solutions

1. Authentication Technology Survey: Kerberos, LDAP, Client-side PKI and Other Solutions Paul B. Hill Information Services and Technology Massachusetts Institute of Technology

2. Abstract • Deploying enterprise authentication can be done in many ways. This session will provide a survey of the available technologies including Kerberos, LDAP, and client-side public key infrastructure authentication. 2

3. The origin of my perspective • MIT developed Kerberos in the mid-80s. • Clear text passwords for email were eliminated before 1991 on the central email servers • Kerberos v4 and v5 currently in use at MIT • Deployed X.509 certificates for users in 1996, these are used as the primary means of web authentication at MIT 3

4. The Authentication Problem • The authentication problem is simple to describe but hard to solve: Two parties are communicating and one wishes to establish its identity to another. 4

5. Authentication vs. Authorization • Authentication and Authorization are two separate mechanisms • Authentication is sometimes mistakenly thought to imply Authorization • Authentication simply identifies a party • Authorization defines whether they can perform a certain action • Authorization necessarily relies on Authentication • Authentication alone does not imply Authorization 5

6. Basic methods to perform authentication • Something you have--a physical token like a key. • Something you know--a secret, e.g., a password • Something you are--some physical characteristic particular to you. • Combinations of the above 6

7. A Basic Survey • Clear Text Passwords • One Time Passwords • Challenge Response • Anonymous Key Exchange • Zero Knowledge Password Proofs • Passwords over HTTPS • Mutual Public Key Systems 7

8. Attacks • Sniffing • Post authentication hijacking • Online password guessing • Offline dictionary attacks • Man in the middle • Replay • Downgrade • Cryptographic (brute force, known plain text,…) 8

9. Countermeasures, sniffing • Encryption done wrong doesn’t solve much • Post authentication hijacking, password guessing, offline dictionary attacks, replay, downgrade, man-in-the-middle • Doing encryption correctly is difficult • Don’t roll your own 9

10. Protocols supporting clear text passwords • Telnet • HTTP (basic authentication) • SASL (password mode) • RLOGIN • POP (among other mechanisms) • IMAP (among other mechanisms) • Too many others to enumerate 10

11. Countermeasures, online password guessing • Limit the number of tries • Self imposed denial of service attack • Impose a delay • Auditing with linkage to intrusion detection or adaptive filtering • One time passwords • Tokens / biometrics 11

12. Countermeasures, offline dictionary attacks • Deny access to the password digest • Encrypt the password file, shadow password file • Iteration of the encryption so that more attempts are required • Salting • Stronger passwords • Pre-authentication 12

13. Countermeasures, replay • Timestamps, Sequence numbers, nonces • Transaction caching and evaluation • One time passwords 13

14. Countermeasures, man-in-the-middle • Very careful protocol design • Mutual authentication • Avoid anonymous key exchange (can be mitigated under some circumstances) 14

15. Countermeasures, downgrade • Do not assume that negotiation will result in the strongest setting, assume it will result in the weakest • System administration • Configure systems to reject settings, mechanisms, or protocols that present an unacceptable risk to your environment 15

16. Countermeasures, post authentication hijacking • Careful protocol design • Careful system administration 16

17. Countermeasures, cryptographic • Don’t attempt to design your own cryptography • Public review of algorithms and implementations • Understand proper usage 17

18. Single Sign On • This can mean many things to many people • What are the pros and cons? 18

19. LDAP Authentication • Using LDAP as a central place to make an authentication decision • Beware of the entire transport path used to transmit the password to the LDAP server • Client to application server • Application server to LDAP server • LDAP server to other backend • Lack of mutual authentication between client and server 19

20. Biometrics • How and where is the verification data stored? • How is the data transmitted over the network? • Is the protocol subject to man in the middle attacks? • How will you deal with warrants and subpoenas ? 20

21. SecureID • Two factor, one time password • Not a smart card, not public key • Time dependent key, LCD displays pseudo-random number that changes every 30 seconds to 2 minutes, synchronized with authentication server • User enters password and the number displayed on the LCD • Replay vulnerability lasting from ~30 seconds to ~ 2 minutes 21

22. SSH – Secure Shell • Most deployments are subject to man in the middle attacks the first time the client ever initiates a connection to a given server • Key caching is used to prevent subsequent MITM attacks • Some deployments are also subject to subsequent connection hijacking 22

23. Passwords with SSL/TLS • If the server doesn’t have a certificate • If the server uses a self signed certificate • If the server’s certificate isn’t signed by a CA trusted by the end user • This is equivalent to most SSH deployments • Connection hijacking, in conjunction with man in the middle can result in password exposure 23

24. Passwords with SSL/TLS (2) • Properly configured server results in a secure connection between client and server • Password then sent using either Digest or Basic authentication or in a form posting • What does the application server do with the password? 24

25. Mutual authentication with public key • SSL/TLS, IPSec, SSH • The server only knows the user’s public key. It cannot forge an authentication message from the client • Pros and Cons • Can provide authentication between unknown parties • Key storage – protect the private key 25

26. Smart Cards and Smart Tokens • Provides two factor authentication • Protects the private key, which never leaves the card or token 26

27. Mutual authentication with public key • Architectural implications for multi-tier applications 27

28. Kerberos • Challenge response system • Trusted third party model • Key Distribution Center (KDC) • Please physically secure the KDC 28

29. Kerberos • In case you haven’t noticed, Kerberos has evolved over the past 15 years and rapidly since 1999 29

30. Scalability? • 500,000 users in a single realm • KDCs with five year up times • A KDC must be available (as do CRL servers in PKI) • Master-slave vs. Multi-master 30

31. Some features • Provides for confidentiality, data integrity, and mutual authentication • Defenses against replay attacks • Multiple encryption types: DES, RC4-HMAC, AES, avoid 3DES 31

32. Weaknesses • KDC must be secured • 5 minute replay window, mitigated by replay cache feature • Offline dictionary attacks, mitigated by pre-authentication • Prove that client has some knowledge about the password before the KDC responds to the AS request • Does not attempt to address host security 32

33. An artifact that is a strength • Historically security problems have been addressed by deploying a change to the KDCs • PKI problems are normally addressed by deploying changes to every machine 33

34. Kerberos in conjunction with other methods • IPSec • PKinit • SecureID 34

35. Kerberos vs. NTLM and NTLMv2 • Provides for mutual authentication • efficiency • Perfect forward secrecy (zero knowledge proof) issues 35

36. Telnet FTP POP IMAP Rlogin AFS, NTFS, NFS lprNG SASL SAP Oracle MS SQL Server 2003 SSH HTTP (getting out there) Exchange (current) Applications need to be “Kerberized” 36

37. Multi-tier applications • Ticket forwarding • Microsoft’s constrained delegation • What about WebSSOs that are Kerberos “like”? 37

38. Cross realm • Possible to configure a realm so that principals in one realm can authenticate to principals in another realm • Transitive cross-realm authentication supported • A KDC cannot generate a ticket for a principal in a realm other than its own 38