Martin, Thanks for the reply. I actually did not make any changes to the IKE_SA_INIT packet, I only changed the reserved fields in the IKE_AUTH message.
Jamie Knight (rjkni...@us.ibm.com) IBM Power Firmware Development (512) 286-7017 (t/l 386-7017) office 045/2A-01 IBM Austin, TX From: Martin Willi <mar...@strongswan.org> To: Richard Knight/Austin/i...@ibmus Cc: users@lists.strongswan.org Date: 06/29/2010 02:53 AM Subject: Re: [strongSwan] non-zero reserved fields in IKE_AUTH response. Hi Richard, > Could someone point me to where the calculation would start and end in the > message below? Start with the IKE_SA SPIs of the IKE_SA_INIT (_not_ the IKE_AUTH seen here!): > | | | IKE_SA Initiator's SPI = c3dfaad709d6bd4b > | | | IKE_SA Responder's SPI = fd546d59933dbe69 > | | | Next Payload = 46 (E) > | | | Major Version = 2 > | | | Minor Version = 0 > | | | Exchange Type = 35 (IKE_AUTH) > | | | Flags = 73 (0b01001001) > | | | | Reserved (XX000000) = 64 > | | | | Response (00R00000) = 0 > | | | | Version (000V0000) = 0 > | | | | Initiator (0000I000) = 1 > | | | | Reserved (00000XXX) = 1 And include all further bytes of the message. Append the nonce of the other IKE_SA_INIT packet, and prf(Sk_px, IDx'). > 09[IKE] authentication of '2001:db8:1:1::1234' (myself) with pre-shared key > 09[IKE] octets = message + nonce + prf(Sk_px, IDx') => 342 bytes @ 0x100636b0 > 09[IKE] 0: CF B9 0A AB 05 DB A9 95 C7 FE 12 99 E1 E9 AD B7 ................ > 09[IKE] 16: 21 20 22 20 0x22 is IKE_SA_INIT, starting with a SECURITY_ASSOCIATION payload (0x21). Flags is 0x20, meaning the responder flag is set only. Did you set other reserved flags in the IKE_SA_INIT message? Regards Martin _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users