Outline 0 Topic 4.1: Securing Real-Time Communications 0 Topic 4.2: Transport Layer Security 0 Topic 4.3: IPsec and IKE 2
Securing Real-time Communications 0 In a real-time protocol, two parties negotiate interactively to (mutually) authenticate each other And may need to provide: 0 Establishment of a security association (session keys) 0 Perfect forward secrecy 0 Clogging protection 0 Escrow-foilage 0 Endpoint identity hiding 0 Session resumption 0 3
Establish Security Association 0 Two parties establish a secure session after authentication 0 Need a sequence number against packet replays 0 Different from TCP sequence numbers 0 Need a session key against session hijacking 0 Both parties should contribute to the session key for freshness and against impersonation 0 Reset before SN wrap around 0 Good key even only one party has a good random key generator 4
Perfect Forward Secrecy (PFS) 0 A protocol is PFS if an eavesdropper cannot decrypt a session after the session ends, even if the eavesdropper can record the entire encrypted session and obtain the long-term secret between the two parties subsequently 0 Kerberos? 0 Session key transport with RSA encryption? 0 How to achieve PFS? 0 Use temporary session key 0 Not derivable from information stored at the node after the session concludes 0 Forget the session key after the session 5
Perfect Forward Secrecy (PFS) 0 E.x.: Diffie-Hellman with signatures 0 Each party signs their D-H share 0 After agreeing on the session key, both parties forget the private numbers: a and b 0 How PFS is provided? [Alice, g a mod p] Alice [Bob, g b mod p] Bob hash(g ab mod p) hash(1, g ab mod p) 6
Escrow-Foilage Protection 0 Key Escrow: Communicating parties have to store their long-term keys with a third-party 0 Escrow-Foilage: Key stored at the third party is used maliciously 0 Escrow-Foilage Protection is to preventing a passive eavesdropper from decrypting a conversation between two parties even if the attacker has prior knowledge of their long-term key 0 Anything with PFS will have escrow-foilage protection against a passive attacker 7
Denial-of-Service Attacks 0 DoS attacks 0 Imposter launches DoS attacks with forged IP addresses 0 The purpose is to use up a server s resource so it cannot respond to legitimate traffic 0 E.x.: TCP SYN flood attack 0 If attacker can make a server do DH exponentiation by just initiating a session, DoS is made easy 8
Clogging Protection 0 Server responds to a session request with a cookie = Hash(IP address, server s secret) 0 Initiator should reply with the right cookie to continue 0 How can the attacker receive the packet sent back to a forged address? 0 Attacker have to either reveal its address or abort the attack 0 Stateless: the server is not required to keep state 0 Server only checks if c = H(IP address, server s secret key) 0 In practical use, SYN cookie also contains a timestamp (a slow counter) 0 Cannot prevent attacks from real IPs 9
Clogging Protection 0 To continue authentication, server requires initiator to solve a puzzle 0 Solving is slow, but verification is fast 0 E.x.: given MD5(x) = y, x =? 0 Make it hard for an attacker to simulate legitimate users 0 Onerous for a single user but too expensive to do at large scale 0 Slow down both non-hostile initiators and the attacker 0 However, clients computation power vary 0 Works well against single attacker DoS attack 0 However, it cannot defend coordinated DDoS attacks 10
Endpoint Identifier Hiding 0 Some apps require hiding identity against eavesdropper 0 Use anonymous Diffie-Hellman exchange 0 First use an DH exchange anonymously 0 Use the shared key to encrypt the rest of the session 0 Passive attackers cannot know the identities 0 Any problem? I want to talk to you, g a mod p K = g ab mod p okay, g b mod p K = g ab mod p { Alice, [g a mod p] Alice } K { Bob, g b mod p Bob } K 11
Endpoint Identifier Hiding 0 Subject to man-in-the-middle attack 0 Active attacker can still learn identities of one or both (how) 0 It can still protect one party s identity (why) 0 Who s ID is protected in previous protocol? 0 Whose ID to protect? 0 Initiator (Alice): Bob s identity is probably already known 0 Responder (Bob): anyone can be Alice to initiate the conversation 12
Live Partner Reassurance 0 Communication partner is vulnerable to replays 0 However, using different D-H exponents for different sessions is costly 0 DH exponentiation is expensive: problem for servers and low-end clients 0 Use same DH exponents but different nonces 0 Incorporate nonce into the session key 0 E.g., K = H(nonce, gab mod p) 0 Is nonce a cookie? 13
Parallel Key Computation 0 Bob can send two messages together. Why not? 0 To ensure Alice computes g ab at the same time as he does [g a mod p] Alice [g b mod p] Bob g ab mod p {Bob s message} g ab mod p {Alice s message} 14
Other Issues 0 Session resumption use previously established session keys to bypass expensive public-key authentication 0 Lotus Notes scheme: derive K AB from a long-term key S and use it to generate session keys 0 Digital DASS scheme:alice Bob: X AB = [{K} Bob ] Alice 0 Bob only compares the received X AB and stored X AB 0 Plausible deniability 0 It leaves a proof that Alice talked to Bob if Bob s name is signed by Alice s private key 0 For plausible deniability 0 Don t use signatures for authentication 0 Use shared secret or public encryption keys 15
Other Issues 0 Crypto negotiation to negotiate cryptographic algorithms and parameters 0 E.g., key size, prime in D-H, compression algorithm 0 Problem: Trudy may force Alice and Bob to use weak crypto 0 If it is available as an option for both parties 0 Tampering with messages and removing stronger options 0 Solution: re-confirm the list of crypto protocols after authentication 0 IKE 16
Outline 0 Topic 4.1: Securing Real-Time Communications 0 Topic 4.2: Transport Layer Security 0 Topic 4.3: IPsec and IKE 17
Network Layered Model 0 Hierarchical layers 0 Each layer uses the services of the lower layer and provides services to the upper layer 0 No security in original design User Process OS Application Layer (HTTP, FTP, SMTP, ) Transport Layer (TCP, UDP) Network Layer (IP) Data Link Layer (PPP, Ethernet,...) Physical Layer 18
Enhance Security as an Add-on 0 At which layer to implement security protocols? 0 Above the OS (layer 4 security) 0 Add a security wrapper around TCP interface: sockets 0 No need to modify the OS 0 Minimum modification to applications 0 However, TCP is below crypto 0 Errors/attacks at lower layers will not be addressed 0 However, no cooperation between SSL and TCP 0 E.g., DoS attack is still possible: the whole TCP session can be forced to reset by inserting a single bogus packet 19
Enhance Security as an Add-on 0 At which layer to implement security protocols? 0 Within the OS (layer 3 security) 0 A more secure implementation above IP: IPsec 0 Secure individual packets independently 0 No modifications to applications 0 However, security of IPsec is underutilized 0 Only supply what IP does 0 No authentication other than IP addresses 0 Better security requires modifying applications 20
Security Protocols Application Layer 0 SSL/TLS, SSH Layer 4 insert SSL (TLS or SSH) 0 IPsec Layer 3 TCP IPsec OS IP 0 Application layer security 0 Client/Server (Kerberos) 0 E-mail (PEM, PGP) 0 Lower Layers 21
SSL/TLS 0 Secure Sockets Layer and Transport Layer Security protocols 0 Same protocol design, but different crypto algorithms 0 SSL 1.0 internal Netscape design in 1994, unreleased 0 SSL 2.0 Netscape, Nov 1994, flawed but used 0 SSL 3.0 Netscape, Nov 1996, developed with public review 0 TLS 1.0 Internet standard RFC 2246, Jan 1999, based on SSL 3.0 0 TLS 1.1 Apr 2006 0 TLS 1.2 Aug 2008, currently in use 0 TLS 1.3 a new version in design (1-RTT handshake) 0 A de facto standard for Internet security 0 Deployed in every Web browser, VoIP, payment systems, distributed systems, 22
SSL/TLS 0 Attacker model: assume an attacker completely owns the network 0 He may control Wi-Fi, DNS, routers, his own websites, 0 He may be able to listen to any packet, modify packets in transit, inject his own packets into the network 0 The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications (RFC 5246) 23
SSL/TLS Protocols Ports https 443 smtps 465 nntps 563 ldaps 636 pop3s 995 0 Provides security atop TCP layer 0 Usually a thin layer between TCP and HTTP/FTP/.. 0 Use TCP for reliable, end-to-end transport 0 Applications need modifications 0 Each has an assigned TCP port 0 Use certificate authentication ftp-datas 889 ftps 990 imaps 991 24
Conceptual Protocol I am Alice, cipher I support, R Alice Certificate, cipher I choose, R bob {S} bob, {keyed hash of handshake msg} Keyed hash of handshake msg data protected with session key 25
SSL Security Services 0 Peer authentication 0 Security parameter negotiation 0 Generation / distribution of session keys 0 Data confidentiality 0 Data integrity 26
In Practice: SSL as Protocol 0 Control Protocols Suite 0 Handshake Protocol: use public key crypto to establishes secret session keys 0 Change Cipher Suite Protocol 0 Alert Protocol: generate warnings or fatal exceptions 0 Data Protocols 0 Record Protocol 0 SSL architecture provides two layers 27
Handshake Protocol 0 The purpose of the handshake protocols is to 0 Negotiate protocol version and cipher suite 0 Encryption, hash algorithms, authentication and key establishment methods 0 Entity authentication 0 Server are nearly always authenticated, client are more rarely 0 Establishment of a fresh, shared secret (master key) 0 The shared secret is used to derive more keys 0 Two main types of handshakes in TLS: 28
Client Server Handshake Protocol Structure ClientHello [Certificate], ClientKeyExchange, [CertificateVerify] ChangeCipherSpec HandshakeFinished ServerHello [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone ChangeCipherSpec HandshakeFinished 29
Phase 1 0 ClientHello (in plaintext) 0 version: highest version supported by client 0 random: timestamp, plus 28 random bytes 0 session_id: 0 = new session;!0 = refresh 0 Cipher_suite: set of cryptographic algorithms supported 0 Compression_method 0 ServerHello (in plaintext) 0 Highest protocol version supported by both client and server 0 cipher_suite: select the strongest from those offered by client 0 compression algorithms 0 random 0 session_id: a new session ID (optional if resumption is needed) 30
Phase 2 0 Certificate 0 Contains server s public key certificate(s) 0 ServerKeyExchange (used in SSL v3 and TLS) 0 Server signs a ephemeral public key with its long-term public key 0 E.g., a RSA or Diffie-Hellman public key depending on the chosen crypto suite 0 CertificateRequest 0 If client authentication is required 0 Server sends a list of CAs it trusts (and the key types) 0 ServerHelloDone 0 Completion of server handshake message 31
Client Server Handshake Protocol Structure C, version C, suite C, N C version S, suite S, N S [Certificate] [ServerKeyExchange] ServerHelloDone 32
Phase 3 0 ClientKeyExchange 0 Client encrypts a pre-master secret with server s public key 0 If RSA is used, the public key is from certificate 0 If D-H is used, it is a ephemeral public key 0 CertificateVerify 0 Keyed hash of the handshake message 0 If client certificate is requested, client needs to prove it knows its private key 0 How does server proves this? 33
Phase 4 0 ChangeCipherSpec 0 Not a handshake message 0 Indicates all the message following this will use ciphers agreed upon 0 HandshakeFinished 0 Computed over all the previously exchanged handshake messages including two randoms 0 HMACed and encrypted using the new session keys 0 Prevent replay, MITM 34
Computing the Keys 0 Pre-master Secret S 0 A 48-byte value negotiated using RSA or D-H 0 Master Secret K 0 A 48-byte value derived from the pre-master secret K = MD5 S SHA1 "A" S R C R S MD5 S SHA1 "BB" S R C R S MD5 S SHA1 "CCC" S R C R S 0 6 Session Keys from key derivation function (TLS-PRF) 0 Client write key, write IV, and write MAC key 0 Server write key, write IV, and write MAC key 0 Why six keys? 35
Other SSL Protocols 0 Two peer protocols of the Handshake Protocol 0 Change cipher spec protocol 0 Used to indicate that entity is changing to recently agreed cipher suite 0 Session state: cause pending state to be copied into current state 0 Alert protocol 0 Manage SSL session error messages: MAC failure, handshake failure, bad certificate, no known certificate, close notification, 0 Warning 0 Fatal error: SSL immediately terminates the connection 0 Both run over Record Protocol 36
Record Protocol Use symmetric keys established in the handshake protocol 0 Carries application data and SSL management data 0 Confidentiality 0 DES, DES-40 (exportable), 3DES, IDEA,... 0 RC2-40, RC4-40 and RC4-128, 0 Integrity 0 HMAC: MD-5 or SHA-1 A record contains a header and a body, is limited to 2 14 bytes 37
Record Format and Payload Type Length Content 22: Handshake 1 Level Alert 20: ChangeCipherSpec 21: Alert Opaque Content 23: Application data (e.g., HTTP) 38
SSL Sessions 0 SSL Session is an association between a client and a server 0 Created through a handshake (by handshake protocol) 0 Negotiates security parameters that can be long-lasting 0 SSL Session Resumption 0 Pre-master secret is established using expensive public key cryptography 0 Establish multiple connections based on a same SSL session 0 Both store the session ID 0 In each handshake, check if it remembers the session ID 0 Skip public key portion and use the remembered pre-master secret 0 Each connection still exchanges nonces 39
SSL Session State 0 Session State 0 Session ID 0 Peer certificates 0 Pre-master secret 0 Compression algorithm 0 Cipher specification (encryption, digest, etc.) 40
Why not SSL v2.0? 0 SSL v2.0 is the real "first" version of the protocol 0 Has several weaknesses 0 Weak MAC 0 Export control limits crypto keys to be 40 bits, also it uses MD5 0 Cipher suite preferences are not authenticated 0 Cipher suite rollback attack, or downgrade attack is possible 0 Suffers Truncation attack: forged FIN 0 Padding is used when computing MAC but padding length field is not authenticated 0 Attacker can delete bytes from the end of messages 0 Use identical keys for authentication and encryption 0 Does not support certificate chains or non-rsa algorithms 41
Client Server Version Rollback Attack C, version C =3.0, 2.0 suite C, N C version S =3.0, suite S, N S Certificate ServerHelloDone {secret C } S+ Server is fooled. C and S end up communicating using SSL 2.0 Many protocols had version rollback attacks: SSL, SSH, GSM 42
Client Server Version Check in SSL 3.0 C, version C =3.0, suite C, N C Embed version number into secret version S =3.0, suite S, N S Certificate ServerHelloDone {version C, secret C } S+ Check if received version is equal to the version in ClientHello 43
Some SSL/TLS Security Flaws 0 SSL 2.0: Flaws in random number generation for SSL, 1996 0 Low quality PRNG leads to predictable session keys 0 Goldberg and Wagner presented this flaw in Randomness and the Netscape Browser 0 http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html 0 TLS 1.0: Flaws in error reporting 0 Session aborts when fatal errors occur: error messages are MACed, padded and encrypted in the same way 0 (Differing response times by server in event of padding failure and MAC failure) + (analysis of padding method for CBC-mode) = recovery of SSL plaintext 0 Brice Canvel et al. presented Password Interception in a SSL/TLS Channel in Crypto 2003 0 http://lasecwww.epfl.ch/php_code/publications/search.php?ref=chv V03 44
Some SSL/TLS Security Flaws 0 Remote timing attack against OpenSSL 0 Analysis of OpenSSL server response times allows attacker in the same LAN segment to derive the private key of the server 0 Boneh and Brumley presented in 2003 Usenix Security Symposium 0 http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html 0 Bad implementation 0 SSL certificate validation is completely broken in many security-critical non-browser applications and libraries 0 Due to badly designed APIs of SSL implementations 0 See additional reading material [Georgiev et. Al. 2012] 45
Goto Fail 0 Goto Fail (2014): Apple s SSL bug Hello I am PayPal.com Here is PayPal s certificate for RSA signing key Here is my signed Diffie-Hellman value 1. Validate the certificate 2. Verify the signature on the DH value using the public key from the certificate 46
Impact: Man-In-The-Middle 0 Goto Fail (2014): Apple s SSL bug 2. Verify the signature on the DH value using the public key from the certificate Check if any error with certificate here if ((err = SSLHashSHA1.update(&hashCtx, &clientrandom))!= 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &serverrandom))!= 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedparams))!= 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashout))!= 0) goto fail; err = sslrawverify(...); fail: return err But signature is actually verified here 47
SSL DDoS 0 THC SSL DOS released in 2011: https://www.thc.org/thcssl-dos/ 0 Exploiting SSL for denial of service 0 The computation cost of an handshake is more important on the server side than on the client side 0 The use of SSL renegotiation allows one to trigger hundreds of handshakes in the same TCP connection 0 Another tool sslsqueeze by Michał Trojnara 0 Using 2048bit RSA certificate 0 A server is using 100x more processing power than the client 48
Outline 0 Topic 4.1: Securing Real-Time Communications 0 Topic 4.2: Transport Layer Security 0 Topic 4.3: IPsec and IKE 49
The Big Picture of Networking 0 Today's Internet is primarily comprised of public, untrusted, and unreliable IP networks 0 TCP/IP provides the basic delivery service 0 Security is at odds 0 Lack of security 0 Subject to types of threats 50
Internet Threats 0 Data integrity content of a packet can be accidentally or deliberately modified 0 Identity spoofing origin of an IP packet can be forged 0 Reply attacks unauthorized data can be retransmitted 0 Loss of confidentiality/privacy content of a packet can be examined in transit Security Problems in the TCP/IP Protocol Suite for more threat analysis 51
Security at Application Layer PGP, Kerberos, SSH, 0 Implemented at end-hosts 0 Advantages 0 Extend application without involving operating system 0 Applications can understand the data and can provide the appropriate security 0 Disadvantages 0 Security mechanisms have to be designed independently of each application 52
Security at Transport Layer Transport Layer Security (SSL/TLS) 0 Implemented at end-hosts 0 Advantages 0 Existing applications get security seamlessly 0 Disadvantages 0 Still protocol specific 53
Security at Data Link Layer Hardware encryption 0 Need a dedicated link between host/routers. 0 Advantages 0 Speed 0 Disadvantages 0 Not scalable 0 Need dedicated links 54
Security at Network Layer IP Security (IPsec) 0 Advantages 0 Provides seamless security to application and transport layers 0 Allows per flow or per connection security and thus allows for very fine-grained security control 0 Disadvantages 0 More difficult to exercise on a per user basis on a multi-user machine 55
IP Provides Basic Delivery Service 0 Internet Protocol V4 (RFC791) 0 A routing service using source/destination addresses + TTL 0 A connectionless delivery: simplifies router design and operation 0 A unreliable, best-effort delivery: packets may get lost (discarded), duplicated, reordered, and/or corrupted 0 Fragmentation and reassembly functions 56
IP Provides Basic Delivery Service 0 All carried in the header fields 0 20 bytes Header Length x4 (4) Type of service (8) Version (4) Protocol Identifier (8) Header Checksum (16) Time-to-Live (8) Source IP Address (32) Destination IP Address (32) Total Length (16) Identification (16) Flags (3) Fragment Offset x8 (13) 57
Why Do We Need IPsec? 0 Limitations of IP V4 0 IP V4 has no authentication 0 IP spoofing 0 Payload could be changed without detection 0 Replay attacks 0 Denial of service attacks: cannot hold the attacker accountable 0 IP V4 has no confidentiality 0 Eavesdropping 58
Why Do We Need IPsec? 0 SSL can not effective defend certain attacks 0 Connection hijacking 0 Attacker can send forged RST packet to tear down a connection 0 Attacker can send bogus data for connection: after accepted by TCP, SSL detects but can do nothing other than alerting 0 SSL is less effective in protecting UDP 59
IPsec 0 Need a network-layer security protocol to provide secure communication across insecure networks 0 IPsec 0 Constructs a secure channel upon IP layer 0 Provides authentication, confidentiality, and key management services 0 It s transparent to applications 0 But needs to modify protocol stack or kernel 60
IPsec Specifications 0 IPsec is specified in a number of RFCs 0 RFC 4301: Security Architecture for the Internet Protocol 0 RFC 4302: IP Authentication Header (AH) 0 RFC 4303: IP Encapsulation Security Payload (ESP) 0 RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP 0 RFC 4304: Internet Security Association and Key Management Protocol (ISAKMP) 0 RFC 5996: The Internet Key Exchange (IKEv2) 0 RFC 2411: IP Security Document Roadmap 0 RFC 2412: The OAKLEY Key Determination Protocol 0 61
IPsec Functionalities 0 IPsec is attached upon IP layer, and is below any layer upon IP 0 Compatible with traditional IPv4 0 Provide security services at firewall or gateways to all passing traffic 0 Point-to-point security services 0 Authentication of data origin 0 Data integrity 0 Data confidentiality 0 Partial flow confidentiality 0 Resistance against replay-attack 0 Algorithm-independent with standard defaults 62
IPsec Services 0 Access control 0 Connectionless integrity 0 Data origin authentication 0 Protection against replays 0 A form of partial sequence integrity 0 Encryption (confidentiality) 0 Limited traffic flow confidentiality 63
IPsec Concepts 0 Allows selection of security protocols 0 Decides which crypto algorithm to use on which services selected 0 Provides interface for manually or automatically generating keys 0 Provides mechanisms to 0 Specify what security services on what traffic 0 Manage security parameters needed for the security service 64
IPsec Architecture SPD: Security Policy Database SAD: Security Association Database SA: Security Association IKE: Internet Key Exchange 65
IPsec Architecture 0 Two mechanisms using nested headers 0 Authentication Header (AH) 0 Authentication and integrity of payload and header 0 Encapsulating Security Payload (ESP) 0 With authentication: confidentiality, authentication and integrity of payload 0 Without authentication: confidentiality of payload 0 IKE protocol 0 Internet Key Management 0 User-granularity keying 66
IPsec Architecture 0 Can be implemented in 0 Host 0 Connect to other hosts in either mode 0 Connect to gateway in tunnel mode 0 Gateway 0 Connect to gateway in tunnel mode 0 Can work in two Modes 0 Tunnel or Transport modes 67
Security Association (SA) 0 Security association is an association between a sender and a receiver 0 Consists of a set of security related parameters, e.g., crypto algorithm selected, crypto keys, sequence number 0 Determines IPsec processing for sender 0 Determines IPsec decoding for destination 0 One-way relationship 0 Unidirectional 0 Bi-directional IPsec channel needs two different SAs 68
Security Association (SA) 0 SAs are not fixed 0 Generated and customized per traffic flows 0 SA is identified by 0 Security parameter index (SPI) 0 IP destination address 0 Security protocol identifier 69
Security Parameters Index (SPI) 0 A 32-bit string assigned to an SA 0 Carried in AH and ESP headers to enable the receiving system to select SA under which the packet will be processed 0 Uniquely identifies each SA in SA Database with 0 SPI + Dest IP address + IPsec Protocol 0 Why need destination IP address? 70
SA Database (SAD) 0 Each host/gateway participating in IPsec has its own SA database 0 SAD holds parameters for each SA 0 Security parameter index 0 Sequence number counter 0 AH and ESP information 0 IPsec protocol mode: tunnel or transport mode 0 Lifetime of this SA 0 Sequence counter overflow 71
Security Policy Database (SPD) 0 Every host or gateway has their own SPD 0 SPD defines which SA or SA Bundles to use 0 what type of traffic to discard, bypass, or protect 0 if an incoming traffic has been properly secured 0 Index into SPD by Selector fields 0 Selectors: IP and upper-layer protocol field values 0 E.g., Dest IP, Source IP, Transport Protocol, IPsec Protocol, Source & Dest Ports, 72
Example: A Host SPD Next layer protocol 73
Outbound Processing 0 IPsec is executed on a packet-to-packet basis 0 Each outbound packet is processed before transmission 74
Inbound Processing 0 IPsec is executed on a packet-to-packet basis 0 Each inbound packet is processed after reception and before passing to transport layer protocols 75
IPsec Modes: Transport Mode 0 Transport mode protects payload of an IP packet 0 Often used between end-stations 0 Or between an end-station and a gateway that performs as host 76
IPsec Modes: Transport Mode 0 Transport mode protects payload of an IP packet 0 Provides protection for upper-layer protocols 0 End-point hosts must be IPsec-aware 0 IPsec processing performed at end-points of secure channel 0 Cannot be shared by other hosts 77
IPsec Modes: Transport Mode 0 Transport mode protects payload of an IP packet 0 AH in transport mode authenticates IP payload and the selected portions of IP header 0 ESP in transport mode encrypts the higher layer payload 0 Authentication optional 78
IPsec Modes: Tunnel Mode 0 Tunnel mode provides protection to the entire IP packet 0 Often used between two gateways 0 Or at an end-station to a gateway that performs as proxy 79
IPsec Modes: Tunnel Mode 0 Tunnel mode provides protection to the entire IP packet 0 Entire IP packet plus security fields are the payload of new outer IP packet with a new header 0 Encapsulated packet with totally different source and destination addresses 80
IPsec Modes: Tunnel Mode 0 Tunnel mode provides protection to the entire IP packet 0 No intermediate router can examine the original packet 0 Eavesdropper cannot see anything about the original IP packet (partial flow confidentiality) 81
IPsec Modes: Tunnel Mode 0 Tunnel mode provides protection to the entire IP packet 0 Security services can be shared by multiple hosts behind two gateways 0 Hosts behind gateways do not need to implement IPsec 82
IPsec Modes: Tunnel Mode 0 Tunnel mode provides protection to the entire IP packet 0 AH in tunnel mode authenticates the entire inner IP packet and the selected portion of outer IP header 0 ESP in tunnel mode encrypts the entire inner IP packet (including original IP header) 83
IPsec Protocols: AH & ESP 0 Authentication Header Protocol 0 Provide data integrity to guarantee entire packet 0 Has not been tampered with 0 Provide authentication to authenticate trusted IP source address 0 Use MAC - keyed cryptographic hash function: 0 HMAC-MD5-96 0 HMAC-SHA-1-96 84
Authentication Header Protocol 0 AH creates a stateful channel 0 Security protocol identifier 0 Sequence number 0 An increasing counter value 0 Anti-replay feature 0 Sequence number is authenticated 0 Integrity check value (ICV) a MAC calculated over 0 IP header fields 0 Upper-level data 0 Code may be truncated to first 96 bits 85
IPsec Protocols: AH & ESP 0 Encapsulated Security Protocol (ESP) 0 Defines header and trailer fields to mark ESP payload 0 Encrypt payload with DES, tripple DES, RC5, IDEA, 0 Confidentiality for upper layer protocol 0 Optional connectionless integrity 0 NOT include IP header 0 Provide anti-reply service 0 Sequence number is authenticated 86
Anti-Replay Feature 0 Anti-replay is provided via sequence number checking when processing inbound packets 0 Sequence number and sliding window 0 A 32-bit sequence number is assigned to outbound IPsec packet 0 Increment on packet-by-packet basis 0 Overflow results in auditable event and re-keying 0 Use sliding windows to track arrival inbound packets 0 Packets are dropped if delayed too long (by network latency) 0 Recommend length 64 bits 87
Anti-Replay Feature 0 When processing inbound packets: 0 sequence number is first check for integrity 0 Sliding window should not be advanced until the packet has been authenticated 0 Sequence number is protected in ICV in both AH and ESP 0 Duplicates are rejected 0 Malicious packets with large sequence numbers are filtered out 0 Otherwise, malicious packets can unnecessarily advance the sliding window to drop later valid packets 88
Combining Security Associations 0 One SA can only implement either the AH or ESP (but not both) 0 What if we want services provided by both? 0 Example: ESP does not authenticate new IP header. How to authenticate? 0 Use one SA to apply ESP w/out authentication to original packet 0 Use a second SA to apply AH 0 What if separate services are needed for different flows between two gateways? 0 SA Bundle: more than one SA can apply to a packet 0 SAs in a bundle may terminate at different endpoints or at the same endpoint 0 How to combine SAs? 0 In which order authentication and encryption should be applied? 89
Combined Confidentiality and Authentication 0 Need to combine encryption and authentication 0 Approach 1: ESP with authentication 0 ESP in transport mode 90
Combined Confidentiality and Authentication 0 Need to combine encryption and authentication 0 Approach 1: ESP with authentication 0 ESP in tunnel mode 91
Combined Confidentiality and Authentication 0 Need to combine encryption and authentication 0 Approach 2: Transport Adjacency 0 two bundled SAs: inner is ESP SA and outer is AH SA 0 both in transport mode 0 authentication extends to original IP header (and extension in IPv6) 0 overhead IP Header AH Header ESP Header Orig IP Header TCP Header TCP Payload ESP trailer AH Auth 92
Combined Confidentiality and Authentication 0 Need to combine encryption and authentication 0 Approach 3: Transport-Tunnel Bundle 0 Authentication before encryption 0 Cannot alter authentication data 0 Store authentication data for later reference 0 Two bundled SAs: 0 Inner: AH SA in transport mode 0 Outer: ESP SA in tunnel mode New IP Header ESP Header Orig IP Header AH Header TCP Header TCP Payload AH Auth ESP trailer 93
SA Combinations: Host-to-Host 0 End-to-end application of IPsec between IPsec-aware hosts: 0 Hosts can connect to other hosts (or gateways) in both transport or tunnel modes 0 One or more SAs, one of the following combinations: 0 AH in transport, or ESP in transport, or ESP SA inside AH SA in transport 0 Any of the above inside an AH or ESP in tunnel mode 94
SA Combinations: Gateway-to-Gateway 0 Gateway-to-gateway only: 0 Gateways can connect to other gateways only in tunnel mode 0 Provide simple virtual private network (VPN) no IPsec at hosts 0 Only need a single tunnel SA 0 supporting any of AH, ESP (conf only) or ESP (conf+auth) 95
SA Combinations: combining both 0 A combination of 1 and 2 above: 0 Gateway-to-gateway tunnel as in 2 carrying host-to-host traffic as in 1 0 Gives additional, flexible end-to-end security on local networks (between gateways and hosts) 0 e.g., ESP in tunnel mode carrying AH in transport mode 96
SA Combinations: Remote Host 0 Remote host support: 0 Remote hosts connect to a single gateway 0 typically remote hosts connect to a firewall to gain access to servers behind 0 Outer tunnel protects inner traffic over Internet 0 Case 1 combination is used between two endpoints 97
Key Management 0 Why do we need key management? 0 IPsec SA needs keys 0 AH authentication key 0 ESP encryption key 0 What if key expires? 0 What if SA terminates? 0 What if the initiator and responder support different crypto algorithms or different key lengths? 0 Need a process to negotiate and establish IPsec SAs between two entities 0 Handle key generation, distribution, and extension 98
IPsec Key Management 0 IPsec is a heavy consumer of symmetric keys: 0 One key for each SA 0 Different SAs: {ESP, AH} x {tunnel, transport} x {sender, receiver} 0 IPsec supports two types of key management: 0 Manual keying 0 Fine for a small number of nodes but hopeless for reasonably sized networks of IPsec-aware hosts 0 Requires manual re-keying 0 IKE: Internet Key Exchange 0 A specific adaptation of more general protocols ( Oakley and ISAKMP ) 99
IPsec Architecture Re-visit 100
Internet Key Exchange 0 An automated key management protocol for IPsec 0 It establishes an IKE SA 0 Define encryption & authentication of IKE traffic 0 IKE SA is bidirectional 0 Uses IKE SA to negotiate IPsec SAs 0 Multiple IPsec SAs can be established with one IKE SA 0 Use refined Diffie-Hellman key exchange to establish shared secret 0 IKE is used when outbound packet does not have a SA 0 Original D-H suffers man-in-the-middle attacks and clogging attacks 101
Resource Clogging Attack 0 Attacker can send many bogus requests 0 Using spoofed IP source address 0 Flood the stateful server 0 Resulting in intensive computing resources for modular exponentiation 0 However, 0 Stopping requests is difficult 0 we need to provide services 0 Ignoring requests is dangerous 0 denial of service attacks 0 Countermeasure using cookies 102
Cookies 0 Cookie exchange 0 Each side sends a pseudo-random number in the initial message 0 It is the other side acknowledges 0 The acknowledgement must be repeated in the first D-H messages 0 If source address is forged, opponent gets no answer 0 Do not begin D-H calculation until getting the right acknowledgement 0 Requirements: 0 Depend on specific parties 0 Only the issuing entity can generate acceptable cookies implies issuer using local secret 0 Cookie generation and verification must be fast 0 Fast Hash (MD5) over IP Src/Dest, UDP Src/Dest, local secret 103
Other Attacks 0 Man-in-the-Middle-Attack 0 Threat to D-H 0 Countermeasures 0 Authentication 0 Pre-shared secret key 0 Public key certificate 0 Replay attack 0 Eavesdrop communication, record the cookie, and replay the cookie 0 Countermeasure 0 Use nonce 104
Conclusion 0 IPsec 0 Key exchange and encryption are separate 0 New encryption algorithms can be added 0 Complex a lot of flexibility and options 0 Best VPN standard we ve got 0 Real-world IPsec 0 IPsec support is usually implemented in the OS kernel 0 Real-world implementations: OpenBSD, Cisco IOS, Microsoft windows, Solaris, IBM AIX, Linux 0 Mandatory in all stands-compliant implementations of IPv6 105