#58 ISAKMP delete notifications processed incorrectly

0.6 branch
closed
nobody
5
2009-01-16
2007-01-26
Uncle Pedro
No

Below is a log showing the incorrect processing of an ISAKMP delete notification (this delete notification is for an IKE SA).
An IKE delete notification has 2 sets of initiator and responder cookies:
1) One in the ISAKMP header.
2) One in the SPI field of the delete payload.

Currently, the cookies in the ISAKMP header are being used to find which IKE SA to delete, which works as long as the 2 sets of cookies match. But if a delete notification is encrypted with a different IKE SA than what was deleted on the sender's side, then the wrong IKE SA is deleted on the receiving side. (Remember what is says in RFC 2408: "The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail.")

Here is the log that shows the improper processing:
There are 2 IKE SAs referenced in this log:
1) The "old" SA, which has I-cookie:R-cookie
7a93f5745e59b54b:de1bc56c18efa0c1
2) The "new" SA, which has I-cookie:R-cookie
bb009b00744e7f86:d20de3713e1aea22

It is clearly seen by this debug message:
2007-01-26 09:35:03: DEBUG:
bb009b00 744e7f86 d20de371 3e1aea22 08100501 1c6ba8fd 0000004c 0c000014 08238e07 efeef609 43aaa35a fef4e679 0000001c 00000001 01100001 7a93f574 5e59b54b de1bc56c 18efa0c1
That the cookies in the header correspond to SA(2), while the cookies in the SPI field correspond to SA(1).
This means that SA(2) should be used to decrypt the message (which it is) and that SA(1) should be deleted as a result (which it is not). Instead, SA(2) is deleted, which is incorrect.
2007-01-26 09:35:03: INFO: purging ISAKMP-SA spi=bb009b00744e7f86:d20de3713e1aea22.
2007-01-26 09:35:03: DEBUG: call pfkey_send_dump
2007-01-26 09:35:03: INFO: purged ISAKMP-SA spi=bb009b00744e7f86:d20de3713e1aea22.
2007-01-26 09:35:03: DEBUG: purged SAs.
2007-01-26 09:35:04: INFO: ISAKMP-SA deleted 30.0.0.104[500]-30.0.0.101[500] spi:bb009b00744e7f86:d20de3713e1aea22

<--Begin log-->

2007-01-26 09:35:03: DEBUG: ===
2007-01-26 09:35:03: DEBUG: 76 bytes message received from 30.0.0.101[500] to 30.0.0.104[500]
2007-01-26 09:35:03: DEBUG:
bb009b00 744e7f86 d20de371 3e1aea22 08100501 1c6ba8fd 0000004c 8337561b
ef24ced3 16c7d74a 480a570c 64f9701f 986bf43f e3e33924 c98d01e6 d7e843f8
e2d30897 3abe1467 d497207d
2007-01-26 09:35:03: DEBUG: receive Information.
2007-01-26 09:35:03: DEBUG: compute IV for phase2
2007-01-26 09:35:03: DEBUG: phase1 last IV:
2007-01-26 09:35:03: DEBUG:
f90bd881 ae30bac8 1c6ba8fd
2007-01-26 09:35:03: DEBUG: hash(md5)
2007-01-26 09:35:03: DEBUG: encryption(des)
2007-01-26 09:35:03: DEBUG: phase2 IV computed:
2007-01-26 09:35:03: DEBUG:
b19f8e5f cb1dec76
2007-01-26 09:35:03: DEBUG: begin decryption.
2007-01-26 09:35:03: DEBUG: encryption(des)
2007-01-26 09:35:03: DEBUG: IV was saved for next processing:
2007-01-26 09:35:03: DEBUG:
3abe1467 d497207d
2007-01-26 09:35:03: DEBUG: encryption(des)
2007-01-26 09:35:03: DEBUG: with key:
2007-01-26 09:35:03: DEBUG:
df49552d ed28dae5
2007-01-26 09:35:03: DEBUG: decrypted payload by IV:
2007-01-26 09:35:03: DEBUG:
b19f8e5f cb1dec76
2007-01-26 09:35:03: DEBUG: decrypted payload, but not trimed.
2007-01-26 09:35:03: DEBUG:
0c000014 08238e07 efeef609 43aaa35a fef4e679 0000001c 00000001 01100001
7a93f574 5e59b54b de1bc56c 18efa0c1
2007-01-26 09:35:03: DEBUG: padding len=194
2007-01-26 09:35:03: DEBUG: skip to trim padding.
2007-01-26 09:35:03: DEBUG: decrypted.
2007-01-26 09:35:03: DEBUG:
bb009b00 744e7f86 d20de371 3e1aea22 08100501 1c6ba8fd 0000004c 0c000014 08238e07 efeef609 43aaa35a fef4e679 0000001c 00000001 01100001 7a93f574 5e59b54b de1bc56c 18efa0c1
2007-01-26 09:35:03: DEBUG: HASH with:
2007-01-26 09:35:03: DEBUG:
1c6ba8fd 0000001c 00000001 01100001 7a93f574 5e59b54b de1bc56c 18efa0c1
2007-01-26 09:35:03: DEBUG: hmac(hmac_md5)
2007-01-26 09:35:03: DEBUG: HASH computed:
2007-01-26 09:35:03: DEBUG:
08238e07 efeef609 43aaa35a fef4e679
2007-01-26 09:35:03: DEBUG: hash validated.
2007-01-26 09:35:03: DEBUG: begin.
2007-01-26 09:35:03: DEBUG: seen nptype=8(hash)
2007-01-26 09:35:03: DEBUG: seen nptype=12(delete)
2007-01-26 09:35:03: DEBUG: succeed.
2007-01-26 09:35:03: INFO: purging ISAKMP-SA spi=bb009b00744e7f86:d20de3713e1aea22.
2007-01-26 09:35:03: DEBUG: call pfkey_send_dump
2007-01-26 09:35:03: INFO: purged ISAKMP-SA spi=bb009b00744e7f86:d20de3713e1aea22.
2007-01-26 09:35:03: DEBUG: purged SAs.
2007-01-26 09:35:04: INFO: ISAKMP-SA deleted 30.0.0.104[500]-30.0.0.101[500] spi:bb009b00744e7f86:d20de3713e1aea22

<--End log-->

Some version information:
2007-01-26 10:51:12: INFO: @(#)ipsec-tools 0.6.6 (http://ipsec-tools.sourceforge.net)
2007-01-26 10:51:12: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/)

Note that there are other side effects to this as well, such as the inability to process delete notifications that have multiple sets of cookies in the SPI field, which is allowed by RFC 2408.

Discussion

  • Logged In: NO

    Hi.

    Please try the following patch, I'll commit it on HEAD / 0.7 if it solves your problem:

    Index: src/racoon/isakmp_inf.c

    RCS file: /cvsroot/src/crypto/dist/ipsec-tools/src/racoon/isakmp_inf.c,v
    retrieving revision 1.14
    diff -b -u -p -r1.14 isakmp_inf.c
    --- src/racoon/isakmp_inf.c 9 Dec 2006 05:52:57 -0000 1.14
    +++ src/racoon/isakmp_inf.c 30 Jan 2007 08:38:47 -0000
    @@ -462,6 +462,7 @@ isakmp_info_recv_d(iph1, delete, msgid,
    int tlen, num_spi;
    vchar_t *pbuf;
    int protected = 0;
    + struct ph1handle *del_ph1;
    struct ph2handle *iph2;
    union {
    u_int32_t spi32;
    @@ -514,12 +515,17 @@ isakmp_info_recv_d(iph1, delete, msgid,
    delete->spi_size, delete->proto_id);
    return 0;
    }
    - EVT_PUSH(iph1->local, iph1->remote,
    +
    + del_ph1=getph1byindex((isakmp_index *)(delete + 1));
    + if(del_ph1 != NULL){
    +
    + EVT_PUSH(del_ph1->local, del_ph1->remote,
    EVTT_PEERPH1_NOPROP, NULL);
    - if (iph1->scr)
    - SCHED_KILL(iph1->scr);
    + if (del_ph1->scr)
    + SCHED_KILL(del_ph1->scr);

    - purge_remote(iph1);
    + purge_remote(del_ph1);
    + }
    break;

    case IPSECDOI_PROTO_IPSEC_AH:

    Yvan.

     
  • Uncle Pedro
    Uncle Pedro
    2007-01-31

    Logged In: YES
    user_id=1702317
    Originator: YES

    Yvan,

    Thanks for the patch.
    I tried it today and it worked.

    Should I close this bug, or do you need to close it when you commit the patch?

    Thanks again!
    unclepedro

     
  • Logged In: NO

    Do NOT close the bug now, as the actual patch does not solve the whole problem: it will "only" process the first SA to be deleted if the DELETE_SA contains more than one Isakmp-SA.

    I guess such message won't be generated in the real life, but it would still be cleaner to correctly process it.

    I just commited the actual patch to HEAD / 0.7, as it is still better than the actual code (which just deletes the PH1 used to generate the DELETE_SA).

    Yvan.

     
  • Uncle Pedro
    Uncle Pedro
    2007-02-01

    Logged In: YES
    user_id=1702317
    Originator: YES

    Yvan,

    Alright -- I'll leave it open.
    Thank you again for the patch!

    unclepedro

     
  • Timo Teras
    Timo Teras
    2009-01-16

    Closing all sourceforge.net bugs. If this issue has not been cared for please submit a new bug report to https://trac.ipsec-tools.net/ issue tracker. Thank you.

     
  • Timo Teras
    Timo Teras
    2009-01-16

    • status: open --> closed