pretazeno z pmwiki, pravdepodobne se spatne renderuje

IETF 68th Meeting

* Prague, 2007, Hotel Hilton * 19. - 23. 3. 2007 * … mel sem se fajne ;) … * http://www3.ietf.org/meetings/68-IETF.html

* {-krb generally rfc4120.txt-} * ghost ??? * iakerb ???? * kerb fast vs. startls - larry zhou, Sam Hartman * {-gss-api-} * threath models … * cram, digest-md5 i kdyz ho nikdo nepouziva * scram * channel binding (nico williams) * ULP, ESP, AH, SPD ? some IPsec stuff * krb preautentizace

oboje jsou “kontrolni soucty”, ktere jsou nakonec zasifrovane nejakym heslem (zpravidla symetricky) slouzi k overeni pravosti a nezmenenosti zpravy po ceste mezi odesilatelem a prijemcem. rekl bych ze H znemoznuje utok na danou symetrickou sifru.

standardizovana specifikace API rozhrani pro autentizacni ukony zleva uzivana aplikacemi a zprava vyvojari/implementatory autentizacnich mechanismu

  • co je to: “TLS vs. SASL”
  • co je to: EAP, EAP vs. TLS?;)) .. PEAP …
  • co je to: preauthentication - preautentizace

* Larry Zhu * Jeffrey Hutzelman * Sam Hartman * Nico Williams

prndeli

stredne zlutej pes.

=JeffH chodi na meetingy oblecenej normalne jako ja do prace akorat bez ponozek ;)

“IETF Meeting” neni konference, je to setkani lidi, kteri pracuji na standartech/RFC pomoci mailing listu. Meetingy jsou pomuckou jak si najit nejake kolegy a upresnit si s nimi nazory a myslenky rychleji nezli psanim. Je to hodne o soušl iventu. Najdou se zde zastupci jednotlivych firem a skupin, ktere dane tema pouzivaji. Pokud clovek na nejakou WG jde, muze se dozvedet co se v nejblizsi dobe v dane oblasti upece, nicmene z prime diskuse nic nevytezi pokud nezna soucasna temata diskuse v mailech nebo necetl propirane dokumenty.

Zajimave bylo prime zprcani =Jeff(a)H od predsedy krb-wg za lehke invektivy na stranu zastupce Microsoftu (asiata s prisernou vyslovnosti nicmene ti zbyli 2 recnici mu rozumeli dost dobre) s tim ze MS prispiva do WG docela otevrene a hodne takze se tu zadny napadani trpet nebudou … Mozna tak vyjel spis proto ze v sale sedelo asi 30 lidi, ale ti co znali problematiku byli 3 ;)

Posledni zajimavosti prndeli bylo, ze kazda WG ma na meetingu svoji jabber room,kam se prepisuji hrube myslenky o cem se jedna a audiostream prispivajicich recniku.

utery

malo kafibrku ;)

no na TLS sem sice tusil o co se jedna nicmene moderator .. um .. mluvil ..um.. tak pekelne ..um.. ze nechapu ..um.. ze ..um. siumelobjednatbyt..um..jen kafe..um

no asi nejvyznamejsi skupinoou byla krb-wg jak jinak. Pekne nam diskutoval tlustej predseda JeffryH se slepym SamemH s hezkym NicemX a asijskym LarrymZ z Microsoftu ;) .. vysledkem bude zrejme nejaka dohoda o sifrovani komunikace mezi klientem a KDC a snad se dohodnou i na standartu s MS. zrejme se i dockame HW preautentizace ale o te se v zasade stejne nehovorilo …

dohadovani o polickach v certifikatech moc zajimave nebylo, ale aspon sem si rozbehal acpi_sleep na T43 ;)))

streda a ctvrtek

zrovna nic moc zajimaveho, nicmene sem nasel E&A, rekl bych ze celkem pobral, a vecer sme meli jednu stihu za druhou. Nejdrif cajti a potom cernej pes ..

#### Athena a Euripides

* http://web.mit.edu/Kerberos/dialogue.html * http://www.faqs.org/faqs/kerberos-faq/general/index.html

* resi vzajemne overeni/prokazani identity 2 principlu (ucastniku|(uzivatel,sluzba)) pomoci 'symetricke kryptografie'. To 'za pomoci duveryhodne 3ti strany', ktere veri oba subj. a spolecnych tajemstvi Ksvc(svc,KDC) a Kc(c,KDC)

* resi zabezpeceni proti odposlechu neposilanim techto tajemstvi po dratech pri procesu autentizace

* zabranuje replay utoku a podvrzeni identity zachycenim prenasenych dat

  • dale pripravi vzajemne sdilene tajemstvi pouzite pro dokonceni autentizace a zabezpeceni dalsi komunikace mezi subj.

    0) terminology K_c := hash(passwd) TKT := {u,svc,ip,time,SK}K_svc AUT := {u,ip,one-time,X}SK cred := SK,TKT,svc,u,ip

    1) obtaining service ticket and session key c -> kdc: u,ip,svc V5: some preauth cause of offline dict attack do K_(c|svc) kdc -> c: {TKT, SK}K_c >>> TKT can't be stolen on the wire V5: TKT,{SK}K_c
    2) mutual authentication by the ticket c generates one-time AUT c -> svc: TKT, AUT svc: - decrypting TKT => SK - decrypting AUT prooves that he's who he caims to be and that he's a legitimate owner of the ticket (SK was given to him only by KDC) - use of AUT cache prevents replay svc -> c: { Y=X+1 [, TKT1] }SK c: Y-1=X => auth server

co je to: S/KEY

* metoda autentizace uzivatele pomoci jednorazoveho hesla vyuzivajici 'sily jednosmernych hash funkci' * neresi problem MIM, auth neni vzajemna, uzivatel nevi jestli posila data spravnemu serveru « zarucuje se pouzitim certifikatu

* predpripravi se data pro budouci pouziti

`init -> H(init) = p_1 -> H(H(w)) = p_2 -> ... -> H^n(W) = p_n`

* uzivatel dostane: p_n, p_(n-1) ... p_1 * server si necha pouze: pn * init nesmi byt prozrazeno * k overeni se pouzije draha znalost p(n-1) ze strany uzivatele. Spocitat H(p(n-1)) = pn je levne .. spocitat H^-1(pn) = p(n-1) je pro utocnika drahe

  • uzivatel tedy posle p(n-1) * server overi ze H(p(n-1)) = pn; potom ulozi p(n-1) jako nove heslo

co je to:Diffie-Hellmans?

* protokol/technika pro ustaveni bezpecneho komunikacniho kanalu (“bezpecnym” generovanim sdileneho tajemstvi/klice) mezi 2ma subjekty (nikoliv autentizace nektere ze stran ⇒ neresi MIM) 0) Y = g^x mod p 1) K = A^b mod p = (g^a mod p)^b mod p = (g^ab mod p) mod p = (g^b mod p)^a mod p = B^a mod p DK) g^(a*b) = (g^a)^b != g^(a+b) || g^a*g^b

a,b jsou tajemstvi p,g jsou zakladem soustavy ??? K je vysledny sdileny klic A,B jsou verejne casti klicovych parecku

  • ??he?? – asociativita umocnovani umozni vymenu struhly na ktere je po celou dobu privesen alespon jeden zamek a vypocet spravne odmocniny je omezen modulem p ?? .. resp. rozsekani prostoru do nekolika intervalu ze kterych si dost dobre nejde vybrat (dostatecne rychle) pokud budou p,a,b dostatecne velike? – ?he?
  • {-ve skutecnosti se metoda opira o problem 'vypoctu diskretniho logaritmu Y vzhledem k modulu p' (viz. [0]), kde DL je cislo x ktere neni diky modulu jednoznacne urceno -}
  • zakladem uspechu algoritmu je vhodne voleni cisel g a p
  • na tomto principu [0] je zalozena sifra RSA (ktera ale uziva narocnosti rozkladu na prvocisla;he? moc nechapu zatim rozdil s DH ;( ) a DSA, ktera zase nekde uprostred zamestnava hashovaci fci. [0] je zakladem vsech asymetrickych sifrovacich mechanismu.

co je to: SSH protokol?

* DH + auth?

#### co je to: SRP? * protokol pro prokazani identity uzivatele za pomoci zero-knowledge dukazu * zaroven ustavi mezi subjekty sdilene tajemstvi kterym muzou zabezpecit dalsi komunikaci * stoji to na DH a jeste se tam ruzne delaji dalsi sachymace pri vymene zprav a by byla zarucena lepsi bezpecnost a vetsi rychlost

co je to: challenge-response

jsou to metody autentizace, kdy dochazi prokazani znalosti urciteho hesla pomoci vyzvy a vypocitani spravne odpovedi (na zaklade zname vypocetni fce/algoritmu). Ve vypoctu obvykle figuruje heslo. Utocnik muze nicmene pouzit utok typu slovnik ci hrubou silu. Heslo se neprenasi

co je to: problem batohu

do batohu dame x zavazi, ktere ma kazde jinou hmotnost a potom se snazime zpetne urcit ktera zavazi jsme tam dali » problem neni jednoznacne resitelny * http://cs.wikipedia.org/wiki/Probl%C3%A9m_batohu vektor x = [x1, x2, .. xn], mnozina A e (a1, a2, .. an) M = x1a1 + x2a2 + .. xnan

Orákulum

http://crypto-world.info/klima/2005/ST_2005_07_14_15.pdf

Z hlediska bezpecnosti bychom byli rádi, kdyby se hasovaci funkce chovala jako náhodné orákulum, tj. stroj, ktery na novy vstup odpovídá náhodnym vyberem z mnoziny moznych vystupu (jeden vystup se tedy muze i opakovat), pricemz na tentyz (stary, opakovany) vstup odpovídá tímtz vystupem. I kdyz z teoretického hlediska nejsou hasovací funkce náhodná orákula, prakticky se tak jeví. Kazdá zmena, byt i jednoho bitu na vstupu, má za následek nepredikovatelnou náhodnou zmenu vsech bitu na výstupu s pravdepodobností 1/2. A naopak jakákoliv zmena na vystupu by mela vést k nepredikovatelné a náhodné zmene na vstupu (vstupech).

  • oldstuff/ietf68.txt
  • Last modified: 2018/09/01 13:01
  • by bodik