Title: each party shares own master key with KDC ... forwards thi
1Lecture 4 Authentication
- Anish Arora
- CSE5473
- Introduction to Network Security
-
2Overview
- 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
3Password-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
4Password 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
5Password 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
6Passwords 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
7Password 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)
8Password-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
9Strong 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
10Strong 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
11Secure 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
12Secure 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
13Address-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
14Threats 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
15Threats 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
16TCP-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
17TCP 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
18TCP 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.
19TCP 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
20TCP 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
21Key-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
22Replay 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)
23One-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
24Lamports 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
25Login 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
26Login 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
27One-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
28One-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
29Mutual 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
30A 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)
31The 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
32Mutual 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
33Denning 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
34Kerberos
- 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
35Kerberos requirements
- first published report identified its
requirements as - security
- reliability
- transparency
- scalability
- implemented using an authentication protocol
based on Needham-Schroeder
36Kerberos 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
37Kerberos 4 overview
38v4 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
39Kerberos 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
40Kerberos 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
41Kerberos 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
42Kerberos 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
43Kerberos 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
44Kerberos 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
45Kerberos 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
46Kerberos 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
47Kerberos 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
48v5 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