Aspekty bezpieczenstwa w sieciach opartych o TCP/IP cz. III
Dotychczas zapoznalismy sie z ogólnym opisem TCP/IP oraz niektórymi zagrozeniami majacymi bezposredni zwiazek z budowa protokolu IP oraz z poznalismy zarys struktury IPsec. Analiza mozliwosci podniesienia bezpieczenstwa w sieciach teleinformatycznych opartych o TCP/IP prowadzi do przyblizenia dwóch protokolów IPsec. Czesc trzecia artykulu przedstawia protokól uwierzytelniajacy rozszerzenia IPsec..
1. Prokokól uwierzytelniajacy (AH)
Protokól uwierzytelniajacy (Authentication Header - AH) zapewnia integralnosc i jednoznacznie okresla nadawce pakietu IP. Jak wiadomo czesc informacji naglówka IP jest niezmienna (np. adres nadawcy), czesc zmienia sie przy kazdym przejsciu przez router (np. pole TTL naglówka). Omawiany protokól uwierzytelnia pakiet IP z dokladnoscia do zmiennych pól naglówka pakietu IP. Moze byc on stosowany w polaczeniu z protokolem zabezpieczenia zawartosci pakietu (Encapsulating Security Payload - ESP). O sposobach i mozliwosciach laczenia tych dwu protokolów mówilismy w porzedniej czesci artykulu [1].
Zgodnie z omówionymi w [1] polaczeniami bezpieczenstwa (Security Associations - SA) nagówek AH moze byc umieszczany w pakiecie IP tworzac transportowe lub tunelowane polaczenie bezpieczenstwa.
2. Naglówek protokolu uwierzytelniajacego
Naglówek protokolu IP poprzedzajacy naglówek AH w polu Protocol (Ipv4) lub Next Header (Ipv6) bedzie mial wpisana wartosc 51, co odpowiada protokolowi uwierzytelniajacemu AH rozszerzenia IPpec jak zostalo okreslone przez IETF w [2].
Format naglówka AH przedstawia ponizszy rysunek. Wszystkie pola przedstawione na rysunku zawsze wystepuja w naglówku AH.
Rys. 1. Format naglówka protokolu uwierzytelniajacego.
Pole Next Header - osmiobitowe pole identyfikujace typ zawartosci pakietu za naglówkiem AH. Wartosc tego pola to zgodny z [2] numer protokolu jaki zostal zastosowany po protokole uwierzytelnienia. Moze to byc np. numer protokolu ESP lub dowolnego z protokolów warstwy transportowej (TCP, UDP itp.)
Pole Payload Len - równiez osmiobitowe pole, które zawiera informacje o dlugosci naglówka AH mierzona w 32-bitowych jednostkach minus 2. "Standardowo" naglówek sklada sie z 96-bitowej wartosci uwierzytelniajacej oraz 96 bitów stalych pól naglówka. Zatem "standardowa" wartosc tego pola wynosi 4 [1].
Pole oznaczone jako RESERVED przeznaczone jest przez twórców standardu do przyszlych zastosowan. Jego obecna wartosc to zero i wartosc ta jest uwzgledniana przy obliczaniu wartosci uwierzytelniajacej. Dlugosc tego pola 16 bitów.
Pole Security Parameters Index (SPI) - 32-bitowa, arbitralnie dobrana wartosc, która wraz z adresem IP przeznaczenia oraz protokolem uwierzytelnienia jednoznacznie okresla polaczenie bezpieczenstwa tego pakietu. Zakres numerów SPI od 0 do 255 jest zarezerwowany dla przyszlych zastosowan, przy czym wartosc 0 nie moze byc "wpisana" do zadnego pakietu przesylanego w laczach.
Pole Sequence Number zawiera monotonicznie zwiekszajaca wartosc prostego licznika. Pole to jest zawsze obecne w naglówku AH, nawet jesli odbiornik nie zada dla uslugi anti-replay dla danego polaczenia bezpieczenstwa (SA). Przy zestawieniu polacznia SA liczniki numerów sekwencyjnych nadajnika i odbiornika sa zerowane a pierwszy transmitowany pakiet ma w polu Sequence Number wpisana wartosc 1. W przypadku, gdy usluga anti-replay jest aktywna jesli wartosc licznika osiagnie wartosc maksymalna (tj. 8589934591) polaczenie SA musi byc rozlaczone. Jesli transmisja danych ma byc kontynuowana musi byc wóczas zestawione nowe polaczenie SA. Natomiast w przypadku braku uslugi anti-replay przejscie z maksymalnej wartosci licznika na zero jest ignorowane i licznik dziala jak licznik modulo.
Pole Authentication Data zawiera obliczona dla danego pakietu wartosc uwierzytelniajaca (Integrity Check Value - ICV). Sposób obliczania tej wartosci zostanie przedstawiony ponizej. To pole moze zawierac odpowiednia ilosc bitów dodatkowych (tzw. padding) tak, by calkowita dlugosc naglówka AH byla wielokrotnoscia 32 bitów (IPv4) lub 64 bitów (IPv6).
3. Przetwarzanie naglówka AH
Naglówek AH moze byc dodawany do pakietu IP w dwóch trybach: transportowym i tynelowanym. W trybie transportowym naglówek AH umieszczany jest bezposrednio za naglówkiem IP i przed naglówkiem protokolu warstwy wyzszej (np. TCP, UDP, ICMP itp.). Opowiednio dla wersji 4 i wersji 6 IP umiejscowienie naglówka AH przedstawia ponizszy rysunek.
Rys. 2. Umiejscowienie naglówka AH w pakiecie IP wersji 4 i 6 dla trybu transportowego.
* naglówki rozszerzone obecne jesli sa stosowane rozszerzenia
** naglówki rozszerzone moga znalezc sie przed, po lub po obu stronach naglówka AH
Jak widac na rys. 2 niektóre naglówki rozszerzonych IPv6 pojawiajac sie przed naglówkiem AH niektóre po nim. Wiaze sie to z rodzajem informacji jaka zawieraja naglówki rozszerzone oraz budowa IPv6.
W trybie tunelowanym z danego pakietu IP tworzony jest nowy pakiet w nastepujacy sposób: naglówek AH umieszczany jest przed naglówkiem IP danego pakietu, nastenie przed naglówkiem AH tworzony jest nowy naglówek IP. Opowiednio dla wersji 4 i wersji 6 IP umiejscowienie naglówka AH w trybie tunelowanym przedstawia ponizszy rysunek.
Rys. 3. Umiejscowienie naglówka AH w pakiecie IP wersji 4 i 6 dla trybu tunelowanego.
* naglówki rozszerzone obecne jesli sa stosowane rozszerzenia
4. Obliczanie wartosci uwierzytelniajacej
Algorytm uwierzytelnienia uzyty do obliczenia wartosc uwierzytelniajaca (ICV) dla danego pakietu IP jest okreslony przez polaczenie bezpieczenstwa (SA). Dla komunikacji punkt-punkt dobrymi rozwiazaniami sa Message Authentication Codes (MACs) oparte o symetryczne algorytmy szyfrowania (np. DES) lub o jednokierunkowe funkcje skrótu (np. MD5 lub SHA-1). Dla innych rodzajów komunikacji mozliwe jest stosowanie kombinacji jednokierunkowych funkcji skrótu z niesymetrycznymi algorytmani podpisu cyfrowego. Niestety to rozwiazanie zostalo wykluczone poniewaz znaczaco wplywa na pogorszenie efektywnosci ze wzgledu na wymagana duza moc obliczeniowa urzadzen. W zasadzie stosownaymi algorytmami sa MD5 lub SHA-1.
Wartosc uwierzytelniajaca oblicza sie z:
· pól naglówka IP, których wartosc nie zmienia sie w trakcie przesylania pakietu lub ich wartosc po wszystkich zmianach jest przewidywalna w momencie dotarcia do zakonczenia polaczenia bezpieczenstwa typu AH,
· pól naglowka AH, przy czym pole Authentication Data jest zerowane do obliczen,
· zawartosci pola danych pakietu IP, która przyjmuje sie za niezmienna w trakcie przesylania pakietu IP.
4.1. Obsluga pól zmiennych naglówka IP
Jesli wartosc pola moze zmieniac sie w trakcie przesylania pakietu IP, to wartosc tego pola przyjmowana jest do obliczenia ICV jako zero. Jesli wartosc pola moze zmieniac sie w trakcie przesylania pakietu IP i mozna ja przewidziec, to do obliczenia ICV przyjmuje sie jego przewidywana wartosc. Dzieki takiemu podejsciu uwzglednione sa dlugosci wszystkich pól a zatem i calego pakietu IP.
Ponizej przedstawione jest zestawienie pól naglówka IP (obu wersji) z zaznaczeniem jak dane pole jest traktowane przy obliczeniu wartosci ICV.
Polaniezmienneprzewidywalnie zmiennezerowaneIPv4Version Internet Header Len Total Len Identification Protocol Source Address Destination AddressType of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header ChecksumIPv6Version Payload Len Next Header Source Address, Destination Address* Destination Address**Class Flow Label Hop Limit* bez naglówka rozszerzonego,
** z naglówkiem rozszerzonym.
Bibliografia
[1] Skonieczny Józef J., "Aspekty bezpieczenstwa w sieciach opartych o TCP/IP cz. III", IT Security Magazine, numer 2(3)
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1700, October 1994
[3] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998
[4] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998
[1] Proste obliczenie: (96 + 96)/32 - 2 = 4.