Transcript Document

Lecture 4: Authentication
Anish Arora
CSE5473
Introduction to Network Security
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
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
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
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 pwd’s
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 user’s password
 shadow file is used to store the pwd file in root accessible
domain and “x”-ed out pwd file in public domain
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
 can’t 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 (26+26+10)8 ~
248 , lends itself to dictionary attacks
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)
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
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): j&k share weak secret h(pwd)
j→k:
h(pwd)‹gxj mod p›
k→j:
h(pwd)‹gxk mod p›;K‹C1› … C1 is challenge, K= gxjxk mod p
j→k:
K‹C1,C2›
k→j:
K‹C2›
… encrypt with h(pwd) as key
… C2 is challenge
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.s‹R.s‹H››, and checks hash
Secure Shell
•
•
j→k:
as key
h(pwd)‹gxj mod p›
… encrypt with h(pwd)
k→j:
h(pwd)‹gxk mod p›;K‹C1› … C1 is challenge, K=
gxjxk mod p
•
j→k:
K‹C1,C2›
•
k→j:
K‹C2›
… C2 is challenge
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 <address of remote machine, account name at remote machine,
local name>
 .rhosts file in each user’s home directory, same privileges are given as would
be given to corresponding local account
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
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 don’t 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
o
interceptor can propose itself to be on source route
 return traffic too will follow source route and can be received in this
way
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 Stamp’s Information Security
book
TCP 3-way Handshake
SYN, SEQ a
SYN, ACK a+1, SEQ b
ACK b+1, data
Bob
Alice
Recall
the TCP three way handshake:

Initial SEQ number must be random

Why? See the next slide…
TCP Authentication Attack
Bob
Trudy
5.
5.
5.
5.
Alice
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 Bob’s 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
TCP Authentication Attack
Random SEQ numbers
Initial SEQ numbers
Mac OS X
 If initial SEQ numbers not very random…

possible to guess initial SEQ number…

and previous attack will succeed
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
One-way authentication with Lamport’s 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-1‹pwd›
k:
compares hash of received value with its stored value
discards old value and stores decremented n & received value
Lamport’s hash
•
Can use salt with hash
•
S/KEY is a deployed version of this scheme
•
Scheme is vulnerable to ”small n attack”:
•

Mal sends m<n 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 can’t fool j into sending “earlier” value

this idea is used in sensor networks
Login with shared secret
A version of one-way authentication:
k→j: str
j→k: S.jk <str>
, 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 <str>
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
Login with shared secret
Yet another version:
j→k: S.jk <timestamp>
•
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
One-way authentication using symmetric encryption
•
•
refine use of KDC but can’t 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› , S‹M›
does not protect against replays
 could rely on timestamp in message, though email delays make
this problematic
One-way authentication using public-keys
•
use a digital signature with a digital certificate:
j→k: M, R.j‹H(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.k‹M›
or by using encrypted session key:
B.k ‹S›, S‹M›
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
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)›
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
Mutual authentication using public-key encryption
•
have a range of approaches based on the use of publickey encryption
•
need to ensure have correct public keys for other parties
•
using a central Authentication Server (AS)
•
various protocols exist using timestamps or nonces
Denning AS Protocol
•
•
•
Denning 81 presented the following:
1. j→AS:
j, k
2. AS→j:
R.AS ‹ j, B.j, T›,
3. j→k:
R.AS ‹ j, B.j, T›, R.AS ‹ k, B.k, T›, B.k ‹S, T›
R.AS ‹k, B.k, T›
note session key is chosen by A, hence AS need not be trusted
to protect it
timestamps prevent replay but require synchronized clocks
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
Kerberos requirements
•
first published report identified its requirements as:
 security
 reliability
 transparency
 scalability
•
implemented using an authentication protocol based on
Needham-Schroeder
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
Kerberos 4 overview
v4 protocol
j→AS:
j,
AS→j:
Sj ‹ Sj,TGS , STGS ‹Tj,TGS››
j→TGS:
Sj,TGS ‹ Aj,k› ,
TGS→j:
Sj,TGS ‹ Sj,k , Sk ‹Tj,k››
j→k:
Sj,k ‹ Aj,k › ,
tgs
STGS ‹Tj,TGS›,
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
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
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 realm’s KDC
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 principal’s 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 it’s own principals
but every principal by claiming to be the penultimate KDC in a
chain
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
Kerberos network layer addresses
•
TGT & ticket contains Alice’s network layer address
•
Bob checks address of connect request matches ticket’s
 Alice can’t handoff ticket to Ted
 Ted can’t 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
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
Kerberos v5
•
developed in mid 1990’s
•
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
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
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
v5 protocol
j→AS:
j, tgs
AS→j:
Sj ‹ Sj,TGS›,
j→TGS:
Sj,TGS ‹ Aj,k› , STGS ‹Tj,TGS›
TGS→j:
Sj,TGS ‹ Sj,k› , Sk ‹Tj,k›
j→k:
Sj,k ‹Aj, › ,
STGS ‹Tj,TGS› ›
Sk ‹Tj,k›
optimizations:

no longer encrypting tickets, authenticators

ticket target no longer in ticket