Virtual Private Networks

Transcription

1 Virtual Private Networks Petr Grygárek rek Agenda: VPN Taxonomy VPN Principles and Usage Cryptography Basics IPSec 1

2 Basic Terminology and Mechanisms of Network Security and Cryptography 2

3 Confidentality Data Protection unauthorized listener cannot understand data meaning implemented by encryption Authentication verification of data sender identity Data integrity verification that data were not modified during transport Non-repudiation data source cannot repudiate that it sent particular piece of data (i.e. it signed it) 3

4 Cryptographic Hash Function (1) one-way function (algorithm) that converts (arbitrary, long) block of data to (short) fixed-size hash value easy to compute infeasible to find a message with a given hash infeasible to modify a message without changing its hash Infeasible to find 2 different messages with the same hash 4

5 Cryptographic Hash Function (2) often used as Hashed Message Authentication Code (HMAC) the hash is computed from [data+secret] block algorithms commonly used as hash function HMAC-MD5 Message Digest 5 (128b message digest) HMAC-SHA1 Secure Hash Algorithm (stronger -160b message digest) 5

6 Cryptographic System plain text Encryption cyper text Decryption plain text Key Key Implementation options Conceal encryption/decryption algorithm If the algorithm is revealed, implementation is useless Conceal keys Keys used to parametrize (known) algorithm Enough number of possible keys has to be available 6

7 Symmetric Cryptosystem 7

8 Properties of Symmetric Cryptosystem Shared secret key Effective algorithm implementations speed, relative simplicity possible to implement in hardware DES, 3DES, AES, Problem with secure secret key distribution 8

9 Authentication in Symmetric Cryptosystem Sender encrypts username u using shared key, receiver decrypts using the same key and tests username validity Requires database of valid usernames Alternative validity check implementation: Sender appends username hash behind username, then encrypts whole block with shared key Receiver decrypts [username+hash] with shared key, computes username hash and compares with received hash Does not require to maintain username database Combines authentication with data integrity check 9

10 Data Integrity Check Implementation [message+shared shared secret key]->hash message+hash is sent receiver appends shared secret key behind received message, calculates hash by itself and compares with received hash Combines origin authentication and data integrity check 10

11 Asymmetric Cryptosystem 11

12 Public and Private Keys K A_PUBLIC K A_PRIVATE K B_PUBLIC K B_PRIVATE ALICE Encryption Decryption BOB public key K B_PUBLIC private key K B_PRIVATE Certification authority KA_PUBLIC K B_PUBLIC Keys generated as pair public and private key One key of pair used for encryption, second one for decryption no matter which one for what uses identical or complementary algorithms for encryption and decryption 12

13 Features of Asymmetric Cryptosystem More calculations comparing to symmetric algorithm => slower RSA, El-Gammal Problem of secure public key distribution no need to conceal them,, but we need a mechanism to protect public keys against modification during transport certification authority digitally signs public keys packed together with owner information (so called certificates ) 13

14 Usages of asymmetric metric system Digital signatures No problem with secret key distribution Exchange of keys for symmetric system Often dynamically generated keys with limited lifetime 14

15 Certification authority (1) Trusted entity Digitally signs public keys packed together with owner information - certificates First contact with CA must be physical (identity verification) obtaining of private+public key pair private key + signed certificate There exist ways how to deliver encrypted private key + certificate (containing signed public key) without physical contact need to authenticate certificate request (e..g with existing trusted password already used for something else) LDAP password etc. prenegotiated password used between user and CA to encrypt private key and certificate before sending it to user private+public key generation may take place at client OS Only client keeps private key and sends public key for signing to CA using HTTPS 15

16 Certification authority (2) Public key of CA needed by communicating parties to verify certificates of other communicating peers Public key of CA has to be inserted into every system by some trustworthy manner built-in into OS/WWW browser installation files, Advantage: only one public key (CA certificate) has to be preconfigured manually 16

17 Authenti entication and Data Integrity Check in Asymmetric System Hash comparison ALICE Data Hash Data Hash BOB K A_PUBLIC K A_PRIVATE K B_PUBLIC K A_PRIVATE K B_PRIVATE K A_PUBLIC K B_PUBLIC K B_PRIVATE 17

18 Virtual Private Networks (VPN) 18

19 What is VPN? VPN allow to build private WANs using (public) shared infrastructure with the same level of security and configuration options as with private infrastructure Cheaper and flexible method for interconnection of geographically dispersed sites Note: In principle, VPN overlay itself does NOT have to be encrypted Trasport over secure infra, encryption on application level,... 19

20 Advantages of VPNs over Physical Private WAN Infrastructure Lower cost Short time of deployment Flexibility of (virtual) topology topology defined purely by configuration No WAN link maintenance and management needed provider (ISP) takes responsibility of infrastructure 20

21 Some VPN Classification Criteria (1) Level of customer trust to the shared infrastructure provider trusted/secured (+ level of security) Protocol/technology applied in the infrastructure provider's (underlay) network L3: packet-based (IPv4/IPv6), VxLANs,... L2: Virtual-circuit based (Frame Relay, ATM, VLANs) L2.5: IP/MPLS VPN Location of tunnel termination (CE/PE) 21

22 Some VPN Classification Criteria (2) Amount of routing information exchanged between provider and customer sites Overlay (CPE-based) model Peer-to-peer (network-based) model Mixed model (MPLS VPN) Virtual topology options Point-to-point (virtual private lines) + topologies built from virtual P2P links Multipoint (virtual routed/switched network) 22

23 Some VPN Classification Criteria (3) OSI layer of overlay connectivity L2 L2-technology dependent May support interworking L3 protocol transparent L3 Independent on L2 protocols L3-protocol dependent unicast/multicast/both traffic support Application scenarios Site-to-site (L2L VPN) / Remote access (Client VPN) / VPDN 23

24 Some VPN Classification Criteria (4) Manual/Automatic configuration automatic configuration requires signaling & authentication automatic configuration is almost inevitable for interconnection of hundreds of thousands of customer sites 24

25 Overlay model Uses tunneling methods Encryption and authentication applied in most cases Does not utilize underlying infrastructure efficiently unless ovoerlay full mesh is configured Customers have no visibility of provider's network and vice versa No special contract with infrastructure provider is needed ISP musr not filter tunneling protocols (GRE, IPSec AH/ESP etc.) 25

26 Peer-to-Peer model Provider network devices have to carry all customers' routes Problems with overlapping (private) addresses non-unique destination addresses Complicated filtering has to be configured poor scalability, risk of misconfiguration Optimal routing across provider's shared infrastructure 26

27 Tunnel Virtual point-to-point connection over shared infrastructure often authenticated and encrypted Carries packets of some protocol encapsulated in another protocol sometimes in the same protocol (IP( over IP) tunnel can carry layer 2 frames also allows other protocols to be carried over underlay (mostly IP) network (even nonroutable protocols such as NetBEUI etc.) 27

28 VPN Protocols and Tunneling Techniques IP/IP (v4xv6), GRE, VxLAN L2TP (PPP frames), MPLS, IPSec SSL... 28

29 Most Common VPN Implementation Options Internetwork-wide VPNs => tunnels at or above layer 3 Layer 3 VPN IPSec media independent (above hop-by-hop L2 security) application independent connectionless security Layer 4 VPN SSL/TLS for TCP DTLS for UDP Layer 7 VPN application level (WWW) Neighbor-to-neighbor protection in today's LANs Later2: MACSec/TrustSec 29

30 Most Common VPN Implementation Scenarios Router-to-router (firewall( firewall) Site-to-site VPNs Single router may terminate multiple tunnels Remote User to VPN concentrator Remote access VPNs user has to have special encryption software installed (VPN client) Often used also over corporate LANs for production network managenent access 2009 Petr Grygárek, FEI VŠB-TU Ostrava, Computer Networks (Bc.) 30

31 Common VPN Applications (1) Site-to-site VPNs Router to router router (firewall to firewall) secure interconnection of (multiple) distant LANs counterpart with classical WAN networks Site-to-sitetunnel Encryption, Decryption Unsecurepublic infrastructure (Internet) Encryption, Decryption Secureintranet (2) Secureintranet (1) 31

32 Common VPN Applications (2/1) Remote access VPNs Client-initiated Remote user to VPN concentratortor user has special encryption software installed (VPN( client) NAS-initiated Remote user dials in to service provider s NAS using some connection-oriented telecommunication network (e.g. PSTN, ISDN) considered trustworthy NAS initiates secure tunnel to secure corporate network 32

33 Common VPN applications (2/2) PSTN NAS-initiated VPN tunnel Encryption tunnels modem User without any special software ISP NAS Unsecure public infrastructure (Internet) VPN concentrator Decryption Encryption User with VPN client software Client-initiated VPN tunnel Secure intranet 33

34 Virtual Private Dial-up Networks Provides connection of remote users into private networks Saves customers from maintaining their own physical RAS solution and interconnection to Telco Interoperation between provider's and customers' AAA infrastructures L2TP carries PPP sessions LAC L2TP Access Concentrator LNS L2TP Network Server 34

35 IPSec 35

36 IPSec (RFC 2401) IPSec = suite of protocols and algorithms used for data security implementation at network layer Open standards framework General, independent to actual algorithms used flexible and stable no need for complete change when particular algorithm is compromised Provides authenti entication, data integrity y and confidentality using particular preconfigured or negotiated algorithms, not by itself Only for unicast IP traffic but other protocols including IP broadcasts/multicasts can be encapsulated into IP before transportation over IPSec mechanism Implemented as additional mechanism for IPv4, natively built-in into IPv6 36

37 Basic IPSec terminology Security Association Set of policies and keys for data protection Shared by (two) communicating partners Authentication Header Header appended to IP packet to carry authentication system information (HMAC etc.) Encapsulating Security Payload Header Header appended to IP packet to carry security system information (authentication, confidenitality) 37

38 Security Association (1) Defines encryption and authentication parameters used between two partners communicating over IPSec tunnel encryption and authentication algorithm, key size, key lifetime encryption and authentication key (symmetric) IPSec mode (tunnel/transport) encapsulation protocol (AH/ESP) specification of traffic to be encrypted (/decrypted) ( proxyid ) Pre-configured or dynamically negotiated between partners during IPSec tunnel establishment 38

39 Security Association (2) Independent for both traffic directions Independent SAs for individual security protocols i.e. AH, ESP, IKE Internet Key Exchange (IKE) provides secure tunnel for dynamic SA negotiation Limited lifetime time/bytes transferred new SA is negotiated before lifetime expiration Stored in Security Association Database (SADB) Security Parameter Index (SPI) + SA values 39

40 IPSec modes: Tunnel and Transport Tunnel mode Transport Mode 40

41 End-to-end security Transport Mode Needs IPSec support in end-user stations operating system AH and ESP inserted between L3 anda L4 headers Impossible to filter traffic according to L4 header in the network (L4 header is encrypted) Next-header field of AH/ESP header identifies L4 header (L4 protocol) Original IP header unencrypted But protected by authenti entication/data integrity => incompatible with NAT 41

42 Tunnel Mode IPSec tunnel between routers connecting secure LANs to unsecure shared infrastructure (IPSec gateways) no need for IPSec support in users station operating systems IP packets encapsulated by another IP packets (tunnel) AH and ESP inserted at the beginning of encapsulating packet data field, original unchanged (tunneled) packet follows Packets encrypted including their IP headers => > potential spy in insecure network cannot even determine which stations of secure networks speak together Used most commonly today. 42

43 Transfer of IPSec Control C Information Authentication Header Information for authentication and data integrity Encapsulating Security Payload Information for encryption, authentication and data integrity and optionally anti-replay May completely supersede authentication header AH defined earlier, still maintained for compatibility with older implementations 43

44 Authentication header Assures authentication and (connectionless) data integrity Protects IP headerh (unchanging fields) and IP packet data carries authentication information (HMAC) carries Security Parameters Index (SPI) to identify particular security association used for current packet if multiple SAs used concurrently Optional support for anti-replay Sender inserts sequence numbers into packets, receiver may optionally verify them Protects transport IP header => > incompatible with NAT 44

45 AH transport mode 45

46 AH tunnel mode 46

47 Encapsulating Security Payload-ESP Carries control information for data encryption (and authentication) encapsulates protected data Optional data authentication and integrity check (only user data) Optional anti-replay check May provide all functions of authentication header 47

48 ESP transport mode 48

49 ESP tunnel mode 49

50 Dynamic SA negotiation Manual configuration of SAs at multiple stations is tedious and error-prone task Need for reoccurring reconfiguration - periodic change of authentication/encryption keys is necessary 50

51 Dynamic SA Negotiation Frameworks Internet Security Association and Key Management Protocol (ISAKMP) framework for secure (dynamic) key exchange and negotiation of security associations does not define any particular algorithms, provides only mechanics of parameter negotiation and key exchange protocols payload formats etc. Internet Key Interchange (IKE) operates within ISAKMP framework key exchange protocol (Oakley Key Exchange + Skeme Key Exchange) used to negotiate IPSec SAs SA negotiation protected by tunnel encrypted with dynamically negotiated keys (Diffie-Hellma( Diffie-Hellman algorithm) 51

52 Diffie-Hellman algorithm Used to negotiate shared secret key between two parties over unsecure channel Key value never sent over unsecure channel Based on public/private key pair generation on both sides, public key interchange and calculations with big prime numbers communicating parties have to be authenticated by some external mechanism prevents man-in-the-middle attack pre-shared key or certificates commonly used 52

53 1. Practical IPSec Operation 1. Interesting traffic detected 2. i.e. traffic whose encryption is required 2. IKE Phase 1 3. IPSec peer authentication (pre-shared keys, RSA signatures (X.509)) Negotiation of IKE SAs (Diffie-Hellman) Encryption algorithm, hash algorithm, keys, key lifetime, Establishes secure channel for IPSec SA negotiation 3. IKE Phase 2 4. Negotiation of IPSec SAs (for both directions) According to policies supported by peers Multiple priorized policies may be defined 4. Secure data exchange using IPSec SAs renegotiated by IKE if lifetime expires 5. After inactivity timeout, IPSec tunnel closed (SAs discarded) 5. 53

54 Which Traffic should be Encrypted? Crypto Access Lists (corresponds ProxyIDs) Outbound - indicate which data have to be protected by IPSec Inbound - filter out and discard traffic that should have been protected by IPSec (but is not) 54

55 Required ACL Modification for Operation of IPSec Underlying infrastructure has to allow these types of traffic: ISAKMP UDP port 500 ESP IP protocol 50 AH IP protocol 51 55

56 IPSec NAT Traversal Changing of IP header fields by NAT causes HMAC mismatch Encapsulates IPSec-protected packet with another UDP/IP envelope NAT-T - UDP port 4500 Negotiated in IKE 56