Newsgroup: it.comp.reti.ip-admin
Titolo: [lunghetto] Win2k IPSEC Des/3Des 'Feature' ne avete gia' discusso?

OKKIO a IPSec in WIN2K versione non USA:
Sintetizzo la questione e scusate la superficialita' con cui approccero' la
questione (spero inoltre di non sbagliare nulla):
* due windows 2k in versione non USA dunque disponibile per l'export e
'castrata' opportunamente (la legge americana prima di Febbraio 2000
imponeva serie limitazioni all'esportazione di tecnologie crittografiche).
* un amministratore che essendosi studiato lo standard IPsec ipotizza che
decidendo tra due scelte i computer si comportino diversamente:
1a scelta - una security policy (per la comunicazione tra i due Win2k) che
impone alle due macchine di contrattare per la cifratura un algoritmo 3DES
se possibile, altrimenti un DES semplice, altrimenti desistere e non
acconsentire alla comunicazione. Policy identica sulle due macchine!
2a scelta - una security policy (per la comunicazione tra i due Win2k) che
impone alle due macchine di contrattare per la cifratura un algoritmo 3DES
se possibile, altrimenti desistere e non acconsentire alla comunicazione.
Policy identica sulle due macchine!
Risultato:
Nel secondo caso un'amministratore attento vedrebbe nei LOG traccia di un
warning che lo avverte di una cosa alquanto strana: la contrattazione su un
3DES non e' andata a buon fine e le macchine hanno convenuto per utilizzare
un DES.
Spiegazione:
Le versioni esportate dall'america (a meno di non installare lo strong
encription pack) non supportano il 3Des e sono programmate volutamente per
contrattare un DES notificando la cosa nei LOG.
Giustificazione di Microsoft (nel senso che ammettono di aver fatto la
scelta by design)che spero aver interpretato bene:
Stante il fatto che le policy possono essere decise centralmente e
distribuite sui vari client e server dei domini senza avere la piu' pallida
idea se quel determinato win2k e' una versione export o una Usa, piuttosto
che rendere impossibile la comunicazione con macchine configurate per il
solo 3DES si e' preferito alleggerire il vincolo ritenendolo meglio di
niente.
Il moderatore tagli se vuole, ma qui un bel 'e non era meglio che lo
decideva l'admin una cosa del genere?' ci vuole proprio! Tacciatemi pure di
sarcasmo stupido e inproduttivo.
Ora io non ho ancora trovato il tempo di fare delle prove, pero' immagino
che la cosa ponga non pochi problemi di interoperabilita' al livello di
sicurezza: tanto per dirne una immagino che configurando un dialogo IPsec
tra un Win2k (export version) ed un gateway IPSec con 3Des/Des/Abort lato
gateway e 3Des/Abort lato win2k potremmo anche vedere un Des contrattato.
Riporto solo (scusate lo spreco di Kbyte ed il moderatore tagli liberamente
in caso lo ritenga opportuno):
la mail che ha aperto il dibattito con la segnalazione
una delle risposte da parte di Microsoft in cui si giustifica la scelta
fatta
un link ad un articolo su wired al riguardo.
Fabio (Zed) Zamparelli
GRID 
http://www.grid.unina.it
Gruppo di Ricerca sull'Informatica Distribuita
Research Group on Distributed Systems
Universita' Federico II di Napoli - ITALY
**************************************************
Hi,
Upon playing with Win2000 IPsec/IKE, I configured an IKE phase 2 policy
that required one of the following ESP transforms:
   3des + hmac-sha-1 auth,  kb lifetime 100001, sec lifetime 900
   3des + hmac-md5 auth,    kb lifetime 100002, sec lifetime 900
   [the lifetimes are set this way to identify the transforms at the
    other end]
All is well and good, but the remote IKE end receives this offer *with
3des transforms changed into des*!  Is this Windows' way of achieving
exportability (by silently manipulating configuration)?  Or is there
something I missed?
From an administrator perspective, it is hard to imagine how a security
hole could be worse: Windows lets you think all is OK but in reality
something else happens on the wire.
I'd appreciate it if anyone could verify this behavior; I suspect I've
gotten something wrong.  Win2000 version in 5.00.2195, and it should be
the exportable version.
-- For info, dump of the QM1 packet:
RAW PACKET (decrypted QM1):
dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9
08 10 20 01 4c 2f 52 23 00 00 00 cc 01 00 00 14
ba 41 8a c4 2a da bd 9c 9d 0d 29 f9 a7 17 f4 d1
0a 00 00 68 00 00 00 01 00 00 00 01 00 00 00 5c
01 03 04 02 f3 8c e3 e7 03 00 00 28 01 02 00 00
80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02
00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02
00 00 00 28 02 02 00 00 80 01 00 01 00 02 00 04
00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a2
80 04 00 02 80 05 00 01 05 00 00 18 70 e3 bf 52
26 38 2a bb a3 5c b0 1f 25 0a 97 8e c7 28 7b 24
05 00 00 0c 01 00 00 00 c0 a8 02 c6 00 00 00 0c
01 00 00 00 c0 a8 02 c7 00 00 00 00
INTERPRETATION:
---------------
*HDR*
dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9
08 10 20 01 4c 2f 52 23 00 00 00 cc
*HASH*
01 00 00 14 ba 41 8a c4 2a da bd 9c 9d 0d 29 f9
a7 17 f4 d1
*SA*
0a 00 00 68 00 00 00 01 00 00 00 01 doi=ipsec, sit=identity only
00 00 00 5c 01 03 04 02 prop #1, len 0x5c, proto=3 (esp),
                        spi_size=4, #tran=2
f3 8c e3 e7             spi 0xf38ce3e7
03 00 00 28 01 02 00 00 tran #1, len 0x28, tran-id=2 (des)
80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02
00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02
    attribs: 0001=0001       sa life type: seconds
             0002=00000384   sa life dur.: 900 (dec)
             0001=0002       sa life type: kilobytes
             0002=000186a1   sa life dur.: 100001 (dec)
             0004=0002       encaps. mode: transport
             0005=0002       auth. alg   : hmac-sha
00 00 00 28 02 02 00 00 tran #2, len 0x28, tran-id=2 (des)
80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02
00 02 00 04 00 01 86 a2 80 04 00 02 80 05 00 01
    attribs: 0001=0001       sa life type: seconds
             0002=00000384   sa life dur.: 900 (dec)
             0001=0002       sa life type: kilobytes
             0002=000186a2   sa life dur.: 100002 (dec)
             0004=0002       encaps. mode: transport
             0005=0001       auth. alg   : hmac-md5
*NONCE*
05 00 00 18 70 e3 bf 52 26 38 2a bb a3 5c b0 1f
25 0a 97 8e c7 28 7b 24
*ID*
05 00 00 0c 01 00 00 00 c0 a8 02 c6
*ID*
00 00 00 0c 01 00 00 00 c0 a8 02 c7
*PADDING*
00 00 00 00
--
Sami Vaarala (
sami.v...@netseal.com
)
NetSeal Technologies
http://www.netseal.com/
**************************************************
Just to clarify the behaviour of Windows 2000 -
Windows 2000 weakens 3DES policy to DES if you do not have the strong
encryption pack (128-bit) installed. This weakening is announced by an event
in the Audit log. So if you have 2 peers with no encryption pack installed,
and a policy to use 3DES, they will talk DES since they cannot do 3DES.
However if one of the peers has high encryption pack installed and his
policy has 3DES only, then he will not accept DES from the other peer and
the negotiation will fail.
For dometic versions you can install the strong crypto pack for doing 3DES
from
http://www.microsoft.com/windows2000/downloads/recommended/encryption/defaul
t.asp
Sumi.(Microsoft)
**************************************************
Envision you are running a world-wide corporation where domain-based
policies are assigned to clients at different sites at different counties.
Some of them run the export version of Win2K.  Since it is near impossible
to know what version of Win2K clients are running, so all clients policies
are set to use 3DES.  On the corp-side, some servers will be configured to
accept 3DES only and others both DES and 3DES.  If you don't weaken 3DES on
the export clients, there is no way to talk to servers with DES configured.
Having said that, the report mechanism should probably be improved and we
will address this in the next release.
--Chun(Microsoft)
**************************************************
Articolo su Wired:
http://www.wired.com/news/technology/0,1282,36336,00.html

Nel post in un paio di punti parlo di un famigerato moderatore, e' solo che
ho fatto un quasi taglia incolla del mio post da una mail spedita in
teach-sicurezza, sorry ;-)
--
Ciao, Fabio Zed Zamparelli

 OKKIO a IPSec in WIN2K versione non USA:
Scusa... ma checcifrega ? Sei abbondantemente OT...
-- 
 Daniele
-------------------------------------------------------------------------------
 Daniele Orlandi - Utility Line Italia - 
http://www.orlandi.com
 Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------

  Daniele


 postare su questo NG riguardo IPSec.
Non e' IPSec il problema. Il fatto e' che il problema non riguarda il
protocollo, ma un'implementazione che tra l'altro e' propria di una sola
marca/release di S/O. Riguarda piu' un newsgroup sulla sicurezza...
