1 Abstract

  isakmpd's, OpenBSD's IKE daemon's, payload handling, especially the
  handling of delete payloads, contains numerous more or less severe
  flaws, which allow for unauthorized deletion of IKE and IPsec SAs.

2 Description

  2.1
  
    isakmpd does not require encryption for messages in Quick Mode,
    although RFC 2409, section 5.5 says:
    
      The information exchanged along with Quick Mode MUST be protected
      by the ISAKMP SA-- i.e. all payloads except the ISAKMP header are
      encrypted.

    This also applies to the last two (one for each, initiator and
    responder) messages of Main mode, informational exchanges, ... See
    RFC 2408, section 4.5 and RFC 2409, sections 5.1 to 5.4 and 5.7

  2.2
 
    When acting as responder in Quick Mode exchanges, isakmpd does not
    apply payload encryption as long as the initiator itself also does
    not apply payload encryption, because isakmpd relies on the
    following lines of code in message_recv() in message.c:
    
      if (flags & ISAKMP_FLAGS_ENC)                       
          msg->exchange->flags |= EXCHANGE_FLAG_ENCRYPT;

    Main Mode is not affected as isakmpd sets the encryption flag
    explicit in {initiator,resonder}_send_ID_AUTH in ike_main_mode.c

  2.3

    isakmpd does only require hash payloads (which contain (H)MACs
    indeed) for messages directly relating to Quick Mode exchanges.
    "Phase 2" messages containing delete payloads ("delete messages"), 
    for example, do not need to include a hash payload to be accepted by
    isakmpd, albeit RFC 2409, section 5.7 requires these "delete
    messages" to include a hash payload. This also applies to notify
    messages of type status in phase 2, although RFC 2407, section 4.6.3
    prescribes their protection:

      Notification Status Messages MUST be sent under the protection of
      an ISAKMP SA: [..] 

      Nota Bene: a Notify payload is fully protected only in Quick Mode,
      where the entire payload is included in the HASH(n) digest.

    See responder_recv_*() in ike_quick_mode.c and RFC 2409 for details.

    Also if isakmpd receives "unexpected" hash payloads it does not
    verify them :-/.

  2.4
  
    When isakmpd receives a "delete message" in phase 2 ("delete
    messages" in phase 1 are ignored, see isakmpd_responder() in
    isakmp_doi.c) it does not check whether the origin of the "delete
    message" is the "owner" of the SA(s) to be deleted or in any other
    way authorized to delete the referenced SA(s).  See
    ipsec_handle_leftover_payload() in ipsec.c for further details

    By the way: This behavior does NOT violate the RFCs, it is just a
    example of a bad local security policy. See RFC 2408, section 5.15.

  2.5

    For compatibility with some Cisco IPsec implementations isakmpd
    accepts phase 2 "delete messages" for ISAKMP SAs. See
    ipsec_delete_spi_list() in ipsec.c.

    This might not be a security issue or even a bug depending on your
    point of view, but it can be leveraged together with the other
    issues.

  Note: It is not required to take any action upon receipt of a "delete
  messages", but most IKE daemons do react by deleting the SA and so
  does isakmpd. RFC 2408, section 3.15:

    NOTE: The Delete Payload is not a request for the responder to
    delete an SA, but an advisory from the initiator to the responder.

3 Affected Systems

  On 2003/09/02 2.1 and as a side effect 2.2 was fixed, i.e. isakmpd
  versions prior to 2003/09/02 include all issues listed above, newer
  versions "only" include the issues 2.{3,4,5}

  As isakmpd runs on a wide variety of platforms ({Open,Free,Net}BSD,
  MacOS X, Linux with FreeS/WAN's KLIPS, Linux 2.6) and is used in some
  appliances there might be some systems endangered due to these
  issues.

  Other IKE daemons are known to have similar issues, but AFAIK they
  cannot be leveraged to launch effective attacks.
  
4 Leveraging the Issues

  There are many ways to "take advantage" of the issues described above.
  IMO the most severe thing to do is unauthorized IKE and/or IPsec SA
  deletion, because it is relatively easy to launch and has serious
  effects.

  4.1 pre 2003/09/02

    To delete an ISAKMP SA of your choice you only need to know the
    ISAKMP cookies and do some IP spoofing. If you want to delete an
    IPsec SA you need to know its SPI and whether it is for ESP or AH.
    http://thinknerd.de/~thomas/IPsec/delete-sa.c gives a clue how a
    "delete message" should look like.

  4.2 post 2003/09/02

    As of 2003/09/02 it is much harder to exploit the issues, because
    you need to send an encrypted "delete message". Therefore you need
    an ISAKMP SA with your victim. If you are a legitimate user or the
    like, you can try http://thinknerd.de/~thomas/IPsec/isakmpd+.diff on
    Linux 2.6.

5. Bugfixes

  2.1 and 2.2 were fixed about 3 weeks after I have had reported the
  issues (see http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/
  message.c.diff?r1=1.60&r2=1.61&f=h). 2.{3,4,5} are still unfixed, but
  there are a few (OpenBSD) developers claiming to be working on this
  issue (for nearly 3 months). I hope that is not what they call
  "proactive security" ;-).

  As a temporary solution one could disable the reaction upon receipt of
  a "delete message".

Thomas Walpuski