IPsec and Secure VPNs

Transcription

1 Cryptography and Security in Communication Networks sec and Secure VPNs (self study for project) ETTI - Master - Advanced Wireless Telecommunications

2 Virtual Private Networks (VPN) Private, public, virtual private networks Private network: Owned and managed by a company, used for its own communications. Public network: Owned and managed by a network service provider, used to offer communication services to customers. Virtual private network: Extension of a private network using a public telecommunication infrastructure. 1 Public network 2 Private network Virtual Private Network Private network VPN requirements Security: Confidentiality, integrity, access control. Quality of Service: Availability. Performance: bandwidth, delay. Low cost: Installation, operation. Octavian Catrina 2

3 Site-to-site VPN Remote access VPN: Access to corporate intranet Bob at home, hotel, airport,... Main VPN scenarios Interconnects geographically dispersed private networks. Intranet: all sites have the same owner (corporate branches). Extranet: sites have different owners (business partners). Remote-access VPN Provides access to the company's intranet to a mobile user, home user, etc. Different requirements and technologies. Internet Extranet VPN: Remote access for business partners 3 Alice Consulting Private network BobSoft Inc. headquarters: Corporate intranet BobSoft branch office networks: Connected to the corporate intranet Private network 1 BobSoft's VPN Site-to-site VPN: Interconnects different sites of the corporate intranet Octavian Catrina 3 2 Private network

4 VPN categories: Secure VPN Strong security using cryptographic protocols Trusted VPN solutions cannot offer strong security (data privacy and integrity, authentication and authorization). Secure VPNs use cryptographic protocols that set up secure channels (authenticated and encrypted) across the Internet. Issues: Scalability (cryptographic overhead), QoS, higher costs. Remote access secure VPN: Secure access to corporate intranet Bob at home, hotel, airport,... Internet Secure channels using cryptographic protocols: 3 Private network Extranet VPN: Secure remote access for business partners Alice Consulting BobSoft Inc. headquarters: Corporate intranet data integrity, authentication, confidentiality BobSoft branch office networks: Connected to the corporate intranet Private network 1 BobSoft's secure VPN Site-to-site secure VPN: Secure interconnection of private networks Octavian Catrina 5 2 Private network

5 Secure VPNs using sec sec: security Suitable for both site-to-site and remote-access VPNs. Creates secure channels available for all applications, between: hosts, entire networks, a host and a network. Available for both v4 and v6. Layer 2 Tunneling Protocol (L2TP) Creates a tunnel and offers PPP features needed for remote access: protocol configuration (address, DNS, etc.), user authentication, data and header compression, etc. Security provided by sec. Solution preferred by Microsoft. Some sec disadvantages Conflicts with anything that tries to inspect and/or modify protected or header (encrypted, authenticated): NAT, firewall, QoS (workarounds available). A VPN client must be installed on the users' computers. Octavian Catrina 6

6 sec VPNs Remote access VPN Bob at home, airport,... header Sec header Protected 3 Extranet VPN Internet Trudy header Alice Consulting Business partner BobSoft Inc. headquarters Corporate intranet header Sec header Protected BobSoft branch office network (connected to corporate intranet) 1 2 header Site-to-site VPN header Tunnel mode: sec is the entire packet. It is delivered encapsulated in another packet ( tunnel). Used for gatewayto-gateway or host-to-gateway secure channels. Transport mode: sec is the packet. Can be used for end-to-end (host-to-host) security. Also used to secure communications within a private network. Octavian Catrina 7

7 sec Security protocols

8 sec protocols and services Encapsulating Security Payload (ESP) protocol Encryption and/or authentication: full packet or. Authentication Header (AH) protocol Authentication: full packet or ; fixed header fields. Internet Key Exchange (IKE) protocol Security association and key management. AH or/and ESP? Do we really need AH, besides ESP? Many believe we don't... We can use ESP for data authentication only, without encryption. However, AH also protects the header. We could also use them together, but it is inefficient. Summary of security services Data origin authentication. Data confidentiality. Access control. Partial packet flow integrity: Connectionless packet integrity. Anti-replay protection. Limited traffic flow confidentiality. Octavian Catrina 10

9 Authenticated encryption Authenticated encryption Combination of encryption and message authentication. Never use encryption without (data) authentication. If confidentiality is not necessary, use MAC alone. Composition of MAC and encryption schemes Variant Protected message Example Provable security Encrypt then MAC (ETM) MAC then Encrypt (MTE) MAC and Encrypt (MAE) E K1 (m) MAC K2 (E K1 (m)) sec Secure composition independent of schemes. Recommended method. E K1 (m MAC K2 (m)) TLS Secure composition for certain (usual) combinations of schemes. E K1 (m) MAC K2 (m) SSH Not provable as general composition method (secure in particular cases). Dedicated authenticated-encryption schemes More efficient than composition techniques. Examples: CCM (Counter with CBC-MAC Mode), NIST SP800-38C. E.g., IEEE i. GCM (Galois/Counter Mode), NIST SP800-38D. E.g., IEEE 802.1ae. Octavian Catrina 11

10 The beginning Brief chronicle of sec sec development and standardization started in First specifications were published in sec Architecture, Authentication Header (AH), and Encapsulated Security Payload (RFC ). No Internet Key Exchange (IKE). Second iteration Revised sec specifications were published in Architecture, AH, ESP (RFC 2401, 2402, 2406); and others. A first specification for IKE: IKEv1 (RFC 2407, 2408, 2409). This version was widely deployed, although IKEv1 was a flop. Work on IKEv2 started soon afterwards. Current specs Revised sec specifications finally issued at the end of Architecture, AH, ESP (RFC ); and others. Substantial redesign of IKE: IKEv2, RFC Octavian Catrina 12

11 Authenticated Encrypted Encapsulating Security Payload (ESP) Header with Protocol ID field = ESP SPI (Security Parameters Index) Sequence Number IV (Initialization Vector, if necessary; variable length) Payload Data (variable length) Padding (0-255 bytes) Pad Length Integrity Check Value (ICV) (variable length, default 96 bits) Next Header Encapsulating Security Payload 32 bits Encrypted and authenticated. Transport mode: sec Payload Data is the packet. header not protected. Tunnel mode: sec Payload Data is the entire packet. Encryption. E.g., AES in CBC or CTR mode. ICV = MAC. E.g., HMAC-SHA1, AES-XCBC. Security Parameters Index (SPI): Identifies the sec Security Association (SA) for this packet at the receiver. Next Header: Protocol ID of Payload Data. Sequence Number: Anti-replay protection. Padding: Values 1, 2,, Pad Length. To multiple of 32 bits and (for some schemes) of block length; may hide length. Octavian Catrina 13

12 ESP: Transport mode, Tunnel mode Without Sec H1 R1 header H1H2 R2 H2 header H1H2 header H1H2 ESP in Transport mode H1 R1 header H1H2 ESP header ESP trailer ESP ICV R2 H2 header H1H2 ESP header ESP trailer ESP ICV Authenticated only header H1H2 ESP header ESP trailer ESP ICV ESP in Tunnel mode Encrypted and authenticated H1 R1 header R1R2 ESP header header H1H2 ESP trailer ESP ICV R2 H2 header H1H2 Can set up tunnels between hosts or gateways. Must use tunnel if an endpoint is gateway. Main use is gateway (or remote host) to gateway. header H1H2 Octavian Catrina 14

13 Authentication Header (AH) Partially Authenticated Header with protocol id field = AH Next Header Payload length Reserved SPI (Security Parameters Index) Sequence Number Authentication Header Authenticated Integrity Check Value (ICV) (variable length, default 96 bits) Payload 32 bits Authenticated and fixed header fields. Transport mode: sec Payload Data is the packet. header not protected. Tunnel mode: sec Payload Data is the entire packet. ICV = MAC. E.g., HMAC-SHA1, AES-XCBC. Security Parameters Index (SPI): Identifies the sec Security Association (SA) for this packet at the receiver (SA records AH or ESP protocol, crypto schemes, keys). Next Header: Protocol ID of Payload Data. Sequence Number: Anti-replay protection. Octavian Catrina 15

14 AH: Transport mode, Tunnel mode Without Sec H1 R1 header H1H2 R2 H2 header H1H2 header H1H2 AH in Transport mode H1 R1 header H1H2 AH header R2 H2 header H1H2 AH header Partially authenticated header H1H2 AH header AH in Tunnel mode Authenticated H1 R1 header R1R2 AH header header H1H2 R2 H2 header H1H2 Can set up tunnels between hosts or gateways. Must use tunnel if an endpoint is gateway. Main use is gateway (or remote host) to gateway. header H1H2 Octavian Catrina 16

15 Transport mode vs. Tunnel mode Advantages Disadvantages Advantages Disadvantages Sec Transport Mode End-to-end (host-to-host) protection. ESP encrypts and authenticates. AH authenticates and header fields. Lower encapsulation overhead. Adds only AH header or ESP header and trailer. Requires a security association per pair of hosts. Not appropriate for inter-site VPN: does not scale up for any-to-any communications. Does not hide header. ESP does not protect the header at all. AH only authenticates it. Requires Sec processing at hosts (not transparent for hosts). Hosts must know Sec. Processing overhead. Sec Tunnel Mode A tunnel between gateways protects all traffic between 2 networks. Good for site-to-site VPN or remote access VPN (remote host to gateway). Can encrypt header and (ESP). ESP protected packet is encapsulated as in outer packet. Good for security, but can hinder other functions (e.g., end-to-end QoS). Tunnel between gateways is transparent for hosts. Hosts need not know Sec. Tunnel between gateways does not offer end-to-end protection. Higher encapsulation overhead. Adds outer header, besides AH header or ESP header and trailer. Octavian Catrina 17

16 Anti-replay service AH and ESP provide an "anti-replay" service Receiver rejects replayed packets (partial sequence integrity). Uses 32-bit sequence numbers in AH and ESP headers. Sender behavior The sender initializes a sequence counter to 0 and increments it for each datagram sent. The sender cannot continue to send if the counter overflows. In this case the security association is re-established. Receiver behavior The receiver discards a packet if it carries a sequence number equal to that of another packet received during the current security association. (Actually, it records recently received sequence numbers within a sliding window of convenient size, e.g., 64). Octavian Catrina 18

17 Security associations Security association (SA) Hosts or routers One-way relationship between a sender and a receiver which defines the security services offered and their parameters. SA database SA identification Security parameters index (SPI). Carried in ESP and AH headers. Used by a receiver to select the SA corresponding to a received packet. Packet destination address. Security protocol identifier: ESP or AH. SA Parameters (selection) AH information (for an AH SA): MAC algorithm, keys, initialization values. ESP information (for an ESP SA): encryption and MAC algorithms, keys, initialization values. Protocol mode: transport/tunnel. Sequence number counter. Anti-replay window. SA lifetime. SA database Hosts or routers See RFC 4301 Octavian Catrina 19

18 Security policies 1/2 Security Policy Database (SPD) Every inbound or outbound packet is subject to processing by sec. SPD specifies what security services have to be offered and how, for every packet. There is (conceptually) an SPD for each interface, for inbound packets, and for outbound packets. SPD contains an ordered list of policy entries. A policy specifies traffic selectors and actions to be taken for matching packets. SPD policy: Traffic selectors Packet filters that select the packets to which a policy applies. Defined based on: Source and destination addresses. Protocol id. Source and destination ports. Source and destination names (e.g., DNS). Octavian Catrina 20

19 Security policies 2/2 SPD policy: Actions Possible actions: discard, bypass, protect. Discard (packet) Do not let the packet in or out. Bypass (sec) Outbound packet: do not apply sec. Inbound packet: do not expect sec. Protect (packet) If the SPD entry points to an SA (or SA bundle): Outbound packet: Apply security as specified in SA. Inbound packet: Check that security has been applied. If an SA does not exist: Outbound packet: use IKE to create a new SA. Inbound packet: discard the packet. Octavian Catrina 21

20 Packet processing (outline) Example: ESP transport mode. Host or router X Sec SA Host or router Y Outbound packet header XY Find matching SP in SPD SPD (policies) DA=Y... SA... header XY If Sec protected packet, get its SA SAD (assoc.)... ESP, TR... ESP header Sec trs. processing Inbound packet header XY AH/ESP SPI, DA ESP trailer ESP header SP = Security Policy SPD = Security Policy Database SA = Security Association SAD = Security Association Database SAD (assoc.)... ESP, TR... ESP trailer header XY SPD (policies) DA=Y... SA... Set up new SA if Sec is required and SA not found If AH/ESP, find matching SA Sec rec. processing Find & check matching SP Discard Sec packet if SA not found, verification fails,... See RFC 4301 Octavian Catrina 22

21 Examples End-to-end security between 2 hosts Transport mode or tunnel mode. H1 Internet or Intranet sec Security Association Transport (or Tunnel) mode Site-to-site VPN (intranet/extranet) Tunnel mode. Can also set up nested tunnels, possibly with different endpoints. H2 Encapsulation # Protocol Transport mode 1 AH [1][AH][upper] 2 ESP [1][ESP][upper] 3 AH + ESP [1][AH][ESP][upper] 1 = Original header 2 = Tunnel header Upper = Original # Protocol Tunnel mode 4 AH [2][AH][1][upper] 5 ESP [2][ESP][1][upper] H1 SG1 Internet SG2 H2 sec Security Association - Tunnel mode SG = sec VPN Gateway Octavian Catrina 23

22 Remote access VPN More examples Tunnel mode (possibly combined with transport mode). H1 Internet sec SG2 or -sec H2 Security Association - Tunnel mode Optional Security Association - Transport mode Site-to-site VPN and end-to-end security Intranet or extranet. Tunnel mode combined with transport mode. H1 SG1 Internet SG2 H2 -sec sec -sec SG = sec VPN Gateway Security association - Tunnel mode Security association - Transport mode Octavian Catrina 24

23 IKE Protocol Internet Key Exchange Introduction

24 IKEv1 overview IKEv1 (1998) description is spread over several RFCs... Start with: RFC 2408: ISAKMP (Internet Security Association Key Management Protocol). Generic framework. RFC 2409: IKE (Internet Key Exchange). RFC 2407: sec Domain Of Interpretation (DOI) for ISAKMP. IKEv1 is a mixture of several protocol proposals... Quotes from RFC 2409: "This document describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP... While Oakley defines "modes", ISAKMP defines "phases". The relationship between the two is very straightforward and IKE presents different exchanges as modes which operate in one of two phases..." it is by far too complex... E.g., main mode and aggressive mode, with 4 different variants: 8 (eight) protocol variants just for creating an IKE SA. and has some design flaws. Octavian Catrina 26

25 Overview: SA management IKEv1 SA management A security association defines the parameters for a single protocol: IKE or AH or ESP. IKE starts by establishing an IKE SA (Phase 1). The IKE SA is a secure channel used to set up efficiently children SAs, which are AH SA or ESP SA (Phase 2), and for other SA management tasks (re-keying, error/status, delete). Negotiation of SA attributes IKE allows the selection of the cryptographic algorithms and their parameters, separately for each SA. Algorithms that are negotiated: encryption, MAC, Diffie-Hellman group (global parameters), PRF (pseudorandom function), etc. The PRF (based on MAC) is used to generate the shared keys from the exchanged key material, for IKE SA and children SAs. Octavian Catrina 27

26 Overview: Key exchange Security requirements Authenticated key exchange with mutual authentication. PFS, identity hiding, (some) protection against DoS attacks. Key generation Distinct sets of keys are established for the IKE SA and for each of the children SA. Keys are different for each direction of data flow and for each algorithm (MAC and encryption). All these keys are obtained using PRF from the random key material exchanged by IKE (DH exponentials and nonces). IKE messages transport IKE messages are delivered using UDP. IKE entities send and receive using UDP port number 500. Octavian Catrina 28

27 IKE design: Identity hiding 1/2 Authenticated key exchange with identity hiding Some application scenarios require the protection of endpoint identities during key exchange, against passive/active attacks. E.g., hide identity info provided in public-key certificates. Conflicting requirements: authentication vs. identity hiding. What protection can be achieved? Hide initiator and responder identity against passive attacks. Hide either initiator, or responder identity against active attacks. Example: AKE protocol that does NOT hide identities DH with authentication based on SIG. A B Choose random DH exponent x, A, g x Choose random DH exponent y,... Authenticate B. Compute keys K = PRF(g xy ). SIG A (A B g x g y ) B, g y, SIG B (B A g y g x ) Compute keys K = PRF(g xy ). Authenticate A. Octavian Catrina 29

28 Identity hiding 2/2 Example: AKE protocol that hides identities DH with authentication based on SIG (and MAC). SIGMA (SIGn and MAc) protocol. Choose random DH exponent x, compute g x Compute keys: PRF(g xy ) = K1A K2A K1B K2B. Authenticate peer and avoid active attacks using SIG and MAC. Use (authenticated) encryption to hide identity. A g x g y, E K1B {B, SIG B (g y g x ), MAC K2B (B)} E K1A {A, SIG A (g x g y ), MAC K2A (A)} Variant (used in IKE): SIG(MAC(g x g y ID)) B Choose random DH exponent y, compute g y. Compute keys: PRF(g xy ) = K1A K2A K1B K2B. Authenticate peer and avoid active attacks using SIG and MAC. Use (authenticated) encryption to hide identity. In the previous variant, signing the peer's identity avoids identity misbinding attacks. But that solution does not allow identity hiding. In SIGMA, the attacks are avoided by using a MAC of the sender's identity, which proves knowledge of the established key. Encryption (authenticated) is added only to hide the identities. This protocol hides both identities for passive attacks, and hides the identity of the initiator for active attacks. Octavian Catrina 30

29 IKE design: Defense against DoS Clogging protection An adversary can mount a denial-of-service attack by sending a large number of authentication requests. Typically the attacker uses forged source addresses to hide his/her identity. Defense (weak): Check if the initiator is indeed at the source address in the request, before committing any resources. Initiator Example: Stateless "cookies" preamble Responder Attacker can send any string as "g x ". g x (I want to talk) cookie (Send back this cookie...) Compute cookie c = hash(secret, addr.). Stateless cookie, g x (Your cookie. My DH exp)... If cookie = hash(secret, addr.) continue protocol. This technique adds a round-trip delay. Should be optional: Use it only when the responder detects a DoS attack. Octavian Catrina 31

30 Towards real-life AKE protocols Combine nonces and DH exponentials Use DH exponentials for key secrecy with PFS. Use nonces for liveness and key freshness. This allows limited reuse of DH exponentials, with "less-than-perfect" forward secrecy. Enable parallel computations Computation of session keys and authenticators is time consuming. Can be done by the two parties in parallel rather than sequentially. Hence, exchange the key material first. Add session ids, crypto negotiation, certificates, etc. SA A, SA B are used to identify the SA and negotiate ciphers and traffic selectors. Compute keys: PRF(g xy, n A n B ) = K1A K2A K1B K2B. Use them to protect next messages. A Example: AKE using DH with authentication based on SIG (and MAC) n A, g x, SA A (SPI A, cipher proposal) n B, g y, SA B (SPI B, cipher selection) Compute MAC K2A (A) and E K1A {A, AUTH A, MAC K2A (A), CERT A } AUTH A = SIG A (n B n A g x SA A ) Verify AUTH B, MAC K2B (B). E K1B {B, AUTH B, MAC K2B (B), CERT B } Compute MAC K2B (B) and Auth B = SIG B (n A n B g y SA B ) Verify AUTH A, MAC K2A (A). Octavian Catrina 32 B Comp. keys: PRF(g xy, n A n B ) = K1A K2A K1B K2B. Use them to protect messages.

31 IKEv1 Internet Key Exchange Version 1

32 IKEv1 key exchange Phase 1 (Main Mode): Establish an IKE SA Two "modes": Main mode offers all features and needs 6 messages. Aggressive modes uses only 3 messages, but less features (e.g., no identity hiding). Four authentication variants (you'll see only 3 of them): Digital signatures (SIG). Pre-Shared Key (PSK). Public-key encryption (PKE, 2 variants!). Phase 2 (Quick Mode): Establish children SA Fast setup of one or more AH or ESP SA. Protected by IKE SA. Also, SA re-keying. Informational exchanges Notification (error, status), SA termination. Protected by IKE SA. Octavian Catrina 34

33 IKEv1 keys and authenticators Generation of IKEv1 master shared secret SKEYID SIG authentication: SKEYID = PRF(Ni Nr, g ir ). PKE authentication: SKEYID = PRF(hash(Ni Nr), CKYi CKYr). PSK authentication: SKEYID = PRF(PSK, Ni Nr). Nonces Ni, Nr, cookies CKYi, CKYr (IKE session IDs) for initiator, responder; DH shared secret g ir ; pre-shared key PSK; PRF(k, x) = MAC k (x), e.g., HMAC. Generation of IKEv1 operational keys SK_d = PRF(SKEYID, g ir CKYi CKYr 0). SK_a = PRF(SKEYID, SK_d g ir CKYi CKYr 1). SK_e = PRF(SKEYID, SK_a g ir CKYi CKYr 2). IKEv1 s are encrypted and authenticated using the keys SK_e and SK_a, respectively (different keys for each direction). SK_d is used as key seed to generate keys for ESP/AH SAs. Computation of the IKEv1 authenticators HASHi = PRF(SKEYID, g i g r CKYi CKYr SAi IDi). HASHr = PRF(SKEYID, g r g i CKYr CKYi SAi IDr). Octavian Catrina 35

34 Phase 1: Authentication using SIG Main mode Generate random DH exponent i and random nonce Ni Generate IKE keys SKEYID = PRF(Ni Nr, g ir ) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Compute AUTHi. AUTHi = SIGi(HASHi) HASHi = PRF(SKEYID, g i g r CKYi CKYr SAi IDi) Verify AUTHr. Aggressive mode No identity hiding. Limited cipher negotiation (initiator chooses DH gr.). No anti-clogging. Initiator Initiator HDRi, g i, Ni Negotiate ciphers, exchange cookies (session ids) HDRi(CKYi), SAi(cipher proposal) HDRi, SKi{IDi, [CERTi], SIGi(HASHi)} HDRr(CKYr), SAr(cipher selection) Exchange DH public exponentials and random nonces HDRr, g r, Nr Compute the master secret SKEYID and the other IKE keys. Payload of next IKE messages is encrypted and authenticated. Exchange identities and authenticators. Identity hiding: Payload is encrypted and authenticated using the IKE keys SK_e and SK_a. HDRr, SKr{IDr, [CERTr], SIGr(HASHr)} The authenticators provide proof of identity and authenticate data sent during IKE exchange (including cipher negotiation). HDRi(CKYi), SAi, g i, Ni, IDi HDRr(CKYr), SAr, g r, Nr, IDr, [CERTr], SIGr(HASHr) HDRi, [CERTi], SIGi(HASHi) Responder Responder Anti-clogging is flawed in all variants: exchange of cookies is not stateless, so partial DOS protection. Generate random DH exponent r and random nonce Nr Generate IKE keys SKEYID = PRF(Ni Nr, g ir ) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Verify AUTHi. Compute AUTHr. AUTHr = SIGr(HASHr) HASHr = PRF(SKEYID, g r g i CKYr CKYi SAi IDr) Flawed: Identities could have been encrypted. Octavian Catrina 36

35 Phase 1: Authentication using PSK Main mode Generate random DH exponent i and random nonce Ni Generate IKE keys SKEYID = PRF(S, Ni Nr) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Compute AUTHi. AUTHi = HASHi HASHi = PRF(SKEYID, g i g r CKYi CKYr SAi IDi) Verify AUTHr. Aggressive mode No identity hiding. Limited cipher negotiation (initiator chooses DH gr.). No anti-clogging. Initiator Initiator Pre-shared key S Negotiate ciphers, exchange cookies (session ids) HDRi(CKYi), SAi(cipher proposal) HDRi, g i, Ni HDRi, SKi{IDi, [CERTi], HASHi} HDRr(CKYr), SAr(cipher selection) Exchange DH public exponentials and random nonces HDRr, g r, Nr Both compute the master secret SKEYID and the other IKE keys. Payload of next IKE messages is encrypted and authenticated. Exchange identities and authenticators. Identity hiding: Payload is encrypted and authenticated using the IKE keys SK_e and SK_a. HDRr, SKr{IDr, [CERTr], HASHr} The authenticators provide proof of identity and authenticate data sent during IKE exchange (including cipher negotiation). HDRi(CKYi), SAi, g i, Ni, IDi HDRi, HASHi HDRr(CKYr), SAr, g r, Nr, IDr, HASHr Responder Responder Flawed: How does the responder know what PSK to use? Must use address as identity. Generate random DH exponent r and random nonce Nr Generate IKE keys SKEYID = PRF(S, Ni Nr) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Verify AUTHi. Compute AUTHr. AUTHr = HASHr HASHr = PRF(SKEYID, g r g i CKYr CKYi SAi IDr) Flawed: Identities could have been encrypted. Octavian Catrina 37

36 Main mode Phase 1: Authentication using PKE (1) Weakness: Both parties must know what public encryption keys to use. Generate random DH exponent i and nonce Ni. Encrypt with PKE Ni, IDi. Generate IKE keys SKEYID = PRF(hash(Ni Nr), CKYi CKYr) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Compute AUTHi. AUTHi = HASHi HASHi = PRF(SKEYID, g i g r CKYi CKYr SAi IDi) Verify AUTHr. Initiator HDRi, g i, [hash(certr),] PKr{IDi}, PKr(Ni) HDRi, SKi{HASHi} First variant Negotiate ciphers, exchange cookies (session ids) HDRi(CKYi), SAi(cipher proposal) HDRr(CKYr), SAr(cipher selection) Exchange DH public exponentials and encrypted random nonces HDRr, g r, PKr{IDr}, PKi(Nr) Both compute the master secret SKEYID and the other IKE keys. Payload of next IKE messages is encrypted and authenticated. Exchange identities and authenticators. Identity hiding: Payload is encrypted and authenticated using the IKE keys SK_e and SK_a. HDRr, SKr{HASHr} The authenticators provide proof of identity and authenticate data sent during IKE exchange (including cipher negotiation). Responder Weakness: Many expensive PKE operations. Generate random DH exponent r and nonce Nr. Encrypt with PKE Nr, IDr. Generate IKE keys SKEYID = PRF(hash(Ni Nr), CKYi CKYr) SKi = (SK_ei, SK_ai) SKr = (SK_er, SK_ar) Verify AUTHi. Compute AUTHr AUTHr = HASHr HASHr = PRF(SKEYID, g r g i CKYr CKYi SAi IDr). Aggressive mode With identity hiding. Limited cipher negotiation. No anti-clogging. Initiator HDRi, SAi, g i, [hash(certr),] PKr{IDi}, PKr(Ni) HDRi, HASHi HDRr, SAr, g r, PKr{IDr}, PKi(Nr), HASHr Responder Octavian Catrina 38

37 Phase 1: Authentication using PKE (2) Compute AUTHi. AUTHi = HASHi HASHi = PRF(SKEYID, g i g r CKYi CKYr SAi IDi) Verify AUTHr. HDRi, SKi{HASHi} Revised (optimized) variant Main mode Initiator Responder Weakness: Initiator must Negotiate ciphers, exchange cookies (session ids) already have responder's HDRi(CKYi), SAi(cipher proposal) public encryption key. Generate random DH HDRr(CKYr), SAr(cipher selection) exponent i and nonce Ni. Exchange DH public exponentials and encrypted random nonces Encrypt with PKE Ni, IDi. Generate SKi = PRF(Ni, HDRi, [hash(certr),] PKr(Ni), SKi{g i, IDi, [CERTi]} CKYi) = (SK_ei, SK_ai) HDRr, PKi(Nr), SKr{g r, IDr} Generate SKr = PRF(Nr, CKYr) = (SK_er, SK_ar). Both compute the master secret SKEYID and the other IKE keys. SKEYID = PRF(hash(Ni Payload of next IKE messages is encrypted and authenticated. Nr), CKYi CKYr) Exchange identities and authenticators. Identity hiding: Payload is encrypted and authenticated using the IKE keys SK_e and SK_a. HDRr, SKr{HASHr} The authenticators provide proof of identity and authenticate data sent during IKE exchange (including cipher negotiation). Advantage: Reduces the number of PKE operations. Generate random DH exponent r and nonce Nr. Encrypt with PKE Nr, IDr. Generate SKi = PRF(Ni, CKYi) = (SK_ei, SK_ai). Generate SKr = PRF(Nr, CKYr) = (SK_er, SK_ar). SKEYID = PRF(hash(Ni Nr), CKYi CKYr) Verify AUTHi. Compute AUTHr. AUTHr = HASHr HASHr = PRF(SKEYID, g r g i CKYr CKYi SAi IDr). Aggressive mode With identity hiding. Limited cipher negotiation. No anti-clogging. Initiator HDRi, SAi, [hash(certr),] PKr(Ni), SKi{g i, IDi, [CERTi]} HDRi, HASHi HDRr, SAr, PKi(Nr), SKr{g r, IDr}, HASHr Responder Octavian Catrina 39

38 Phase 2 (Quick Mode) Initiator IKE SA (Phase 1 completed) Responder SAi: SPIi, cipher proposal and traffic selectors HDRi, SKi{Hash(1), SAi, Ni [, g i ][, IDci, IDcr]} HDRi, SKi{Hash(3)} HDRr, SKr{Hash(2), SAr, Nr [, g r ] [, IDci, IDcr]} Phase 2 authenticators (M-ID is the Message ID in HDR): HASH(1) = PRF(SKEYID_a, M-ID SAi Ni [ g i ] [ IDci IDcr]) HASH(2) = PRF(SKEYID_a, M-ID Ni SAr Nr [ KE ] [ IDci IDcr]) HASH(3) = PRF(SKEYID_a, 0 M-ID Ni Nr) Key generation (AH/ESP protocol; new ciphers, nonces, DH secret): No PFS: KEYMAT = PRF(SKEYID_d, protocol SPI Ni Nr) With PFS: KEYMAT = PRF(SKEYID_d, g ir (new) protocol SPI Ni Nr) SAr: SPIr, cipher selection and traffic selectors Phase 2 is used to create a child SA (ESP or/and AH) of the current IKE SA or for re-keying. New keys for this SA are computed using a secret derived in Phase 1 for this purpose (SKEYID_d), the new nonces and the (optional) D-H exponentials. The messages are encrypted and integrity protected using the algorithms and keys established in Phase 1 (i.e., using IKE SA). Octavian Catrina 40

39 IKEv2 Internet Key Exchange Version 2

40 IKEv2 overview IKEv2 is a substantial redesign of IKE Revised authentication methods Keeps authentication using SIG or PSK. Skips PKE variant. Adds extensible authentication using EAP. Simpler and more efficient Two handshakes (4 messages) are sufficient to set up an IKE SA together with a child SA (the typical case). Contrast this with messages in IKEv1. Clear description in one document RFC 4306 (Dec. 2005). Improved functionality Elimination of IKEv1 flaws. Some new features: e.g., support for NAT traversal. Octavian Catrina 42

41 Protected message (encryption and MAC using ESP format) IKEv2 exchanges: overview Initiator IKE_SA_INIT exchange - Negotiate cryptographic algorithms for IKE SA. - Exchange nonces and Diffie-Hellman public exponentials. Responder Compute IKE SA keys IKE_SA_INIT request IKE_SA_INIT response IKE_AUTH exchange Exchange identities and (optionally) certificates. Authenticate using signature or MAC (for PSK) and check integrity of previous messages, prove knowledge of the IKE SA keys (they are used to protect these messages). Establish the first AH or/and ESP child SA(s). IKE_AUTH request IKE_AUTH response CREATE_CHILD_SA exchange (optional) Establish additional child SA(s), or re-key IKE SA. Compute IKE SA keys CREATE_CHILD_SA request CREATE_CHILD_SA response INFORMATIONAL exchanges Error notifications, liveness tests, SA termination, etc. Request-response exchange, like all IKE exchanges. Octavian Catrina 43

42 IKE_SA_INIT exchange Initiator IKE_SA_INIT exchange - Negotiate cryptographic algorithms for IKE SA. - Exchange nonces and Diffie-Hellman (DH) exponentials. Responder M1: IKE_SA_INIT request: HDR, SAi1, KEi, Ni. I want to set up a new SA. Ciphers I propose for IKE SA, SAi1. My DH public exponential KEi = g i, and my nonce Ni. M2: IKE_SA_INIT response: HDR, SAr1, KEi, Nr. Ciphers I choose for IKE SA, SAr1. My DH public exponential KEr = g r, and my nonce Nr. This completes the selection of cryptographic algorithms and the exchange of key material. Both parties can now compute SKEYSEED and generate the IKE keys, used starting with the next exchange, IKE_AUTH. A clogging protection mechanism can be used in case of denial-of-service attacks (responder replies with a cookie instead of the normal response). An SA contains an ordered list of proposals. Each proposal may contain multiple protocols (IKE, ESP, or AH). Each protocol may contain multiple transforms. Each transform may contain multiple attributes. Octavian Catrina 44

43 Key generation for IKE_SA Master shared secret SKEYSEED SKEYSEED = PRF(Ni Nr, g ir ). Ni, Nr nonces (initiator, responder); g ir = Diffie-Hellman shared secret. Notation: PRF(k, x) = MAC k (x), where MAC is HMAC or AES-XCBC. Iterated PRF for key expansion PRF+ (K, S) = T1 T2 T3... T1 = PRF(K, S 0x01); T2 = PRF(K, T1 S 0x02); T3 = PRF(K, T2 S 0x03); T4 = PRF(K, T3 S 0x04),... Computation of IKEv2 keys PRF+ (SKEYSEED, Ni Nr SPIi SPIr) = SK_d SK_ai SK_ar SK_ei SK_er SK_pi SK_pr SK_d is used as key seed to similarly generate keys for children SAs. MAC keys SK_ai/SK_ar and encryption keys SK_ei/SK_er for IKE initiator/responder; SK_pi, SK_pr are used for (entity) authentication. Octavian Catrina 45

44 Protected message (encryption and MAC using ESP format) IKE_AUTH exchange Initiator IKE_AUTH exchange - Exchange identities and (optionally) certificates. - Authenticate using signature or MAC (for PSK) and check integrity of previous messages, prove knowledge of the IKE SA keys (they are used to protect these messages). - Establish the first AH or/and ESP child SA(s). Responder M3: IKE_AUTH request: HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}. My identity IDi. My certificates CERT, my trusted CAs CERTREQ, your assumed identity IDr (optional). My signature on s of previous messages AUTH. Ciphers I propose for the first child SA, SAi2, and its traffic selectors TSi, TSr. All encrypted and integrity protected using established keys SK (ESP-like ), also proving I know the keys. M4: IKE_AUTH response: HDR, SK{IDr, [CERT,] AUTH, SAr2, TSi, TSr}. My identity IDr and my certificates CERT (optional). My signature on s of previous messages AUTH. Ciphers I choose for the first child SA, SAr2, and traffic selectors TSi, TSr. All this encrypted and integrity protected using established keys SK (ESP-like ). This completes the creation of the IKE SA and of the first CHILD_SA (ESP or/and AH). The keys for the first child SA are computed using the same algorithm like the IKE keys, using SK_d as key seed and nonces Ni, Nr. Octavian Catrina 46

45 Authentication of IKE SA Authentication data Initiator: Auth_data = M1 Nr PRF(SK_pi, IDi). Responder: Auth_data = M2 Ni PRF(SK_pr, IDr). Authentication based on signature AUTH = SIG(Auth_data). This also provides data authentication for the IKE_SA_INIT exchange (M1 and M2, including SA negotiation, etc.). Moreover, IKE_AUTH is protected by MAC and encryption with the new IKE SA keys. This also proves knowledge of the keys. Authentication based on PSK MAC with shared key K instead of signature. AUTH = PRF(PRF(K, "Key Pad for IKEv2"), Auth_data). Extensible authentication Modified authentication exchange to accommodate the Extensible Authentication Protocol (EAP). Octavian Catrina 47

46 Protected message (encryption and MAC using ESP format) CREATE_CHILD_SA exchange Initiator CREATE_CHILD_SA exchange - Establish additional child SA(s) for an existing IKE SA. - Or re-key the current IKE SA. Responder CREATE_CHILD_SA request: HDR, SK{[N], SA, Ni, [KEi], [TSi, TSr]}. I want to set up an additional child SA. Proposed ciphers, SA (and optionally traffic selectors TSi, TSr). My new nonce Ni and optionally a new DH public exponential KEi. Payload N indicates re-keying of existing SA. All this encrypted and integrity-protected using the keys SK of the current IKE SA (ESP-like ). CREATE_CHILD_SA response: HDR, SK{SA, Nr, [KEr], [TSi, TSr]}. OK. Ciphers I choose, SA (and optionally traffic selectors TSi, TSr). My new nonce Nr and optionally a new DH public exponential KEr. All this encrypted and integrity-protected using the keys SK of the current IKE SA (ESP-like ). ESP SAs and AH SAs exist in pairs, one for each direction. A CHILD_SA exchange can create a pair of ESP SAs, AH SAs, or ESP+AH SAs. Keys for these SAs are computed using SK_d and the new nonces and (if exchanged) DH exponentials (next slide). Octavian Catrina 48

47 Keys for CHILD_SAs. Re-keying Creating CHILD_SAs and re-keying existing SAs A first CHILD_SA is created by the IKE_AUTH exchange. CREATE_CHILD_SA exchanges are used to create additional CHILD_SAs or to re-key the IKE SA and existing CHILD_SAs. Key material for CHILD_SAs KEYMAT = PRF+(SK_d, [g ir (new) ] Ni Nr). First CHILD_SA: No DH secret. Ni, Nr from IKE_SA_INIT exchange. Next CHILD_SAs: Ni, Nr, and (optionally) the DH secret (if available) from CREATE_CHILD_SA exchange. Encrypt and MAC keys are taken from KEYMAT (similar to IKE). IKE SA re-keying SKEYSEED = PRF(SK_d (old), [g ir (new) ] Ni Nr). Ni, Nr, and DH secret (if available) from CREATE_CHILD_SA. SK_d, SK_ai, SK_ar, SK_ei, and SK_er are then computed from SKEYSEED as described earlier. Octavian Catrina 49