[Openswan Users] Questions on how to check the "hash" payload

[Rolando Zappacosta]

Hi all,

	sorry for this question but I'm everything but an
expert on this stuff and I've some questions, three
actually:

1) Can someone tell me if the 52 bytes pointed here:
17:04:23 "Intranet" #1: Aggressive mode peer ID is
ID_IPV4_ADDR: '<Server's IP>'
17:04:23 | hashing 52 bytes of SA	<============== the
whole "Security Association" is 64 bytes (from a
traffic sniff)
17:04:23 | received HASH:  4b 2b 52 10  ac 68 84 b2 
b0 90 24 13  9b 7d f4 60
17:04:23 |   c6 9c cb 26
17:04:23 "Intranet" #1: received Hash Payload does not
match computed value
17:04:23 | complete state transition with (null)
17:04:23 "Intranet" #1: sending notification
INVALID_HASH_INFORMATION to <Server's IP>:500

are referencing these ones:
17:04:23 | ****parse ISAKMP Proposal Payload:
17:04:23 |    next payload type: ISAKMP_NEXT_NONE
17:04:23 |    length: 52	<==================== these,
what actually are for the "proposal payload"
17:04:23 |    proposal number: 0
17:04:23 |    protocol ID: PROTO_ISAKMP
17:04:23 |    SPI size: 8
17:04:23 |    number of transforms: 1
17:04:23 | parsing 8 raw bytes of ISAKMP Proposal
Payload into Oakley SPI
17:04:23 | Oakley SPI  9f 4d 14 3b  09 54 ff 73
17:04:23 | *****parse ISAKMP Transform Payload
(ISAKMP):
17:04:23 |    next payload type: ISAKMP_NEXT_NONE
17:04:23 |    length: 36
17:04:23 |    transform number: 0
17:04:23 |    transform ID: KEY_IKE
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_LIFE_TYPE
17:04:23 |    length/value: 1
17:04:23 |    [1 is OAKLEY_LIFE_SECONDS]
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_LIFE_DURATION (variable
length)
17:04:23 |    length/value: 4
17:04:23 |    long duration: 86400
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_ENCRYPTION_ALGORITHM
17:04:23 |    length/value: 5
17:04:23 |    [5 is OAKLEY_3DES_CBC]
17:04:23 | ike_alg_enc_ok(ealg=5,key_len=0):
blocksize=8, keyminlen=192, keydeflen=192,
keymaxlen=192, ret=1
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_HASH_ALGORITHM
17:04:23 |    length/value: 2
17:04:23 |    [2 is OAKLEY_SHA1]
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_AUTHENTICATION_METHOD
17:04:23 |    length/value: 1
17:04:23 |    [1 is OAKLEY_PRESHARED_KEY]
17:04:23 | started looking for secret for
!@#$%-><Server's IP> of kind PPK_PSK
17:04:23 | actually looking for secret for
!@#$%-><Server's IP> of kind PPK_PSK
17:04:23 | 1: compared PSK !@#$% to !@#$% / <Server's
IP> -> 4
17:04:23 | best_match 0>5 best=0x8108ae0 (line=1)
17:04:23 | concluding with best_match=5 best=0x8108ae0
(lineno=1)
17:04:23 | ******parse ISAKMP Oakley attribute:
17:04:23 |    af+type: OAKLEY_GROUP_DESCRIPTION
17:04:23 |    length/value: 2
17:04:23 |    [2 is OAKLEY_GROUP_MODP1024]
17:04:23 | Oakley Transform 0 accepted

2) Besides, as far as I could see on some documents
around on the web when a "Hash" payload is received,
the receiver should apply the agreed hash algorithm to
what is specified in the DOI and then compare its
value against the received one. Am I understanding
this properly?

3) If yes, and as I got:
17:04:23 | ***parse ISAKMP Security Association
Payload:
17:04:23 |    next payload type: ISAKMP_NEXT_KE
17:04:23 |    length: 64
17:04:23 |    DOI: ISAKMP_DOI_IPSEC
17:04:23 | np=4 and sd=0

doesn't it mean the hash algorithm should be applied
to the "Identification" payload instead?

All this is because I'm still getting an
INVALID_HASH_INFORMATION while trying to connect to a
Lucent Brick with the right PSK (I'm now more than
sure after checked it against the hex output of the
"Preshared Key" value of a pluto debug dump).


Thank you all in advance,
Rolando.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs