Re: One-way authentication

--===============0962532366==
Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>Come fa il client a sapere che il pacchetto =C3=A8 stato accettato se non
>c'=C3=A8 un ack?

Per garantire un acknowledgement devi per forza instaurare una connessione=
=20
diretta col server (mandare one-way packets a ritroso, dal client verso il=
=20
server, puo' non essere sempre fattibile, se il client e' NATtato, ad esemp=
io)=20
ma a questo punto infrangi il pricipio stesso del sistema che e' quello di =
non=20
lasciare socket in listening lato server. Cosa fai? Inibisci l'accesso TCP =
ad=20
SSHd (esempio piu' classico) per permetterlo a knockd? E' un controsenso.=
=20

>Cosa succede se ti estraggono un pacchetto e le due parti si
>desincronizzano?=20

Una finestra temporale di 2-3 secondi mi pare sufficiente per mettersi al=
=20
riparo da questo inconveniente. Il problema non e' tanto la sincronizzazion=
e=20
quanto il fatto che il sistema resta vulnerabile a MITM per tutto il tempo =
di=20
durata della finestra temporale (2-3 secondi, quindi). E' proprio per quest=
o=20
che chiedevo soluzioni alternative.
Il pk resta cmq sempre abbastanza un compromesso. In giro se ne trovano=20
diverse implementazioni: chi utilizza hash derivanti da valori temporali=20
variabili includendoli sotto forma di payload, chi al termine della sequenz=
a=20
apre un socket lato server per scambiarsi una chiave col client, chi non=20
effettua autenticazione basandosi sul solo valore della porta di destinazio=
ne,=20
ecc...

--===============0962532366==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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