each party shares own master key with KDC ... forwards thi

1
Lecture 4 Authentication

• Anish Arora
• CSE5473
• Introduction to Network Security

2
Overview

• Password based schemes
• EKE
• Secure Shell (SSH)
• Address based schemes
• TCP, subject to syn attacks
• Key based schemes
• Lamport Hash
• Needham Schroeder and Dennis AS
• Kerberos, an old system

3
Password-based authentication

• Proof by knowledge sharing
• convenient for dealing with people (unaided by
  smart end devices)
• but approach is risky when applied to machine
  authentication e.g., cellular phone password
  communications subject to cloning
• mechanisms needed to support single password
  across multiple hosts and resources
• key problem in network context eavesdropping
• on the wire or at entry
• by reading files where passwords are stored
• by guessing online (even with limitations on
  number of tries)
• by performing offline searches

4
Password guessing

• Passwords are easily guessed
• 123456
• names of family members, initials
• secret
• stress related words (deadline, work)
• sports teams or terms
• payday, bonkers
• current season
• ethnic group
• repeated characters
• obscenities, sexual terms
• Online to deal with this
• limit tries (deny further access, raise alarm,
  delay subsequent access)
• audit access history or tell users about their
  previous usage

5
Password guessing

• Offline
• storing pwd file is unsafe, so Unix approach was
  to store hash(pwd) file and make that file world
  readable
• but this is subject to dictionary attack ?
• capture file of hash(pwd) search whether any
  easy/wellknown pwds hash is in file
• a technique use to mitigate the dictionary attack
  is to add salt
• salt is a non-secret randomly chosen value per
  user
• store hash(pwd, salt), instead of storing
  hash(pwd)
• so users with same pwd have different stored
  value
• salt makes it difficult to search for some
  account whose pwd is easy, but not more difficult
  for guessing a particular users password
• shadow file is used to store the pwd file in root
  accessible domain and x-ed out pwd file in
  public domain

6
Passwords as keys how to compute hashed
passwords

• Humans prefer short, memorable key
• (common is 8 characters, 48bits)
• Can use directly or as basis for constructing
  longer key
• directly as 56-bit key
• cant use for RSA p,q
• but can use as seed for rng
• Unix used this approach (crypt3)
• instead of encrypting password, used password
  based key to encrypt a well known value, with DES
• derived 56 bit key from first 8 (7-bit ASCII)
  characters
• encryption performed 25 times
• brute force attack on alphanumeric password is
  (262610)8 248 , lends itself to dictionary
  attacks

7
Password storage

• System storage options
• per node /etc/passwd
• at one location authentication storage server,
  retrieved by node e.g. Yellow Pages / NIS
  (Network Information Service)
• at facilitator node CA server
• Authenticating node needs to
• store hash only
• or store table encrypted with good, protected key
• but needs to be in non-volatile memory (e.g.,
  ROM)

8
Password-based authentication protocols

• Send pwd, compare against hash(pwd)
• Send hash(pwd), compare against hash(pwd)
• Send hash(pwd), compare against hash(hash(pwd))
• Send hash(pwd) as secret in challenge/response

9
Strong password protocols using passwords to
exchange keys

• No user-specific information stored at a server,
  so someone who impersonates or eavesdrop cannot
  gain information for dictionary attack
• Recall Diffie Helman had authentication issues
• EKE (encrypted key exchange) jk share weak
  secret h(pwd)
• j?k h(pwd)gxj mod p encrypt with
  h(pwd) as key
• k?j h(pwd)gxk mod pKC1 C1 is
  challenge, K gxjxk mod p
• j?k KC1,C2 C2 is challenge
• k?j KC2

10
Strong password protocols another pasword-based
key exchange

• SPEKE (simple password exponential key exchange)
  
• jk share weak secret h(pwd)
• j?k h(pwd)j mod p
• k?j choose challenge C1
• h(pwd)k mod p, C1
• j?k choose challenge C2 K h(pwd)jk mod p
• KC1, C2
• k?j KC2

11
Secure Shell (SSH)

• Precursor for client c to logon to server s with
  username and password in remote setting
• also based on Diffie Helman
• server authentication prevents client from
  divulging password
• assumes c knows the public key of s
• Protocol
• c?s gxc mod p
• c computes K gxcxs mod p
• H hash(params gxc mod
  p gxs mod p K)
• s?c (B.s, gxs mod p, R.s H)
• c computes K, extracts H from
  B.sR.sH, and checks hash

12
Secure Shell

• j?k h(pwd)gxj mod p encrypt with
  h(pwd) as key
• k?j h(pwd)gxk mod pKC1 C1 is
  challenge, K gxjxk mod p
• j?k KC1,C2 C2 is challenge
• k?j KC2

13
Address-based authentication

• Instead of sending passwords, assume identity is
  derived from the network address from where
  data arrives
• Wrt authorization, user on remote location is
  mapped to local user, and given same privileges
• Unix implementations of these ideas
• per node
• maintain equivalent machines in
  /etc/hosts.equiv file accounts on node j are the
  same as node k
• so accounts must have same name on equivalent
  nodes get equal privileges
• per user
• maintain list of ltaddress of remote machine,
  account name at remote machine, local namegt
• .rhosts file in each users home directory, same
  privileges are given as would be given to
  corresponding local account

14
Threats in address-based authentication

• Address Spoofing Sending on behalf of other
  addresses is possible at data link or network
  layer
• Such forging may be dealt with as follows
• e.g., on a ring or a star, detection of link
  level forging is easy
• e.g., ingress router may check whether source
  address is valid
• by per-link configuration of routers to check
  whether source addresses are as expected, but
  this is expensive to implement
• if all routers are trusted (!), then by
  calculating this per link information from a
  routing database

15
Threats in address-based authentication

• Receiving the messages of others addresses also
  possible
• trivial in broadcast environment
• possible when interceptor is in the path
• but link address checking of all possible
  messages to discard those that dont belong to
  source may be hard
• when not in path, by injecting routing messages
  to attract source traffic
• e.g. source routing feature of IP allow source
  to specify intermediate destinations
• interceptor can propose itself to be on source
  route
• return traffic too will follow source route and
  can be received in this way

16
TCP-based Authentication

• TCP not intended for use as an authentication
  protocol
• But IP address in TCP connection often used for
  authentication
• One mode of IPSec uses IP address for
  authentication
• This can cause problems
• This material is from Mark Stamps Information
  Security book

17
TCP 3-way Handshake
SYN, SEQ a
SYN, ACK a1, SEQ b
ACK b1, data
Bob
Alice

• Recall the TCP three way handshake
• Initial SEQ number must be random
• Why? See the next slide

18
TCP Authentication Attack
1. SYN, SEQ t (as Trudy)
2. SYN, ACK t1, SEQ b1
3. SYN, SEQ t (as Alice)
5. ACK b21, data
Bob
Trudy
5.
5.
4. SYN, ACK t1, SEQ b2
5.
Alice
5.
19
TCP SYN Attack (contd.)

• Trudy cannot see what server Bob sends, but she
  can send packets to Bob while posing as Alice
• Trudy must prevent Alice from receiving Bobs
  packets (or else connection will terminate)
• If password (or other authentication) required,
  this attack fails
• If TCP connection is relied on for
  authentication, then attack succeeds
• Bad idea to rely on TCP for authentication

20
TCP Authentication Attack
Initial SEQ numbers Mac OS X
Random SEQ numbers

• If initial SEQ numbers not very random
• possible to guess initial SEQ number
• and previous attack will succeed

21
Key-based authentication

• As discussed before
• These are used to convince parties of each others
  identity and to exchange session keys
• May be one-way or mutual
• one-way allows sender receiver not to be in
  communication at same time, e.g. email
• Primary issues are
• confidentiality to protect session keys
• timeliness to prevent replay attacks
• May use public keys, shared keys, passwords,
  even hash functions

22
Replay attacks

• where a valid signed message is copied and later
  resent
• simple replay
• repetition that can be logged
• repetition that cannot be detected
• backward replay without modification
• countermeasures include
• use of sequence numbers (sometimes impractical)
• timestamps (needs synchronized clocks)
• challenge/response (using unique nonce)

23
One-way authentication with Lamports hash

• No public key cryptography
• But still safe from eavesdropping database
  reading (on servers)
• Useful in asymmetric environments
• e.g. Alice is client stores pwd
• Bob is server stores username, n,
  hashn(pwd)
• The protocol
• j?k j
• k?j n
• j?k hashn-1pwd
• k compares hash of received value with its
  stored value
• discards old value and stores decremented n
  received value

24
Lamports hash

• Can use salt with hash
• S/KEY is a deployed version of this scheme
• Scheme is vulnerable to small n attack
• Mal sends mltn to j, gets hashm-1(pwd) from j
• uses this hash value to authenticate itself as to
  k
• Use of asymmetry to decrease processing at j
• send list of hash(pwd), hash2(pwd),,
  hashn-1(pwd) to j, now cant fool j
  into sending earlier value
• this idea is used in sensor networks

25
Login with shared secret

• A version of one-way authentication
• k?j str
• j?k S.jk ltstrgt , where S can be hash
• subject to password attack
• compromise of database at k lets j be
  impersonated
• include identity of j in response if
  protocol used in symmetric settings
• Another version
• k?j S.jk ltstrgt
• j?k str , where S.jk is reversible (e.g.
  DES)
• allows off-line guessing of S
• if str has non random part, j can
  authenticate k

26
Login with shared secret

• Yet another version
• j?k S.jk lttimestampgt
• assumes that clocks are synchronized
• stateless
• replay attack ? remember messages received in
  skew window
• must prevent the clock of k from being forced
  back ? secure network clock sync
• replay attack ? several servers with same secret
  (so include server name)
• can use message digest instead of encryption, so
  send timestamp in clear

27
One-way authentication using symmetric encryption

• refine use of KDC but cant have final exchange
  of nonces
• 1. j?KDC j, k, N1
• 2. KDC?j S.j S, k, N1, S.k S, j
• 3. j?k S.k S, j , SM
• does not protect against replays
• could rely on timestamp in message, though email
  delays make this problematic

28
One-way authentication using public-keys

• use a digital signature with a digital
  certificate
• j?k M, R.jH(M), R.AS T, j, B.j
• i.e., message, signature, certificate
• can encrypt message if confidentiality a concern,
  
• either via sending instead of M B.kM
• or by using encrypted session key B.k S,
  SM

29
Mutual authentication using symmetric encryption

• As discussed in Lecture 3, use a two-level
  hierarchy of keys
• Usually with a trusted Key Distribution Center
  (KDC)
• each party shares own master key with KDC
• KDC generates session keys used for connections
  between parties
• master keys used to distribute these to them

30
A flaw in the original protocol

• original version of third-party key distribution
  protocol for session between j and k mediated by
  KDC had a flaw
• protocol
• 1. j?KDC N1
• 2. KDC?j S.j S, N1, S.k S, j
• 3. j?k S.k S, j
• 4. k?j S N2
• 5. j?k S f(N2)

31
The flaw

• Protocol is vulnerable to a replay attack if an
  old session key has been compromised
• then message 3 can be resent convincing k that is
  communicating with j
• modifications to address this require
• timestamps (Denning 81)
• using an extra nonce (Neuman 93)
• Kerberos v.4 is based on this protocol, but with
  timestamps other main used version of Kerberos
  is v.5

32
Mutual authentication using public-key encryption

• have a range of approaches based on the use of
  public-key encryption
• need to ensure have correct public keys for other
  parties
• using a central Authentication Server (AS)
• various protocols exist using timestamps or
  nonces

33
Denning AS Protocol

• Denning 81 presented the following
• 1. j?AS j, k
• 2. AS?j R.AS j, B.j, T, R.AS k, B.k, T
• 3. j?k R.AS j, B.j, T, R.AS k, B.k, T,
  B.k S, T
• note session key is chosen by A, hence AS need
  not be trusted to protect it
• timestamps prevent replay but require
  synchronized clocks

34
Kerberos

• trusted key server system from MIT
• provides centralised private-key trusted
  third-party authentication in a distributed
  network
• allows users access to services distributed
  through network
• without needing to trust all workstations
• rather all trust a central authentication server
• two versions in use 4 5
• 4 only for TCP/IP networks, greater installed
  base
• 5 is more complex, not just for TCP/IP networks,
  more functionality
• implementation KDC on secure node subroutine
  library for applications (eg telnet, rtools, NFS)
  to authenticate users

35
Kerberos requirements

• first published report identified its
  requirements as
• security
• reliability
• transparency
• scalability
• implemented using an authentication protocol
  based on Needham-Schroeder

36
Kerberos 4 overview

• for TCP/IP networks
• has an Authentication Server (AS)
• users initially negotiate with AS to identify
  self
• AS provides a non-corruptible authentication
  credential (ticket granting ticket TGT)
• has a Ticket Granting server (TGS)
• users subsequently request access to other
  services from TGS on basis of users TGT
• symmetric keys are typically DES

37
Kerberos 4 overview
38
v4 protocol

• j?AS j, tgs
• AS?j Sj Sj,TGS , STGS Tj,TGS
• j?TGS Sj,TGS Aj,k ,
  STGS Tj,TGS, k
• TGS?j Sj,TGS Sj,k , Sk Tj,k
• j?k Sj,k Aj,k ,
  Sk Tj,k
• Issues
• Mal can cache replay old authenticators, since
  servers may not store all valid tickets
• Clocks can be fooled to correct their time, so
  replay may succeed
• Mal can execute server program that impersonates
  Kerberos records passwords

39
Kerberos 4 replicas

• login session defined as period from login to
  logout
• principals are users and resources
• principals share password (humans)/secret key
  (network devices) with KDC
• KDC may be replicated
• replicas share same master KDC key
• have identical databases of principals secret
• this makes coordination an issue if any one
  replica is down/slow
• master database (whose entries are encrypted
  under KDC master key) is exchanged in clear,
  integrity via secure hash

40
Kerberos realms

• a Kerberos environment consists of
• a Kerberos server
• a number of clients, all registered with server
• application servers, sharing keys with server
• this is termed a realm
• typically a single administrative domain
• principals are divided in realms
• each has its own KDC database
• if there are multiple realms, their KDCs must
  share keys and trust (although each will have a
  separate master key)
• register each KDC as a principal of each other
  realms KDC

41
Kerberos realms

• if Alice in realm A wishes to talk to Bob in
  realm B
• Alice gets from her KDC a ticket to KDC in realm
  B
• KDC of realm B is registered as principal in KDC
  of realm A
• Alice sends a tgs request to KDC of realm B along
  with her ticket
• the source realm of Alice, A, is part of a
  principals name
• so the KDC of B knows which key to use
• no chaining of realms
• otherwise principal of realm A could go via realm
  B to realm C even if A and C do not share master
  keys
• prevents rogue AS from impersonating not just
  its own principals but every principal by
  claiming to be the penultimate KDC in a chain

42
Kerberos for privacy and integrity

• encrypt and protect (with modified version of DES
  CBC)
• if only integrity desired, DES CBC residue may be
  too expensive so used own algorithm for checksum
• algorithm not documented (but not yet broken)
• checksum is hash over session key message
  transmit
• message checksum
• may not have weak collision freedom, may be
  reversible and so leak session key

43
Kerberos network layer addresses

• TGT ticket contains Alices network layer
  address
• Bob checks address of connect request matches
  tickets
• Alice cant handoff ticket to Ted
• Ted cant steal session key and use it from
  elsewhere
• prevent eavesdropping/replay with 5 min window
• Issues
• does not work with mobile nodes
• does not support delegation
• addresses easily spoofable

44
Kerberos message format

• timestamp seconds since 1970-1-1 expires in
  2038
• standard Unix format
• D bit direction (used to avoid reflection
  attack)
• lifetime octet, units of 5 min (up to 21 hours,
  not enough)
• 5 ms granularity timestamp (for quick auth.
  generation)
• session key 8 byte DES key
• B bib byteorder (little or big endian)
• padding, network address, message type, version
  numbers

45
Kerberos v5

• developed in mid 1990s
• provides improvements over v4
• addresses environmental shortcomings
• fixed network protocol, fixed encryption
  algorithm, fixed byte order, short ticket
  lifetime, no delegation, no inter-realm chaining
• addresses technical deficiencies
• weak encryption, session keys, password attacks
• specified as Internet standard RFC 1510

46
Kerberos 5 environmental improvements

• message layout no longer fixed, uses ASN data
  representation
• allows use of non IP networks
• allows use of different encryption schemes
• may delegate rights to access object, for limited
  time
• e.g. so Alice could log onto node Bob and then
  telnet onto Carol
• involves exchanging TGT with one with different
  network address (including multiple/all
  addresses)
• forwards this ticket to Bob
• ticket lifetime can now be unlimited (17 bytes),
  tickets can be renewed (but only) before they
  expire, can be postdated
• useful for long running applications
• but cannot be revoked

47
Kerberos 5 realm hierarchy and chaining

• hierarchy of realms and chaining is allowed in v5
• in v4, each realm must be registered in source
  realm
• now we allow Alice in realm A to impersonate any
  principal
• to limit impersonation, list transited domains in
  ticket
• destination should reject request if any transit
  KDC is not trusted
• transit domains are encrypted, reject request if
  final domain does not match key used to encrypt
• realm tree policy share key with parents and
  childrem
• trust is based on allowing only shortest path
  through tree
• to identify tree, use (IP/X.500) names in the
  domain hierarchy
• cross links may be used as shortcuts

48
v5 protocol

• j?AS j, tgs
• AS?j Sj Sj,TGS, STGS Tj,TGS
• j?TGS Sj,TGS Aj,k , STGS Tj,TGS
• TGS?j Sj,TGS Sj,k , Sk Tj,k
• j?k Sj,k Aj, , Sk Tj,k
• optimizations
• no longer encrypting tickets, authenticators
• ticket target no longer in ticket