Network Security

1. Network Security CPSC6128 – Lecture 7 IKE/SSL VPNs

2. IKE

3. Internet Key Exchange • In previous examples, we manually established IPsec SAs in IPsec endpoints Example SA SPI: 12345 Source IP: 192.168.1.100 Dest IP: 192.168.2.100 Protocol: ESP Encryption algorithm: 3DES HMAC algorithm: SHA-1 Encryption key: 0x7f5c146b… HMAC key: 0x9a01d45…. • IKE is used to establish SAs automatically: • SPI number, protocol, algorithms, & keys • Also provides mutual authentication

4. IKE more (2) • lots of flexibility & options • accommodating everyone • SSL handshake has less flexibility and complication • From Kaufman, Perlman, Speciner: • “IKE took many years to come out of IETF. The original contenders…would have been just fine in practice. But due to committee politics, neither one was chosen and instead IKE/ISAKMP emerged, almost a decade after the work began, with a protocol so complex and a specification so incomprehensible that nobody had the patience to understand what was being decided upon, and so nobody had objections. The result had lots of ambiguities and flaws, although the world did manage to have interoperable implementations…”

5. IKE more (3) • Authentication (proof who you are) with either • pre-shared key (PSK) or • PKI (pubic/private keys and certificates) • With PSK • both sides start with PSK • run IKE to authenticate each other and • obtain IPsec SAs, including session keys • With PKI • both sides start with public/private key pair and certificates • run IKE to authenticate each other and • obtain IPsec SAs (normally one in each direction) • Racoon in lab

6. IKE more (4) • IKE has two phases • Phase 1: Establish bi-directional IKE SA • Note: IKE SA different from IPsec SA • Use Diffie Hellman to generate a shared key • Phase 2: • the IKE peers use the secure channel established in Phase 1 • to negotiate Security Associations on behalf of other services like IPsec • Phase 1 has two modes • Aggressive mode • uses fewer messages • No identity protection • Main mode • provides identity protection (encrypts certificates) and • is more flexible

7. Recall: Diffie-Hellman • Allows two entities to agree on shared key • But does not provide encryption • p is a large prime; g is a number less than p. • p and g are made public • Alice and Bob each separately choose 512-bit random numbers, SA and SB. • the private keys • Alice and Bob compute public keys: • TA = gSAmod p ; TB = gSBmod p ;

8. Diffie-Helman (2) • Alice and Bob exchange TA and TB • Alice computes (TB)SA mod p • Bob computes (TA)SB mod p • shared secret: • S = (TB)SA = (TA)SB = gSASB mod p • Even though Trudy might sniff TBand TA , Trudy cannot easily determine S.

9. IKE Phase 1: example with main mode and PSKuse slide 103 • IKE can be done in 8 different ways; see Kaufman et al. this is just 1 way. • Nonces for replay attack • Note neither user’s identity is revealed to sniffer crypto proposal for IKE SA crypto proposal accepted ga mod p, nonceA gb mod p, nonceB compute K =f(gab mod p, nonceA, nonceB) K {“Alice,” HMAC(exchanged data, PSK)} K {“Bob,” HMAC(exchanged data, PSK)}

10. IKE: Phase 2 • IKE SA now in place • provides encrypted, authenticated channel • Phase 2 takes place over this secured channel • Goal is to establish IPsec SAs • Alice & Bob negotiate crypto algorithms for IPsec SA • Alice sends SPIA to Bob and Bob sends SPIB to Alice • Both sides compute keys for IPsec SA • Function of IKE SA key and nonces

11. IKE Overview (Again) Threat Mitigation Denial of Service Replay Man in Middle Perfect Forward Secrecy (PFS)

12. Perfect Forward Secrecy • If a key is compromised • only the specific session it protected will be revealed to an attacker • The security of previous or future encrypted sessions is not affected • Keys are securely deleted after use • Without these keys, there is no way that cipher text captured can be decrypted • It is actually computational forward secrecy

13. IKE Overview • A hybrid protocol • that uses part Oakley and SKEME inside ISAKMP framework • used to establish a shared security policy, and • authenticated keys for services • Combination of • ISAKMP • Internet Security Association and Key Management Protocol • a protocol to establish framework authentication and key exchange • RFC 2408 • SKEME • a key exchange technique that provides anonymity, reputability, and quick key refreshment • Oakley • Oakley Key Determination Protocol • Describe a series of key exchange • RFC 2412

14. ISAKMP • Defines procedures and packet formats • to establish, negotiate, modify or delete security associations • Defines payloads • for exchanging key generation and authentication data • ISAKMP message • consists of header followed by one or more payloads • Implementations • must support UDP for the transport protocol

15. ISAKMP

16. ISAKMP Header Each payload begins with the following generic payload header:

17. ISAKMP Payloads • SA payload • used to begin establishment of SA • Proposal Payload • Protocol, SPI and transform • Transform payload • Key exchange payload • Identification payload • Certificate payload • Hash payload • Signature payload • Nonce payload • Notification payload • error or status messages • Delete payload

18. ISAKMP Message Example

19. Oakley • Oakley is a refinement of Diffie-Hellman • Uses cookies to thwart Denial-of-Service attacks • Enables two parties to negotiate group • global parameters of Diffie-Hellman • Uses nonce's to protect against replay attacks • Enables exchange of Diffie-Hellman public key values • Authenticates Diffie-Hellman exchange • to thwart man-in-the-middle attack

20. Oakley ---How Cookie Exchange thwart DoS attack An attacker can forge source address and force victim to do numerous Diffie-Hellman exponentiations which can overwhelm it Cookie exchange requires that each side send a pseudo-random number, the cookie, in the initial message If source address forged, attacker does not get victim’s cookie and hence cannot proceed Diffie-Hellman exponentiation done only after successful cookie exchange

21. Oakley – Cookie Generation • Cookie generation must satisfy the following: • Cookie must depend on specific parties • Only issuing entity must be able to generate cookies that are accepted by it • Cookie generation and verification methods must be fast • Recommended method • fast (MD5) hash of • source and destination IP address • source and destination ports, and • locally generated secret value

22. Oakley - Authentication • Multiple methods of authentication supported • Digital Signatures • exchange is authenticated by signing mutually obtainable hash • Hash generated over important parameter like ID’s and nonces • Public-key encryption • Exchange is authenticated by encrypting critical parameters with sender’s private key • Symmetric-Key encryption • Exchange is authenticated by encrypted symmetric key exchanged by some out-of-band method

23. Five Steps of IPSec Operation • Interesting Traffic • the VPN devices recognize the traffic to protect • IKE Phase 1 • The VPN devices negotiate an IKE security policy and establish a secure channel • IKE Phase 2 • The VPN devices negotiate an IPSec security policy used to protect the IPSec data • Data Transfer • The VPN devices apply security services to traffic and then transmit the data • Tunnel terminated • The tunnel is torn down

24. Step 1 – Interesting Traffic

25. Step 2 – IKE Phase 1

26. First and Second ExchangeIKE Policy Sets and Establishing a Shared Secret Negotiates Matching IKE Transform sets to protect IKE exchange A DH exchange is performed to establish the shared secret

27. Third Exchange – Authenticate Peer Identity • Peer authentication methods • Pre shared keys • RSA Signatures • RSA Encrypted Nonces

28. Step 3 - IKE Phase 2 Negotiates IPSec security parameters IPSec transform sets Establishes IPSec SAs Periodically renegotiates IPSec SAs to ensure security Optionally performs an additional DH exchange

29. IPSec Transform Sets A transform set is a combination of algorithms and protocols that enact a security policy for traffic.

30. SAs • •SA DB • Destination IP • SPI • Protocol (ESP or AH) • •Security Policy DB • Encryption Algorithm • Authentication Algorithm • Mode • Key Lifetime

31. SPI/SAs

32. Security Association Database (SAD) • Endpoint holds state of its SAs in a SAD • where it can locate them during processing • With n endpoints, 2 + 2n SAs in R1’s SAD • When sending IPsec datagram • R1 accesses SAD to determine how to process datagram • When IPsec datagram arrives to R2 • R2 examines • SPI in IPSec datagram • indexes SAD with SPI, and • processes accordingly

33. SA Lifetime SA need to be changed periodically The longer the SA is not changed the more vulnerable it becomes Can be changed based on time or data transmitted

34. IPSec Sequence Numbers • For new SA, sender initializes seq# to 0 • Each time datagram is sent to SA: • Sender increments seq# counter • Places value in seq# field • Goal is to prevent attacker from sniffing and replaying a packet

35. Step 4 – IPSec Session SAs are exchanged between peers The negotiated security services are applied to the traffic

36. Step 5 – Tunnel Termination • A tunnel is terminated • By an SA lifetime timeout • If the packet counter is exceeded • Removes IPsec SA

37. Example: STEP 1 – IKE Phase 1 Policy IP R1 R2 IPsec 3.1.0.0/24 3.2.0.0/24 2.0.0.1/30 2.0.0.2/30 crypto isakmp policy 1 authentication pre-shared hash sha encr aes 128 group 2 ! crypto isakmp key 123 address 2.0.0.2 crypto isakmp policy 1 authentication pre-shared hash sha encr aes 128 group 2 ! crypto isakmp key 123 address 2.0.0.1

38. Example: STEP 2 – IKE Phase 2 Policy IP R1 R2 IPsec 3.1.0.0/24 3.2.0.0/24 2.0.0.1/30 2.0.0.2/30 crypto ipsec transform-set ts esp-aes 128 esp-sha-hmac ! access-list 101 permit ip 3.1.0.0 0.0.0.255 3.2.0.0 0.0.0.255 ! crypto map cm 10 ipsec-isakmp set peer 2.0.0.2 match address 101 set transform-set ts crypto ipsec transform-set tsesp-aes 128 esp-sha-hmac ! access-list 101 permit ip 3.2.0.0 0.0.0.255 3.1.0.0 0.0.0.255 ! crypto map cm 10 ipsec-isakmp set peer 2.0.0.1 match address 101 set transform-set ts

39. STEP 3 – Applying the VPN PolicySite-2-Site Configuration IP R1 R2 IPsec 3.1.0.0/24 3.2.0.0/24 2.0.0.1/30 2.0.0.2/30 interface serial 1/0 ip address 2.0.0.1 255.255.255.0 crypto map cm ! ip route 3.2.0.0 255.255.255.0 2.0.0.2 interface serial 1/0 ip address 2.0.0.2 255.255.255.0 crypto map cm ! ip route 3.1.0.0 255.255.255.0 2.0.0.1

40. SSL

41. Widely deployed security protocol Supported by almost all browsers and web servers https Tens of billions $ spent per year over SSL Originally designed by Netscape in 1993 Number of variations: TLS: transport layer security, RFC 2246 Provides Confidentiality Integrity Authentication Original goals: Had Web e-commerce transactions in mind Encryption (especially credit-card numbers) Web-server authentication Optional client authentication Minimum hassle in doing business with new merchant Available to all TCP applications Secure socket interface SSL: Secure Sockets Layer

42. Application Application SSL TCP TCP IP IP Normal Application Application with SSL SSL and TCP/IP • SSL provides • application programming interface (API) to applications • C and Java SSL libraries/classes readily available

43. . KS( ) + + - KB(KS ) KA KB + + . - KA( ) . - KA(H(m)) H( ) . + KB( ) Could do something like PGP: KS m m Internet KS • But want to send byte streams & interactive data • Want a set of secret keys for the entire connection • Want certificate exchange part of protocol: • handshake phase

44. Toy SSL: a simple secure channel • Handshake: • Alice and Bob use their certificates and private keys to authenticate each other and exchange shared secret • Key Derivation: • Alice and Bob use shared secret to derive set of keys • Data Transfer: • Data to be transferred is broken up into a series of records • Connection Closure: • Special messages to securely close connection

45. Toy: A simple handshake hello • MS = master secret • EMS = encrypted master secret certificate KB+(MS) = EMS

46. Toy: Key derivation • It is bad to use same key for more than one cryptographic operation • Use different keys for message authentication code (MAC) and encryption • Four keys: • Kc = encryption key for data sent from client to server • Mc = MAC key for data sent from client to server • Ks = encryption key for data sent from server to client • Ms = MAC key for data sent from server to client • Keys • derived from key derivation function (KDF) • Takes master secret and (possibly) some additional random data and creates the keys

47. s = shared secret s s message message message H( ) H( ) compare Recall MAC • Recall that HMAC is a standardized MAC algorithm • SSL uses a variation of HMAC • TLS uses HMAC

48. Toy: Data Records • Why not encrypt data in constant stream as we write it to TCP? • Where would we put the MAC? • If at end, no message integrity until all data processed • For example, with instant messaging • how can we do integrity check over all bytes sent before displaying? • Instead, break stream in series of records • Each record carries a MAC • Receiver can act on each record as it arrives • Issue • in record, receiver needs to distinguish MAC from data • Want to use variable-length records length data MAC

49. Toy: Sequence Numbers • Attack • Attacker can capture and replay record or re-order records • Solution • put sequence number into MAC: • MAC = MAC(Mx, sequence||data) • Note: no sequence number field • Attacker could still replay all of the records • Solution: Use random nonce

50. Toy: Control information • Truncation attack: • attacker forges TCP connection close segment • One or both sides thinks there is less data than there actually is • Solution • record types, with one type for closure • type 0 for data; type 1 for closure • MAC = MAC(Mx, sequence||type||data) type data MAC length