Chapter 5: Network Layer Security

Transcription

1 Managing and Securing Computer Networks Guy Leduc Mainly based on Network Security - PRIVATE Communication in a PUBLIC World C. Kaufman, R. Pearlman, M. Speciner Pearson Education, (chapters 17 and 18) For a summary, see: Chapter 5: Network Layer Security Computer Networking: A Top Down Approach, 6 th edition. Jim Kurose, Keith Ross Addison-Wesley, March (section 8.7) 5: Securing IP 5-1 Chapter 5: Network Layer Security Chapter goals: security in practice: Security in the network layer (versus other layers) IPsec 5: Securing IP 5-2 1

2 Chapter Roadmap Security in the network layer IPsec - The big picture IPsec protocols: AH and ESP IPsec Key Exchange protocol: IKE 5: Securing IP 5-3 Relative Location of Security Facilities in the TCP/IP Stack HTTP FTP SMTP TCP / UDP IP / IPsec Security at network level HTTP FTP SMTP SSL / TLS TCP IP Security at transport level Both are general-purpose (i.e. application independent) solutions, but IPsec is NOT specific to TCP Does work with UDP, and any other protocol above IP (e.g., ICMP, OSPF) IPsec protects the whole IP payload, including transport s (e.g. port #) Traffic analysis is thus more difficult (could be web, , ) IPsec is from network entity to network entity, not from application process to application process Blanket coverage 5: Securing IP 5-4 2

3 Virtual Private Networks (VPNs) Institutions often want private networks for security Costly! Separate routers, links, DNS infrastructure VPN: institution s inter-office traffic is sent over public Internet instead Encrypted before entering public Internet Logically separate from other traffic 5: Securing IP 5-5 Virtual Private Networks (VPNs) public Internet IP IPsec Secure payload laptop w/ IPsec Secure payload IPsec IP IPsec salesperson in hotel Secure payload IP router w/ IPv4 and IPsec router w/ IPv4 and IPsec payload IP IP payload headquarters branch office 5: Securing IP 5-6 3

4 Three functional areas IP-level security encompasses the following 3 functional areas: origin authentication (and data integrity) assures that a received packet was, in fact, transmitted by the party identified as the source in the packet includes replay attack prevention also assures that the packet has not been altered confidentiality enables communicating nodes to encrypt messages to prevent eavesdropping by third parties key management secure exchange of keys 5: Securing IP 5-7 IP Security Overview In 1994, the Internet Architecture Board (IAB) issued a report entitled "Security in the Internet Architecture" General consensus that the Internet needs more and better security In 1997, 2500 reported security incidents affecting nearly 150,000 sites Most serious attacks: IP spoofing and packet sniffing This justified the 2 main functions of IPsec The security capabilities were designed for IPv6 but fortunately they were also designed to be usable with the current IPv4 IPsec can encrypt and/or authenticate all traffic at the IP level. Thus IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet VPN (Virtual Private Networks) Secure remote access over the Internet Enhancing Extranet and Intranet connectivity with partners Enhancing Electronic Commerce 5: Securing IP 5-8 4

5 Benefits of IPsec When IPsec is implemented in a firewall or router, it provides strong security that can be applied to all traffic crossing the perimeter IPsec is below the transport layer and so is transparent to applications No need to change software on a user or server system when IPsec is implemented in a firewall or router No need to train users, issue keying material on a per-user basis, or revoke keying material when users leave the organization IPsec can provide security to individual users if needed IPsec can play a vital role in the routing architecture. It can ensure that: router and neighbour advertisements come from authorized routers a redirect message comes from the router to which the initial packet was sent a routing update is not forged 5: Securing IP 5-9 Chapter Roadmap Security in the network layer IPsec - The big picture IPsec protocols: AH and ESP IPsec Key Exchange protocol: IKE 5: Securing IP

6 IPsec Transport Mode IPsec IPsec IPsec datagram emitted and received by end-system Protects upper level protocols 5: Securing IP 5-11 IPsec tunneling mode (1) IPsec IPsec End routers are IPsec aware Hosts need not be 5: Securing IP

7 IPsec tunneling mode (2) IPsec IPsec Also tunneling mode 5: Securing IP 5-13 Two Ipsec protocols Authentication Header (AH) protocol provides source authentication & data integrity but not confidentiality Encapsulation Security Protocol (ESP) provides source authentication, data integrity, and confidentiality more widely used than AH 5: Securing IP

8 Four combinations are possible! Host mode with AH Host mode with ESP Tunnel mode with AH Tunnel mode with ESP Most common and most important 5: Securing IP 5-15 IP Security Overview IPsec enables a system to select security protocols, determine the algorithm(s) to use, and put in place any cryptographic keys required IPsec services and their support by AH and ESP AH ESP ESP encryption only encryption+authentication Access Control x x x Connectionless integrity x x Data origin authentication x x Rejection of replayed packets x x x Confidentiality x x Limited traffic flow confidentiality x x 5: Securing IP

9 Security associations (SAs) Before sending data, a virtual connection is established from sending entity to receiving entity Called security association (SA) SAs are simplex: for only one direction Both sending and receiving entities maintain state information about the SA Recall that TCP endpoints also maintain state information IP is connectionless; IPsec is connection-oriented! How many SAs in VPN w/ headquarters, branch office, and n traveling salespeople? 5: Securing IP 5-17 Security Association (2) An SA is uniquely identified by 3 parameters: Security Parameters Index (SPI): a bitstring assigned to this SA by the receiver end, and having local significance only. Used to select the SA under which a received packet will be processed. IP Destination Address: can be a router address, can be unicast or multicast. Security Protocol Identifier: indicates whether the association is an AH or ESP SA The SPI alone seems to suffice to uniquely identify the SA, but The same SPI can be assigned to both an ESP SA and an AH SA, so this security protocol identifier is needed to remove ambiguity For multicast, the SPI is chosen by the source, so the destination address field is also needed to remove ambiguity Hence, in any IP packet, the SA is uniquely identified by these 3 fields 5: Securing IP

10 Example SA from R1 to R2 headquarters Internet branch office /24 R1 security association R /24 R1 stores for SA: 32-bit identifier for SA: Security Parameter Index (SPI) origin SA interface ( ) destination SA interface ( ) type of encryption used (e.g., 3DES with CBC) encryption key type of integrity check used (e.g., HMAC with MD5) authentication key 5: Securing IP 5-19 Security Association Database (SAD) endpoint holds SA state in security association database (SAD), where it can locate them during processing with n salespersons, 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 datagram accordingly 5: Securing IP

11 IPsec datagram Focus for now on tunnel mode with ESP enchilada authenticated encrypted new IP ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth SPI Seq # padding pad length next 5: Securing IP 5-21 What happens? headquarters Internet branch office /24 R1 security association R /24 enchilada authenticated encrypted new IP ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth SPI Seq # padding pad length next 5: Securing IP

12 R1 converts original datagram into IPsec datagram Appends to back of original datagram (which includes original fields!) an ESP trailer field Encrypts result using algorithm & key specified by SA Appends to front of this encrypted quantity the ESP, creating enchilada Creates authentication MAC over the whole enchilada, using algorithm and key specified in SA Appends MAC to back of enchilada, forming payload Creates brand new IP, with all the classic IPv4 fields, which it appends before payload 5: Securing IP 5-23 Inside the enchilada: enchilada authenticated encrypted new IP ESP hdr original IP hdr Original IP datagram payload ESP trl ESP auth SPI Seq # padding pad length next ESP trailer: Padding for block ciphers Next contains original packet type Packet type in new IP is ESP ESP : SPI, so receiving entity knows what to do Sequence number, to thwart replay attacks MAC in ESP auth field is created with shared secret key 5: Securing IP

13 IPsec sequence numbers For new SA, sender initializes seq. # to 0 Each time datagram is sent on SA: Sender increments seq # counter Places value in seq # field Goal: Prevent attacker from sniffing and replaying a packet Receipt of duplicate, authenticated IP packets may disrupt service Method: Destination checks for duplicates But doesn t keep track of ALL received packets; instead uses a window 5: Securing IP 5-25 IPsec Anti-Replay in Action R1 #4 #3 #2 #1 R2 #2 #2 #4 #2 #1 #2 #2 Packet #3 lost, Packets #2 are out of sequence and/or duplicates no problem 5: Securing IP

14 #4 Packet reordering and IPsec Anti-Replay Window R1 #3 #2 #1 R2 Network may change the packet order #4 #1 #3 #2 Packet #1 out of sequence. If in window: OK, otherwise: drop & log 5: Securing IP 5-27 SA Database (SAD) - More 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 datagram accordingly Parameters associated with each SA: AH information: authentication algorithm, keys, key lifetime, ESP information: encryption and authentication algorithm, keys, initialization values, key lifetimes, Sequence number counter: used to generate the sequence number field in AH and ESP s Anti-replay window: used to determine whether an inbound AH or ESP packet is a replay Lifetime of the SA Sequence counter overflow flag: indicates what to do when a counter overflow occurs (usually close the SA) IPsec protocol mode: tunnel or transport mode Path MTU: any observed path maximum transmission unit (to avoid fragmentation) 5: Securing IP

15 Security Policy Database (SPD) Policy: For a given datagram, sending entity needs to know if it should use IPsec Needs also to know which SA to use A nominal Security Policy Database (SPD) defines the means by which IP traffic is related to specific SAs (or possibly to no SA) Info in SPD indicates what to do with arriving datagram Then info in the SAD indicates how to do it An SPD contains entries, each of which defines a subset of IP traffic (via some IP and upper-layer protocol field values, called selectors) and points to an SA for that traffic Outbound processing obeys the following general sequence for each packet: Compare the values of the appropriate fields in the packet (selector fields) against the SPD to find a matching SPD entry Determine the SA associated with that entry (if any) and its associated SPI Do the required IPsec processing (i.e. AH or ESP processing) Like the packet filter rules in firewalls (see next chapter) 5: Securing IP 5-29 Summary: IPsec services Suppose Trudy sits somewhere between R1 and R2. She doesn t know the keys. Will Trudy be able to see contents of original datagram? How about source, dest IP address, transport protocol, application port? flip bits without detection? masquerade as R1 using R1 s IP address? replay a datagram? 5: Securing IP

16 Chapter Roadmap Security in the network layer IPsec - The big picture IPsec protocols: AH and ESP IPsec Key Exchange protocol: IKE 5: Securing IP 5-31 Transport and Tunnel Modes Brief overview Transport mode Protection of the IP packet payload only IP unchanged Tunnel mode Protection of the entire IP packet To do this, the entire protected original packet is treated as the payload of a new "outer" IP packet, with a new outer IP 5: Securing IP

17 AH - Transport Mode Original IP datagram Original IP other s and payloads secret key Non mutable fields only Parts of Original Auth. IP AH but PT = 51 Digital signature produced by a MAC (Message Authentication Code) algorithm (MD5 or SHA-1) other s and payloads Authenticated IP datagram Part of the AH is also authenticated 5: Securing IP 5-33 AH - Tunnel Mode New IP built by tunnel end Original IP datagram Original IP other s and payloads Non mutable fields only All fields secret key Parts of Digital signature produced by a MAC (Message Authentication Code) algorithm (MD5 or SHA-1) New IP Auth. AH Original IP other s and payloads Authenticated IP datagram Part of the AH is also authenticated 5: Securing IP

18 IPsec AH Header Next Header Payload Len RESERVED Security Parameters Index (SPI) Sequence Number Field Authentication Data (variable) Total length = 32 bytes Next identifies protocol type above IP The sequence number is used to guard against the replay attack 5: Securing IP 5-35 ESP without Authentication Transport Mode Original IP datagram Original IP other s and payloads ESP trailer (padding) Encryption algorithm (e.g. DES with CBC) secret key Original IP but PT = 50 ESP other s and payloads and ESP trailer IP datagram with transport ESP 5: Securing IP

19 ESP without Authentication Tunnel Mode Original IP datagram new IP built by tunnel end IP other s + payloads ESP trailer (padding) secret key Encryption algorithm (e.g. DES with CBC) new IP ESP IP other s + payloads + ESP trailer IP datagram with tunnel ESP 5: Securing IP 5-37 ESP with Authentication Transport Mode Original IP datagram Original IP other s + payloads ESP trailer Encrypted part IP datagram with transport ESP Original IP ESP other s + payloads + ESP trailer ESP authentication Authenticated part 5: Securing IP

20 ESP with Authentication Tunnel Mode Original IP datagram IP other s + payloads ESP trailer Encrypted part IP datagram with tunnel ESP new IP ESP IP other s + payloads + ESP trailer ESP authentication Authenticated part 5: Securing IP 5-39 IPsec ESP format Security Parameters Index (SPI) ^Auth Cov- Sequence Number erage Payload Data* (variable) ^ ~ ~ Conf Cov- Padding (0-255 bytes) erage* Pad Length Next Header v v Authentication Data (variable) ~ ~ Added length: minimum 8 bytes (+4 bytes IV for DEC-CBC) before and minimum 2 bytes after without authentication. 5: Securing IP

21 Combining authentication and confidentiality First method: ESP with authentication does not authenticate the non mutable parts of the IP (in transport mode) or new IP (in tunnel mode) applies encryption before authentication so authentication applies to the cyphertext, rather than the plaintext Second method: ESP (without authentication), then AH does authenticate the non mutable parts of the IP has the disadvantage of using two SAs Third method: first AH, then ESP (without authentication) authentication applies to the plaintext allows to store the authentication information together with the message (without having to reencrypt the message to verify the authentication) the authentication is protected by encryption still two SAs Usage of AH and ESP can be in transport or tunnel modes 5: Securing IP 5-41 Do we need AH? We clearly need ESP for encryption, but do we need AH? AH protects the IP itself. But does IP protection matter? If it were necessary, ESP in tunnel mode could provide it Note that intermediate routers cannot check integrity. Why? So integrity can only be checked at the other end of the SA Note also that, even with AH, an untrusted source host could still spoof its own IP address Only integrity is ensured 5: Securing IP

22 IPsec and NAT NAT translates the source IP address and the source port of the IP packet! A NAT box actually does IP spoofing An IPsec SA cannot go through a NAT box With AH, the integrity check would fail With ESP, the port number is encrypted And the NAT box doesn t have the key Need to encapsulate IPsec packets in UDP packets: IP TCP User Data IP ESP 50 Encrypted Data HASH IP UDP Payload 5: Securing IP 5-43 IPSec Tunnels & QoS Original IP datagram IP IP payload TOS / DSCP New IP built by tunnel end TOS byte is copied new IP ESP IP IP payload IP datagram with ESP tunnel 5: Securing IP

23 Chapter Roadmap Security in the network layer IPsec - The big picture IPsec protocols: AH and ESP IPsec Key Exchange protocol: IKE 5: Securing IP 5-45 IKE: Internet Key Exchange In previous examples, we manually established IPsec SAs in IPsec endpoints: Example SA: SPI: Source IP: Dest IP: Protocol: ESP Encryption algorithm: 3DES-cbc HMAC algorithm: MD5 Encryption key: 0x7aeaca HMAC key:0xc0291f Manual keying is impractical for large VPN with 100s of endpoints Instead use IPsec IKE (Internet Key Exchange) 5: Securing IP

24 IKE: PSK and PKI Authentication (proof of who you are) with either pre-shared secret (PSK) or with PKI (public/private keys and certificates) With PSK: both sides start with secret: run IKE to authenticate each other and to generate IPsec SAs (one in each direction), including encryption and authentication keys With PKI: both sides start with public/private key pair and certificate: run IKE to authenticate each other and obtain IPsec SAs (one in each direction) Similar with handshake in SSL 5: Securing IP 5-47 IKE - 2 phases - overview IKE has two phases Phase 1: establish bi-directional IKE SA The two peers establish a secure, authenticated channel with which to communicate. This is called the IKE Security Association (SA), aka ISAKMP SA Note: IKE SA is different from IPsec SA Based on a Diffie-Hellman (DH) exchange computationally expensive, but done only once Result: one shared key used in (possibly many instances of) phase 2 More precisely, 3 keys are derived from this one (one for IKE encryption, one for IKE authentication, and one for phase 2) Phase 1 has two modes: aggressive mode and main mode Phase 2: IKE SA is used to securely negotiate IPsec pair of SAs SAs are negotiated on behalf of services such as IPsec (e.g. AH or ESP) or any other service which needs key material and/or parameter negotiation Uses the 3rd shared secret key (of phase 1) and random numbers to create IPsec shared secret keys for AH and ESP SAs Those IPsec SAs are unidirectional Quick procedure and keys can be changed often 5: Securing IP

25 IKE Phase 1 - Thwarting Clogging Attacks (1) DH is computationally expensive IKE employs a mechanism, known as cookies, to thwart clogging attacks The protocol starts by a cookie request containing a random value (c 1 ) The other side will send back a cookie response containing this value (c 1 ) and a new random number (c 2 ) The only overhead is to send an acknowledgement, not to perform a DH calculation If the source address was forged, the opponent may not get any answer If the responder is too busy, it does not send acknowledgements The returned value (c 2 ) must be repeated in the first message of the DH key exchange Gets it only if initial IP address was not spoofed c 1 c 2, c 1 DHparam, c 2 Check c 2, if OK starts DH 5: Securing IP 5-49 Thwarting Clogging Attacks(2) c 1 c 2, c 1 DHparam, c 2 Improvement: Don t keep a copy of c 2. Possible thanks to the fact that the party can recognise that c 2 is one of its own cookies! But then the scheme is vulnerable to the following attack: Spoofed IP address c 1 Don t know c 2, but can use another c 2 recorded in a run with my address So, cookies must depend on (i.e. be a hash of) the specific parties (IP source and destination addresses, UDP source and destination ports) and a locally generated secret value c 2, c 1 DHparam, c 2 OK, c 2 is one of my cookies I start DH 5: Securing IP

26 DH - Defence against Man-in-the-Middle (MIM) (1) If DH parameters (Y A and Y B ) are permanent and public numbers And if we can be sure that Y A and Y B are the numbers reliably associated with A and B respectively For example, by means of a PKI (Public Key Infrastructure) That is the pairs (A, Y A ) and (B, Y B ) are certified by some trusted authority So-called Fixed DH Then The Man-in-the-Middle attack is not possible And the exchanges of Y A and Y B can even be eliminated B will need to fetch the certified Y A only once But this needs a PKI We lose the simplicity of the original Diffie-Hellman scheme Also, the fact that Y A and Y B are permanent makes them more vulnerable to brute-force attacks to find X A and X B 5: Securing IP 5-51 DH - Defence against MIM (2) Authenticated (Ephemeral) Diffie-Hellman If A and B know some sort of secret with which they can authenticate each other (before running DH) Knowledge of a (pre-shared) secret key, or Knowledge of each other s public key (and their own private key) Then they can use this secret to prove it was they who generated their DH values Several solutions: Encrypt the DH exchange with the pre-shared secret key Sign the transmitted DH value (Y) with own private key Encrypt the DH value (Y) with the other side s public key Why does it work, knowing that anyone can so encrypt? Following the DH exchange, transmit a hash of the pre-shared key and the DH value (Y) you transmitted Following the DH exchange, transmit a hash of the agreed-upon shared DH value, your name and the pre-shared key Again this needs a PKI or a pre-shared key Note that the DH values can be changed often in this case 5: Securing IP

27 Back to IKE phase 1 - Authentication The DH exchange should be authenticated to bar the MIM attack Several authentication methods are used Authentication with a pre-shared key Authentication based on public key cryptography Authentication with signatures Authentication with public key encryption But, if one needs public key cryptography anyway, why using DH to generate a shared secret in the first place? After all, one party could have generated the secret key and sent it encrypted with the other party s public key! With DH, both parties contribute to the shared secret/key. So it will be random if either side has a good random number generator. 5: Securing IP 5-53 IKE phase 1 - main mode Crypto_suite A Crypto_suite_chosen B Negotiation of the cryptographic methods used in later exchanges Y B Y A K AB (A, proof I m A) Anonymous DH: no identity revealed, only the IP addresses K AB is the calculated DH shared key. Note, both computations in //. A only reveals her identity here. K AB (B, proof I m B) Moreover, identities are hidden to passive attackers. So, a MIM will only discover A s id. But could also be hidden. How? Proof of identity: proof that the sender knows the key associated with the identity, which can be based on The pre-shared key The private signature key or encryption key (two pairs of asymmetric keys are used) Typically some hash of (1) the key associated with the identity and (2) almost all fields in previous messages (also provides integrity). With private signature keys, the proof can also be a signature on the fields 5: Securing IP

28 IKE phase 1 - aggressive mode A, Y A, Crypto_proposal A Take-it-or-leave-it negotiation. In particular, A chooses a (g,p) pair. B, Y B, proof I m B proof I m A Identities revealed, even to passive attackers: no encryption. How would you change this mode to hide identities to passive attackers (with public keys)? Note: in both modes (main and aggressive), nonces are added to messages. The DH shared key is then computed from the DH values AND the nonces For example: K AB = hash (nonces, standard DH key) This allows IKE to reuse the same DH values in successive runs and still generate different shared keys Protection against replay attack 5: Securing IP 5-55 IPsec only authenticates the host! If the host is stolen, it can still establish IPsec SAs and connect to a VPN! IPsec does not authenticate the user Needs an extra level: user authentication E.g., IPsec client with Smart card Or, extra authentication with username and password after IKE phase 1 5: Securing IP

29 Automated Public Key Exchange Peers choose their private/public key pairs they keep the secret key their public keys must be certified Use a notary = Certification Authority = CA Peer must prove authenticity in front of CA Notary signs certificates Peers dynamically exchange certificates Scalable: n peers requires n authentications and n certificates 5: Securing IP 5-57 Certificates peer name peer public key expiration date other info signature by the CA Certificates are not secret Common structure ITU X.509 v3 or PKCS#6 (S/MIME, SSL, ) 5: Securing IP

30 How peers work with CA CAʼs own certificate signed by CA 3. peer s certificate signed by CA 1. peer fetches CA s certificate 2. peer transmits its public key 4. peer fetches its certificate Strong or human authentication needed for steps 1. and peer generates public/private key pair 5: Securing IP 5-59 How to check a certificate? Check CA signature CA s certificate needed to get CA signature Check black list = CRL (Certificate Revocation List) connect to CA to get the CRL CRL List of revoked certificates signed by CA Stored on CA or directory service No requirement on devices to ensure CRL is current 5: Securing IP

31 How to scale CA? A root CA can delegate authentication to lower CA root lower CA root CA own certificate signed by root CA lower CA certificate signed by root CA router certificate signed by lower CA certificates chain of router 5: Securing IP 5-61 IPsec: summary IKE used to establish shared secret keys, algorithms, SPI numbers two principal protocols: authentication (AH) protocol encapsulation security payload (ESP) protocol for both AH and ESP, source, destination handshake: create network-layer logical channel called a security association (SA) Tunnel and transport modes shortcomings IPsec departs from the pure connectionless paradigm IPsec interferes with NAT boxes IPsec only authenticates a host, not a user IPsec is complex: more than a dozen RFCs 5: Securing IP