Re: OpenVPN

antirez wrote:
> Qual'e' il problema a fare il rekey con la crittografia simmetrica?
> Client e Server condividono un segreto da cui generano nuove
> chiavi per ogni sessione e dopo ogni tot di byte/tempo, usando
> qualcosa di pseudo-random per fare session_key=HMAC(secret,random).

in effetti nessuno, esistono schemi di key agreement/transport
simmetrici che fanno il loro mestiere egregiamente

ma se non sei disposto a tollerare una TTP che triangola la
distribuzione delle chiavi (a la kerberos per capirci) fra i peer
allora il problema diventa la scalabilita'

in effetti sei costretto ad avere una chiave (un master secret)
per ogni peer col quale intendi comunicare

se invece usi un meccanismo di key agreement asimmetrico
la chiave di sessione la generi alla bisogna, poi te la dimentichi

e direi che cosi' scala molto meglio

per tornare dove eravamo partiti (vpn) gli scenari variano molto ma
agli estremi ci stanno da una parte gli n (con n grande a piacere)
roaming users che si collegano alla sede e dall'altra due black box che
parlano solo tra di loro

se decidi che il tuo scenario e' (concettualmente) piu' vicino
alle due black box puoi anche fare a meno di diffie-hellman e
ottenere quello che hai bisogno con uno schema semplice di key
pre-distribution

per riprendere quello che dicevi:
> Per alcune applicazioni puo' essere utile, ma ... io non capisco
> che utilita' possa avere IKE in ambito VPN classica.
direi che il problema e' che non esiste il concetto di "vpn classica"
e tanta dell'ipertrofia di IKE dipeda proprio dal non avere
identificato il modello di vpn dal quale derivare i requisiti


> Secondo me uno schema in cui c'e' un segreto per ogni diverso
> client nel keyring del server, e in ogni diverso client, e'
> ragionevole in un sacco di casi. E' possibile tagliare fuori
> i client togliendo la loro chiave nel keyring. Il segreto
> non viene mai esposto direttamente, passa sempre per una
> funzione ad una via in cui si mescola a qualcosa di casuale
> che passa in chiaro. Anche se SHA1 avesse dei problemi non
> conosciuti, non mi sembra banale ottenere masterkey se si
> parte dal seguente schema:
>
> ksess1 = SHA1HMAC(masterkey, RAND1)
> ksess2 = SHA1HMAC(masterkey, RAND2)
> ksess3 = SHA1HMAC(masterkey, RAND3)
> ...
> ksessN = SHA1HMAC(masterkey, RANDN)
>
> L'attacker conosce solo RAND1,RAND2,RAND3, ..., RANDN,
> e possiede del ciphertext cifrato con ksess1, ksess2, ... e cosi'
> via. Da quel che ne so, masterkey e' assolutamente al sicuro
> persino se il block cipher utilizzato per cifrare e' assolutamente
> insicuro.

a uno schema del genere manca perfect forward secrecy:
se a un certo istante masterkey fosse compromessa (ad
esempio per incuria), immediatamente sarebbero compromesse
anche le {ksess_i}i=1..N

e questo puo' essere piuttosto grave (tendenzialmente piu' grave
di un known-key attack)

se usi diffie-hellman, che puro e semplice ha un livello di
complessita' paragonabile, pfs viene gratis e lo storage richiesto
e' lineare con il numero di partecipanti invece che quadratico

in piu' conviene mettere un sequence number da qualche parte nel
pacchetto di key update e di MACcare pure lui per evitare che
un replay mandi fuori sincrono il client (ma questo solo per
rendere facile il check perche' dovrebbe essere abbastanza
improbabile che RAND_i == RAND_j e i != j) :-)


ciao, tho
--

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List