CS 5950 6030 Network Security Class 32 M 11 14 05

CS 5950/6030 Network Security Class 32 (M, 11/14/05) Leszek Lilien Department of Computer Science Western Michigan University Based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides (as indicated) courtesy of: Prof. Aaron Striegel — at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. Washington Prof. Jussipekka Leiwo — at Vrije Universiteit (Free U. ), Amsterdam, The Netherlands Slides not created by the above authors are © by Leszek T. Lilien, 2005 Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

© by Leszek T. Lilien, 2005 7. Security in Networks. . . 7. 2. Threats in Networks. . . 7. 3. Networks Security Controls. . . c) Encryption i. Link encryption vs. end-to-end (e 2 e) encryption ii. Virtual private network (VPN) iii. PKI and certificates—PART 1 Class 31 2 iii. iv. v. vi. PKI and certificates—PART 2 SSH protocol SSL protocol (a. k. a. TLS protocol) IPsec protocol suite—PART 1

PKI and certificates (3) § PKI sets up: 1) Certificate authorities (CAs) 2) Registration authority 1) Certificate authority (CA) § CA can be in-house or external (commercial TTP = trusted third party) § CA is trusted § § Entities delegate to CA creation, issuance, acceptance, and revocation of their certificates CA actions: § Managing public key certificates (whole life cycle) § Issuing certificates by binding entity’s identity to its public key § § § Binding is done via CA’s digital signature § By publishing revocation lists Determining expiration dates for certificates Revoking certificates when necessary 3 © by Leszek T. Lilien, 2005

iv. SSH protocol (SSH = Secure SHell) SSH protocol v. 1 and v. 2 – provides authenticated and encrypted communication with shell/OS command interpreter § § Originally defined for Unix Replaced insecure utilities for remote access § § Such as Telnet / rlogin / rsh Protects against spoofing attacks (falsifying one end of § communication, incl. masquerading, sesssion hijacking, MITM) message modification / falsification § Involves negotiation between local and remote sites § Negotiate which encryption algorithm to use § E. g. , DES? IDEA? AES? Negotiate which authentication technique to use § § E. g. , public key? Kerberos? 4 © by Leszek T. Lilien, 2005 &

v. SSL protocol (a. k. a. TLS prot. ) (1) SSL protocol (v 3) = TLS protocol - interfaces betwen app (on client C) and TCP/IP protocols to provide server S authentication, optional C authentication, and encrypted communication channel between C and S for a session between C and S § SSL = Secure Sockets Layer / TLS = Transport Layer Security § Simple but effective – most widely used secure communication protocol on Internet (incl. WWW browsers/servers) § § Originally defined by Netscape to protect browser-to-server communication Involves negotiation between C and S § Negotiate which encryption suite to use for session § § § E. g. , DES? RC 4 w/ 128 -bit/40 -bit key? RC 2? Fortezza? [Bishop] Negotiate which hashing technique to use for session E. g. , SHA 1 or MD 5? 5 © by Leszek T. Lilien, 2005

vi. IPsec protocol suite (1) IPsec (IP Security Protocol Suite) = standard for securing § IP communications by encrypting and/or authenticating all IP packets § IPsec is public (published / scrutinized) § By design, protects against threats including: spoofing (incl. session hijacking) / eavesdropping § Choice of ciphers/hash protocols § Communicating parties negotiate which ones to use § IPsec defines some ciphers/hash as required in every IPsec implementaion 6 © by Leszek T. Lilien, 2005

IPsec protocol suite (4) Security parameter index (SPI) data structure § Resides on each host H running IPsec Used to select 1 of n SAs that exist on H § § Different SAs for concurrent communications with different remote Hs Fundamental IPsec data structures / protocols 1) AH = authentication header / AH protocol § For authentication-only IPsec service: § Authenticates S (sender ) 2) ESP = encapsulated security payload / ESP protocol § For encryption-only IPsec service OR § For combined encryption/authentication IPsec service 7 © by Leszek T. Lilien, 2005

IPsec protocol suite (5) § IPsec can be used for various crypto sessions: § VPN § e 2 e (incl. app 2 app) § For network mgmt (e. g. , for routing) § IPsec scenario § TCP layer passes conventional TCP Header & Data down to IP layer § IP layer calls upon IPsec to encapsulate conventional TCP Header & Data into ESP (encapsulated security payload) § Fig. 7 -28, p. 441 § IP layer adds IP Header § IP layer passes packet down to physical layer § Physical layer adds Physical Header & Physical Trailer 8 © by Leszek T. Lilien, 2005

End of Class 31 9 © by Leszek T. Lilien, 2005

© by Leszek T. Lilien, 2005 7. Security in Networks. . . 7. 2. Threats in Networks. . . 7. 3. Networks Security Controls. . . c) Encryption i. Link encryption vs. end-to-end (e 2 e) encryption ii. Virtual private network (VPN) iii. PKI and certificates—PART 1 Class 31 iii. iv. v. vi. Class 32 vi. IPsec protocol suite—PART 2 iii. Signed code iv. Encrypted e-mail Message content integrity controls i. Error correcting codes ii. Cryptographic checksum Strong authentication i. One-time passwords ii. Challenge-response systems iii. Digital distributed authentication iv. Kerberos d) e) 10 PKI and certificates—PART 2 SSH protocol SSL protocol (a. k. a. TLS protocol) IPsec protocol suite—PART 1

[---SKIP---] IPsec protocol suite (6) § ESP structure – includes more than just TCP Header & Data § Fig. 7 -29, p. 441 § „authenticated” — portion authenticated by IPsec with Authentication Data (Auth. Data = kind of signature) § „encrypted” — portion encrypted by IPsec § Fields within ESP: 1) SPI (unencrypted) – index for security association to be used for this pkt 2) Sequence Number (unencrypted) – sequential number, prevents pkt replay attacks 3) Payload Data – (part of) data passed fr. TCP Layer 4) Padding / Padding Length – padding necessary to inflate pkt to required fixed size (e. g. , size required by block cipher used for encryption) 11 © by Leszek T. Lilien, 2005 5) Next Header – type of data in Payload Data field 6) OPTIONAL: Authentication Data (unencrypted) – authenticates all above fields

IPsec protocol suite (7) ISAKMP (Internet Security Association Key Management Protocol) = key mgmt protocol for IPsec § § In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange) § IKE properties § Provides ways to agree on protocols, cipher and authentication algorithms, keys § § § 12 Key mgmt is always a critical element in crypto apps ISAKMP is simple, flexible, scalable Distinct key for each IPsec security association (SA) § § § © by Leszek T. Lilien, 2005 E. g. , agree as follows: protocol = EPS, cipher = triple DES; authentication alg. = SHA-1; key used for session Provides ways to manage protocols, cipher and authentication algorithms, keys Uses key exchange protocol based on Diffie. Hellman scheme

[---SKIP---] IPsec protocol suite (8) § IKE key exchange scenario (using Diffie-Hellman scheme) § X and Y know number g § X and Y choose large primes x and y, respectively § X send gx to Y / Y send gy to X § X calculates (gy)x / Y calculates (gx)y Since (gy)x = (gx)y => X and Y share secret § § Actual calculation is mod(n) — a bit more complex X and Y exchange identities & certificates § Certificates authenticate identities X and Y derive shared crypto key X and Y enter security association => they establish session IKE key exchange is very efficient § 13 © by Leszek T. Lilien, 2005 § § Can be done in 2 messages if w/o authentication Can be done in 4 messages if w/ authentication

vii. Signed code © by Leszek T. Lilien, 2005 § § Partial solution: code signed by TTP (trusted third party) § TTP appends digital signature to piece of code § PKI can be used by prospective code users to validate signature § 14 Problem: malicious active code § E. g. , malicious code on a web site for downloads Still code security not guaranteed § E. g. , March 2001 mistake of Verisign (CA) § Erronously issued two code-signing certificates to impostors masquerading as Microsoft employees § Verisign detected mistake after almost 2 months § Customers who didn’t validate certificate (by checking Verisign’s certificate revocation list) could still trust bad certificates

[---SKIP---] viii. Encrypted e-mail § E-mail msgs – like a postard that everybody who handles it between S and R can read People use envelopes for confidentiality (C in C-I-A) We can „envelope” e-mail msgs by encrypting them § Encryption protects C and can protect I § Encryption is easy, establishing good key mgmt is difficult § 2 basic key mgmt approaches: 1) Hierarchical certificate-based PKI solution § E. g. , S/MIME 2) Use of flat, individual-to-individual key exchange § § 15 E. g. , PGP E-mail security (incl. PGP and S/MIME) will be discussed soon © by Leszek T. Lilien, 2005

[---SKIP---] e) Msg content integrity controls (1) © by Leszek T. Lilien, 2005 Content integrity verification provided „for free” with encryption § § Since can’t perform meaningful data modification w/o decrypting it But attacker can modify encrypted data to make it useless § § § 16 E. g. , changing a bit of data in packet Threats to msg content integrity 1) Malicious modification that changes content in a meaningful way 2) Nonmalicious modification that changes content in a way that is not necessarily meaningful 3) Malicious modification that changes content in a way that is not meaningful NOTE: Different cases than in text! Encryption can solve the toughest case: Case (1) above EASIER TO PREVENT OR DETECT

[---SKIP---] § © by Leszek T. Lilien, 2005 Msg content integrity controls (2) Msg content integrity controls #1: DETECT Error detection and error correction codes § As discussed before („Intro to Cryptology” section) § § § Simplest error detection code: even/odd parity check More complex error detection codes: § Hash codes or Huffman codes Some detect multiple bit errors Some also pinpoint which bits are incorrect § For detecting/correcting nonmalicious changes § Can also stop some malicious attacks § 17 Does not matter whether accidentally „meaningful” or not Again does not matter whether msg changes „meaningful” or not § E. g. , attackers not knowing which code used => can’t fool it § E. g. , attacker manipulating 2 bits & thinking that we have 2– bit correction code fails if we have 3 -bit correction code More complex error detection codes can stop tougher attackers

[---SKIP---] § § Msg content integrity controls (3) [OPTIONAL] Msg content integrity controls #2: PREVENT or DETECT Cryptographic checksum / msg digest / hash § To prevent or malicious attacks on data — As discussed before („Intro to Cryptology” section) Can also detect malicious errors Can also detect nonmalicious errors Note that attacker can modify: § Modify only data bits § Modify error prevention/detection mechanism 18 © by Leszek T. Lilien, 2005

f) Strong authentication § § Networked environments as well as both ends of communication need authentication Strong authentication controls include: i. One-time passwords ii. Challenge-response systems iii. Digital distributed authentication iv. Kerberos authentication system 19 © by Leszek T. Lilien, 2005

[---SKIP---] i. One-time passwords (1) § One-time password (OTP) method § Controls wiretapping and spoofing § § § Prevents reuse of pwd captured by wiretapper Strong authentication prevents spoofing (incl. masquerading, session hijacking, MITM) Each password used only once § „Thrown away” after use § OTP uses secretly maintained pwd list OR § User has password token (PT) = device to randomly generate new pwd (e. g. ) every minute E. g. , Secure. ID device from Security Dynamics – random # every minute 20 © by Leszek T. Lilien, 2005

[---SKIP---] One-time passwords (2) § § Pwd generation for user U is based on time synchronization with PT of this particular user U § Pwd changed in sync by both U’s PT and system authenticating U § PTs of different users produce different pwd sequences Problems with OTP 1) Attacker can steal/find PT (device) 2) One-minute window of vulnerability § Wiretapper can reuse password for one minute § 21 If PT generates new pwd once per minute © by Leszek T. Lilien, 2005

[---SKIP---] ii. Challenge-response systems § Challenge-response systems solve OTP problems 1) Solve problem of stolen/lost password tokens (PTs) § Solution: PT requires a PIN § Even if stolen by attacker, PIN protects „responses” 2) Solve problem of window of vulnerability § Solution: New challenge for each use § Does not matter whether new use within one minute window or not § Challenge-response systems can be viewed as more sophisticated version of OTP § Problem: Neither OTP or C-RS protect user from rogue system 22 © by Leszek T. Lilien, 2005

[---SKIP---] iii. Digital distributed authentication (1) „Digital” from „Digital Equipment Corporation” (DEC) § Once a powerful computer company § § § Acquired (1998) by Compaq, which subsequently merged with Hewlett. Packard (2002) [Wikipedia] As of 2004 their product lines were still produced under HP name § In 1980 s DEC recognized need for authentication of nonhuman entities in distributed environment § E. g. , mutual authentication of user query processor and DB manager (process) § Goals of Digital distributed authentication: § Prevent server impersonation (e. g. , DB mgr impersonation) § Prevent interception/modific. of msgs between entities § Prevent replay of previous authentication 23 © by Leszek T. Lilien, 2005

[---SKIP---] § Digital distributed authentication (2) Architecture of Digital distributed authentication (1989): § Each server S has KPRIV-S Corresponding KPUB-S available to any process that might need authenticated channel to S § A to B communication uses KPUB-B B to A communication uses KPUB-A § A and B use sequence #s to msg replay § B can establish secret (symmetric) session key K for communication with A by: § Selecting key K § Sending E(K, KPUB-A) to A § From now on, A and B can exchange data encrypted with K 24 © by Leszek T. Lilien, 2005

iv. Kerberos authentication system (1) § Kerberos – system for authentication between intelligent processes in distributed systems (incl. C-S authentication) [K. = guard dog in Hades (Greek mythology)] § Developed at MIT (1988+) § Design goal: § Enable systems to withstand attacks in distributed systems § Basic idea of Kerberos: Central server provides tickets to requesting app § Ticket is authenticated, non-forgeable, non-replayable token => Implemented as encrypted data structure naming user U and service for which U has access permission (also contains time value, control info) 25 © by Leszek T. Lilien, 2005

Kerberos authentication system (2) § User’s Step 1: Establishing session w/ Kerberos — Fig. 730, p. 448 § U’s workstat’n sends U’s identity to Kerberos server (KS) § KS verifies that U is authorized § KS sends 2 msgs: U U 1) Msg to U, which contains: E(ST-GS + TT-GS , pwd) U § ST-GS — U’s session key for session with T-GS U § TT-GS — U’s ticket for T-GS Enables U to request service from T-GS pwd — user’s pwd (Note: used as encryption key by KS) § § U 2) Msg to T-GS, which contains: ST-GS and U’s identity (encrypted under key shared by KS and T-GS) U § ST-GS — T-GS’s session key for session with U (same as U’s session key for session with T-GS) § U U If U’s workstation can decrypt E(ST-GS + TT-GS , pwd) using its pwd, then U’s authentication succeeds 26 © by Leszek T. Lilien, 2005

Kerberos authentication system (3) § Note: KS stores users’ pwds => no need to pass pwds over network between U’s workstation and KS § Security advantage! § User’s Step 2: Access services of distributed system — e. g. , access file F — Fig. 7 -31, p. 448 § Using U’s ticket for T-GS (received fr. KS in Step 1), U sends to T-GS: U E(„request R for U’s ticket for accessing F” , ST-GS) U Note: ST-GS (U’s session key for session with T-GS obtained fr. KS in Step 1) is used to encrypt R § T-GS verifies U’s access permission. . . continued. . . 27 © by Leszek T. Lilien, 2005

Kerberos authentication system (4). . . continued. . . § If verified OK, T-GS returns to U message encrypted U under ST-GS, which contains: 1) U’s session key for session with F (really: with F’s file U server) = SF 2) U’s ticket for accessing F § Ticket is encrypted under secret key („T-GS—F key”) known only to T-GS and F’s file server § Ticket contains: U § U’s authenticated identity (T-GS knows that ST-GS is U’s key —and nobody else’s— because KS sent to T-GS U ST-GS and U’s identity tied together in Step 1) § Identification of file F § Access rights (e. g. , read permission) U § F’s session key for F’s session with U = SF (same as U’s session key for session with F) 28 © by Leszek T. Lilien, 2005 § Ticket expiration date

Kerberos authentication system (5) § Strenghts of Kerberos system § No pwds communicated over network (sent only once by user to Kerberos server & sent outside the network, e. g. , in letter) § Crypto protection against spoofing (each access request § Limited period of ticket validity (disables some long-term § Prevents replay attacks (each user’s request stamped with § Mutual authentication (user can be assured of server’s mediated by T-GS, which knows requester’s identity; this identity known based on authentication performed initiallly by Kerb. server) attacks—e. g. , brute force cryptanalysis) time of request; unreasonably old requests rejected by request servers) authenticity by requesting server’s authenticating response) 29 © by Leszek T. Lilien, 2005

Kerberos authentication system (6) § Weaknesses of Kerberos system § Requires continuous availability of trusted ticketgranting server (T-GS) § Server S’ authenticity requires trust between T-GS & S § Requires timely transactions (too quick ticket expiration will result in rejecting legitimate requests) § § Subverted workstation can replay user pwds Pwd guessing works (attacker can send initial —Step 1— authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd) Kerberos does not scale well (due to system size might need > 1 KS and/or T-GS server; coordination and security problems if more than one KS and/or more than one T-GS is needed; cf. Fig. 7 -32, p. 450) Use of Kerberos requires compatibility of all apps in a given computing environment (to date few apps are compatible with Kerberos; modifying apps to make them compatible is not feasible) 30 © by Leszek T. Lilien, 2005

End of Class 32 31 © by Leszek T. Lilien, 2005