1 / 29

Secure Protocols and VPNs

Secure Protocols and VPNs. Stefek Zaba Hewlett-Packard Labs, Bristol stefek_zaba@hp.com. What we’ll cover. This lecture: network layering revision “secure channel” concept substantial example: IPSec Next lecture: substantial example 1: TLS/SSL substantial example 2: SSH

sitara
Download Presentation

Secure Protocols and VPNs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Protocols and VPNs Stefek Zaba Hewlett-Packard Labs, Bristol stefek_zaba@hp.com

  2. What we’ll cover • This lecture: • network layering revision • “secure channel” concept • substantial example: IPSec • Next lecture: • substantial example 1: TLS/SSL • substantial example 2: SSH • summaries and random rants

  3. Network layers • You heard this in Lecture 1! • Simplified Internet model: application transport network link

  4. IP header srcIP, destIP, TTL, pktID, … len TCP headerport, seqnum, SYN, ACK, FIN, … len application data TCP headerport, seqnum, SYN, ACK, FIN, … len application data Ethernet header ether-addr, checksum, … len IP header srcIP, destIP, TTL, pktID, … len TCP headerport, seqnum, SYN, ACK, FIN, … len application data X.25 header Virtual-circuit-ID, … len IP header’ srcIP, destIP, TTL-n, pktID, … len TCP headerport, seqnum, SYN, ACK, FIN, … len application data Network layers Application layer: lots of protocols, e.g. HTTP carrying Web traffic, SMTP carrying email, NNTP carrying News, … Transport layer: TCP - reliable connections (sequence nums, retransmission), carries HTTP, FTP, Telnet, …; UDP – unreliable datagrams, e.g. streaming audio/video Network (IP) layer: “is” Internet. Carries: TCP, UDP, ICMP (“ping”, router control), … Link layer: carries IP (and others, e.g. Appletalk, NetBUI, IPX, ARP, ...): hop-by-hop LAN.Examples: IEEE802.3, PPP, RF LAN

  5. Where shall we “put security”? • Link level: • covers all traffic on that link, e.g. RF • only one hop • Network (IP) level: • covers “all” traffic, end-to-end • transparent to applications • little application control • “unnatural”, since IP is stateless packets but channel is stateful

  6. Where shall we “put security”? • Transport (TCP) level: • end-to-end • apps can control when it’s used • apps must be modified (unless proxied) • Application level: • can be tuned to payload requirements • no “leverage” - must rework for every app

  7. What “security” are we providing? • A “secure channel”, typically offering • Origin authentication (but of what: OS? App? User?) • Integrity • Confidentiality • … • Not: • Non-repudiation • Any services once data received

  8. Crypto primitives used • Symmetric ciphers • Asymmetric ciphers & signatures • (Keyed) hash functions • (Keyed) pseudo-random functions • Key agreement protocols: mainly DH

  9. Typical goals • At least one party authenticated • Shared secret established • MAC & bulk cipher keys derived from shared secret • Further traffic “protected” • Optional: session re-use, rekeying, …

  10. IPSec: overview • Network-level: all IP datagrams covered • Mandatory for next-generation IP (v6), optional for current-generation (v4) • Authentication-only or confidentiality too • Two “modes” • “transport” mode: for IPSec-aware hosts as endpoints • “tunnel” mode: for IPSec-unaware hosts, established by intermediate gateways or host OS References: RFC2401..2412; FreeSWAN

  11. Authentication: AH • Authenticates whole payload and most of header • vitally, covers source IP address • omits only fields modified in transit • e.g. TTL/hop-limit, fragmentation fields, some options

  12. Encryption + auth: ESP • Encrypts and optionally authenticates payload, but not IP header • Combine with AH for “full” conf+auth • Use alone for payload conf+auth • There are both engineering and political reasons for their separate existence!

  13. IP header srcIP, destIP, TTL, pktID, … len TCP headerport, seqnum, SYN, ACK, FIN, … len application data IP header srcIP, destIP, TTL, pktID, … IP header srcIP, destIP, TTL, pktID, … len len ESP header: SPI,seqnum AH SPI, seqnum, MAC, … TCP header TCP header len len application data application data MAC scope ESP trailer: pad, padlen, … MAC scope encryption scope IP header srcIP, destIP, TTL, pktID, … len ESP header: SPI, seqnum TCP header len application data Outer IP header gw-srcIP, gw-destIP, TTL, pktID, … len ESP header: SPI,seqnum Inner IP header host-srcIP, host-destIP, TTL, pktID, … len AH SPI,seqnum, MAC, … TCP header len application data ESP trailer: pad, padlen… Inner AH MAC scope Outer ESP MAC scope encryption scope AH & ESP, Tunnel & Transport Original unprotected datagram AH in transport mode ESP auth: MAC ESP (conf and auth) in transport mode ESP auth: MAC ESP auth-only in transport mode MAC scope Outer IP header gw-srcIP, gw-destIP, TTL, pktID, … len AH SPI, seqnum, MAC. … Inner IP header host-srcIP, host-destIP, TTL, pktID, … len TCP header len application data AH in tunnel mode MAC scope ESP I(conf and auth) in tunnel mode carrying AH in transport mode ESP auth: MAC

  14. Why so many combinations!? • To support different VPN arrangements, to meet different security and deployment-practicality requirements

  15. IP len TCP len app data IP len TCP len app data IP IP len len AH AH len len ESP ESP len len TCP TCP len len app data app data ESP ESP Simple transport-mode usage:host-to-host(no singing, please) Without transport-mode IPSec With transport-mode IPSec

  16. IPhost-to-host len TCP len app data IPhost-to-host len TCP len app data IP gw-to- gw IP gw-to- gw len len ESP ESP len len IP host-to- host IP host-to- host len len TCP TCP len len app data app data ESP ESP Simple tunnel-mode usage:gateway-to-gateway

  17. IP header srcIP, destIP, TTL, pktID, … IP header srcIP, destIP, TTL, pktID, … len len ESP header: SPI,seqnum AH SPI, seqnum, MAC, … TCP header TCP header len len application data application data MAC scope ESP trailer: pad, padlen, … MAC scope encryption scope IP header srcIP, destIP, TTL, pktID, … len ESP header: SPI, seqnum TCP header len application data Outer IP header gw-srcIP, gw-destIP, TTL, pktID, … len ESP header: SPI,seqnum Inner IP header host-srcIP, host-destIP, TTL, pktID, … len AH SPI,seqnum, MAC, … TCP header len application data ESP trailer: pad, padlen… Inner AH MAC scope Outer ESP MAC scope encryption scope Other combinations for other requirements AH in transport mode Host-to-host auth-only, e.g. network management? ESP (conf and auth) in transport mode Host-to-host secure channel, e.g. encapsulated legacy apps? ESP auth: MAC ESP auth-only in transport mode As for AH-transport; probably worse in all cases… ESP auth: MAC MAC scope AH in tunnel mode Between-gateway VPN with no overall confidentiality provision (may be good performance choice) Outer IP header gw-srcIP, gw-destIP, TTL, pktID, … len AH SPI, seqnum, MAC. … Inner IP header host-srcIP, host-destIP, TTL, pktID, … len TCP header len application data MAC scope ESP in tunnel mode carrying AH in transport mode Common “road warrior” VPN: secure channel across public network, and strong, continuing authentication to end system(s) ESP auth: MAC

  18. But where did the keys come from? • “SPI” (security parameters index) refers to an “SA” (security association) • SAs set up manually or by IKE – IPSec Key Exchange • Policy “databases” define how fine- or coarse-grained SAs are • anything from “all traffic shall use this key” to individual combinations of source and destination addresses and ports • even “user-based” keying supported… but binding a user to an IP address is (very) problematic…

  19. Outbound processing • Lookup policy for this datagram • drop, pass through, or process • Create a new SA if none exists • Apply keys from SA for MAC and enciphering • Add explicit IV for each datagram • because they can be lost and arrive out-of-order • Pass assembled datagram down to link layer • or to next instance of IPSec processing! • Let’s ignore fragmentation, PMTU discovery, …

  20. Inbound processing • Lookup policy for this datagram • drop, pass through, or process • SA should already exist (we’re the responder) • Apply keys from SA for MAC-check and deciphering (using datagram’s IV too) • Raise security error if needed; otherwise, • Pass assembled datagram up to rest of normal IP processing • or to next instance of IPSec processing!

  21. What can be MAC’ed? • Immutable or predictable fields and options in IPv4 and IPv6 • AH-controlled all immutable, so MACed: • payload, payload length, next-header, SPI, sequence number, reserved fields • IP header immutables and predictables v6: • version, payload length, next-header, source and destination IP addrs, • BUT NOT: class, flow label, or hop limit (= v4 TTL) • all v6 extension headers self-describing as to mutability • IP header immutables and predictables v4: • version, header and payload lengths, packetID, protocol type, source and destination IP addrs • BUT NOT: ToS, flags, fragment offset, TTL, header checksum • All unpredictable fields zero-filled for MAC calculation • so overall length and alignment still protected

  22. IPsec Key Exchange – IKEor, time for a deep breath! • Documentation hard to follow • IKE is specific adaptation of more general protocols (“Oakley” and “ISAKMP”) • Two levels of SA negotiated • an initial context (bidirectional, with heavy-duty authentication and negotiation) • then several client SAs, negotiated quickly using initial SA as secure channel; one for each direction and each AH and ESP • initial SA also used for error traffic and similar management traffic

  23. IKE security goals • Authentication of parties (by digital signature, proof of knowledge of private key, or shared key) • Establishment of a fresh shared secret • Shared secret used to derive keys for channel confidentiality and authentication • “Perfect Forward Secrecy”, at cost of using up shared material • (partial) anti-clogging, against denial-of-service attacks • Secure negotiation of algorithms: asymmetric (e.g. RSA, elliptic curve), symmetric (e.g. 3DES, Blowfish, AES), and hash (e.g. MD5, SHA-1)

  24. IKE details • Phase 1 is the heavyweight exchange to establish a secure key management channel • “Main mode” variant: slower, more cautious, hides details of credentials used and allows forward secrecy (independence of short-term keys) • “Aggressive mode”: less negotiation, fewer round trips, more information disclosed • Phase 2 (“quick mode”) established SAs for IPSec itself, using the Phase 1 channel

  25. Main Mode IKE Phase 1using digital signatures(see RFC2409, p.11) Initiator Responder HDR, SA_i --> <-- HDR, SA_r Headers (HDR) include “cookies” CKY-I and CKY-R respectively. Initiator’s SA has one or more “proposals”, in preference order, for algorithms to be used for ISAKMP, the key management channel we’re building. The responder chooses exactly one of these proposals. These SAs may refer to one of a few standard Diffie-Hellman groups (both integer and ECC), or may define new DH groups. HDR, KE, Ni --> <-- HDR, KE, Nr Ni, Nr are initiator’s and responder’s nonces, respectively; KE are Diffie-Hellman g^x and g^y values HDR*{IDii, [CERT,] SIG_I} --> <-- HDR*{IDir, [CERT,] SIG_R} HDR* denotes remaining ISAKMP traffic is encrypted. IDii, IDir are IDentifiers, typically IP addresses.SIG_I is over HASH_I = prf( SKEYID, g^x | g^y | CKY-I | CKY-R | SA_i | IDii )SIG_R is over HASH_R = prf(SKEYID, g^y | g^x | CKY-R | CKY-I | SA_i | IDir )where SKEYID = prf( Ni_b | Nr_b, g^xy ), and prf is the negotiated keyed pseudo-random function Note 3 round-trips, 4 DH modular exponentiations, 2 signature-generations and 2 signature-verifications

  26. Aggressive Mode IKE Phase 1using public-key proof(see RFC2409, p.14) HDR, SA_i, <Ni>Pubkey_r, <KE>Ke_i, <IDii>Ke_i --> HDR includes CKY-I. SA_i has exactly one “take-it-or-leave-it” proposal. The nonce Ni is encrypted in the responder’s public key; KE (that’s g^x) and IDII are encrypted under Ke_i = prf( Ni, CKY-I ). So, the responder can decrypt Ni and so derive Ke_i only if it has the private complement to Pubkey_r. <-- HDR, SA_r, <Nr>Pubkey_i, <KE>Ke_r, <IDir>Ke_r, HASH_R HDR includes CKY-R. SA_r must equal SA_i. Similarly to the initiator’s message, the nonce Nr is encrypted in the initiator’s public key, while KE (that’s g^y) and IDir are encrypted under KE_r = prf( Nr, CKY-R ), requiring the initiator to have the private complement of Pubkey_i. HASH_R is as on the previous page. HDR, HASH_I --> The hashes sent in each direction aren’t signed; but the ability to generate them proves receipt and successful decryption of the nonce received from the other party. Note 1.5 round-trips only, still 4 DH modular exponentiations, 2 public-key encrypts and 2 public-key decrypts. Careful analysis shows “plausible deniability”: the absence of digital signatures allows either party to disown the exchange.

  27. Use of Phase 1 agreed material Key material for the underlying ISAKMP key-management SA we’re building first is derived from the shared-secret quantity g^xy and the nonces securely exchanged during Phase 1 as follows: SKEYID = prf( Ni | Nr, g^xy ) SKEYID_d = prf( SKEYID, g^xy | CKY-I | CKY-R | “0” ) SKEYID_a = prf( SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | “1” ) SKEYID_e = prf( SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | “2” ) where _a refers to Authenticator (MAC) material for the ISAKMP channel, and _e is for Encrypting material for the ISAKMP channel. _d is dual-purpose; firstly, it’s used as input for the _a and _e pseudo-random streams; secondly, it’s the main source of key material for the Phase 2 SAs which are the ones used by IPSec itself. SKEYID is used directly as the prf key for HASH_I and HASH_R, used to authenticate the parties. Particular “transforms” (symmetric encryption algorithms, MACs, and so on) specify exactly how SKEYID_a, SKEYID_e, and SKEYID_d is to be used. For example, the specification for single-key DES uses at minimum the first 8 bytes of the PRF, forcing the parity bits to appropriate values, throwing away any bytes which would give rise to the known weak or semi-weak keys. (There are only 16 out of 2^56 such keys, so this isn’t likely to occur in practice!) The Triple-DES definition uses at least 24 bytes of the prf output, and the prf definition “stretches” its initial result by repeated application to produce as many bytes as are needed.

  28. Phase 2: “Quick Mode” Now that we have an ISAKMP SA to define a secure key-management channel, doing algorithm and key agreement for client SAs such as AH and ESPis cheap and easy (relatively speaking). As example, this is how you get 4 SAs (one for each direction of an AH + ESP pair) - see RFC2409 p.19: HDR*{HASH(1), SA0, SA1, Ni} --> As before, HDR*{} means that all further material is encrypted (under SKEYID_e, remember?). SA0, SA1, etc. are “proposals” for client SAs for the AH and ESP transforms – each one is a preference-ordered list of possible algorithm combinations. Ni is a new initiator nonce. HASH(1) = prf( SKEYID_a, M-ID | SA0 | SA1 | Ni ); see how SKEYID_a is the MAC key. M-ID is the unique message-ID from HDR. <-- HDR*{HASH(2), SA0, SA1, Nr} Back come single algorithm choices for each SA, and a new responder nonce Nr. HASH(2) is similar to HASH(1): HASH(2) = prf( SKEYID_a, M-ID | Ni | SA0 | SA1 | Nr ); it has Ni added as a liveness proof. HDR*{HASH(3} --> This is a simple acknowledgement that the responder’s message has been received;HASH(3) = prf(SKEYID_a, “0” | M-ID | Ni | Nr ) Now key material for each IPSec SA is defined as follows: KEYMAT = prf( SKEYID_d, protocol | SPI | Ni | Nr ) Since protocol and SPI are unique to AH/ESP and direction respectively, this gives 4 separate chunks of KEYMAT. If necessary, they are “stretched” as before by applying prf iteratively. Note the single Phase 1 DH exchange and public-key operations have been used to derive key material for all four IPSec SAs, spreading the cost of those expensive operations. There’s an option to include a fresh DH exchange in each Quick Mode if you prefer Forward Secrecy to computational efficiency...

  29. Final notes on IPSec • IKE is carried over UDP; hence unreliable (may need to be restarted) and blocked by some firewalls • Managing IPSec policy and deployments isn’t easy, and getting it wrong can be embarassing in losing connectivity, e.g. by making exchanges of routing updates unreadable • After trying to roll-its-own with PPTP, MS has put IPSec into WinXP • See FreeS/WAN for implementation (and contribute too, unless you’re a US citizen):http://www.xs4all.nl/~freeswan/

More Related