Network Security Protocols • Understandinggy How Security Can Be Added to the Basic Internet Protocols Prof

Internet Security Protocols February 2018

Goals

Network Security Protocols • Understandinggy how security can be added to the basic Internet protocols Prof. Bart Preneel • Understandingg TLS and its limitations COSIC • Understanding IPsec and its limitations Bart.Preneel(at)esatDOTkuleuven.be http://homes.esat.kuleuven.be/~preneel February 2018

Outline ItInternet tE Evolution lti ((prediction di ti ffrom 2000)

1800 Subscriptions worldwide (millions) • Internet summaryy mobile 1600 Mobile subscribers • IETF pprocess Fixed 1400 Mobile Internet • Basic principles 1200 FiFixed d Internet I t t 1000 mobile • Transport layer security Internet – SSL / TLS 800 subscribers 600 • Network layer security 400 – IPSecIPSec, VPNVPN, SSH 200 0 1995 2000 2005 2010

3 4

Internet evolution (prediction from 2015) The Internet - A Network of Networks

• “IP is the protocol that integrates all infrastructures”

Internet Workstation, Workstation, PC, Laptop, PC, Laptop, PDA, ... IP RRouter IP RRouter PDAPDA, ...

NtNetwork kA A NtNetwork kB B NtNetwork kC C Fixed broadband: 2-3 users per subscription Mobile: multiple subscriptions per user various  Ethernet  DECT  PSTN 2015: 3.3 billion internet users (world stats) transmission  Token Ringg  GSM  ISDN technologies  WLAN  UMTS  ATM 2020: 50 billion IOT devices (machine to machine)  Powerline  Satellites  Frame Relay

5 6 Source: Ericcson Mobility Report June 2015

1 Internet Security Protocols February 2018

Internet Protocols Data Encapsulationp

Applicationpp Layer y Applicationpp Layer y SMTP HTTP . . . Application SMTP HTTP . . . Application (Web, FTP, ... ) (Web, FTP, ... ) Transportp Data Data TCP/UDPC/ TCP/UDP

Network Transport Layer Transport Transport Layer IP IP (TCP, UDP) (TCP, UDP) Transport Transport Header Data Header Data Link Link Network Layer Network Layer Network (IP) (IP) Transport Transport IP Header Data IP Header Data • Network Layer Header Header

– Internet Protocol (IP) Network Access Network Access • TtLTransport Layer Layer Layer – Transmission Control Protocol (TCP), (TCP) User Datagram Protocol ()(UDP) Internet 8 7

Internet Standardization IETF Standards: St d d RFC

– PProposed d StStandard d d (PS) • stable spec Experimental • ISOC/IAB/IESG/IETF • lowest level of standards track • Internet Engineering Task Force (IETF) – Draft Standard (DS) Proposed • IETF Working Groups • at least two independentp and – Mailing List Information interoperable implementations Draft std – Scope of the Working Group – Goals and Milestones – Standard (STD) Standard – CICurrent Internet Df&RFCDrafts & RFCs • widely,id l successfully f ll used d – http://www.ietf.org/html.charters/wgpg g-dir.html • RFCs Historic – http://www.rfc-editor.org – fftp://FTP.ISI.EDU/in //FTP ISI EDU/i -notes// 9 10

IETF Securityy Area IETF Intermediate I t di t ddocuments t Area Directors: Kathleen Moriarty and Eric Rescorla ACE Authentication and Authorizati Authorizationon for Constrained Environments • Request for Comments (RFCs) with different ACME Automated Certificate Management Environment CURDLE CURves, Deprecating and a Little more Encryption maturity levels dane DNS-based Authentication of Named Entities dkim Domain Keys Identified Mail – Experimental (E) DOTS DDoS Open Threat Signaling I2NSF Interface to Network Securityy Functions – IInformational f ti l (I) IPSECME IP Security Maintenance and Extensions jose Javascript Object Signing and Encryption – Historic (H) KITTENGSS-API Next Generation krb-wg Kerberos – Best Current Practice (BCP( ) – does not influence bits on the wire LAMPS LiLimited i d AddiAdditional i l MMechanisms h i ffor PKIX and d SMIME MILE Managed Incident Lightweight Exchange • Internet-Drafts (I( -D))g are working documents of the OAUTH Open Authentication A thentication working groups and have no formal status pkix Public-Key Infrastructure (X.509) SACM Security Automation and Continuous Monitoring • Protocol Status (requirement level) SECEVENTS Security Events TLS Transport Layer Security – "required", "recommended", "elective", TOKBIND Token Binding TRANS Public Notaryypy Transparency "limited use", se" or "not recommended” QUIC – “must”must and “should” should securityy work in other areas: Secure Inter-Domain Routing TCP increased security 11 ( DNS Extensions) 12

2 Internet Security Protocols February 2018

CommCommunications nications insecinsecurity rit A historical perspective (1) wireless • architectural errors 1900 data 1960 1980 1990 2000 – wrong trust assumptions – default = no security Vernam: rotor LFSR WLAN OTP machines • protocolp errors PAN 3GSM – unilateral entity authentication – weak entity authentication mechanism wired – downgrade attack 1900 data 1960 1980 1990 2000 block • modes of operation errors rangeg of wireless X25 TLS SSH – no authenticated encryption communication digital ciphers IPsec – wrong use of crypto is often encryption wired • cryptographicthi errors underestimated!dtitd! 1900voice 1960 1980 1990 2000 – weak crypto STU VoIP • implementation errors analog scramblers 13 14

A historical perspective (2) mobile Securityy Goals (started( in ISO 7498-2)) 1980 phones 1990 2000 2010 • confidentiality:fid i li AMPS GSM/TDMA 3G LTE – entities (anonimity) analog cloning, TDMA attacks on A5, – data scanners cloning COMP128 – traffic flow 1997 2002 2004 • (unilateral or mutual) entity authentication WLAN WEP WPA WPA2/802.11i • data authentication (connection-less or WEP WPA WPA2 connection-oriented): data origin authentication broken weak flaw + data integritygy • access control 1999 2007 PAN • non-repudiation of origin versus deniability Bluetooth Zigbee Bluetooth15 2.1 BlBluetooth t th problems bl 16

Securityy Protocols & Services Internet Security Protocols Electronic Commerce Layer PayPal, Ecash, 3D Secure ... • Cryptographic techniques: S-HTTP PGP PEM S/MIME PKIX – symmetricti encipherment i h t

– message authentication mechanisms Transport Layer Security (SSH(SSH, SSL, TLS) SPKI – entity authentication mechanisms Transmission Control Protocol User Datagram Protocol (UDP) – key establishment mechanisms (e.g., combined (TCP) with entity authentication) IP/ IPSec (Internet Protocol Security) Public-Key Infrastructure

SP hdr hd dtdata SP tltlr MAC • security services depend on the layer of integration: confidentiality – the mechanisms can only protect the payload and/or header integrity information available at this layer – header information of lower layers is not protected !! 17 18

3 Internet Security Protocols February 2018

Security:yy at which layer? SP Architecture I: Encapsulationp

• Applicationpp layer: y unprotected data – closer to user

– more sophisticated/granular controls SP hdr encrypted data MAC – end-to-end confidentiality – btbut what ht about b tfi firewalls? ll? integrity • Lower layer: – application independent • Bulk data: symmetric cryptography – hide traffic data – but vulnerable in middle points • Authenticated encryption: best choice is to • Combine? authenticate the ciphertext

19 20

SP Architecture II: Algorithm Selection Session (Association) Establishment "a la carte“ “suite” • each algorithm (encryption, • all parameters are encoded Host A Host B SP hdr encrypted data MAC integrity protectionprotection, pseudo- into a single suite number; random function, Diffie- negotiationgg consists of offering Hellman group, etc.) is one or more suites and having negotiatedti t d independently i d d tl ththe other th side id choose h Securityy Associations • less compact to encode • simpler and more compact to (Security Parameters incl. Shared Keys) • more flexible encode • potentially exponential numberbfit of suites • less flexible Key Management and Security Association Establishment Protocols • e.g.,g, IKEv1 • e.g., TLS and IKEv2

21 22

SSL/TLS Protocols

Secure Browser WWW Server

http:// https:// Transportpy layer security y SSL SSL

Transport System Transport System HTTP over SSL SSL / TLS HTTP

– connection-oriented data confidentialityy and integrity, and optional client and server authentication.

4 Internet Security Protocols February 2018

Transport Layer Security Protocols SSL / TLS

Application • IETF Working W ki GGroup: Data Transportpy Layer Security y() (tls) Application • Mainlyyy in context of WWW security, i.e., to – RFC 2246 (PS), 01/99 Encapsulation Negotiation secure the HyperText Transfer Protocol TLS Authentication Decapsulation • transparent secure channelshl Key Establishment independentpp of the respective (HTTP) application. TCP • TLS: security at the transport layer Protected Handshake • availableil bl protocols: l Data – can be used (and is intended) for other applications too IP – Secure Shell (SSH), (IMAP(IMAP, telnet, telnet ftp, ftp …) ) SSH Ltd. – Secure Sockets Layer (SSL)(SSL), – end-to-end secure channel,,g but nothing more... Netscape – data is only protected during communication – Transport Layer Security – no non-repudiation! (TLS), IETF

25 26

SSL/TLS SSL/TLS DDeployment l t more dildetails: h//llb/lhttps://www.ssllabs.com/ssl-pulse/l/ • “Secure Sockets Layer”Layer (Netscape) TLSS11 1.1 and d12d 1.2 deployment l very slow l (about ( b 25% 2 % of f servers in i – SSL 2.0 (1995):() security y flaws! FebFeb. 14); boost in Nov. Nov 2013 (new attacks + Snowden revelations) – SSL 3.0 (1996): still widely used - not interoperable with TLS 1.0 • “T“Transport t LLayer SSecurity” it ” (IETF) – TLS 1.0 (01/99)()p adopted SSL 3.0 with minor changes g - RFC 2246 - default DSA/3DES Status is – TLS 11.1 1 (4/2006) - RFC 4346 – default: RSA/3DES; several fixes improving for padding oracle and timing attacks (explicit IV for CBC) – TLS 1.2 1 2 (8/2008) - RFC 5246 • replaces MD5 and SHA-1 by SHA-256 (SHA-1 still in a few places) • adddd AES ciphersuitesih i (b(but still ill supports RC4!) ) • add support for authenticated encryption: GCM and CCM – RFC 5176 (2/2011) removes backward compatibility with SSL 2.0 – Currentlyy 314 ciphersuitesp ! – TLS 1.3 expected for Q1 2018 (worked started in April 2014)

27 28

Application ege.g., httphttp, telnettelnet, ... SSL/TLS in more detail Application Data • “RecordRecord layer”layer protocol – fragmentation Handshake Protocol Change Cipher Spec Alert Application Protocol Protocol Protocol – compressionp(p) (not in practice) – will be removed in 1.3 – cryptographic security: CliClient t HllHello ChChange Application Alert Server Hello Cipher Spec Data → ... • encryption data confidentiality •MAC → data authentication [no digital signatures!] Record Layer Protocol • “Handshake” protocol – negotiation of cryptographic algorithms SSL record – client and server authentication – establish cryptographic keys (master key and derived Transport layer TCP/IP key for encryption and MAC algorithm) 29 – key confirmation 30

5 Internet Security Protocols February 2018

HdhkHandshake: overview i TLS 1.2 Data Encapsulationpp Options CLIENT SERVER

Hello Request Integrity CliClient t Hello H ll key size 144 160 256 Server Hello algorithm HMAC- HMAC- HMAC- Certificate Certificate options MD5 SHA SHA256 Client Key Exchange Server Key Exchange

Certificate Verify Certificate Request mandatoryy [changecipherspec] Server Hello Done Finished CConfidentiality fid ti lit [changecipherspec] kikey size 40 56 128 168 256 Finished √ RC4RC4_40 40 RC4 start handshake,hdhk protocol l version, i algorithms l ih algorithm 3DES_ √ authentication server + exchange (pre)master secret RC2_CBC_40 DES_CBC IDEA_CBC AES_CBC EDE_C CBC C √ client authentication options DESDES_CBC_40 CBC 40 AESAES_CBC CBC √ end handshake, integrity verification

mandatoryy 31 32

TLS 1.2 Keyyg Management Options p FdForward secrecy

AAnonymous NNon anonymous • Default algorithmg( in TLS 1.2 is RSA (better performance, at least for RSA-1024) • no forward secrecy: compromise of private server DHDH_anon anon Server authentication, Server and client no client authentication authentication key results in compromise of all past sessions

vulnerable to a • DH-DSS and DH-DSA: same problem meet-in-the- mandatory RSA RSA • DHE-DSS and DHE-DSA: Ephemeral Diffie- middle attack DH_ DSS DH_SS DSS DH_RSA DH_RSA HllHellman kkeys lleads d tto forward f d secrecy DHEDHE_DSS DSS DHEDHE_DSS DSS DHE_RSA DHE_RSA • For performance reasons: switch to a 256 -bit Elliptic Curve (e(e.g. g Google in November 2013)

DHEDHE_DSS DSS ((notation i from f IKE) SSL/TLS: securityy services

proposed attributes SSL/TLS only provides: • entity authentication selected attributes Initiator Responder • data confidentiality

x • data authentication g , Ni

y SSL/TLS does not provide: g , Nr K derived from • non-repudiation xy SIG = Signature on mastertf(N = prf( Ni || Nr, g ) E(K, ID , [Cert(i)], SIG ) r i i y x • unobservability (identity privacy) H( master, g || g || ... || IDr ) SIGi = Signature on H( master, master gx || gy || ... || ID ) • protectionpg against traffic analysis y i E(K, ID , [Cert(r)], SIG ) r r • secure many-to-many communications (multicast) • securityit of f the th end d-pointsi t (b(but t relies li on it!)

H is equal to prf or the hash function tied to the signature algorithm (all inputs are concatenated) 36 36

6 Internet Security Protocols February 2018

SSL/TLS: securityyy analysis TLS overview [Stebila’14][]

DDetailed t il d analysis l i and d security it reductions d ti (“(“proofs”): f ”)

– Handshake protocol: most unaltered TLS ciphersuites form a secure Crypto Ciphersuite PtProtocol l Libraries Applications channel (authenticated and confidential channel establishment) primitives details “Framework” – RRecord d layer l protocol: t l Authenticated A th ti t d EEncryption ti well ll understood d t d (b(but t badly implemented) – miTLS: validated reference implementation RSA, DSA, Data structures Alerts and errors OpenSSL Web browsers ECDSA KditiKey derivation CCertification/re tifi ti / - GGnuTLS TLS WbWeb servers DH, EC-DH vocation Current analysis does not take into account the full complexity Encryption SChannel Application HMAC modes and IVs (Re-)Negotiation SDKs – Cipher suites: negotiation, renegotiation, reuse of master key over Java JSSE0 multiple suites MD5, SHA-1, Padding Session Certificates SHA-2 Resumption – Cross protocol attacks Compression – Fragmentation DES, 3DES, Key reuse – Compression brings security problems RC4RC4, AES

– Timing attacks 37 Theoretical 37 analysis 38

TLS attack overview [Stebila’14][] TLS attacks (1) updated November 2016 • Renegotiation attack (2009) – allows injection of data; patched by RFC 5746 DH parameter • Version rollback attacks (2011) validation – exploits false start feature (introduced to improve performance) • CRIME and BREACH attacks ()(2013) Lucky Microseconds – recovery of cookies when data compression is used – all TLS versions are vulnerable

FREAK • Truncation attack (2013) – suppress logout by injecting an unencrypted TCP FIN message Logjam DROWN • Heartbleed (2014)() POODLE – Buffer over-read in OpenSSL implemenation

SLOTH sweet32t32 • Poodle (2014) Padding Oracle On Downgraded Legacy Encryption – Man-in-the middle that exploits downgrade to SSL 3.0 • LLogjam j (2015)(2015): ddown negotiation i i to 512 -DLOG that h can bbe bbroken k iin real l time Improved RC4 • SLOTH (2016): TLS 1.2 allow use of pure MD5 – down negotiation biases • DROWN (2016): crossprotocol attack on SSLv2 40

TLS attacks (2) TLS problemsp • PPadding ddi oracle l and d timing i i attacks k – RSA • [Bleichenbacher 98] PKCS #1v1.5 – 1 million chosen ciphertexts (in practice 200,000); • many PKI issues:iikfkifi revocation, root keys, fake certificates, • [Klima+ 03] 40% improvement certificate parsing,… parsing • [Bardou+ 12]: reduced to about 10,000 chosen ciphertexts • timing attack [Kocher’95][Kocher 95], [Boneh-Brumley’03]Brumley 03] • web spoofingpgp and phishing g • [Meyer+14] new Bleichenbacher attacks, even on TLS 1.3 draft • what if the user does not know that a particular website has to use – CBC (IV and padding) SSL/TLS (solution HSTS – HTTP Strict Transport Security • paddingpg[ [Rogawaygy],][ [Vaudenayy 02]][ , [Canvel+ 03]:]p password recovery y (HSTS): mandate that you interact with particular servers using • BEAST attack [Rizzo-Duon 11]: exploits IV issues - patched from TLS 1.1 onwards • Lucky 13 [AlFardan -Paterson’13]:Paterson 13]: timing attack on CBC padding https/TLS only) • Cryptographic attacks • traffic analysis: – Weak random number generators: Netscape, Debian, embedded devices… – length of ciphertext might reveal useful info – Exhaustive key search: 40 -bit and 56 -bit keys – time to retrieve a page indicates whether it has been retrieved before – Cross-protocol attack: elliptic curve parameters can be read as DH-prime – Biases in RC4 (re-introduced to 50% of web in Feb. 2013 to stop BEAST attack) [AlFardan+ 13] [Isobe+ 13] More attacks and details: https://mitls.org/pages/attacks 41 42

7 Internet Security Protocols February 2018

Implementation attacks TLS Renegotiation attack [Marsh Ray Nov.09] Debian-OpenSSLp[y] incident [13 May 2008] https://cseweb.ucsd.edu/~hovav/dist/debiankey.pdf • CiCipher h suite i can bbe renegotiated dynamically • WkkWeak key generation: i throughout the session only 32K keys – negotiation and renegotiation look the same – easy to generate all private keys • Person-In-The-Middle can – collisions inject (plaintext) traffic in a protectedt t d session i as if it came • Between 13 -17 May 2008 from a client 280 bad keys out of 40K (0.6%) • Fix: TLS renegotiation indication extension RFC 5746 – FebFeb. ’10 10 • Revocation problematic (84%(py deployment in Jan.’14) ) Figure: L. O’Connor 44 43 44

TLS certificate "NULL" issue User authentication First authentication, then authorization ! • [Moxie Marlinspike 09] Black Hat – browsers may accept bogus SSL certs SSL/TLS client authentication: – CACAs may sign i malicious li i certs – DDuring i handshake, h d h k client li can digitally di i ll sign i a specific ifi • certificatetifi t ffor www.paypal.coml \0k0.kuleuven.be l b willill be b message that depends on all relevantrelevant parameters of secure session with server issued if the request comes from a kuleuvenkuleuven.be be admin – Support by software devices, smart cards or USB tokens • response by PayPal: suspend Moxie’sMoxie s account – PKCS#12 key container provides software mobility – http://www.theregister.co.uk/2009/10/06/paypal_banishes_ssl_hacker/ – rarely implemented Usually another mechanism on top of SSL/TLS

45 46

TLS 1.3

• Reduce the number of cipher suites: – only authenticated encryption with associated data (AEAD): AES- GCM,, AES-CCM,ARIA, -GCM,, Camellia-GCM,,y ChaCha/Poly1305 – only (perfect) forward secrecy (still RSA for signatures) Network layeryy security – no custom DH groups • Forbid renegotiation but keep resumption with tickets • Improve privacy: encrypt more of the handshake IPsecIPsec, VPN, VPN SSH • Improve latency: target: 1-RTT handshake for naive clients but 0-RTT handshake for repeat connections Backward compatibility remains very important because of huge installed base 47

8 Internet Security Protocols February 2018

IPSec VPN models: IP Securityy Protocols Hosts and Security Gateways

• IETF Working Group: Application / SA Establishment Authentication Host-to- Internet IP Security Protocol (ipsec) IKE Application Key Establishment host (not Untrusted Network Security Architecture for the Data VPN) Internet Protocol TCP/UDP – RFC 2401 (PS), 11/98 Handshake Encapsulation IP/IPSec IPSec Gateway IPSec Gateway • IP Authentication Header (AH) Decapsulation – RFC 2402 (PS)(PS), 11/98 Internet Branch- Untrusted Network • IP Encapsulatingpg Security y to-branch Payload (ESP) Protected Trusted Trusted Data Network Network – RFC 2406 (PS)(PS), 11/98 • Internet Keyyg() Exchange (IKE) IPSec Gateway Internet – RFC 2409 (PS), 11/98 • Large and complex…………. Host-to- Untrusted Network – AliiApplication llayer protocol lf for (48 documents) gatewayt negotiation of Security Associations • Mandatory for IPv6, optional Trusted for IPv4 Network (SA) and Key Establishment 49 50

IPsec - Securityy services IPsec - Conceptsp

• Access control • SitftSecurity features are added dddti as extension • Connectionless integritygy hheaders d that th t follow f ll the th main i IP header h d • Data origin authentication – AAuthentication th ti ti hheader d (AH) • Rejection of replayed packets (a form of – EEncapsulating l ti SSecurity it PPayload l d (ESP) hheader d partial sequence integrity) • SitAiti(SA)Security Association (SA) • Confidentiality – SSecurity i PParameter IIndex d (SPI) • Limited traffic flow confidentiality – IP destination d ti ti address dd – SSecurity it PProtocol t l IdIdentifier tifi (AH or ESP)

51 52

IKE Algorithm Selection IPsec - Parameters MMandatory d t Algorithms Al ith

• sequence numberbt counter AlAlgorithm ith Type T IKE v1 1 IKE v2 2 • sequence countertfl overflow Payload Encryption DES-CBC AES-128-CBC HMAC-MD5 Payload Integrity HMAC-SHA1 • anti-replay window HMAC-SHA1 • AH info (algorithm, (algorithm keys, keys lifetimes, lifetimes ...) ) DH Group G 768 Bit Bi 1536 BiBit Transfer Type 1 • ESP info (algorithms, (algorithms keyskeys, IVsIVs, lifetimeslifetimes, ...) ) ENCR_DES_CBC ENCR_AES_128_CBC (Encryption) • lifetime Transfer Type 2 PRF_HMAC_SHA1 PRF_HMAC_SHA1 • IPSec protocol mode (tunnel or transport) (PRF) [RFC2104] [RFC2104] Transfer Type 3 AUTH_HMAC_SHA1_96 AUTH_HMAC_SHA1_96 • path MTU (maximum transmission unit) (Integrity) [RFC2404] [RFC2404]

Source: draft-ietf-ipsec-ikev2-algorithms-0000.txt, txt May 2003 53 54

9 Internet Security Protocols February 2018

IPsec - Modes IPsec - AH Transportp mode

• Transport (host-to-host) • Security Parameters Index: identifies SA – ESP: encrypts and optionally authenticates IP • Sequence number: anti-replay payloadpayload, but not IP header • Integrity Check Value: data authentication using – AH: authenticates IP payload and selected HMAC-SHA-1-96 or HMAC-MD5-96 portionsp of IP header

• Tunnel (between(ygy) security gateways) IP hdr upper layer data – after AH or ESP fields are added,, the entire packet is treated as payload of new outer IP packet with new outer header IP hdr AH (..., Seq. Num., ICV) upper layer data – used for VPN Integrity (only(y header fields that are not change gd or are changed g in a ppredictable manner) ) 55 56

IPsec - AH Tunnel mode IPsec - ESP header

IP hdr upper layer data • Security Parameters Index: identifies SA • Sequence number: anti -replay • Encrypted payload data: data confidentiality using DES,,,,, 3DES, RC5, IDEA, CAST, , Blowfish New IP hdr IP hdr upper layer data AH (..., Seq. Num., ICV) • Padding:gq required by y encryption ypg algorithm (additional padding to provide traffic flow Integrity (only header fields that are not changed or are changed in a predictable manner)) confidentiality) • Integrity Check Value : data authentication using HMAC-SHA-1-96 or HMAC-MD5-96

57 58

IPsec - ESP Transportp mode IPsec - ESP Tunnel mode

IP hdr upper layer data IP hdr upper layer data

new IP hdr ESP hdr IP hdr upper layer data ESP tlr ICV IP hdr ESPS hdr upper ldtlayer data ESP tltlr ICV

Confidentiality Confidentiality

Integrity Integrity

59 60

10 Internet Security Protocols February 2018

IPsec: Keyyg management IPsec: Keyyg management

• IKE defines 5 exchangesg • RFCs 2407, 2408, and 2409 – Phase 1: establish a secure channel • Manuall • Main mode • AdAutomated • Aggressive mode – procedured/f / framework k – Phase 2: negotiate IPSEC security association • Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408 (PS) • QikQuick mode d (only ( l hashes, h h PRFs) PRF) – khkey exchange mechanism: hi Internet Key Exchange h() (IKE) – Informational exchanges: statusstatus, new DH group • Oakley: DH + cookie mechanism to thwart clogging attacks • bdbased on 5 generic i exchanges h dfididefined in •SKEME ISAKMP

61 • cookieski for f anti ti-cloggingli 62

IPsec: Keyyg management IKE - Main Mode with Digital Signatures

• protectionp(g) suite (negotiated) proposed attributes

– encryptionyp algorithm g selected attributes Initiator Responder

– hash algorithm x g , Ni

– authentication method: y g , Nr • preshared keys, DSA, RSA, encrypted nonces K derived from xy SIG = Signature on mastertf(N = prf( Ni || Nr, g ) E(K, ID , [Cert(i)], SIG ) r i i H( master, gy || gx || ... || ID ) – Diffie Hellman group: 5 possibilities r SIGi = Signature on x y H( master, master g || g || ... || IDi ) E(K, IDr, [Cert(r)], SIGr )

H is equal to prf or the hash function tied to the signature algorithm (all inputs are concatenated) 63 64

IKE - Main Mode with Digital Signatures IKE v2 - RFC Dec 2005 • mutual entity authentication • IKEv1 implementations incorporate additional functionality • mutualt l iimplicit li it and d explicit li it key k iincluding l di ffeatures ffor NAT traversal, l legacy l authentication, h i i authentication and remote address acquisition, acquisition not documented in the base documents • mutual key confirmation • Goals of the IKEv2 specification include • joint key control – tto specify if all ll that th t functionality f ti lit iin a single i l document d t • identity protection – to simplify and improve the protocol, protocol and to fix various problems in IKEv1 that had been found through • freshness of keying material deployment or analysis • perfect forward secrecy of keying material • IKEv2 preserves most of the IKEv1 features while redesigninggg the pprotocol for efficiency, y, security, y, • non-repudiation of communication robustness, and flexibility

• cryptographic algorithm negotiation 65 66

11 Internet Security Protocols February 2018

IKE v2 Initial Handshake (1/2)() IKE v2 Initial Handshake (2/2)()

• Alice and Bob negotiateg cryptographic ypgp • Second exchangeg algorithms, mutually authenticate, and – divulgeg identities establish a session key, creating an IKE-SA – prove identities using an integrity check based • Usually consists of two request/response on the secret associated with their identity pairs (i(private kkey or shared h d secret k)key) and dh the contents of the first pair of messages in the – The first pair negotiates cryptographic exchange algorithms and does a Diffie-Hellman exchange – establish a first IPsec SA (“child( child-SA”)SA ) is during – The second pair is encrypted and integrity the initial IKE-SA creation protectedt t d with ith kkeys based b d on the th Diffie Diffi - Hellman exchange 67 68

IPsec Overview VPN?

• much better than previous alternatives •Virtual Private Network • IPsec documents hard to read • Connects a private network over a public network. • committee design: too complex • Connection is secured by tunneling protocols. – ESP in Tunnel mode with authenticated encryption • ThThe nature t of f the th public bli network t k is i irrelevant i l t tto probablprobably ssufficient fficient the useruser. – simplify key management • It appearspp as if the data is being g sent over the – clarifyy cryptographic ypgp requirements q private network • …and thus difficult to implementp(y) (securely) – remote user access over the Internet – connectingikh networks over the Internet • avoid encryption without data authentication – connection computers over an intranet

69 70

Concludingg comments More information

• WW. Stallings, St lli NtNetwork k and dIt Internetwork t kS Security: it • IPsec is really transparent, transparent SSL/TLS only Principles and Practice , PearsonPearson, 7th EdEd., 2016 conceptuallyconceptually, but not really in practice • N. Doraswamy, D. Harkins, IPSec (2nd Edition ), Prentice Hall, 2003 (outdated) • SSHSSH, PGP: stand -alone applicationsapplications, • Erik Rescorla, SSL and TLS: Designing and Building immediately and easy to deploy and use Secure Systems, Addison-Wesley, 2000 (outdated) • NtNetwork k security: it solvedldiiilbt in principle but • JCJon C. SdSnader, VPNVPNs IllIllustrated: d TTunnels, l VPNVPNs, and d – many implementationil ttii issues IPsecIPsec, Addison-WesleyWesley, 2005 – complexitylit creates t security it weaknesses k • IETF web site: wwwwww.ietf.org ietf org – e.g.,g IETF-TLS Workinggp Group • AlitiApplication and d end d point it security: it more is i http://www.ietf.org/html.charters/tls-charter.html

needed! 71 72