Lecture 4: Authentication

1. Lecture 4: Authentication Anish Arora CIS651 Introduction to Network Security

2. 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

3. Password guessing • Passwords are easily guessed: • 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

4. 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

5. 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)

6. 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

7. Passwords as keys • 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

8. 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

9. 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

10. Threats in address-based authentication • Receiving the messages of others’ addresses also possible: • trivial in 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 • interceptor can propose itself to be on source route • return traffic too will follow source route and can be received in this way

11. 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

12. 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…

13. TCP Authentication Attack 1. SYN, SEQ = t (as Trudy) 2. SYN, ACK = t+1, SEQ = b1 3. SYN, SEQ = t (as Alice) 5. ACK = b2+1, data Bob Trudy 5. 5. 4. SYN, ACK = t+1, SEQ = b2 5. Alice 5.

14. TCP SYN Attack (contd.) • Trudy cannot see what server Bob sends, but she can send packets to Bob while posing asAlice • 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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›

23. 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

24. 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)›

25. 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

26. 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

27. 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

28. 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

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

30. 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

31. Kerberos 4 overview

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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