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› … encrypt with h(pwd) as key

k→j: h(pwd)‹gxk mod p›;K‹C1› … C1 is challenge, K= gxjxk mod p

j→k: K‹C1,C2› … C2 is challenge

k→j: K‹C2›

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: h(pwd)‹gxj mod p› … encrypt with h(pwd) as key

• k→j: h(pwd)‹gxk mod p›;K‹C1› … C1 is challenge, K= gxjxk mod p

• j→k: K‹C1,C2› … C2 is challenge• k→j: K‹C2›

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

destinationso 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

Alice Bob

SYN, SEQ a

SYN, ACK a+1, SEQ b

ACK b+1, data

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

TCP Authentication Attack

Alice

BobTrudy

1. SYN, SEQ = t (as Trudy)2. SYN, ACK = t+1, SEQ = b13. SYN, SEQ = t (as Alice)

4. SYN, A

CK = t+1, S

EQ = b 2

5. ACK = b2+1, data

5.

5.

5.

5.

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 numbersMac 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 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

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

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, 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

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›, 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