IPSec za NAT [trosicku delsi ;o)]

[Pavel Janoušek]

> -----Original Message-----
> From: Pavel Kankovsky [mailto:peak na argo.troja.mff.cuni.cz] 
> Co myslite tim "od zacatku duveryhodny"? Pokud se tim mysli, 
> ze uz prvni
> paket, co jde po siti, je sifrovany a podepsany, pak to opravdu u SSL
> dosahnout nelze (pomineme-li to TCP pod tim, tak aspon musi probehnout

	Ano, priznam se a zaroven omlouvam, ze pokud nejsem schopen pouzit odpovidajici technicky termin, nez pouzit nejaky, o kterem presne neznam jeho vyznamove pojeti, radsi pouziji cesky opis, ktery vyjadruje (pokud mozno presne) to same...

	Myslel jsem tim skutecne to, ze u IPsecu mam moznost jinou cestou (coz muze a nemusi byt bezpecnejsi, ale to uz je otazka "implementace") dostat na obe strany potrebna prerekvizita, u SSL/TLS to nemam, protoze je to vlastnost.

> klicu and "it just doesn't scale up". Pokud vezmete IPSec + 
> ISAKMP nebo
> jakykoli jiny protokol zajistujici vymenu klicu za chodu, tak to vyjde
> v principu nastejno.

	Ano, ale nic mne nenuti pouzit tento zpusob.

> Tedy jiny problem take je, jestli je ta duveryhodnost protazena az do
> aplikacni urovne nebo nejlepe az k uzivateli. U IPSecu, je-li pouzivan

	Protazeni bezpecnosti az na aplikacni uroven ma samozrejme sve pro a proti (pak ale uz nema smysl se bavit o vecech jako AH protokol apod., ktery prave vyuziji zejmena u tunelovaneho prenosu nehostinnym prostredim), na druhou stranu zde jsem se bavil zejmena o tunelovani...

> Jestli myslite tu variaci Bleichenbacherova utoku (a nechapu, 
> proc davate 
> slovo nasli do zavorky), pak mate pravdu, ze chyba je 

	Ty uvozovky tam byly zamerne z duvodu, ze je to jiz variace (ja tu algebru vazne nemel nikdy rad a tak nektere nadhozene pojmy jsou pro mne skoro nadavkou, opravdu nejsem sifrovaci teoretik...:-))) na drivejsi vlastnosti systemu trochu dale rozvinute (cimz samozrejme p. Klimovi & spol. neupiram jeho zasluhy za to, ze se to konecne zacalo implementacne resit (OpenSSL) a neskoncilo to v urovni akademicke debaty... - jejich zpravu jsem si vsak byl schopen precist v originale a zaver jsem vyvodil)

> Je docela dobre mozne, ze ISAKMP ma podobny problem (a ze je 
> ho take treba
> spravne implementacne osetrit), jediny rozdil je, ze ISAKMP preferuje

	Ano, ale ISAKMP v principu nepotrebuji, jake jine moznosti, abych to desifrovaci orakulum nemel in natura v systemu, mam v pripade SSL/TLS - nevhodny time-sensitivity attack je jen jedna moznost...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------