General

1
Authentication
CS 6262 Spring 02 - Lecture 16 (Thursday,
3/12/2002)
2
Password

• Proof by knowledge, sharing
• Password guessing
• On-line limit tries, alarm
• Off-line dictionary attack
• Storing passwords
• Per-node /etc/passwd
• Server authentication storage server, retrieved
  by node (yp/NIS)
• Facilitator server says yes/no

3
Address-based

• .rhosts
• node, user name
• /etc/hosts.equiv
• trusted hosts
• Threats
• break in one, break in all
• often A trusts B, then B trusts A
• address spoofing

4
Humans and Computers

• Humans
• Short, memorable key (8 characters, 48 bits),
  directly or as key for longer key
• Computers
• (Long) high-quality secret
• Hidden key (encrypted by password), directly
  (e.g., hash of the password)

5
Eavesdropping and Server Database Reading

• Public key
• Need to protect private key
• Use good password
• Eavesdropping
• Use random challenge with signing
• Server database reading
• Lamport hash

6
Trusted Intermediaries

• Cant do pair-wise authentication with secret
  key key explosion
• Key distribution center (KDC)
• Single point of failure, performance bottleneck
• Certification authorities (CAs)
• Can be off-line
• Single point of failure
• Need to manage revocation list (CRL)

7
Authentication of People

• What you know (passwords)
• What you have (keys)
• What you are (biometric devices)
• Where you are (physical)

8
Trojan Horses

• A faked login prompt to capture passwords
• Counter measures
• Make it hard to have the appearance of login
  prompt
• Use interrupts
• Prevent login by user programs

9
Authentication Tokens

• What you have
• Smart cards
• Challenge/response
• Cryptographic calculator
• Interaction through a user (typing ...)

10
Biometrics

• Accuracy
• False acceptance rate.
• False rejection rate.
• Can adversary select imposters?
• Identical twins, family members, etc.
• Retinal scanner, fingerprint reader, handprint
  reader, voiceprint, keystroke timing, signature.

11
Fingerprints

• Vulnerability
• Dummy fingers and dead fingers
• Suitability and stability
• Not for people with high probability of damaged
  fingerprints
• Not for kids growing up

12
Voice Recognition

• Single phrase
• Can use tape recorder to fake
• Stability
• Background noise
• Colds
• Use with public phones

13
Keystroke Timing

• Each person has a distinct typing timing/style
• Hand/finger movements
• Suitability
• Best done for local authentication
• Avoid network traffic delay

14
Signatures

• Machines cant match human experts in recognizing
  shapes of signatures
• Add information of timing (dynamics) of movements
• Signing or an electronic tablet

15
Kerberos V4
16
What Is Kerberos?

• Recommended reading
• http//web.mit.edu/kerberos/www/dialogue.html
• Provide cryptographic authentication in network
  environment
• Enable secure access control of networked
  resources
• Relieve users/administrators the burden of
  managing potentially many accounts and passwords

17
Kerberos Model
Realm2
H4
KDC
Realm1
KDC
Master KDC
H5
H1
H2
H6
KDC
KDC
Master KDC
Realm3
H10
H3
KDC
H7
KDC
Master KDC
H8
H9
KDC
18
Kerberos Deployment...

• KDCs are physically secured
• Kerberos libraries are distributed on all nodes
  with users, applications, and other
  Kerberos-controlled resources
• All Kerberos exchanges are protected against
  confidentiality and integrity attacks
• Kerberos-rized applications
• telnet
• rtools (rlogin, rcp, rsh)
• Network file systems (NFS/AFS)

19
Where To Start...

• Every principal has a master (secret) key
• Human users master key is derived from passwd
• Other resources must have their keys configured
  in
• Every principal is registered with the Kerberos
  server, i.e. KDC
• All principals master keys are stored in the KDC
  database, encrypted using the KDC master key

20
Tickets ...

• Every principal has a main shared secret with the
  KDC - principals master key
• Any secure communication/access among principals
  must be mediated by KDC through tickets
• How would Alice talk to bob?

21
Alice, Bob, and KDC
KDC
2
1
KAKAB, KBKAB, Alice,...
Alice
3
Bob
Ticket to Bob KBKAB, Alice,...
22
Session Key and Ticket-granting Ticket (TGT)

• Messages between a host and the KDC can be
  protected using the principals master key
• For every request to KDC from the principal
• Insists on principal retyping in the password
• Remember the principals password
• Remember the principals master key derived from
  the password
• All options are equally inadequate!

23
Session Key and TGT...

• To avoid potentially too much exposure to
  password/master key
• At initial login, a per principal session key SB
  (for bob) is requested from KDC
• SB has a limited valid time period
• A TGT for Bob is also issued by the KDC, which
  includes the session key SB and Bobs
  identification information, all encrypted using
  the KDCs master key

24
Session Key and TGT...

• Bobs Kerberos client decrypts and remembers
• SB, for subsequent message with KDC
• TGT, for reminding/convincing KDC to use SB with
  it as well
• No need for remembering/storing password
• New request to KDC must include TGT in the
  request message
• New tickets from KDC must be decrypted with SB

25
Login
2. AS_REQ
1. ltBob,passwdgt
3. create SB and TGTB KKDCBob, SB
Bobs Local Host
KDC
Bob
4. AS_REP KBSB ,TGTB
5. local host decrypts and saves SB and TGTB
26
Need A Ticket...
2. TGS_REQ access to hp1, TGTB, SBtimestamp
1. lpr -Php1
Bobs Local Host
Bob
3. create SBP decrypt TGTB verify
authenticator generate Ticket to printer for
Bob TP KPBob,KBP KDC
5. local host decrypts and obtaining
service using KBP TP
4. TGS_REP SBBob, KBP, TP
27
Accessing the Printer...
1. AP_REQ TP, KBPtimestamp
Bobs Local Host
Bob
2. decrypt TP for KBP verify authenticator
Printer Server
3. AP_REP KBPtimestamp1
28
Authentication and Global Clock Synchronization

• Authenticator KXtimestamp
• Global clock sync is implied
• Is the authenticator for TGS_REQ necessary?
• What about the AP_REQ?
• Main purposes of authenticator
• replay of old requests to the same server
• replay of request on one server to another
  (server farm, shared principals master key)

29
Replicated KDCs

• Multiple replica of KDC - availability and
  performance
• Keeping KDC databases consistent
• Single master KDC as the point of direct update
  to principals database entries
• Updated database is downloaded from the master to
  all replica KDCs
• Periodic download or on-demand

30
Will It Be Effective?

• KDC dynamic state consists of outstanding TGTs
  and tickets.
• Kerberos puts the burden of maintaining them on
  the clients - hosts/servers/grantees.
• Convince me that I did this for you...
• KDC is only involved in the initial mediation
  and it stays out of the picture once a ticket
  is issued.
• Only static state information is principals
  database - read only for all replica KDCs.

31
Database Content Protection

• Encryption is required for sensitive data
• Integrity of the database must be ensured
• Installation of masqueraded master keys
• Substitution (replay) of old databases
• Kerberos stores principals master keys encrypted
  with KDC master key
• Kerberos transmits a secure hash of the database
  with encryption, in a separate message during
  downloads

32
Multiple Trust Domains

• Single master KDC can only stretch so far...
• KDC asks people to put too much trust in it.
• Should competing commercial entities use the same
  KDC?
• .gov, .org, .edu etc, each having a different
  model of what is more trustworthy.
• Single master KDC - greatest temptation - biggest
  security risk/vulnerability.
• So comes different domains or realms.

33
Kerberos Realms

• Each realm has a different master KDC, with
  different master KDC key
• Each realm can have many replica KDCs, but all
  sharing the same KDC master key
• Two KDCs in different realms have different
  principals master key databases

34
Inter-realm Authentication
Realm1 KDC
Realm2 KDC
1. TGS_REQ Bob_at_Realm1, Alice_at_Realm2
3. TGS_REQ Bob_at_Realm1, Alice_at_Realm2
2. TGS_REP credential for Realm2 KDC
4. TGS_REP credential for Alice_at_Realm2
Bob
Alice
5. AP_REQ Bob, KAKBA, Bob,...