Todo list k slajdum na CF / vypisky z IPsec-related RFCs Vladimir Kotal, vlada AT devnull DOT cz, 2003 - podrobnosti o SHA-2 Motivated by the AES selection, NIST proposed replacements for SHA-1 that provide a level of collision resistance equivalent to the security of each AES key sizes. The new hash functions are SHA-256, SHA-384, andSHA-512 (sometimes collectively called SHA-2), defined in the recently approved FIPS 180-2. -> vicemene je rozdil hlavne v message digest size (SHA-1 z 1995 mela 160bits, SHA-2 ma 256, 384 nebo 512 bitu) -> proc to je ? pokud je hash alg. pouzity ve spojeni napr. s digital signature alg. (napr. DSA): zprava je podpsana DSA, ktery poskytuje 128bits of security, signature alg. muze vyzadovat secure hash funkci, ktera poskytuje 128bits of security, napr. SHA-256 http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf http://planeta.terra.com.br/informatica/paulobarreto/hflounge.html - security achitecture for IP XXX - ESP/AH komentare: AH poskytuje autentizaci pro vsechny pole IP hlavicky pro ktere je to mozne (nemeni se behem tranzitu) a taky pro data protokolu nad IP (TCP, UDP) ESP i AH poskytuji autentizaci, ale lisi se mirou, s jakou ji poskytuji - ESP neautentizuje zadne pole z IP hlavicky, pokud tato hlavicka nespada pod ESP (tunnel mode) obe poskytuji taky ochranu proti replay utokum - pomoci seq. #, receiver je ovsem musi kontrolovat - AH 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Authentication Data (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ viz ah.sh IP | AH | ICMP (plaintext) IP = { Version (4), Header len, DiffServ. field, Total len, IP ID, Flags, Fragment offset, TTL, Protocol (AH = 0x33 = 51), Checksum, Src, Dst } AH = { Next Header (i.e. ICMP), payload length, SPI, seq. #, ICV } vsechny pole jsou povinne a pocita se z nich ICV (Integrity Check Value) NextHeader - z /etc/protocols Paylen - delka AH ve slovech (4-byte units) minus 2 (pokud bude "null" auth. algorithm, vyjde "1" pro IPv4 a "2" pro IPv6, protoze nebude pole ICV (Authentication Data field)) SPI - 32bit hodnota pro identifikaci SA (spolu s dest. addr a security protocol (AH)) 1-255 rezervovane by IANA 0 je pouze pro lokalni pouziti, nesmi byt poslano po siti obvykle je toto cislo zvoleno dest. hostem pri ustaveni SA AH je v IPv6 Extension header (vypada to temer stejne jako v IPv4 - az na IP hlavicku) sequence # - 32bit, monotone rostouci od 0, povinne v AH hlavicce sender musi toto cislo odeslat, receiver ho nemusi zpracovat - pokud je zapnuta anti-replay ochrana (default), musi byt po preteceni counteru seq # ustavena nova SA (tj. 2^32 paketu per SA) v pripade dyn. vymeny klicu XXX co se stane v pripade manual. klicu ? Authentication Data - obsahuje ICV pro tento paket delka AH hlavicky musi byt nasobek 32 (v bitech) pro IPv4, nebo 64 pro IPv6, pripadne se pouzije padding padding issue: paddovat se muze jak auth. data (ICV), tak payload v datove casti paketu (pokud to vyzaduje HMAC fce specifikovana v AH) v takovem pripade se pouzije vyplneni nulami pocitani ICV: - pres vsechny pole IP hlavicky, ktere se nemeni pri tranzitu nebo ktere jsou predikovatelne ve chvili kdy dorazi k dest. addr (dest addr pri loose nebo strict source routing) - AH hlavicka (Auth. data jsou ve chvili vypoctu ICV nastavena na 0) - data vyssi vrstvy, u kterych se predpoklada, ze se v tranzitu nebudou menit pozn.: IPv4 header ma 5 mutable polozek, IPv6 pouze 3 (Class, Flow label, Hop limit) integrity checks: - sekvencni cisla nemusi byt checkovana, dokonce nesmi byt v priapde nekolika odesialatlu na totez SA (kazdy pouziva jine inicialni seq #) (SHOULD NOT) check seq #s by mel byt proveden jako 1. check vubec implementace seq # check by mela byt provedena pomoci sliding window - pravy okraj je nejvyssi zatim prijate seq # cislo, cokoliv prijde "pod" levym okrajem je rejectnuto, cokoliv v rozmezi okna je checkovano oproti seznamu zatim prijatych paketu pro toto SA - ICV verifikace : ihned po uspesne verifiakce seq # receive window je updatovano pouze pokud uspeje ICV verifikace a) one-way hash fce b) hash fce + digital signature -> slozitejsi matching process vkladani AH hlavicky: transport mode : za IP hlavickou, pred hlavickou upper protokolu nebo pred dalsi IPsec hlavicky pokud byly vlozeny IPv4: IP | TCP | Data -> IP | AH | TCP | Data (autentizovano je vsechno krome poli ktera se meni pri tranzitu) IPv6: IP | ext. hdrs | AH | Data -> IP | hop-by-hop,dest*,routing,frag. | AH | dest* | TCP | Data (autentizovano vse krome menicich se poli, destination options extension header muze byt pred i za AH) tunnel mode: ochrana celeho vnitrniho paketu, vcetne cele jeho hlavicky (ta se pri transportu nemeni) IPv4: new IP hdr | AH | orig IP hdr | TCP | Data IPv6: new IP hdr | ext. hdrs if present | AH | orig. IP hdr | ext. hdrs if present | TCP | Data auth. algoritmy: pro unicast (point to point) se hodi MACs (e.g. based on DES) nebo 1way hash functions (MD5, SHA-1) fragmentace: probiha az pote, co je paket zpracovan IPsecem (transport mode) pro tunnel mode muze IPsec zpracovavat uz fragmentovane pakety. tyto musi byt nejdrive slozeny na strane receivera aby se mohly verifikovst vlastnosti zarucene AH - ESP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Auth. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |erage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |erage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Authentication Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ poskytuje: - confidentality - autentizace - data integrity - anti-replay service (forma castecne integrity sekvenci) (posledni tri poskytuje AH taky, ale v jinem meritku) data origin auth. a connectionless integrity tvori spolecne jednu sluzbu, ktere se dohromady rika autentizace. tato sluzba muze byt pouzita dohromady s confidentality service. antireplay ochrana muze byt pouzita pouze tehdy, je-li pouzita autentizace a jeji volba zavisi ciste na prijemci. odesilatel muze inkrementovat sekvenci cisla, ale prijemce je nemusi checkovat. confidentality je na ostatnich services nezavisla, ale ! pouziti vlastnosti pro confidentality bez integrity/authentication muze vystavt traffic nekolika typum utokum, ktere mohou vest k confidentality subvertion Dukaz: "demonstrace" (Steven M. Bellovin - Areas for the IP Security Protocols (1996)) sifrovani CBC mode ma nasl. zajimave vlastnosti: (Cipher block chaning : sifra soucasneho bloku zavisi na sifre predchoziho na OT se XORuje predchozi blok ST ST(i-1) |-----------------| | | v |-------| | ---> XOR ---| E_k |---+-- ST(i) |-------| chyba v jednom bitu se tak rozprostre do dvou bloku ST ) 1. prefix CBC sifry je sifra prefixu tj. mame-li stream C_1, ..., C_i, ..., C_n pak C_1, ..., C_i je zasifrovana sekvence P_1, ..., P_n , kde P_i je "kus" plaintextu. -> utocnik muze tedy zkratit blok ST 2. zobecneni 1) substring C_i, ..., C_j je platna sifra P_i, ..., P_j pokud IV muze byt nastaven na C_{i-1}. -> utocnik muze extrahovat jakoukoliv cast ST 3. omezena propagace chyby - pokud je blok ST porusen pri tranzitu, pouze on a nasledujici plaintext blok jsou poruseny - pokud je blok ST ztracen, pouze nasl. plaintext blok bude porusen 1) + 2) + 3) dovoluji cut-n-paste operaci predpokladame pouziti ESP, ale nikoliv AH soucasne predpokladame uzivatele L a X, kde L je legitimni uzvatel, L_A je konto toho uzivatele na stroji A, X_A je neprivilegovane konto utocnika na stroji A. utocnik je dale schopen cist, modifikovat nebo vkladat data mezi A a B. reading encrypted data: monitored traffic: L_A -> L_B : IP | ESP_k | [ TCP | secret ] (i) X_A -> X_B : IP | ESP_k | [ UDP | any ] (ii) reinjected data : X_A -> X_B : IP | ESP_k | [ UDP | TCP | secret ] (iii) znaceni: data mezi [ a ] jsou zasifrovana A, B jsou pocitace L_A, L_B jsou je legitimni user na A, B X_A, X_B je utocnik falsujici data z A, resp. B postup: utocnik zachyti puvodni zpravu (i), vytvori (a posle) zpravu (ii) s podobnou IP hlavickou (total length). tento paket obsahuje ESP hlavicku, kterou mu priradi IPsec processing. tato UDP zprava (ii) je poslana B. utocnik tuto zpravu zachyti a vyjme ze site. misto ni vlozi zpravu, kterou ziska nasledujici konstrukci: zasifrovana cast z (i) [ TCP | secret ] je vlozena do tela (ii) (+pripadny padding aby sedely delky (ii) a (iii)) a tento paket je poslan. kernel na stroji B projde paket IPsec processingem, a posle zpet A. uzivatel X_B dostane paket, ktery ma desifrovane telo [ UDP | TCP | secret ] z vyse uved. vlastnosti CBC (self-healing) muze byt prvni blok TCP hlavicky ztracen. vsechno ostatni bude citelne. pozn. : podobne se da provest hijacking spojeni - do paketu lze vlozit libovolna data (napr. 'rm -rf /' do shellu uzivatele L_B) => pouceni: pouzivat ochranu confidentality vzdy s autentizaci+integrity checks dalsi genericka metoda je pouzivat jiny klicovy material pro kazdou "konekci" - tj. menit ho dost casto. outbound processing: 1. zazpouzdreni (do pole 'ESP payload') - transport mode : pouze informace tykajici se vyssi vrstvy (mysleno 3. vrstva) - tunnel mode: zapouzdri cely IP datagram 2. prida nezbytny padding 3. zasifruje vysledek (1) a (2) tj. Payload data, padding, pad length, next header pouzitim klice, sifrovaciho algoritmu, modu sifrovaciho algoritmu, ktere jsou urcene SA pro tento paket. dale se pridaji pripadna data pro kryptografickou synchronizaci - napr. IV pro dany sifrovaci algoritmus. pokud se pouziva autetizace, nejdrive se sifruje payload atd. (ted se mluvi o outbound processingu !) a sifrovani nezhrnuje pole pro autentizaci. tim se dosahne toho, ze - sifrovani, vypocet autentizacnich dat muze byt provedeno praralelne - rapid detection and rejection of replayed packets (inbound processing je inverzn process k outbound processing) vypocet ICV: pokud je nastaveno pouziti autentizace, sender pocita ICV pres ESP krome Auth. data. Tim padem jsou autentizovana pole SPI, seq #, Payload data, Padding, Pad len, Next header. Posledni 4 pole jsou autentizovana zasifrovana, protoze sifrovani probiha pred vypoctem ICV. -> rozdil dosahu autentizace oproti AH je v tom, ze AH autentizuje vsechny polozky celeho paketu, ktere je mozne (vyjma mutable fields v IP hlavicce), ESP autentizuje pouze vsechno od ESP hlavicky dal. (ESP hlavicka nasleduje az za IP hlavickou a dalsimi ext hdrs za IP hlavickou) pozn.: tato semantika je zajimava a nekdy kritizovana: autentizovat by se alternativne mohlo to, "co bylo mysleno", nikoliv data, ktera nic neznamenaji. check ICV: nejprve je odejmuta z paketu polozka ICV, pote je zkontrolvoana delka ESP paketu minus delka ICV. na toto je pusten vypocet ICV s tim, ze se provedene implicitini zero-fill padding pokud to tento vypocet vyzaduje. pokud je pro autentizaci pouzit digitalni podpis a one-way hash, proces je slozitejsi. ICV verifikace a decrypt mohou byt provedeny paralelne nebo seriove. pokud jsou provadeny seriove, musi byt ICV check proveden jako prvni. fragmentace: je provadena az po IPsec zpracovani celeho paketu. tyto fragemnty musi na konci cesty reasemblovany recievrem. pokud je IPsec processingu predan ESP paket, ktery ma nastaven MORE FRAGMENTS flag, je okamzite zahozen. verfikace seq #: opet problem multi-sender enviroment per 1 SA anti-replay service by nemela byt v takovem prostredi pouzivana zajimava vec: muze se stat, ze se vybere spatna SA pokud se behem cesty poskodi dest IP addr nebo Protocol field v IP hlavicce (tyto nejsou chraneny autentizaci poksytovanou ESP), muze dojit k tomu, ze se vybere spatna SA. XXX reseni: pouzit ESP spolu s AH ? - RFC2401 bis00 (Security Architecture for the Internet Protocol) - zakladni dokument o IPsecu na nej navazuji ESP, AH, IKE, apod. veci, ktere dale rozvadeji, co je napsano tady obsahuje definice zakladnich abstrakci: SA, spi, SAD, SPD pro jednu SA muze byt bud AH nebo ESP, ale ne oba. pokud security policy vyzaduje kombinaci ESP a AH, pouzije se vice SA - tzv. SA bundle. SA bundles mohou byt dvou typu: - transport adjacency - iterasted tunneling - transport dajacency aplikovani vice protokolu ESP a AH na jeden paket bez toho, ze by se vyvolal tunnel mod Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)---------- - iterated tunneling 3 zakladni typy iterated tunnelingu, podporovane jsou nasledujici dva: jeden endpoint pro SAs je spolecny, cilove endpointy jsou dva: Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- ruzne endpointy: Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)----------- pro transport mod je pouzitelna pouze jedna kombinace AH a ESP: za IP hlavickou je AH, pak teprve nasleduje ESP. v tomto kontextu je AH aplikovana na CT produkovany ESP. IP | AH | ESP | [ TCP hdr | payload ] AH + ESP tunnel mode: IP hdr 1 | AH | ESP | IP hdr 2 | [ TCP hdr | payload ] - ISAKMP/IKE ISAKMP je protokol pro spravu SA (mysleno AH SA nebo ESP SA) ISAKMP pouziva protokoly pro vymenu klicu, napr. IKE. toto je dobre schema - pokud bude nalazena chyba v nejakem protokolu pro KE, lze pouzit jednodusse jiny (implementation dependent) v tomto pohledu je SA specificka mnozina, ktera jednoznacne definuje sluzby a mechanismy nezbytne pro ochranu trafficu pro danou uroven. tyto parametry obsahuji identifikatory algoritmu, mody, kryptograficke klice, atd. vice viz. sekce 2.3 a 2.5 z RFC 2408 ISAKMP definuje velke mnozstvi payloadu, ktere jsou urceny pro prenos informaci mezi dvema ISAKMP servery. tyto payloady jsou urceny pro prenos dat jako napr. security association (SA) data, key exchange data atd. v single ISAKMP zprave muze byt poslano vice payloadu. payload se sestava z obecne hlavicky identifikujici payload a pak dat, ktera jsou pro ISAKMP neinterpretovatelna. payload types: Security Association Payload 3.5 Proposal Payload 3.6 Transform Payload 3.7 Key Exchange Payload 3.8 Identification Payload 3.9 Certificate Payload 3.10 Certificate Request Payload 3.11 Hash Payload 3.12 Signature Payload 3.13 Nonce Payload 3.14 Notification Payload 3.14.1 Notify Message Types 3.15 Delete Payload 3.16 Vendor ID Payload exchange: specifikace poctu zprav v ISAKMP exchange, a payload typu techto zprav v teto vymene. kazdy echg. type ma danou fci, napr. zajisitit anonymitu ucastniku nebo vymenu klicoveho materialu. typy echanges: Base Exchange 4.5 Identity Protection Exchange 4.6 Authentication Only Exchange 4.7 Aggressive Exchange 4.8 Informational Exchange - "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation XXX co to presne je ? - novinky: opportunistic encryption http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic.html draft-richardson-ipsec-opportunistic-12.txt Pocitac se dotaze na reverzni zaznam v DNS pocitace s nimz chce komunikovat Existuje nekolik specifikaci jak to udelat resp. existuje nekolik formatu ulozeni v DNS FreeS/WAN ocekava TXT zaznam, v nemz najde klic pokud ho najde, zavede si ho a dal se vsechno odehrava normalne ochrana proti DNS spoofingu: dnssec V tom draftu se psalo, ze je to v podstate IKE pro sirokou verejnost resp. cesta jak za pomoci existujicich standardu realizovat vymenu klicu - prakticka cast: - simulace point-to-point spojeni (staticke klice, pouziti IKE, raccon, IPv6) -> vsechny ttyo veci po jedne - simulace full blown VPNky (nahodit obrazek s 'borland-like' konekci) vysvetlit gif device funcknost racoon - manualni/automaticka vymena klicu (IKE) ukazat prakticky (ah.sh) OpenDarwin: src/network_cmds/{ping,ping6} spddump; dump; spdflushl (-F), dump (-D); - porovnat implementace racoon/isakmpd XXX - nastaveni racoon simstim:/Users/techie/.racoon root# chown root psk.txt simstim:/Users/techie/.racoon root# chmod 600 psk.txt - links Normy: http://www.ietf.org/html.charters/ipseckey-charter.html Implementace: http://www.freeswan.org/freeswan_trees/CURRENT-TREE/doc/quickstart.html http://netbsd.gw.com/cgi-bin/man-cgi/man?setkey+8ŅetBSD-current http://www.netbsd.org/Documentation/network/ipsec/