Re: OpenVPN

On Mon, Oct 07, 2002 at 08:15:22PM +0000, tho wrote:
> 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

Esattamente, ma il mio punto e': quanti utilizzano cose come
ssh per accedere al server che amministrano in una, due persone?
Dire la maggior parte. Per le VPN non so, ma immagino ci sia
tanta gente che e' interessata a connettere un po' di host assieme
e nulla di piu'.

> 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

sono d'accordo anche in questo caso. Per 'classica', che in effetti
non significa un cappero, intendevo dire 'piccola'.

[snip]
> > ksess1 = SHA1HMAC(masterkey, RAND1)
> > ksess2 = SHA1HMAC(masterkey, RAND2)
> > ksess3 = SHA1HMAC(masterkey, RAND3)
> > ...
> > ksessN = SHA1HMAC(masterkey, RANDN)
[snip]

> 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

piu' che vero, ma e' cosi' anche con PGP che e' pensato per
scambio di dati che hanno valore nel tempo, mentre non e'
cosi' per OpenSSH per cui la cifratura della sessione e'
piu' strumentale per garantire sicurezza in termini
applicativi che non strettamente crittografici.
Dunque... sembra come se attualmente e' dotato di perfect
forward secrecy chi non ne ha bisogno e vice-versa :)

Ma c'e' un modo 'simmetrico' per mitigare problema:
Nulla vieta di fare un 'update' della master key
ogni tanto, dopo che e' stata stabilita la cifratura
simmetrica del canale, sovrascrivendo fisicamente la
vecchia chiave. In questo modo e' virtualmente impossibile
recuperare una data master-key che ha generato una data
chiave di sessione, perche' non esiste piu'. Ovviamente
una volta in cui una master-key viene esposta, tutte le
successive sono nelle mani dell'attacker.

> 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

Tenendo la quadraticita' (purtroppo) si potrebbe utilizzare
DH solo nel mezzo della sessione cifrata per scambiare una
nuova master key. In questo modo si ottiene una maggiore
forward secrecy senza rinunciare allo schema 'parlo solo dopo
che mi provi di essere impossesso della master-key, poi decifro
tutto quello che arriva con la chiave di sessione senza curarmi'.

> 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) :-)

Questi dettagli devono essere sicuramente stabiliti con cura,
e sicuramente serve un HMAC magari troncato visto che
si parla sempre di modificabili-a-piacere-dall'attacker connessioni
TCP, cosi' come sequence-number e timestamp possono aiutare 
a prevenire alcuni problemi come giustamente da te osservato.

Ciao!
Salvatore

-- 
Salvatore Sanfilippo <antirez at invece dot org> s/at/@/ s/dot/\./
          finger antirez@tella.alicom.org for PGP key
      "Don't worry about what anybody else is going to do.
 The best way to predict the future is to invent it." (Alan Kay)

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