Authentication Technology Survey: Kerberos, LDAP, Clientside 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.

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

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.

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
  

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

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

8
Attacks

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

9
Countermeasures, sniffing

• Encryption done wrong doesnt solve much
• Post authentication hijacking, password guessing,
  offline dictionary attacks, replay, downgrade,
  man-in-the-middle
• Doing encryption correctly is difficult
• Dont roll your own

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

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

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

13
Countermeasures, replay

• Timestamps, Sequence numbers, nonces
• Transaction caching and evaluation
• One time passwords

14
Countermeasures, man-in-the-middle

• Very careful protocol design
• Mutual authentication
• Avoid anonymous key exchange (can be mitigated
  under some circumstances)

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

16
Countermeasures, post authentication hijacking

• Careful protocol design
• Careful system administration

17
Countermeasures, cryptographic

• Dont attempt to design your own cryptography
• Public review of algorithms and implementations
• Understand proper usage

18
Single Sign On

• This can mean many things to many people
• What are the pros and cons?

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

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 ?

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

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

23
Passwords with SSL/TLS

• If the server doesnt have a certificate
• If the server uses a self signed certificate
• If the servers certificate isnt 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

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?

25
Mutual authentication with public key

• SSL/TLS, IPSec, SSH
• The server only knows the users 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

26
Smart Cards and Smart Tokens

• Provides two factor authentication
• Protects the private key, which never leaves the
  card or token

27
Mutual authentication with public key

• Architectural implications for multi-tier
  applications

28
Kerberos

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

29
Kerberos

• In case you havent noticed, Kerberos has evolved
  over the past 15 years and rapidly since 1999

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

31
Some features

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

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

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

34
Kerberos in conjunction with other methods

• IPSec
• PKinit
• SecureID

35
Kerberos vs. NTLM and NTLMv2

• Provides for mutual authentication
• efficiency
• Perfect forward secrecy (zero knowledge proof)
  issues

36
Applications need to be Kerberized

• Telnet
• FTP
• POP
• IMAP
• Rlogin
• AFS, NTFS, NFS
• lprNG
• SASL

• SAP
• Oracle
• MS SQL Server 2003
• SSH
• HTTP (getting out there)
• Exchange (current)

37
Multi-tier applications

• Ticket forwarding
• Microsofts constrained delegation
• What about WebSSOs that are Kerberos like?

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