[Openswan Users] Hash payload place for agressive mode

[Rolando Zappacosta]

Hi all,

Yet another theory to (possibly) explain why I can't
connect to a Lucent VPN Gateway from my OpenSwan
client.

I'm getting always INVALID_HASH_INFORMATION complains
from pluto and I could see, between other interesting
things, that the server (the Lucent's gateway) is
sending me back this ISAKMP packet after mine (the
first one):

Internet Security Association and Key Management
Protocol
    Initiator cookie: F4B16542588CA2AE
    Responder cookie: 30DB5E384EBAA6E3
    Next payload: Security Association (1)
    Version: 1.0
    Exchange type: Aggressive (4)
    Flags: 0x00
        .... ...0 = Not encrypted
        .... ..0. = No commit
        .... .0.. = No authentication
    Message ID: 0x00000000
    Length: 308
    Security Association payload
        Next payload: Key Exchange (4)
        Payload length: 64
        Domain of interpretation: IPSEC (1)
        Situation: IDENTITY (1)
        Proposal payload # 1
            Next payload: NONE (0)
            Payload length: 52
            Proposal number: 1
            Protocol ID: ISAKMP (1)
            SPI Size: 8
            Proposal transforms: 1
            SPI: 0x30DB5E384EBAA6E3
            Transform payload # 4
                Next payload: NONE (0)
                Payload length: 36
                Transform number: 4
                Transform ID: KEY_IKE (1)
                Encryption-Algorithm (1): 3DES-CBC (5)
                Hash-Algorithm (2): SHA (2)
                Authentication-Method (3): PSK (1)
                Group-Description (4): Alternate
1024-bit MODP group (2)
                Life-Type (11): Seconds (1)
                Life-Duration (12): Duration-Value
(864000)
    Key Exchange payload
        Next payload: Nonce (10)
        Payload length: 132
        Key Exchange Data (128 bytes / 1024 bits)
    Nonce payload
        Next payload: Identification (5)
        Payload length: 20
        Nonce Data
    Identification payload
        Next payload: Hash (8)
        Payload length: 12
        ID type: 1
        ID type: IPV4_ADDR (1)
        Protocol ID: Unused
        Port: Unused
        Identification data: <IPsecSERVER-IP>
    Hash payload
        Next payload: Vendor ID (13)
        Payload length: 24
        Hash Data
    Vendor ID:
4C5647392E312E3235353A425249434B3A392E312E323535
        Next payload: NONE (0)
        Payload length: 28
        Vendor ID:
4C5647392E312E3235353A425249434B3A392E312E323535

and I read the order in above packet should be:
ISAKMP header + hash payload + SA payload
and this is not the case here.

Could be Openswan is assuming the first payload is the
hash, while it's actually not, and checking it against
another one instead (the Security Association or the
Key Exchange in this case)?

Kind regards,
Rolando.



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping