[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Win2000 IKE and 3des
Dear Sami,
I noticed the same. Agree it is sloppy but to solve this I read somewhere
that you have to install the high encryption pack and in the Netherlands you
have to fill in some form.
I haven't done that so far since I feel that DES is safe enough if you are
changing the key more often. However this does have impact on performance of
course.
thx
Michel
-----Oorspronkelijk bericht-----
Van: Sami Vaarala [mailto:sami.vaarala@netseal.com]
Verzonden: Wednesday, May 10, 2000 5:37 PM
Aan: ipsec@lists.tislabs.com; sami.vaarala@netseal.com
Onderwerp: Win2000 IKE and 3des
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.vaarala@netseal.com)
NetSeal Technologies
http://www.netseal.com/
Follow-Ups: