380 likes | 576 Views
Authentication Technology Survey: Kerberos, LDAP, Client-side PKI and Other Solutions. Paul B. Hill Information Services and Technology Massachusetts Institute of Technology. Abstract.
E N D
Authentication Technology Survey: Kerberos, LDAP, Client-side PKI and Other Solutions Paul B. Hill Information Services and Technology Massachusetts Institute of Technology
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
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
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
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
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
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
Attacks • Sniffing • Post authentication hijacking • Online password guessing • Offline dictionary attacks • Man in the middle • Replay • Downgrade • Cryptographic (brute force, known plain text,…) 8
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
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
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
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
Countermeasures, replay • Timestamps, Sequence numbers, nonces • Transaction caching and evaluation • One time passwords 13
Countermeasures, man-in-the-middle • Very careful protocol design • Mutual authentication • Avoid anonymous key exchange (can be mitigated under some circumstances) 14
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
Countermeasures, post authentication hijacking • Careful protocol design • Careful system administration 16
Countermeasures, cryptographic • Don’t attempt to design your own cryptography • Public review of algorithms and implementations • Understand proper usage 17
Single Sign On • This can mean many things to many people • What are the pros and cons? 18
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
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
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
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
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
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
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
Smart Cards and Smart Tokens • Provides two factor authentication • Protects the private key, which never leaves the card or token 26
Mutual authentication with public key • Architectural implications for multi-tier applications 27
Kerberos • Challenge response system • Trusted third party model • Key Distribution Center (KDC) • Please physically secure the KDC 28
Kerberos • In case you haven’t noticed, Kerberos has evolved over the past 15 years and rapidly since 1999 29
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
Some features • Provides for confidentiality, data integrity, and mutual authentication • Defenses against replay attacks • Multiple encryption types: DES, RC4-HMAC, AES, avoid 3DES 31
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
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
Kerberos in conjunction with other methods • IPSec • PKinit • SecureID 34
Kerberos vs. NTLM and NTLMv2 • Provides for mutual authentication • efficiency • Perfect forward secrecy (zero knowledge proof) issues 35
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
Multi-tier applications • Ticket forwarding • Microsoft’s constrained delegation • What about WebSSOs that are Kerberos “like”? 37
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