IPsec – ISAKMP-IKE: IPsec – ISAKMP-IKE Eddie Rmaili


Key Management in IPSec: Key Management in IPSec Målet Generera och hantera SA för AH & ESP. asymmetrisk Både responder och initiator har olika SA. Manuellt / Automatiserat manual key management automated key management


Manual Key Management : Manual Key Management Konfigurerar varje system med sina egna nycklar och med nycklar från andra kommunikationssystem. Praktiskt för små, relativt statiskt miljö.


Automated Key Management : Automated Key Management Möjliggör on-demand skapande av nycklar för SA och förenklar användningen av nycklarna I ett större utspritt system. Ett automatiserat system är mer flexibelt… Kräver mer ansträngning att konfigurera. Kräver mer mjukvara,  mindre installationer är mer passande en manuell key management.


Key Management in IPSec: Key Management in IPSec Flera protokoll erbjuds av IPSec Oakley, SKEME, SKIP, Photuris ISAKMP, IKE IKE förefaller vara IPSec key management protocol men den är en kombination av: Oakley, SKEME and använder ISAKMP struktur


Oakley: Oakley Key exchange protocol based on Diffie-Hellman have extra features cookies precaution against clogging (denial-of-service) attacks makes the attack more difficult cookies are unique values based on connection info (kind of socket identifiers) used at every message during the protocol predefined groups fixed DH global parameters regular DH and ECDH nonces against replay attacks authentication (via symmetric or asymmetric crypto)


Internet Security Association and Key Management Protocol, ISAKMP: Internet Security Association and Key Management Protocol, ISAKMP Definierar procedurer, meddelandeformat för att Etablera Förhandla Modifiera Radera SA. Oberoende av key exchange protocol, encryption algorithm authentication method IKE kombinerar allt


ISAKMP: ISAKMP SAs innehåller all information som behövs för exekveringen av olika nätverk säkerhetstjänster. IP lager tjänster (header autenticering, payload inkapsling). Transport eller applikations lager tjänster Eller self-protection of negotiation traffic. ISAKMP definerar payload för utbyte av key generation & authentication data.


ISAKMP: ISAKMP ISAKMP skiljer sig från key exchange protocols för att rent av separera Detaljerna av SA management (och key management) från Detaljerna av key exchange. Det kan finnas olika ”key exchange protokoll”, var och en med olika säkerhets egenskaper (security properties). En gemensam ramverk behövs för att: Komma överens om SA formatet. För förhandling. Modifiera. Radera SA ISAKMP serves as this common framework.


Slide10: ISAKMP kan implementeras på vilket transport protokoll som helst. All implementationer måste inkludera (send och receive) möjligheterna för ISAKMP vid användning av UDP port 500.


ISAKMP: ISAKMP ISAKMP (och även IKE) först skapar en SA för sig själv ISAKMP or IKE SA Sedan används detta SA för att skapa IPSec (AH och ESP) SA:er Inom ISAKMP, en ” Domain of Interpretation” DOI används för att gruppera relaterade protokoll som använder ISAKMP för att förhandla SA. Säkerhetsprotokoll som delar på DOI väljer Säkerhetsprotokoll och kryptografiska transformer från en gemensam namespace & share key exchange protocol identifierare. De kan också dela på en gemensam tolkning av DOI-specifik payload data, inkl. SA och Identification payload.


DOI, Domain of Interpretation: DOI, Domain of Interpretation Definerar: payload formats, exchange types, and conventions for naming security-relevant information such as security policies or cryptographic algorithms and modes. En DOI identifierare används för att tolka payloaden i ISAKMP.


ISAKMP: ISAKMP Definierar hur 2 peers kommunicerar. Hur de meddelanden de använder är uppbyggda. Även definierar övergångstillståndet de använder för att säkra kommunikationen. Har de medel för att autenticera en peer Den definierar inte hur en partikulär autenticerad key exchange är gjord Inte heller de nödvändiga attribut för etablering av SA.


ISAKMP- header + Payload: ISAKMP- header + Payload Responder cookie KE Next payload 0 8 16 31 Initiator cookie Message ID Total message length Nonce KE payload data Nonce payload data Key Exchange KE payload ISAKMP Header Major Version Exchange Flags 0 KE payload length 0 0 Nonce payload length Nonce payload Minor Version


Initiator Cookie, Responder Cookie: Initiator Cookie, Responder Cookie De skapas hos varje peer. Används längs meddelandets ID. För att identifiera Tillstånd som definierar ISAKMP. Nästa payload som talar om vilket ISAKMP payload som omedelbart följer efter headern. Initiator Cookie: Cookie av denna enhet som inititierade uppkopplingen av SA, SA tillkännagivande eller SA radering. Responder Cookie: Cookie av denna enhet som svarar på uppkopplingen av SA, SA tillkännagivande eller SA radering.


Initiator Cookie: Initiator Cookie The cookie exchange takes place in the first two messages exchanged. The first message is from the initiator of the protocol to the responder. The initiator creates a cookie unique to the responder and the exchange he wishes to begin and inserts it into the initiator cookie portion of the ISAKMP header. Since this is the first message there is no responder cookie and that field is zero.


Responder Cookie: Responder Cookie The responder generates a cookie for this exchange. To formulate a reply he copies this to the responder cookie portion of the header of his reply and copies the cookie provided by the initiator into the initiator cookie field of the header of his reply.


Next payload: Next payload 8 bitar. Indikerar typen av den nyttolasten i det 1:a meddelandet.


ISAKMP Payloads: ISAKMP Payloads ISAKMP has several payload types Följer varandra som i en kedja (each payload points to the next one) De kan bära påolika typer avinformation för SA generering och management. Vissa payload typer SA payload to exchange the DoI information Proposal and Transform payloads to exchange the security and crypto capabilities in the DoI Key Exchange payload to exchange the key exchange info Others (e.g. nonce, identification, certificate, certificate request, signature, …)


ISAKMP Generic Header i payload: ISAKMP Generic Header i payload Det finns upp till 13 olika payload som är definierade i ISAKMP Alla dessa börjar med samma generic header. Den typen av ISAKMP payload som följer den nuvarande payload anges i fältet Next payload Den totala längden av en ISAKMP payload, inklusive header, anges i payload length. Reserverade fältet sätts till 0.


SA payload: SA payload As mentioned, a single SA payload may contain multiple proposal payloads. The proposal number of the proposal payload is used to express the logical operators OR and AND. Matching proposal numbers are taken as a logical AND and differing proposal numbers are taken as a logical OR.


Proposal Payload: Proposal Payload Each proposal may be, in fact, an offer of multiple transforms. Each of these transforms are a different way of accepting the proposal and each transform is the logical OR of the others. Continuing with our complex policy expression, we could add multiple transforms per proposal and desire 3DES over AES and SHA over MD5 and LZS over Deflate (for PCP) and our offer would be:


Slide23: Proposal 1: AH Transform 1: HMAC-SHA Transform 2: HMAC-MD5 Proposal 2: ESP Transform 1: 3DES with HMAC-SHA Transform 2: 3DES with HMAC-MD5 Transform 3: AES with HMAC-SHA Transform 4: AES with HMAC-MD5 Proposal 3: ESP Transform 1: 3DES with HMAC-SHA Transform 2: 3DES with HMAC-MD5 Transform 3: AES with HMAC-SHA Transform 4: AES with HMAC-MD5 Proposal 3: PCP Transform 1: LZS Transform 2: Deflate ((AH-HMAC-SHA OR AH-HMAC-MD5) OR (3DES w/HMACSHA OR 3DES w/HMAC-MD5 OR AES w/HMAC-SHA OR AES w/HMAC-MD5) OR [(3DES w/HMAC-SHA OR 3DES w/HMAC-MD5 OR AES w/HMAC-SHA OR AES w/HMAC-MD5) AND (PCP-LZS OR PCP-DEFLATE)]).


Version: Version Major version (4 bitar): The major version of the ISAKMP protocol in use. Minor version (4 bitar): The minor version of the ISAKMP protocol in use.


Exchange type. : Exchange type. 8 bits. Indikerar typen av den exchange som används. Den bestämmer ordningen av meddelandet och payloaden i ISAKMP exchange.


ISAKMP Protocol Flow (Message Exchange): ISAKMP Protocol Flow (Message Exchange) negotiate / key exchange / authenticate 5 such ISAKMP message exchanges are proposed will go over two important ones here identity-protection exchange aggressive exchange each message is one ISAKMP message (header + payloads) main header includes cookies for each message each step specify which payloads exist SA payload means (SA + proposal + transform) payloads


Identity Protection Exchange: Identity Protection Exchange * means encrypted message payload that is why identity is protected AUTH is the authentication information, such as digital signatures


Aggressive Exchange: Aggressive Exchange minimizes the number of exchanges but does not provide identity protection


Flaggor: Flaggor 3 flaggor definieras I en 8-bitsord. Authetication-only bit: används primärt av dem som önskar att addera key recovery till ISAKMP. Commit Flag: Indikerar att en Host(peer) behöver en tillkännagivande om en exchange slutförande. Encryption: Indikerar att payloaden som följer headern är krypterad.


Message ID: Message ID 4 byte Ett unikt värde används för att identifiera protokoll tillstånd under fas 2 av förhandlingen. Den genereras slumpmässigt av initiatorn under fas 2 av förhandlingen.


Length: Length 4 byte Den totala längden av ISAKMP headern och den inkapslade payloaden i # byte.


IKE (Internet Key Exchange): IKE (Internet Key Exchange) now we are ready to go over IKE the actual protocol used in IPSec uses parts of Oakley and SKEME and ISAKMP messages to exchange authenticated keying material Analogy for the protocols ISAKMP: railways, highways, roads Oakley, SKEME: prototypes for cars, trains, buses (and other vehicles) IKE: a system that has several vehicles running on railways, highways, roads


IKE (Internet Key Exchange): IKE (Internet Key Exchange) UDP port 500 Negotiates connection parameters Hybrid protokoll baseras på : ISAKMP (Internet Security Association and Key Management Protocol) Oakley (Diffie-Helmen key exchange)


IKE: IKE Authentication Methods of IKE certificate based public key signature certificates are exchanged public-key encryption same as signature operations but uses previously known public keys no certificates, so no non-repudiation pre-shared key symmetric method simplest, no public key crypto Material to be authenticated is derived from the messages exchanged


Phases of IKE: Phases of IKE Phase 1: establish IKE SA (negotiate two way SA’s) Uses certificates or Pre-Shared Secrets Main mode (DH with identity protection) ISAKMP identity protection exchange Aggressive mode (DH without identity protection) ISAKMP aggressive mode Between phases New group mode allows to negotiate groups other than the ones offered by Oakley


Phases of IKE: Phases of IKE Phase 2: Establishes SA for target protocol (AH or ESP) Or : Negotiate IPSEC (AH, ESP, Tunnel, Transport) How shall I encrypt your data today? Always Uses Quick mode because we are already authenticated IKE SA is used to protect this exchange


Main Mode: Main Mode Använder 6 meddelanden, i tre steg. SA- förhandling Diffie-Hellman exchange Nonces exchange. Autenticering av peer.


Main Mode med preshared key authentication: Main Mode med preshared key authentication Initiator Responder Header, SA Header, SA Header, KE, Nonce Header, KE, Nonce Header, ID-I, Hash Header, ID-R, Hash


Main mode med key signatur: Main mode med key signatur Initiator Responder Header, SA Header, SA Header, KE, Ni [,Cert_Req] Header, KE, Nr [,Cert_Req] Header, ID-I, [Cert,] Signature Header, ID-R, [Cert,] Signature


Aggressive Mode: Aggressive Mode Tar bara hälften av antalet meddelande i en Main mode. Begränsar sin förhandlingseffekt. Kan inte erbjuda identitetsskydd. Initiator erbjuder en lista över alla protection suites, DH public value, nonce, och även sin identitet i det första meddelandet. Responder svarar på alla förhandlingsfrågor med också ett meddelande.


Quick Mode: Quick Mode Har man för en gång etablerat en IKE SA, med en Main- eller aggressive mode. Kan även användas för att skapa en Quick mode exchange.


IKE Negotiation: IKE Negotiation Negotiates the following parameters: SA lifetime Encryption Algorithm (NEVER USE DES, USE 3DES) Authentication Algorithm (MD5, SHA, SHA-1) Type of Key Exchange Remember: # ipsecadm new esp -spi 1000 -src HostA \ -dst HostB -forcetunnel -enc 3des -auth sha1 \ -key 7762d8707255d974168cbb1d274f8bed4cbd3364 \ -authkey 6a20367e21c66e5a40739db293cf2ef2a4e6659f


IPSec Example: IPSec Example ESP Only (demo only) Two hosts on the same network: Jerry 192.168.0.11 - OpenBSD 2.8 Tom 192.168.0.17 – OpenBSD 2.7 Why OpenBSD? Good realisering and documentation


Jerry Configuration(192.168.0.11): Jerry Configuration(192.168.0.11) ipsecadm new esp -spi 1000 -src 192.168.0.11 -dst 192.168.0.17 -forcetunnel \ -enc blf -auth sha1 -key b4bc9f7f37d09332ac95dd32223e685fe6aaa026 \ -authkey d041653ae78a9fa5ca795df2a051102ec30b33aa ipsecadm new esp -spi 1001 -src 192.168.0.11 -dst 192.168.0.17 -forcetunnel \ -enc blf -auth sha1 -key b4bc9f7f37d09332ac95dd32223e685fe6aaa026 \ -authkey d041653ae78a9fa5ca795df2a051102ec30b33aa ipsecadm flow -proto esp -dst 192.168.0.17 -addr 192.168.0.11 255.255.255.255\ 192.168.0.17 255.255.255.255 -proto esp -acquire Encap: Source Port Destination Port Proto SA(Addr/Proto/Type/Direction) 192.168.0.11/32 0 192.168.0.17/32 0 0 192.168.0.17/50/acquire/out


Tom Configuration(192.168.0.17): Tom Configuration(192.168.0.17) ipsecadm new esp -spi 1001 -src 192.168.0.17 -dst 192.168.0.11 -forcetunnel \ -enc blf -auth sha1 -key b4bc9f7f37d09332ac95dd32223e685fe6aaa026 \ -authkey d041653ae78a9fa5ca795df2a051102ec30b33aa ipsecadm new esp -spi 1000 -src 192.168.0.17 -dst 192.168.0.11 -forcetunnel \ -enc blf -auth sha1 -key b4bc9f7f37d09332ac95dd32223e685fe6aaa026 \ -authkey d041653ae78a9fa5ca795df2a051102ec30b33aa ipsecadm flow -proto esp -dst 192.168.0.11 -spi 1001 -addr 192.168.0.17 255.255.255.255 192.168.0.11 255.255.255.255 Encap: Source Port Destination Port Proto SA(Address/SPI/Proto) 192.168.0.17/32 0 192.168.0.11/32 0 0 192.168.0.11/00001001/50


Packets Before - ICMP: Packets Before - ICMP ICMP 12:46:21.545929 192.168.0.11 > 192.168.0.17: icmp: echo request (ttl 255, id 29731) 0000: 4500 0054 7423 0000 ff01 c618 c0a8 000b E..Tt#.......... 0010: c0a8 0011 0800 09d8 9d66 0000 3b6d 104f .........f..;m.O 0020: 0008 19fa 0809 0a0b 0c0d 0e0f 1011 1213 ................ 0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 ............ !"# 0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'()*+,-./0123 0050: 3435 45


Packets After - ICMP: Packets After - ICMP ICMP 12:51:58.736930 esp 192.168.0.11 > 192.168.0.17 spi 0x00001001 seq 1 len 116 (ttl 64, id 16933) 0000: 4500 0088 4225 0000 4032 b6b2 c0a8 000b E...B%..@2...... 0010: c0a8 0011 0000 1001 0000 0001 b5c1 1de8 ................ 0020: 9e67 4463 cab1 f496 2970 e7d9 267c 0cef .gDc....)p..&|.. 0030: 6bfc a5d6 6f6a 9f51 0e95 20fe c930 0e77 k...oj.Q.. ..0.w 0040: 2918 6c92 d7ac 6c13 f9f1 de8b 1674 fd42 ).l...l......t.B 0050: be98 4a40 29e8 9ecb 6759 cfbe 993d 1001 ..J@)...gY...=.. 0060: 0f11 0b8b 5e93 8852 dc28 786b 2479 465d ....^..R.(xk$yF] 0070: 5a67 d503 6b51 ff0b 074c 0076 6d03 a1ec Zg..kQ...L.vm... 0080: 5b14 765f cb06 51f8 [.v_..Q.


Packets Before - FTP: Packets Before - FTP FTP 12:47:42.431056 192.168.0.11.42261 > 192.168.0.17.21: P [tcp sum ok] 13:28(15) ack 98 win 17232 [tos 0x10] (ttl 64, id 44333) 0000: 4510 0043 ad2d 0000 4006 4c0b c0a8 000b E..C.-..@.L..... 0010: c0a8 0011 a515 0015 5062 b4c2 5d0f 41e7 ........Pb..].A. 0020: 8018 4350 a693 0000 0101 080a 0000 25bf ..CP..........%. 0030: 0000 25e1 5041 5353 2070 6173 7377 6f72 ..%.PASS passwor 0040: 640d 0a d..


Packets After - FTP: Packets After - FTP FTP 12:52:29.730868 esp 192.168.0.11 > 192.168.0.17 spi 0x00001001 seq 2 len 100 (ttl 64, id 28675) 0000: 4500 0078 7003 0000 4032 88e4 c0a8 000b E..xp...@2...... 0010: c0a8 0011 0000 1001 0000 0002 6b51 ff0b ............kQ.. 0020: 074c 0076 30fa 28c7 ef53 592a 7b13 a068 .L.v0.(..SY*{..h 0030: 06bf 071d 81a0 98de ddd8 0174 b637 2b9a ...........t.7+. 0040: f1d2 a36e d83a 08ec 59bf 5341 a4b3 7ae5 ...n.:..Y.SA..z. 0050: bbc3 000b d2b1 e93c e086 cf69 71d6 dcf5 .......<...iq... 0060: 8498 13d7 8930 2451 f43b b6fc 4abc da2c .....0$Q.;..J.., 0070: 77c5 91dd ab2e ba11 w.......


Public Key Certificates : Public Key Certificates An important element of IPSec key management is the use of public key certificates A public key certificate is provided by a trusted Certificate Authority (CA) to authenticate a user's public key The essential steps include…


Public Key Certificates : Public Key Certificates Step 1 Client software creates a pair of keys, one public and one private The client prepares an unsigned certificate that includes a user ID and the user's public key The client then sends the unsigned certificate to a CA in a secure manner


Public Key Certificates : Public Key Certificates Step 2 A CA creates a signature by calculating the hash code of the unsigned certificate and encrypting the hash code with the CA's private key The encrypted hash code is the signature The CA attaches the signature to the unsigned certificate and returns the now signed certificate to the client


Public Key Certificates : Public Key Certificates Step 3 The client may send its signed certificate to any other user That user may verify that the certificate is valid by Calculating the hash code of the certificate (not including the signature) Decrypting the signature using the CA's public key Comparing the hash code to the decrypted signature.


Public Key Certificates : Public Key Certificates If all users subscribe to the same CA, then there is a common trust of that CA User certificates can be placed in the directory for access by all users. Or a user can transmit his or her certificate directly to other users. In either case, once B is in possession of A's certificate, B has confidence that messages it encrypts with A's public key will be secure from eavesdropping and that messages signed with A's private key are unforgeable


Public Key Certificates : Public Key Certificates If there is a large community of users, it may not be practical for all users to subscribe to the same CA Because it is the CA that signs certificates, each participating user must have a copy of the CA's own public key to verify signatures This public key must be provided to each user in an absolutely secure


IPsec Pitfalls: IPsec Pitfalls Too complicated, many different ways to configure Can be configured insecurely Client security is an issue Performance in IPv4 realisering (Especially a BITS)


Advantages of IPSec over SSL/TLS: Advantages of IPSec over SSL/TLS Encrypts the entire packet, including IP Header (not just layer 4 and higher) Can Encrypt any protocol No Impact on users when using SG to SG Acts independent of IP address