IPsec

Internet Protocol Security (IPsec) este o suită de protocoale pentru securizarea comunicațiilor peste stiva TCP/IP. Această suită se bazează pe folosirea funcțiilor matematice și a algoritmilor de criptare și autentificare pentru a asigura confidențialitatea, integritatea și non-repudierea informațiilor din fiecare pachet IP transmis pe rețea. IPSec este la ora actuală una dintre cele mai folosite metode de securizare a transmisiei pe Internet, alături de SSL (Secure Sockets Layer) și TLS (Transport Layer Security). Spre deosebire de acestea, protocoalele IPSec se regăsesc la nivelul 3 al stivelor TCP/IP și ISO-OSI, ceea ce face posibilă securizarea tuturor aplicațiilor care folosesc stiva TCP/IP.

IPSec are o arhitectură de tip end-to-end, compatibilă atât cu protocolul IPv4, cât și cu IPv6, unde integrarea funcțiilor de securizare este nativă, încă de la proiectarea protocolului. Modelul IPsec este descris în mod oficial de către IETF, printr-o serie de documente RFC.

Prin suita IPsec pot fi securizate comunicațiile între două sau mai multe calculatoare independente, între două sau mai multe subrețele aflate fiecare în spatele unui gateway care se ocupă de folosirea funcțiilor criptografice pentru fiecare subrețea aflată în administrarea sa, precum și între un calculator independent și o subrețea aflată în spatele unui gateway. IPsec se bazează pe proprietățile criptografice ale unor modele precum Diffie-Hellman, RSA sau DSA și a algoritmilor de criptare și autentificare, cum sunt DES, 3 DES, AES, MD5, SHA1.

Arhitectura de securitate

IPsec este un set de standarde deschise, publicate de IETF. Această suită de standarde poate fi privită ca având două componente principale: stabilirea protocoalelor de securitate și securizarea traficului efectiv.

Stabilirea protocoalelor de securitate

Această etapă se ocupă de stabilirea algoritmilor criptografici și a parametrilor acestora, comuni entităților care participă la securizarea traficului. Scopul acestei etape este obținerea unui set de cunoștințe comune participanților, referitoare la identitatea participanților, seria exactă de algoritmi de criptare și de autentificare ce vor fi folosiți, parametrii acestora și reprezentarea traficului ce va fi supus securizării prin IPsec. Aceste elemente sunt concretizate în numele algoritmilor și valorile cheilor asociate, ansamblul de algoritmi și chei fiind numit asociere de securitate.

Această etapă poate avea loc static sau dinamic. Denumirea oficială a stabilirii statice a acestor asocieri este manual keying (română schimb manual de chei). Pe fiecare entitate participantă în traficul IPsec se definesc apriori algoritmii folosiți și cheile acestora.

Metoda dinamică de stabilire a asocierilor de algoritmi și chei este numită ISAKMP - Internet Security Association and Key Management Protocol, descrisă în RFC 2408. Există două versiuni ale ISAKMP, IKEv1 și IKEv2 - Internet Key Exchange. Rezultatul acestui procedeu este crearea unei asocieri de securitate între entități, iar negocierea se face pe portul 500 (UDP sau TCP).

Asocierea de securitate

Asocierea de securitate este un ansamblu de date de tip nume de algoritm - cheie, care reprezintă capabilitățile criptografice comune entităților participante la asocierea IPsec. Ansamblul acestor seturi de asocieri de securitate pe un anumit calculator sau gateway este numit SAD - Security Association Database, baza de date cu informații criptografice, de pe fiecare entitate IPSec, în legătură cu celelalte entități conexe.

Pe fiecare entitate IPsec se mai găsește o a doua bază de date, numită SPD - Security Policy Database, cu informații despre traficul care trebuie securizat, numit trafic interesant.

Conținutul bazei de date SAD este populat fie manual, de către administratorul acelui sistem, fie dinamic, prin negocierea de IKE între entități, însă tot pe baza unui set predefinit de capabilități ale fiecărui sistem.

Pentru ca în momentul securizării traficului fiecare entitate să cunoască parametrii de securizare pentru fiecare tip de trafic este folosit identificatorul SPI - Security Parameter Index, un index pe baza de date SAD. Folosind acest index și valoarea adresei IP din destinația pachetului ce urmează a fi supus procesului de criptare sau autentificare, fiecare entitate IPsec știe exact ce transformare trebuie realizată pe fiecare pachet IP pentru ca acesta să poată fi decriptat la receptor și corect interpretat. Procesul de decriptare este asemănător în momentul recepției unui pachet astfel securizat.

În cazul în care sunt mai mult de doi participanți la asocierea de securitate, în cazul traficului de tip multicast, asocierea de securitate este furnizată pentru întregul grup și este prezentă pe fiecare sistem participant. Pot exista, de asemenea, mai multe asocieri de securitate pentru un același grup de entități, fiecare cu diverse nivele de securitate în interiorul grupului.

Clasificare

Manual / ISAKMP

În funcție de modalitatea de stabilire a parametrilor asocierii de securitate, suita IPSec poate fi stabilită prin ISAKMP - negociere prin mesaje IKE sau manual - static, preconfigurate de administrator pe fiecare sistem.

Tunel / Transport

În funcție de tipul de încapsulare al traficului supus IPsec, suita poate realizare securizarea prin încapsulare de tip tunel sau de tip transport.

• Încapsularea de tip tunel apare în momentul în care entitățile participante la IPsec sunt de tip gateway; ele au în administrare una sau mai multe subrețele pentru traficul cărora realizează operații criptografice. Pachetul încapsulat IPsec va avea un set de adrese IP exterioare - adresele IP ale entităților gateway și un set de adrese IP interioare sau protejate - adresele IP, publice sau private, ale subrețelelor din spatele acestor gateway-uri.
• Încapsularea de tip transport apare în momentul în care entitățile participante la IPSec sunt calculatoare independente, care au instalat un soft specializat IPsec, realizînd operații criptografice pentru propriul trafic. Pachetul încapsulat va avea un singur set de adrese IP, publice, ale acestor calculatoare.

Site-to-Site / Remote-Access

Această manieră de clasificare se pretează în exclusivitate tipului de încapsulare tunel, neavând sens pentru tipul transport. Criteriul de clasificare este acela al tipului entității participante la IPsec.

• În cazul în care entitățile sunt două gateway-uri de securitate care realizează operații criptografice pentru subrețele protejate aflate în administrarea lor, modelul de trafic se numește Site-to-Site sau LAN-to-LAN, în accepțiunea mai multor producători de echipamente de securitate IPsec. Denumirea sugerează scenariul de comunicare descris în figura de mai jos.
• În cazul în care entitățile sunt un gateway de securitate care are în administrare o subrețea și un calculator independent care dorește să comunice cu acea subrețea, scenariul se numește Remote-Access sau Dial-Up VPN, în accepțiunea mai multor producători de echipamente. Denumirea sugerează scenariul de comunicare descris în figura de mai jos.

Cazul de remote-access este un tip de scenariu de tunel, deoarece, în momentul în care este trimis pe rețea, pachetul încapsulat are două seturi de adrese IP: un set "extern", reprezentat de adresele IP ale calculatorului și al gateway-ului căruia se adresează, și un set de adrese IP "intern", reprezentat de adresa IP a unei mașini din interiorul rețelei și a unei adrese IP noi a calculatorului, obținută de la acel gateway pentru a avea adresabilitate de nivel IP în interiorul rețelei la care acest calculator se conectează.

Procedeul prin care un calculator obține, în momentul negocierii IPsec, o adresă de la gateway pentru a avea acces într-o rețea internă este numit mode-config în scenariile de tip IKEv1 sau configurare remote în cele de IKEv2.

PSK / PKI / EAP

În momentul negocierii de IKE a parametrilor asocierii de securitate se realizează și faza de autentificare mutuală sau unilaterală a entităților. Există mai multe modalități de a realiza această autentificare:

• PSK - Pre-Shared Key : pentru autentificare, fiecare entitate are pre-configurată o cheie secretă, o parolă. În momentul realizării negocierii IKE, entitățile trimit această cheie pe rețea, spre a fi verificată de entitățile omoloage și verifică, la rândul lor, că o anumită entitate-pereche are o anumită cheie secretă.

• PKI - Public Key Infrastructure: pentru autentificare este folosit un sistem de tip PKI. Fiecare entitate are un certificat digital semnat de o autoritate de certificare publică sau internă companiei, dar de încredere pentru toate entitățile participante în IPSec. În faza de autentificare din IKE, fiecare entitate își trimite certificatul digital către omologi spre a fi verificat și verifică la rândul ei validitatea acelui certificat digital.

• EAP - Extensible Authentication Protocol: la rândul său un framework, de data aceasta de autentificare, EAP nu realizează autentificare per se, ci oferă o schemă de mesaje de autentificare ce folosește metode specifice, cum sunt MD5, GTC, TLS, SIM, AKA. În faza de autentificare, EAP este folosit ca extensie a protocolului IKEv2, acest framework nefiind suportat în IKEv1.

Modul de funcționare

În afara cazului de manual keying unde baza de date SAD este completată într-o manieră statică, negocierea IKE este descrisă mai jos. Există două versiuni ale acestui protocol: IKEv1 - RFC 2409 și IKEv2 - RFC 4306. Cele două protocoale nu sunt compatibile unul cu celălalt.

IKEv1

Negocierea IKEv1 este alcătuită din două etape sau faze, numite sugestiv Phase1 și Phase2. Prima fază are rolul de a autentifica entitățile de IPSec, de a stabili o asociere de securitate și de a deriva cheile Diffie-Hellman din care vor fi derivate ulterior cheile efective de criptate și/sau autentificare pentru traficul de date. Prima fază are la rândul ei două variante sau moduri: modul principal - main mode și modul agresiv - aggressive mode, fiecare redat mai jos. Faza a doua este numită modul rapid - quick mode.

• Modul principal cuprinde un număr de șase mesaje care se schimbă între inițiatorul și responderul de IPsec.

• Modul agresiv cuprinde un număr de trei mesaje schimbate și este considerat un schimb nesigur, de aceea nu se mai recomandă utilizarea lui.

• Modul rapid cuprinde un număr de trei mesaje și este dependent de realizarea unui schimb anterior (de tip principal sau agresiv), care să protejeze informația conținută în aceste pachete. Modul de bază (fără schimb de chei) împrospătează informația din materialul criptografic derivat în schimbul de prima fază. Acest procedeu nu furnizează însă serviciul de PFS - Perfect Forward Secrecy, serviciu care poate fi obținut prin utilizarea unui payload special de schimb de chei + KE, care presupune încă o exponențiere.

IKEv2

Negocierea IKEv2 are un singur mod de stabilire si cuprinde un schimb inițial - Initial Exchange și un schimb de creare de asocieri de securitate - CREATE_CHILD_SA Exchange.

• Initial Exchange este un schimb alcătuit din patru mesaje, el fiind oarecum echivalentul primei faze în accepțiunea protocolului IKEv1.

• CREATE_CHILD_SA Exchange este un schimb alcătuit din două mesaje, echivalentul celei de-ale doilea faze din IKEv1.

Cazuri speciale

• Atât IKEv1, cât și IKEv2 au definit un timp de validitate (sau de expirare) al cheilor negociate, pentru a proteja traficul criptat și/sau autentificat de eventualele atacuri asupra cheii, la o utilizare îndelungată a acesteia. Acest timp este numit lifetime (durată de viață). După o valoare negociată a acestui lifetime (în IKEv1) sau după aceeași valoare, dar stabilită individual (în IKEv2), protocolul de IKE împrospătează valoarea cheilor prin procedeul numit rekey. Un caz special de rekey este numit PFS - Perfect Forward Secrecy, în care este refăcută negocierea Diffie-Hellman și se obține un nou set de chei, care va fi materialul criptografic de bază pentru noile negocieri. Renegocierea cheilor se poate face și ca urmare a depășirii unui anumit volum de date transmis prestabilit. Presupunând că un atacator a capturat tot traficul transmis pe un anumit canal securizat, se dorește ca acesta să nu dispună de suficient de multă informație criptografică pentru a deduce cheia de criptare și a despacheta informația încapsulată.

• În oricare dintre clasificările IPsec, setul de adrese IP externe se presupune a fi alcătuit din adrese publice, pentru a putea obține corecta autentificare a părților. IETF a definit și maniera în care negocierea IKE poate avea loc fără ca cele două (sau mai multe) adrese IP participante să fie publice, anume cazul în care acestea se găsesc în spatele unui sistem de NAT - Network Address Translation. În acest caz special, negocierea IKE nu se mai realizează pe portul 500, ci pe 4500, după ce entitățile au făcut în prealabil o probă a adresabilității directe și au determinat că cel puțin una dintre ele se află în spatele unui server de NAT. Bineînțeles, acest caz exclude posibilitatea încapsulării AH (din cauza adresei IP externe care se schimbă), dar se poate realiza în continuare încapsularea ESP cu și fără autentificare. Procesul de negociere IKE în care cel puțin una dintre entitățile participante este în spatele unui NAT se numește IKE - traversare NAT sau NAT-T for IKE - NAT Traversal pentru IKE.

• Cele mai multe implementări de IPsec încearcă să realizeze pe cât posibil optimizarea utilizării resurselor computaționale disponibile. Un exemplu în acest sens este închiderea tunelului IPsec în cazul în care nu se mai trimit date pentru o anumită durată de timp, sau dacă lărgimea de bandă ocupată pentru o anumită conexiune este nulă. Dacă aceasta este configurația implicită, pentru anumite conexiuni se poate dori suprascrierea ei și menținerea acelei conexiuni. Una dintre posibilitățile puse la dispoziție de standard se numește DPD - Dead Peer Detection. Acesta este un mecanism de timp keepalive care presupune trimiterea unui pachet între capetele conexiunii, la un interval stabilit.

Bibliografie

• Doraswamy, Naganand (2003). IPSec - The New Security Standard for the Internet, Intranets, and Virtual Private Networks (în engleză) (ed. a doua). Prentice Hall. ISBN 0-13-046189-X. 

Standarde

• RFC 2367: PF_KEY Interface
• RFC 2401: Security Architecture for the Internet Protocol (IPsec overview) Obsolete by RFC 4301
• RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
• RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
• RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 2409: The Internet Key Exchange
• RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
• RFC 2411: IP Security Document Roadmap
• RFC 2412: The OAKLEY Key Determination Protocol
• RFC 2451: The ESP CBC-Mode Cipher Algorithms
• RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
• RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
• RFC 3947: Negotiation of NAT-Traversal in the IKE
• RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Security Architecture for the Internet Protocol
• RFC 4302: IP Authentication Header
• RFC 4303: IP Encapsulating Security Payload
• RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 4306: Internet Key Exchange (IKEv2) Protocol
• RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308: Cryptographic Suites for IPsec
• RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
• RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
• RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
• RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
• RFC 4718: IKEv2 Clarifications and Implementation Guidelines
• RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
• RFC 4809: Requirements for an IPsec Certificate Management Profile
• RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
• RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX